aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2020-04-29arm64: dts: meson-g12: remove spurious blank lineNeil Armstrong1-1/+0
Remove spurious blank line introduced in f12a463d2f43 but was not part of the original patch at [1]. [1] http://lore.kernel.org/r/20200313090713.15147-3-narmstrong@baylibre.com Fixes: f12a463d2f43 ("arm64: dts: meson-g12: add the SPIFC nodes") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200420080018.11607-1-narmstrong@baylibre.com
2020-04-29arm64: dts: meson: S922X: extend cpu opp-pointsTim Lewis1-0/+15
Add extra cpu pop points to allow mild overclock on S922X. The opp points are found in Hardkernel N2 sources [1] and testing shows no obvious issues on other S922X devices. Thermal throttling should keep things in-check if needed. [1] https://github.com/hardkernel/linux/commit/f86cd9487c7483b2a05f448b9ebacf6bd5a2ad2f Signed-off-by: Tim Lewis <elatllat@gmail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Tested-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20200426162119.GA23268@imac
2020-04-29arm64: dts: meson-g12b-khadas-vim3: add missing frddr_a status propertyNeil Armstrong1-0/+4
In the process of moving the VIM3 audio nodes to a G12B specific dtsi for enabling the SM1 based VIM3L, the frddr_a status = "okay" property got dropped. This re-enables the frddr_a node to fix audio support. Fixes: 4f26cc1c96c9 ("arm64: dts: khadas-vim3: move common nodes into meson-khadas-vim3.dtsi") Reported-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Tested-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20191018140216.4257-1-narmstrong@baylibre.com
2020-04-29arm64: dts: meson: fix leds subnodes nameNeil Armstrong11-16/+16
Fix the leds subnode names to match (^led-[0-9a-f]$|led) It fixes: meson-g12b-a311d-khadas-vim3.dt.yaml: leds: 'red', 'white' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-g12b-s922x-khadas-vim3.dt.yaml: leds: 'red', 'white' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-g12b-odroid-n2.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-nanopi-k2.dt.yaml: leds: 'stat' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-nexbox-a95x.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-odroidc2.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-vega-s95-pro.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-vega-s95-meta.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-vega-s95-telos.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-wetek-hub.dt.yaml: leds: 'system' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-wetek-play2.dt.yaml: leds: 'ethernet', 'system', 'wifi' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxl-s905x-libretech-cc.dt.yaml: leds: 'blue', 'system' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxl-s905d-libretech-pc.dt.yaml: leds: 'blue', 'green' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxm-rbox-pro.dt.yaml: leds: 'blue', 'red' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxm-s912-libretech-pc.dt.yaml: leds: 'blue', 'green' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-sm1-sei610.dt.yaml: leds: 'bluetooth' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-sm1-khadas-vim3l.dt.yaml: leds: 'red', 'white' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200326165958.19274-6-narmstrong@baylibre.com
2020-04-29arm64: dts: meson-gxbb-kii-pro: fix board compatibleNeil Armstrong1-1/+1
Remove the uneeded "amlogic,p201", "amlogic,s905" in the board compatible list. It fixes: meson-gxbb-kii-pro.dt.yaml: /: compatible: ['videostrong,kii-pro', 'amlogic,p201', 'amlogic,s905', 'amlogic,meson-gxbb'] is not valid under any of the given schemas Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200326165958.19274-5-narmstrong@baylibre.com
2020-04-29arm64: dts: meson-g12b-ugoos-am6: fix board compatibleNeil Armstrong1-1/+1
Add missing amlogic,s922x in the board compatible list. It fixes: meson-g12b-ugoos-am6.dt.yaml: /: compatible: ['ugoos,am6', 'amlogic,g12b'] is not valid under any of the given schemas Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200326165958.19274-4-narmstrong@baylibre.com
2020-04-29arm64: dts: meson: fixup SCP sram nodesNeil Armstrong2-8/+8
The GX and AXG SCP sram nodes were using invalid compatible and node names for the sram entries. Fixup the sram entries node names, and use proper compatible for them. It notably fixes: sram@c8000000: 'scp-shmem@0', 'scp-shmem@200' do not match any of the regexes: '^([a-z]*-)?sram(-section)?@[a-f0-9]+$', 'pinctrl-[0-9]+' Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200326165958.19274-3-narmstrong@baylibre.com
2020-04-29arm64: dts: meson-g12-common: fix dwc2 clock namesNeil Armstrong1-1/+1
Use the correct dwc2 clock name. Fixes: 9baf7d6be730 ("arm64: dts: meson: g12a: Add G12A USB nodes") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20200326160857.11929-3-narmstrong@baylibre.com
2020-04-29arm64: dts: meson-g12b-ugoos-am6: fix usb vbus-supplyNeil Armstrong1-1/+1
The USB supply used the wrong property, fixing: meson-g12b-ugoos-am6.dt.yaml: usb@ffe09000: 'vbus-regulator' does not match any of the regexes: '^usb@[0-9a-f]+$', 'pinctrl-[0-9]+' Fixes: 2cd2310fca4c ("arm64: dts: meson-g12b-ugoos-am6: add initial device-tree") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20200326160857.11929-2-narmstrong@baylibre.com
2020-04-29arm64: dts: amlogic: use the new USB control driver for GXL and GXMMartin Blumenstingl16-31/+68
Add the correcly architectured USB Glue node and adapt all the Amlogic GXL and GXM board to the new organization. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20200326134507.4808-11-narmstrong@baylibre.com
2020-04-29arm64: vdso: use consistent 'map' nomenclatureMark Rutland1-38/+26
The current code doesn't use a consistent naming scheme for structures, enums, or variables, making it harder than necessary to determine the relationship between these. Let's make this easier by consistently using 'map' nomenclature for mappings created in userspace, minimizing redundant comments, and using designated array initializers to tie indices to their respective elements. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200428164921.41641-5-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-29arm64: vdso: use consistent 'abi' nomenclatureMark Rutland1-35/+34
The current code doesn't use a consistent naming scheme for structures, enums, or variables, making it harder than necessary to determine the relationship between these. Let's make this easier by consistently using 'vdso_abi' nomenclature. The 'vdso_lookup' array is renamed to 'vdso_info' to describe what it contains rather than how it is consumed. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200428164921.41641-4-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-29arm64: vdso: simplify arch_vdso_type ifdefferyMark Rutland1-10/+5
Currently we have some ifdeffery to determine the number of elements in enum arch_vdso_type as VDSO_TYPES, rather that the usual pattern of having the enum define this: | enum foo_type { | FOO_TYPE_A, | FOO_TYPE_B, | #ifdef CONFIG_C | FOO_TYPE_C, | #endif | NR_FOO_TYPES | } ... however, given we only use this number to size the vdso_lookup[] array, this is redundant anyway as the compiler can automatically size the array to fit all defined elements. So let's remove the VDSO_TYPES to simplify the code. At the same time, let's use designated initializers for the array elements so that these are guarnateed to be at the expected indices, regardless of how we modify the structure. For clariy the redundant explicit initialization of the enum elements is dropped. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200428164921.41641-3-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-29arm64: vdso: remove aarch32_vdso_pages[]Mark Rutland1-7/+12
The aarch32_vdso_pages[] array is unnecessarily confusing. We only ever use the C_VECTORS and C_SIGPAGE slots, and the other slots are unused despite having corresponding mappings (sharing pages with the AArch64 vDSO). Let's make this clearer by using separate variables for the vectors page and the sigreturn page. A subsequent patch will clean up the C_* naming and conflation of pages with mappings. Note that since both the vectors page and sig page are single pages, and the mapping is a single page long, their pages array do not need to be NULL-terminated (and this was not the case with the existing code for the sig page as it was the last entry in the aarch32_vdso_pages array). There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200428164921.41641-2-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-29arm64: dts: fsl: add fsl,extts-fifo property for fman ptpYangbo Lu1-0/+1
The 1588 timer supports external trigger timestamp FIFO on FMan on QorIQ ARM platforms. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-29arm64: dts: imx8mn: Update VDD_ARM 1.2GHz setpoint voltageAnson Huang1-1/+1
The latest datasheet Rev. 0.1, 03/2020 removes below constrain: "If VDD_SOC/GPU/DDR = 0.95V, then VDD_ARM must be >= 0.95V." So, for 1.2GHz setpoint VDD_ARM can use its typical voltage directly. The datasheet can be downloaded from below link: https://www.nxp.com/docs/en/data-sheet/IMX8MNCEC.pdf Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-29arm64: dts: freescale: imx8mp: update input_val for AUDIOMIX_BIT_STREAMShengjiu Wang1-23/+23
Update input_val for AUDIOMIX_BIT_STREAM according to latest RM. Fixes: 6d9b8d20431f ("arm64: dts: freescale: Add i.MX8MP dtsi support") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-29arm64: dts: lx2160a: add more thermal zone supportYuantian Tang1-5/+125
There are 7 thermal zones in lx2160a soc. Add the rest thermal zone node to enable them. Also correct one of the values for tmu-calibration property. Signed-off-by: Yuantian Tang <andy.tang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-29arm64: dts: imx8qxp-mek: Add PMIC thermal zone supportAnson Huang1-0/+33
i.MX8QXP MEK board has PMIC thermal sensor, add support for it. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-29arm64: dts: imx8qxp-mek: Sort labels alphabeticallyAnson Huang1-30/+30
Sort the labels alphabetically for consistency. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-29arm64: dts: imx8mm: specify #sound-dai-cells for SAI nodesMatt Porter1-0/+4
Add #sound-dai-cells properties to SAI nodes. Signed-off-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-28Merge branch 'work.sysctl' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/viro/vfsDaniel Borkmann2-3/+2
Pull in Christoph Hellwig's series that changes the sysctl's ->proc_handler methods to take kernel pointers instead. It gets rid of the set_fs address space overrides used by BPF. As per discussion, pull in the feature branch into bpf-next as it relates to BPF sysctl progs. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20200427071508.GV23230@ZenIV.linux.org.uk/T/
2020-04-28efi/libstub/arm64: align PE/COFF sections to segment alignmentArd Biesheuvel2-2/+3
The arm64 kernel's segment alignment is fixed at 64 KB for any page size, and relocatable kernels are able to fix up any misalignment of the kernel image with respect to the 2 MB section alignment that is mandated by the arm64 boot protocol. Let's increase the PE/COFF section alignment to the same value, so that kernels loaded by the UEFI PE/COFF loader are guaranteed to end up at an address that doesn't require any reallocation to be done if the kernel is relocatable. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20200413155521.24698-6-ardb@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: vdso: Add '-Bsymbolic' to ldflagsVincenzo Frascino1-3/+5
Commit 28b1a824a4f44 ("arm64: vdso: Substitute gettimeofday() with C implementation") introduced an unused 'VDSO_LDFLAGS' variable to the vdso Makefile, suggesting that we should be passing '-Bsymbolic' to the linker, as we do when linking the compat vDSO. Although it's not strictly necessary to pass this flag, it would be required if we were to add any internal references to the exported symbols. It's also consistent with how we link the compat vdso so, since there's no real downside from passing it, add '-Bsymbolic' to the ldflags for the native vDSO. Fixes: 28b1a824a4f44 ("arm64: vdso: Substitute gettimeofday() with C implementation") Reported-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20200428150854.33130-1-vincenzo.frascino@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: drop duplicate definitions of ID_AA64MMFR0_TGRAN constantsArd Biesheuvel1-11/+0
A bunch of ID_AA64MMFR0_TGRAN_* constant definitions appear twice in arch/arm64/include/asm/sysreg.h, so drop the duplicates. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20200414134706.8435-1-ardb@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28KVM: arm64: Drop PTE_S2_MEMATTR_MASKZenghui Yu1-1/+0
The only user of PTE_S2_MEMATTR_MASK macro had been removed since commit a501e32430d4 ("arm64: Clean up the default pgprot setting"). It has been about six years and no one has used it again. Let's drop it. Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200415105746.314-1-yuzenghui@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64/kernel: Fix range on invalidating dcache for boot page tablesGavin Shan3-3/+11
Prior to commit 8eb7e28d4c642c31 ("arm64/mm: move runtime pgds to rodata"), idmap_pgd_dir, tramp_pg_dir, reserved_ttbr0, swapper_pg_dir, and init_pg_dir were contiguous at the end of the kernel image. The maintenance at the end of __create_page_tables assumed these were contiguous, and affected everything from the start of idmap_pg_dir to the end of init_pg_dir. That commit moved all but init_pg_dir into the .rodata section, with other data placed between idmap_pg_dir and init_pg_dir, but did not update the maintenance. Hence the maintenance is performed on much more data than necessary (but as the bootloader previously made this clean to the PoC there is no functional problem). As we only alter idmap_pg_dir, and init_pg_dir, we only need to perform maintenance for these. As the other dirs are in .rodata, the bootloader will have initialised them as expected and cleaned them to the PoC. The kernel will initialize them as necessary after enabling the MMU. This patch reworks the maintenance to only cover the idmap_pg_dir and init_pg_dir to avoid this unnecessary work. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200427235700.112220-1-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirelyArd Biesheuvel1-1/+1
TEXT_OFFSET on arm64 is a historical artifact from the early days of the arm64 port where the boot protocol was basically 'copy this image to the base of memory + 512k', giving us 512 KB of guaranteed BSS space to put the swapper page tables. When the arm64 Image header was added in v3.10, it already carried the actual value of TEXT_OFFSET, to allow the bootloader to discover it dynamically rather than hardcode it to 512 KB. Today, this memory window is not used for any particular purpose, and it is simply handed to the page allocator at boot. The only reason it still exists is because of the 512k misalignment it causes with respect to the 2 MB aligned virtual base address of the kernel, which affects the virtual addresses of all statically allocated objects in the kernel image. However, with the introduction of KASLR in v4.6, we added the concept of relocatable kernels, which rewrite all absolute symbol references at boot anyway, and so the placement of such kernels in the physical address space is irrelevant, provided that the minimum segment alignment is honoured (64 KB in most cases, 128 KB for 64k pages kernels with vmap'ed stacks enabled). This makes 0x0 and 512 KB equally suitable values for TEXT_OFFSET on the off chance that we are dealing with boot loaders that ignore the value passed via the header entirely. Considering that the distros as well as Android ship KASLR-capable kernels today, and the fact that TEXT_OFFSET was discoverable from the Image header from the very beginning, let's change this value to 0x0, in preparation for removing it entirely at a later date. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20200415082922.32709-1-ardb@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: lib: Consistently enable crc32 extensionMark Brown1-1/+1
Currently most of the assembly files that use architecture extensions enable them using the .arch directive but crc32.S uses .cpu instead. Move that over to .arch for consistency. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20200414182843.31664-1-broonie@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: cpufeature: Add an overview comment for the cpufeature frameworkWill Deacon1-0/+50
Now that Suzuki isn't within throwing distance, I thought I'd better add a rough overview comment to cpufeature.c so that it doesn't take me days to remember how it works next time. Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20200421142922.18950-9-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: cpufeature: Relax checks for AArch32 support at EL[0-2]Will Deacon1-7/+3
We don't need to be quite as strict about mismatched AArch32 support, which is good because the friendly hardware folks have been busy mismatching this to their hearts' content. * We don't care about EL2 or EL3 (there are silly comments concerning the latter, so remove those) * EL1 support is gated by the ARM64_HAS_32BIT_EL1 capability and handled gracefully when a mismatch occurs * EL0 support is gated by the ARM64_HAS_32BIT_EL0 capability and handled gracefully when a mismatch occurs Relax the AArch32 checks to FTR_NONSTRICT. Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20200421142922.18950-8-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: cpufeature: Relax AArch32 system checks if EL1 is 64-bit onlyWill Deacon2-1/+39
If AArch32 is not supported at EL1, the AArch32 feature register fields no longer advertise support for some system features: * ISAR4.SMC * PFR1.{Virt_frac, Sec_frac, Virtualization, Security, ProgMod} In which case, we don't need to emit "SANITY CHECK" failures for all of them. Add logic to relax the strictness of individual feature register fields at runtime and use this for the fields above if 32-bit EL1 is not supported. Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20200421142922.18950-7-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: cpufeature: Factor out checking of AArch32 featuresWill Deacon1-47/+65
update_cpu_features() is pretty large, so split out the checking of the AArch32 features into a separate function and call it after checking the AArch64 features. Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20200421142922.18950-6-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: cpufeature: Remove redundant call to id_aa64pfr0_32bit_el0()Will Deacon1-3/+1
There's no need to call id_aa64pfr0_32bit_el0() twice because the sanitised value of ID_AA64PFR0_EL1 has already been updated for the CPU being onlined. Remove the redundant function call. Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20200421142922.18950-5-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: cpufeature: Add CPU capability for AArch32 EL1 supportWill Deacon4-11/+17
Although we emit a "SANITY CHECK" warning and taint the kernel if we detect a CPU mismatch for AArch32 support at EL1, we still online the CPU with disastrous consequences for any running 32-bit VMs. Introduce a capability for AArch32 support at EL1 so that late onlining of incompatible CPUs is forbidden. Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200421142922.18950-4-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: cpufeature: Spell out register fields for ID_ISAR4 and ID_PFR1Will Deacon2-2/+43
In preparation for runtime updates to the strictness of some AArch32 features, spell out the register fields for ID_ISAR4 and ID_PFR1 to make things clearer to read. Note that this isn't functionally necessary, as the feature arrays themselves are not modified dynamically and remain 'const'. Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20200421142922.18950-3-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: cpufeature: Relax check for IESB supportSai Prakash Ranjan1-1/+1
We don't care if IESB is supported or not as we always set SCTLR_ELx.IESB and, if it works, that's really great. Relax the ID_AA64MMFR2.IESB cpufeature check so that we don't warn and taint if it's mismatched. [will: rewrote commit message] Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20200421142922.18950-2-will@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64/mm: Use phys_to_page() to access pgtable memoryGavin Shan1-3/+3
The macros {pgd, pud, pmd}_page() retrieves the page struct of the corresponding page frame, which is reserved as page table. There is already a macro (phys_to_page), defined in memory.h as below, to convert the physical address to the page struct. Also, the header file (memory.h) has been included by pgtable.h. #define phys_to_page(phys) (pfn_to_page(__phys_to_pfn(phys))) So it's reasonable to use the macro in pgtable.h. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200427234655.111847-1-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: smp: Make cpus_stuck_in_kernel staticZou Wei1-1/+1
Fix the following sparse warning: arch/arm64/kernel/smp.c:68:5: warning: symbol 'cpus_stuck_in_kernel' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Link: https://lore.kernel.org/r/1587623606-96698-1-git-send-email-zou_wei@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: entry: remove unneeded semicolon in el1_sync_handler()Jason Yan1-1/+1
Fix the following coccicheck warning: arch/arm64/kernel/entry-common.c:97:2-3: Unneeded semicolon Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200418081909.41471-1-yanaijie@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64/kernel: vmlinux.lds: drop redundant discard/keep macrosArd Biesheuvel1-8/+2
ARM_EXIT_KEEP and ARM_EXIT_DISCARD are always defined in the same way, so we don't really need them in the first place. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200416132730.25290-1-ardb@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: drop GZFLAGS definition and exportArd Biesheuvel1-2/+1
Drop the definition and export of GZFLAGS, which was never referenced on arm64, and whose last recorded use in the ARM port (on which arm64 was based original) was removed by patch commit 5e89d379edb5ae08b57f39dd8d91697275245cbf [*] Author: Russell King <rmk@flint.arm.linux.org.uk> Date: Wed Oct 16 14:32:17 2002 +0100 [ARM] Convert ARM makefiles to new kbuild (Sam Ravnborg, Kai, rmk) [*] git commit ID based on Thomas Gleixner's historical GIT repository at git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200415123049.25504-1-ardb@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: kexec_file: Avoid temp buffer for RNG seedGeorge Spelvin1-4/+4
After using get_random_bytes(), you want to wipe the buffer afterward so the seed remains secret. In this case, we can eliminate the temporary buffer entirely. fdt_setprop_placeholder() returns a pointer to the property value buffer, allowing us to put the random data directly in there without using a temporary buffer at all. Faster and less stack all in one. Signed-off-by: George Spelvin <lkml@sdf.org> Acked-by: Will Deacon <will@kernel.org> Cc: Hsin-Yi Wang <hsinyi@chromium.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20200330173801.GA9199@SDF.ORG Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: rename stext to primary_entryArd Biesheuvel4-14/+13
For historical reasons, the primary entry routine living somewhere in the inittext section is called stext(), which is confusing, given that there is also a section marker called _stext which lives at a fixed offset in the image (either 64 or 4096 bytes, depending on whether CONFIG_EFI is enabled) Let's rename stext to primary_entry(), which is a better description and reflects the secondary_entry() routine that already exists for SMP boot. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200326171423.3080-1-ardb@kernel.org Reviwed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: simplify ptrauth initializationMark Rutland7-69/+32
Currently __cpu_setup conditionally initializes the address authentication keys and enables them in SCTLR_EL1, doing so differently for the primary CPU and secondary CPUs, and skipping this work for CPUs returning from an idle state. For the latter case, cpu_do_resume restores the keys and SCTLR_EL1 value after the MMU has been enabled. This flow is rather difficult to follow, so instead let's move the primary and secondary CPU initialization into their respective boot paths. By following the example of cpu_do_resume and doing so once the MMU is enabled, we can always initialize the keys from the values in thread_struct, and avoid the machinery necessary to pass the keys in secondary_data or open-coding initialization for the boot CPU. This means we perform an additional RMW of SCTLR_EL1, but we already do this in the cpu_do_resume path, and for other features in cpufeature.c, so this isn't a major concern in a bringup path. Note that even while the enable bits are clear, the key registers are accessible. As this now renders the argument to __cpu_setup redundant, let's also remove that entirely. Future extensions can follow a similar approach to initialize values that differ for primary/secondary CPUs. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Reviewed-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200423101606.37601-3-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: remove ptrauth_keys_install_kernel sync argMark Rutland3-8/+19
The 'sync' argument to ptrauth_keys_install_kernel macro is somewhat opaque at callsites, so instead lets have regular and _nosync variants of the macro to make this a little more obvious. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200423101606.37601-2-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-04-28arm64: dts: imx8qxp: support scu mailbox channelPeng Fan1-12/+6
With mailbox driver support i.MX8 SCU MU channel, we could use it to avoid trigger interrupts for each TR/RR registers in one MU, instead, only one RX interrupt for a recv and one TX interrupt for a send. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-04-27arm64: dts: rockchip: Fix Pinebook Pro FUSB302 interruptRobin Murphy1-1/+2
Although the FUSB302 driver has apparently supported the "fcs,int_n" property since the beginning, the DT binding has never documented it, and in fact defines a standard "interrupts" property as required. It's also questionable whether the GPIO specifier with GPIO_ACTIVE_HIGH is even correct, since the FUSB302 datasheet says INT_N is an "Active-LOW open-drain interrupt output", and the Pinebook Pro schematic shows it wired directly to the GPIO pin. Just use the standard property like all the other RK3399 boards sharing the same design. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/f731122c5ccde4e3d6d149a9d7bf01708b4279f7.1587736459.git.robin.murphy@arm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-04-27arm64: dts: rockchip: remove #sound-dai-cells from &spdif node of rk3399-hugsun-x99.dtsJohan Jonker1-1/+0
The '#sound-dai-cells' property is already defined in rk3399.dtsi at the 'spdif' node, so remove it from the '&spdif' node in 'rk3399-hugsun-x99.dts'. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200424155600.24254-2-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-04-27arm64: dts: rockchip: remove #sound-dai-cells from &i2s1 node of rk3399-pinebook-pro.dtsJohan Jonker1-1/+0
The '#sound-dai-cells' property is already defined in rk3399.dtsi at the 'i2s1' node, so remove it from the '&i2s1' node in 'rk3399-pinebook-pro.dts'. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200424155600.24254-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.