- Dec 17, 2017
-
-
Enric Balletbo i Serra authored
Add the usb3 phyter for the USB3.0 OTG controller. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Enric Balletbo i Serra authored
After commit '06c47e62 usb: dwc3: of-simple: Add support to get resets for the device' you can add the reset property to the dwc3 node, the reset is required for the controller to work properly, otherwise bind / unbind stress testing of the USB controller on rk3399 we'd often end up with lots of failures that looked like this: phy phy-ff800000.phy.9: phy poweron failed --> -110 dwc3 fe900000.dwc3: failed to initialize core dwc3: probe of fe900000.dwc3 failed with error -110 Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Enric Balletbo i Serra authored
The aclk_usb3 must be enabled to support USB3 for rk3399. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Enric Balletbo i Serra authored
Add the usb3 power-domain, its qos area and assign it to the usb device node. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Dec 05, 2017
-
-
Jeffy Chen authored
Add edp panel and enable related nodes on kevin. Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by:
Mark Yao <mark.yao@rock-chips.com> Tested-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Dec 04, 2017
-
-
Nickey Yang authored
We might include additional ports in derivative device trees, so the 'port' node should have an address, and the parent 'ports' node needs /#{addres,size}-cells. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Nickey Yang authored
This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Brian Norris authored
We've documented this one already, but we didn't add it to the DTSI yet. Suggested-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Nov 17, 2017
-
-
Masahiro Yamada authored
Commit 429f203e ("arm64: dts: uniphier: route on-board device IRQ to GPIO controller") missed to update this DTS. It becames a real problem when arm and arm64 trees are merged together. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
- Nov 16, 2017
-
-
Will Deacon authored
The kasan shadow is currently mapped using vmemmap_populate() since that provides a semi-convenient way to map pages into init_top_pgt. However, since that no longer zeroes the mapped pages, it is not suitable for kasan, which requires zeroed shadow memory. Add kasan_populate_shadow() interface and use it instead of vmemmap_populate(). Besides, this allows us to take advantage of gigantic pages and use them to populate the shadow, which should save us some memory wasted on page tables and reduce TLB pressure. Link: http://lkml.kernel.org/r/20171103185147.2688-3-pasha.tatashin@oracle.com Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Pavel Tatashin <pasha.tatashin@oracle.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Steven Sistare <steven.sistare@oracle.com> Cc: Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Bob Picco <bob.picco@oracle.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Alexander Potapenko <glider@google.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David S. Miller <davem@davemloft.net> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Michal Hocko <mhocko@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Levin, Alexander (Sasha Levin) authored
Convert all allocations that used a NOTRACK flag to stop using it. Link: http://lkml.kernel.org/r/20171007030159.22241-3-alexander.levin@verizon.com Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Cc: Alexander Potapenko <glider@google.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Pekka Enberg <penberg@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Tim Hansen <devtimhansen@gmail.com> Cc: Vegard Nossum <vegardno@ifi.uio.no> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Nov 15, 2017
-
-
Jeff Layton authored
Currently, we're capping the values too low in the F_GETLK64 case. The fields in that structure are 64-bit values, so we shouldn't need to do any sort of fixup there. Make sure we check that assumption at build time in the future however by ensuring that the sizes we're copying will fit. With this, we no longer need COMPAT_LOFF_T_MAX either, so remove it. Fixes: 94073ad7 (fs/locks: don't mess with the address limit in compat_fcntl64) Reported-by:
Vitaly Lipatov <lav@etersoft.ru> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Reviewed-by:
David Howells <dhowells@redhat.com>
-
- Nov 14, 2017
-
-
Dave Martin authored
If CONFIG_SYSCTL=n and CONFIG_ARMV8_DEPRECATED=y, the deprecated instruction emulation code currently leaks some memory at boot time, and won't have any runtime control interface. This does not feel like useful or intended behaviour... This patch adds a dependency on CONFIG_SYSCTL, so that such a kernel can't be built in the first place. It's probably not worth adding the error-handling / cleanup code that would be needed to deal with this otherwise: people who desperately need the emulation can still enable SYSCTL. Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Jason A. Donenfeld authored
Commit fb872273 ("arm64: support __int128 on gcc 5+") added support for the __int128 data type, but this breaks the build in some configurations where GCC ends up emitting calls to the __lshrti3 helper in libgcc, which results in a link error: kernel/sched/fair.o: In function `__calc_delta': fair.c:(.text+0xca0): undefined reference to `__lshrti3' kernel/time/timekeeping.o: In function `timekeeping_resume': timekeeping.c:(.text+0x3f60): undefined reference to `__lshrti3' make: *** [vmlinux] Error 1 Fix the build by providing an implementation of __lshrti3, like we do already for __ashlti3 and __ashrti3. Reported-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
- Nov 10, 2017
-
-
Marc Zyngier authored
In order to control the GICv4 view of virtual CPUs, we rely on an irqdomain allocated for that purpose. Let's add a couple of helpers to that effect. At the same time, the vgic data structures gain new fields to track all this... erm... wonderful stuff. The way we hook into the vgic init is slightly convoluted. We need the vgic to be initialized (in order to guarantee that the number of vcpus is now fixed), and we must have a vITS (otherwise this is all very pointless). So we end-up calling the init from both vgic_init and vgic_its_create. Reviewed-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org>
-
Masahiro Yamada authored
If CONFIG_OF_ALL_DTBS is enabled, "make ARCH=arm64 dtbs" compiles each DTB twice; one from arch/arm64/boot/dts/*/Makefile and the other from the dtb-$(CONFIG_OF_ALL_DTBS) line in arch/arm64/boot/dts/Makefile. It could be a race problem when building DTBS in parallel. Another minor issue is CONFIG_OF_ALL_DTBS covers only *.dts in vendor sub-directories, so this broke when Broadcom added one more hierarchy in arch/arm64/boot/dts/broadcom/<soc>/. One idea to fix the issues in a clean way is to move DTB handling to Kbuild core scripts. Makefile.dtbinst already recognizes dtb-y natively, so it should not hurt to do so. Add $(dtb-y) to extra-y, and $(dtb-) as well if CONFIG_OF_ALL_DTBS is enabled. All clutter things in Makefiles go away. As a bonus clean-up, I also removed dts-dirs. Just use subdir-y directly to traverse sub-directories. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> [robh: corrected BUILTIN_DTB to CONFIG_BUILTIN_DTB] Signed-off-by:
Rob Herring <robh@kernel.org>
-
- Nov 09, 2017
-
-
Masahiro Yamada authored
We need to add "clean-files" in Makfiles to clean up DT blobs, but we often miss to do so. Since there are no source files that end with .dtb or .dtb.S, so we can clean-up those files from the top-level Makefile. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Rob Herring <robh@kernel.org>
-
Masahiro Yamada authored
Most of DT files are compiled under arch/*/boot/dts/, but we have some other directories, like drivers/of/unittest-data/. We often miss to add gitignore patterns per directory. Since there are no source files that end with .dtb or .dtb.S, we can ignore the patterns globally. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Rob Herring <robh@kernel.org>
-
- Nov 07, 2017
-
-
Ard Biesheuvel authored
The Socionext Synquacer SoC has an external interrupt unit (EXIU) that forwards a block of 32 configurable input lines to 32 adjacent level-high type GICv3 SPIs. The EXIU has per-interrupt level/edge and polarity controls, and mask bits that keep the outgoing lines de-asserted, even though the controller may still latch interrupt conditions that occur while the line is masked. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
James Morse authored
Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on __set_fixmap() to do the invalidation. Remove it. Move the IPI-considered-harmful comment to __set_fixmap(). Signed-off-by:
James Morse <james.morse@arm.com> Acked-by:
Will Deacon <will.deacon@arm.com> Tested-by:
Tyler Baicar <tbaicar@codeaurora.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: All applicable <stable@vger.kernel.org>
-
James Morse authored
Replace ghes_io{re,un}map_pfn_{nmi,irq}()s use of ioremap_page_range() with __set_fixmap() as ioremap_page_range() may sleep to allocate a new level of page-table, even if its passed an existing final-address to use in the mapping. The GHES driver can only be enabled for architectures that select HAVE_ACPI_APEI: Add fixmap entries to both x86 and arm64. clear_fixmap() does the TLB invalidation in __set_fixmap() for arm64 and __set_pte_vaddr() for x86. In each case its the same as the respective arch_apei_flush_tlb_one(). Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
James Morse <james.morse@arm.com> Reviewed-by:
Borislav Petkov <bp@suse.de> Tested-by:
Tyler Baicar <tbaicar@codeaurora.org> Tested-by:
Toshi Kani <toshi.kani@hpe.com> [ For the arm64 bits: ] Acked-by:
Will Deacon <will.deacon@arm.com> [ For the x86 bits: ] Acked-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: All applicable <stable@vger.kernel.org>
-
Eric Auger authored
This patch selects IRQ_BYPASS_MANAGER and HAVE_KVM_IRQ_BYPASS configs for ARM/ARM64. kvm_arch_has_irq_bypass() now is implemented and returns true. As a consequence the irq bypass consumer will be registered for ARM/ARM64 with the forwarding callbacks: - stop/start: halt/resume guest execution - add/del_producer: set/unset forwarding at vgic/irqchip level We don't have any actual support yet, so nothing gets actually forwarded. Acked-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Eric Auger <eric.auger@redhat.com> [maz: dropped the DEOI stuff for the time being in order to reduce the dependency chain, amended commit message] Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org>
-
- Nov 06, 2017
-
-
Dongjiu Geng authored
kvm_vcpu_dabt_isextabt() tries to match a full fault syndrome, but calls kvm_vcpu_trap_get_fault_type() that only returns the fault class, thus reducing the scope of the check. This doesn't cause any observable bug yet as we end-up matching a closely related syndrome for which we return the same value. Using kvm_vcpu_trap_get_fault() instead fixes it for good. Signed-off-by:
Dongjiu Geng <gengdongjiu@huawei.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org>
-
Marc Zyngier authored
Both arm and arm64 implementations are capable of injecting faults, and yet have completely divergent implementations, leading to different bugs and reduced maintainability. Let's elect the arm64 version as the canonical one and move it into aarch32.c, which is common to both architectures. Reviewed-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org>
-
Eric Auger authored
On reset we clear the valid bits of GITS_CBASER and GITS_BASER<n>. We also clear command queue registers and free the cache (device, collection, and lpi lists). As we need to take the same locks as save/restore functions, we create a vgic_its_ctrl() wrapper that handles KVM_DEV_ARM_VGIC_GRP_CTRL group functions. Reviewed-by:
Christoffer Dall <christoffer.dall@linaro.org> Reviewed-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org>
-
Christoffer Dall authored
When trapping on a guest access to one of the timer registers, we were messing with the internals of the timer state from the sysregs handling code, and that logic was about to receive more added complexity when optimizing the timer handling code. Therefore, since we already have timer register access functions (to access registers from userspace), reuse those for the timer register traps from a VM and let the timer code maintain its own consistency. Signed-off-by:
Christoffer Dall <cdall@linaro.org> Acked-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Christoffer Dall authored
Add suport for the physical timer registers in kvm_arm_timer_set_reg and kvm_arm_timer_get_reg so that these functions can be reused to interact with the rest of the system. Note that this paves part of the way for the physical timer state save/restore, but we still need to add those registers to KVM_GET_REG_LIST before we support migrating the physical timer state. Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <cdall@linaro.org>
-
Christoffer Dall authored
As we are about to be lazy with saving and restoring the timer registers, we prepare by moving all possible timer configuration logic out of the hyp code. All virtual timer registers can be programmed from EL1 and since the arch timer is always a level triggered interrupt we can safely do this with interrupts disabled in the host kernel on the way to the guest without taking vtimer interrupts in the host kernel (yet). The downside is that the cntvoff register can only be programmed from hyp mode, so we jump into hyp mode and back to program it. This is also safe, because the host kernel doesn't use the virtual timer in the KVM code. It may add a little performance performance penalty, but only until following commits where we move this operation to vcpu load/put. Signed-off-by:
Christoffer Dall <cdall@linaro.org> Reviewed-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Christoffer Dall authored
Using the physical counter allows KVM to retain the offset between the virtual and physical counter as long as it is actively running a VCPU. As soon as a VCPU is released, another thread is scheduled or we start running userspace applications, we reset the offset to 0, so that userspace accessing the virtual timer can still read the virtual counter and get the same view of time as the kernel. This opens up potential improvements for KVM performance, but we have to make a few adjustments to preserve system consistency. Currently get_cycles() is hardwired to arch_counter_get_cntvct() on arm64, but as we move to using the physical timer for the in-kernel time-keeping on systems that boot in EL2, we should use the same counter for get_cycles() as for other in-kernel timekeeping operations. Similarly, implementations of arch_timer_set_next_event_phys() is modified to use the counter specific to the timer being programmed. VHE kernels or kernels continuing to use the virtual timer are unaffected. Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <cdall@linaro.org>
-
Christoffer Dall authored
As we are about to use the physical counter on arm64 systems that have KVM support, implement arch_counter_get_cntpct() and the associated errata workaround functionality for stable timer reads. Cc: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org>
-
- Nov 04, 2017
-
-
Andreas Färber authored
Give the serial driver a fixed-clock as input for baudrate 115200. Signed-off-by:
Andreas Färber <afaerber@suse.de>
-
- Nov 03, 2017
-
-
Jason A. Donenfeld authored
Versions of gcc prior to gcc 5 emitted a __multi3 function call when dealing with TI types, resulting in failures when trying to link to libgcc, and more generally, bad performance. However, since gcc 5, the compiler supports actually emitting fast instructions, which means we can at long last enable this option and receive the speedups. The gcc commit that added proper Aarch64 support is: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d1ae7bb994f49316f6f63e6173f2931e837a351d This commit appears to be part of the gcc 5 release. There are still a few instructions, __ashlti3 and __ashrti3, which require libgcc, which is fine. Rather than linking to libgcc, we simply provide them ourselves, since they're not that complicated. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Dave Martin authored
This patch adds basic documentation of the user/kernel interface provided by the for SVE. Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Alan Hayward <alan.hayward@arm.com> Cc: Alex Bennée <alex.bennee@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Szabolcs Nagy <szabolcs.nagy@arm.com> Cc: linux-api@vger.kernel.org Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Dave Martin authored
This patch enables detection of hardware SVE support via the cpufeatures framework, and reports its presence to the kernel and userspace via the new ARM64_SVE cpucap and HWCAP_SVE hwcap respectively. Userspace can also detect SVE using ID_AA64PFR0_EL1, using the cpufeatures MRS emulation. When running on hardware that supports SVE, this enables runtime kernel support for SVE, and allows user tasks to execute SVE instructions and make of the of the SVE-specific user/kernel interface extensions implemented by this series. Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Dave Martin authored
KVM guests cannot currently use SVE, because SVE is always configured to trap to EL2. However, a guest that sees SVE reported as present in ID_AA64PFR0_EL1 may legitimately expect that SVE works and try to use it. Instead of working, the guest will receive an injected undef exception, which may cause the guest to oops or go into a spin. To avoid misleading the guest into believing that SVE will work, this patch masks out the SVE field from ID_AA64PFR0_EL1 when a guest attempts to read this register. No support is explicitly added for ID_AA64ZFR0_EL1 either, so that is still emulated as reading as zero, which is consistent with SVE not being implemented. This is a temporary measure, and will be removed in a later series when full KVM support for SVE is implemented. Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Dave Martin authored
When trapping forbidden attempts by a guest to use SVE, we want the guest to see a trap consistent with SVE not being implemented. This patch injects an undefined instruction exception into the guest in response to such an exception. Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Dave Martin authored
Until KVM has full SVE support, guests must not be allowed to execute SVE instructions. This patch enables the necessary traps, and also ensures that the traps are disabled again on exit from the guest so that the host can still use SVE if it wants to. On guest exit, high bits of the SVE Zn registers may have been clobbered as a side-effect the execution of FPSIMD instructions in the guest. The existing KVM host FPSIMD restore code is not sufficient to restore these bits, so this patch explicitly marks the CPU as not containing cached vector state for any task, thus forcing a reload on the next return to userspace. This is an interim measure, in advance of adding full SVE awareness to KVM. This marking of cached vector state in the CPU as invalid is done using __this_cpu_write(fpsimd_last_state, NULL) in fpsimd.c. Due to the repeated use of this rather obscure operation, it makes sense to factor it out as a separate helper with a clearer name. This patch factors it out as fpsimd_flush_cpu_state(), and ports all callers to use it. As a side effect of this refactoring, a this_cpu_write() in fpsimd_cpu_pm_notifier() is changed to __this_cpu_write(). This should be fine, since cpu_pm_enter() is supposed to be called only with interrupts disabled. Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Christoffer Dall <christoffer.dall@linaro.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Dave Martin authored
Because of the effect of SVE on the size of the signal frame, the default vector length used for new processes involves a tradeoff between performance of SVE-enabled software on the one hand, and reliability of non-SVE-aware software on the other hand. For this reason, the best choice depends on the repertoire of userspace software in use and is thus best left up to distro maintainers, sysadmins and developers. If CONFIG_SYSCTL and CONFIG_PROC_SYSCTL are enabled, this patch exposes the default vector length in /proc/sys/abi/sve_default_vector_length, where boot scripts or the adventurous can poke it. In common with other arm64 ABI sysctls, this control is currently global: setting it requires CAP_SYS_ADMIN in the root user namespace, but the value set is effective for subsequent execs in all namespaces. The control only affects _new_ processes, however: changing it does not affect the vector length of any existing process. The intended usage model is that if userspace is known to be fully SVE-tolerant (or a developer is curious to find out) then this parameter can be cranked up during system startup. Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Dave Martin authored
This patch adds two arm64-specific prctls, to permit userspace to control its vector length: * PR_SVE_SET_VL: set the thread's SVE vector length and vector length inheritance mode. * PR_SVE_GET_VL: get the same information. Although these prctls resemble instruction set features in the SVE architecture, they provide additional control: the vector length inheritance mode is Linux-specific and nothing to do with the architecture, and the architecture does not permit EL0 to set its own vector length directly. Both can be used in portable tools without requiring the use of SVE instructions. Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Alex Bennée <alex.bennee@linaro.org> [will: Fixed up prctl constants to avoid clash with PDEATHSIG] Signed-off-by:
Will Deacon <will.deacon@arm.com>
-
Dave Martin authored
This patch defines and implements a new regset NT_ARM_SVE, which describes a thread's SVE register state. This allows a debugger to manipulate the SVE state, as well as being included in ELF coredumps for post-mortem debugging. Because the regset size and layout are dependent on the thread's current vector length, it is not possible to define a C struct to describe the regset contents as is done for existing regsets. Instead, and for the same reasons, NT_ARM_SVE is based on the freeform variable-layout approach used for the SVE signal frame. Additionally, to reduce debug overhead when debugging threads that might or might not have live SVE register state, NT_ARM_SVE may be presented in one of two different formats: the old struct user_fpsimd_state format is embedded for describing the state of a thread with no live SVE state, whereas a new variable-layout structure is embedded for describing live SVE state. This avoids a debugger needing to poll NT_PRFPREG in addition to NT_ARM_SVE, and allows existing userspace code to handle the non-SVE case without too much modification. For this to work, NT_ARM_SVE is defined with a fixed-format header of type struct user_sve_header, which the recipient can use to figure out the content, size and layout of the reset of the regset. Accessor macros are defined to allow the vector-length-dependent parts of the regset to be manipulated. Signed-off-by:
Alan Hayward <alan.hayward@arm.com> Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: Alex Bennée <alex.bennee@linaro.org> Cc: Okamoto Takayuki <tokamoto@jp.fujitsu.com> Signed-off-by:
Will Deacon <will.deacon@arm.com>
-