summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2019-04-12ARM: dts: am335x: chilisom: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: chiliboard: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: bonegreen-common: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: boneblue: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: bonegreen-wireless: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: base0033: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: baltos: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: baltos-leds: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: baltos-ir5221: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: baltos-ir3220: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: baltos-ir2110: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12Merge tag 'dma-mapping-5.1-1' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds
Pull dma-mapping fixes from Christoph Hellwig: "Fix a sparc64 sun4v_pci regression introduced in this merged window, and a dma-debug stracktrace regression from the big refactor last merge window" * tag 'dma-mapping-5.1-1' of git://git.infradead.org/users/hch/dma-mapping: dma-debug: only skip one stackframe entry sparc64/pci_sun4v: fix ATU checks for large DMA masks
2019-04-12arm64: tegra: Enable command queue for Tegra186 SDMMC4Sowjanya Komatineni
The workaround for a hardware bug preventing this from working has been merged now, so command queue support can be enabled again for Tegra186. Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12arm64: tegra: Fix default tap and trim valuesSowjanya Komatineni
Default tap and trim values are incorrect for Tegra186 SDMMC4. This patch fixes them. Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12arm64: tegra: Add supply for temperature sensor on P2888Jon Hunter
The VCC supply property is not populated for the temperature sensor on the P2888 board and so the following warning is observed on boot ... lm90 0-004c: 0-004c supply vcc not found, using dummy regulator On the P2888 board, the VCC supply for the temperature sensor is connected to the 'vdd_1v8ls' rail. Add the 'vcc-supply' property for the temperature sensor to prevent this warning message from occurring. Fixes: 8b457812f54b ('arm64: tegra: Add temperature sensor on P2888') Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12arm64: tegra: Enable aconnect, ADMA and AGIC on Jetson TX1Sameer Pujar
These are currently mostly unused because we lack a proper audio driver on Tegra210. However, enabling them makes sure that at least their probe code paths are tested at runtime. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12arm64: tegra: Add L2 cache topology to Tegra210Joseph Lo
Add L2 cache and make it the next level of cache for each of the CPUs. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12arm64: tegra: Enable CPU idle support for ShieldJoseph Lo
Enable CPU idle support for Shield platform. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12arm64: tegra: Enable CPU idle support for SmaugJoseph Lo
Enable CPU idle support for Smaug platform. Signed-off-by: Joseph Lo <josephl@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12arm64: tegra: Enable CPU idle support for Jetson TX1Joseph Lo
Enable CPU idle support for Jetson TX1 platform. Signed-off-by: Joseph Lo <josephl@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12arm64: tegra: Add CPU idle states properties for Tegra210Joseph Lo
Add idle states properties for generic ARM CPU idle driver. This includes a cpu-sleep state which is the power down state of CPU cores. Signed-off-by: Joseph Lo <josephl@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12arm64: tegra: Fix timer node for Tegra210Joseph Lo
Fix timer node to make it work with Tegra210 timer driver. Signed-off-by: Joseph Lo <josephl@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-04-12ARM: davinci: da830-evm: add a fixed regulator for ohci-da8xxBartosz Golaszewski
Instead of directly using the vbus GPIO we should model it as a fixed regulator. Add all necessary fix-ups for the regulator to be registered and configure the vbus GPIO as its enable pin. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-04-12ARM: davinci: omapl138-hawk: add a fixed regulator for ohci-da8xxBartosz Golaszewski
Instead of directly using the vbus GPIO we should model it as a fixed regulator. Add all necessary fix-ups for the regulator to be registered and configure the vbus GPIO as its enable pin. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-04-12ARM: davinci: add missing sentinels to GPIO lookup tablesBartosz Golaszewski
Some GPIO lookup tables defined in davinci board files are missing array sentinels. If an entry for given device cannot be found, this will cause a kernel panic. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-04-12arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result valueWill Deacon
Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't explicitly set the return value on the non-faulting path and instead leaves it holding the result of the underlying atomic operation. This means that any FUTEX_WAKE_OP atomic operation which computes a non-zero value will be reported as having failed. Regrettably, I wrote the buggy code back in 2011 and it was upstreamed as part of the initial arm64 support in 2012. The reasons we appear to get away with this are: 1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get exercised by futex() test applications 2. If the result of the atomic operation is zero, the system call behaves correctly 3. Prior to version 2.25, the only operation used by GLIBC set the futex to zero, and therefore worked as expected. From 2.25 onwards, FUTEX_WAKE_OP is not used by GLIBC at all. Fix the implementation by ensuring that the return value is either 0 to indicate that the atomic operation completed successfully, or -EFAULT if we encountered a fault when accessing the user mapping. Cc: <stable@kernel.org> Fixes: 6170a97460db ("arm64: Atomic operations") Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-12x86/fpu: Merge the two code paths in __fpu__restore_sig()Sebastian Andrzej Siewior
The ia32_fxstate case (32bit with fxsr) and the other (64bit frames or 32bit frames without fxsr) restore both from kernel memory and sanitize the content. The !ia32_fxstate version restores missing xstates from "init state" while the ia32_fxstate doesn't and skips it. Merge the two code paths and keep the !ia32_fxstate one. Copy only the user_i387_ia32_struct data structure in the ia32_fxstate. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-23-bigeasy@linutronix.de
2019-04-12x86/fpu: Restore from kernel memory on the 64-bit path tooSebastian Andrzej Siewior
The 64-bit case (both 64-bit and 32-bit frames) loads the new state from user memory. However, doing this is not desired if the FPU state is going to be restored on return to userland: it would be required to disable preemption in order to avoid a context switch which would set TIF_NEED_FPU_LOAD. If this happens before the restore operation then the loaded registers would become volatile. Furthermore, disabling preemption while accessing user memory requires to disable the pagefault handler. An error during FXRSTOR would then mean that either a page fault occurred (and it would have to be retried with enabled page fault handler) or a #GP occurred because the xstate is bogus (after all, the signal handler can modify it). In order to avoid that mess, copy the FPU state from userland, validate it and then load it. The copy_kernel_…() helpers are basically just like the old helpers except that they operate on kernel memory and the fault handler just sets the error value and the caller handles it. copy_user_to_fpregs_zeroing() and its helpers remain and will be used later for a fastpath optimisation. [ bp: Clarify commit message. ] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Aubrey Li <aubrey.li@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-22-bigeasy@linutronix.de
2019-04-12ARM: dts: iwg23s-sbc: Enable HS-USBBiju Das
Enable HS-USB device for the iWave SBC based on RZ/G1C. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: dts: r8a77470: Add HSUSB device nodesBiju Das
Define the r8a77470 generic part of the HSUSB0/1 device nodes. Currently the renesas_usbhs driver doesn't handle multiple phys and we don't have a proper hardware to validate such driver changes. So for hsusb1 it is assumed that usbphy0 will be enabled by either channel0 host or device. In future, if any boards support hsusb1, we will need to add multiple phy support in the renesas_usbhs driver and override the board dts to enable the same. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: dts: iwg23s-sbc: Enable USB USB2.0 HostBiju Das
Enable USB2.0 host on the iwg23s sbc. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: dts: r8a77470: Add USB2.0 Host (EHCI/OHCI) deviceBiju Das
Define the r8a77470 generic part of the USB2.0 Host Controller device nodes (ehci[01]/ohci[01]). Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: dts: iwg23s-sbc: Enable USB Phy[01]Biju Das
Enable USB phy[01] on iWave iwg23s sbc based on RZ/G1C SoC. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: dts: r8a77470: Add USB PHY DT supportBiju Das
Define the r8a77470 generic part of the USB PHY device node. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: shmobile: Enable USB [EO]HCI HCD PLATFORM support in shmobile_defconfigBiju Das
The USB [EO]HCI controller on RZ/G1C SoC doesn't have PCI bridge like other R-Car Gen2 devices. So enable generic USB [EO]HCI HCD PLATFORM support in shmobile_defconfig. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: shmobile: Enable PHY_RCAR_GEN3_USB2 in shmobile_defconfigBiju Das
Enable PHY_RCAR_GEN3_USB2 in shmobile_defconfig so that boards based on RZ/G1C SoC design can use the corresponding driver. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: dts: r8a77470: Add VIN supportCao Van Dong
Add vin{0|1} nodes to dtsi for VIN support on the RZ/G1C (r8a77470) SoC. Signed-off-by: Cao Van Dong <cv-dong@jinso.co.jp> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: dts: r8a77470: Add PWM supportCao Van Dong
Add pwm{0|1|2|3|4|5|6} nodes to dtsi for PWM support on the RZ/G1C (r8a77470) SoC. Signed-off-by: Cao Van Dong <cv-dong@jinso.co.jp> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: dts: r8a77470: Add HSCIF supportCao Van Dong
Add hscif{0|1|2} nodes to dtsi for HSCIF support on the RZ/G1C (r8a77470) SoC. Signed-off-by: Cao Van Dong <cv-dong@jinso.co.jp> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-12ARM: dts: rockchip: Add DDR retention/poweroff to rk3288-veyron hogsDouglas Anderson
Even though upstream Linux doesn't yet go into deep enough suspend to get DDR into self refresh, there is no harm in setting these pins up. They'll only actually do something if we go into a deeper suspend but leaving them configed always is fine. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-12ARM: rockchip: Mark pm-init functions __initDouglas Anderson
The functions rk3288_config_bootdata() and rk3288_suspend_init() are only called in the context of rockchip_suspend_init() which is already marked __init. We can mark them __init too. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-12ARM: dts: rockchip: Add dynamic-power-coefficient for rk3288Matthias Kaehlcke
The value was determined with the following method: - take CPUs 1-3 offline - for each OPP - set cpufreq min and max freq to OPP freq - start dhrystone benchmark - measure CPU power consumption during 10s - calculate Cx for OPPx - Cx = (Px - P1) / (Vx²fx - V1²f1) [1] using the following units: mW / Ghz / V [2] - C = avg(C2, ..., Cn) [1] see commit 4daa001a1773 ("arm64: dts: juno: Add cpu dynamic-power-coefficient information") [2] https://patchwork.kernel.org/patch/10493615/#22158551 FTR, these are the values for the different OPPs: freq (kHz) mV Px (mW) Cx 126000 900 39 216000 900 66 370 312000 900 95 372 408000 900 122 363 600000 900 177 359 696000 950 230 363 816000 1000 297 361 1008000 1050 404 362 1200000 1100 528 362 1416000 1200 770 377 1512000 1300 984 385 1608000 1350 1156 394 Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-12arm64: dts: mt2712: Remove un-used property for PCIeHonghui Zhang
The "num-lanes" property for PCIe is not used, remove it. Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2019-04-11x86/fpu: Inline copy_user_to_fpregs_zeroing()Sebastian Andrzej Siewior
Start refactoring __fpu__restore_sig() by inlining copy_user_to_fpregs_zeroing(). The original function remains and will be used to restore from userland memory if possible. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-21-bigeasy@linutronix.de
2019-04-11x86/fpu: Update xstate's PKRU value on write_pkru()Sebastian Andrzej Siewior
During the context switch the xstate is loaded which also includes the PKRU value. If xstate is restored on return to userland it is required that the PKRU value in xstate is the same as the one in the CPU. Save the PKRU in xstate during modification. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Juergen Gross <jgross@suse.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-20-bigeasy@linutronix.de
2019-04-11arm64: vdso: use $(LD) instead of $(CC) to link VDSOMasahiro Yamada
We use $(LD) to link vmlinux, modules, decompressors, etc. VDSO is the only exceptional case where $(CC) is used as the linker driver, but I do not know why we need to do so. VDSO uses a special linker script, and does not link standard libraries at all. I changed the Makefile to use $(LD) rather than $(CC). I tested this, and VDSO worked for me. Users will be able to use their favorite linker (e.g. lld instead of of bfd) by passing LD= from the command line. My plan is to rewrite all VDSO Makefiles to use $(LD), then delete cc-ldoption. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-11arm64: perf_event: Remove wrongfully used inlineRaphael Gault
The functions armv8pmu_read_counter() and armv8pmu_write_counter() are `static inline` while they are only referenced when assigned to a function pointer field in a `struct arm_pmu` instance. The inline keyword is thus counter intuitive and shouldn't be used. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Raphael Gault <raphael.gault@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-11x86/fpu: Prepare copy_fpstate_to_sigframe() for TIF_NEED_FPU_LOADRik van Riel
The FPU registers need only to be saved if TIF_NEED_FPU_LOAD is not set. Otherwise this has been already done and can be skipped. [ bp: Massage a bit. ] Signed-off-by: Rik van Riel <riel@surriel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-19-bigeasy@linutronix.de
2019-04-11x86/fpu: Always store the registers in copy_fpstate_to_sigframe()Rik van Riel
copy_fpstate_to_sigframe() stores the registers directly to user space. This is okay because the FPU registers are valid and saving them directly avoids saving them into kernel memory and making a copy. However, this cannot be done anymore if the FPU registers are going to be restored on the return to userland. It is possible that the FPU registers will be invalidated in the middle of the save operation and this should be done with disabled preemption / BH. Save the FPU registers to the task's FPU struct and copy them to the user memory later on. Signed-off-by: Rik van Riel <riel@surriel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-18-bigeasy@linutronix.de
2019-04-11x86/entry: Add TIF_NEED_FPU_LOADSebastian Andrzej Siewior
Add TIF_NEED_FPU_LOAD. This flag is used for loading the FPU registers before returning to userland. It must not be set on systems without a FPU. If this flag is cleared, the CPU's FPU registers hold the latest, up-to-date content of the current task's (current()) FPU registers. The in-memory copy (union fpregs_state) is not valid. If this flag is set, then all of CPU's FPU registers may hold a random value (except for PKRU) and it is required to load the content of the FPU registers on return to userland. Introduce it now as a preparatory change before adding the main feature. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Aubrey Li <aubrey.li@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-17-bigeasy@linutronix.de
generated by cgit (git 2.34.1) at 2025-09-23 21:10:45 +0000