aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2022-09-16arm64: alternatives: hoist print out of __apply_alternatives()Mark Rutland1-2/+4
Printing in the middle of __apply_alternatives() is potentially unsafe and not all that helpful given these days we practically always patch *something*. Hoist the print out of __apply_alternatives(), and add separate prints to __apply_alternatives() and apply_alternatives_all(), which will make it easier to spot if either patching call goes wrong. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Joey Gouly <joey.gouly@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20220912162210.3626215-5-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: alternatives: proton-pack: prepare for cap changesMark Rutland1-1/+1
The spectre patching callbacks use cpus_have_final_cap(), and subsequent patches will make it invalid to call cpus_have_final_cap() before alternatives patching has completed. In preparation for said change, this patch modifies the spectre patching callbacks use cpus_have_cap(). This is not subject to patching, and will dynamically check the cpu_hwcaps array, which is functionally equivalent to the existing behaviour. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Joey Gouly <joey.gouly@arm.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20220912162210.3626215-4-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: alternatives: kvm: prepare for cap changesMark Rutland1-2/+3
The KVM patching callbacks use cpus_have_final_cap() internally within has_vhe(), and subsequent patches will make it invalid to call cpus_have_final_cap() before alternatives patching has completed, and will mean that cpus_have_const_cap() will always fall back to dynamic checks prior to alternatives patching. In preparation for said change, this patch modifies the KVM patching callbacks to use cpus_have_cap() directly. This is not subject to patching, and will dynamically check the cpu_hwcaps array, which is functionally equivalent to the existing behaviour. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Joey Gouly <joey.gouly@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20220912162210.3626215-3-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: cpufeature: make cpus_have_cap() noinstr-safeMark Rutland1-2/+2
Currently it isn't safe to use cpus_have_cap() from noinstr code as test_bit() is explicitly instrumented, and were cpus_have_cap() placed out-of-line, cpus_have_cap() itself could be instrumented. Make cpus_have_cap() noinstr safe by marking it __always_inline and using arch_test_bit(). Aside from the prevention of instrumentation, there should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Joey Gouly <joey.gouly@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20220912162210.3626215-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16ata: clean up how architectures enable PATA_PLATFORM and PATA_OF_PLATFORMLukas Bulwahn1-1/+0
There are two options for platform device PATA support: PATA_PLATFORM: Generic platform device PATA support PATA_OF_PLATFORM: OpenFirmware platform device PATA support If an architecture allows the generic platform device PATA support, it shall select HAVE_PATA_PLATFORM. Then, Generic platform device PATA support is available and can be selected. If an architecture has OpenFirmware support, which it indicates by selecting OF, OpenFirmware platform device PATA support is available and can be selected. If OpenFirmware platform device PATA support is selected, then the functionality (code files) from Generic platform device PATA support needs to be integrated in the kernel build for the OpenFirmware platform device PATA support to work. Select PATA_PLATFORM in PATA_OF_PLATFORM to make sure the needed files are added in the build. So, architectures with OpenFirmware support, do not need to additionally select HAVE_PATA_PLATFORM. It is only needed by architecture that want the non-OF pata-platform module. Reflect this way of intended use of config symbols in the ata Kconfig and adjust all architecture definitions. This follows the suggestion from Arnd Bergmann (see Link). Suggested-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/all/4b33bffc-2b6d-46b4-9f1d-d18e55975a5a@www.fastmail.com/ Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
2022-09-16arm64: errata: remove BF16 HWCAP due to incorrect result on Cortex-A510James Morse3-0/+40
Cortex-A510's erratum #2658417 causes two BF16 instructions to return the wrong result in rare circumstances when a pair of A510 CPUs are using shared neon hardware. The two instructions affected are BFMMLA and VMMLA, support for these is indicated by the BF16 HWCAP. Remove it on affected platforms. Signed-off-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20220909165938.3931307-4-james.morse@arm.com [catalin.marinas@arm.com: add revision to the Kconfig help; remove .type] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: cpufeature: Expose get_arm64_ftr_reg() outside cpufeature.cJames Morse2-1/+3
get_arm64_ftr_reg() returns the properties of a system register based on its instruction encoding. This is needed by erratum workaround in cpu_errata.c to modify the user-space visible view of id registers. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20220909165938.3931307-3-james.morse@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: cpufeature: Force HWCAP to be based on the sysreg visible to user-spaceJames Morse1-7/+30
arm64 advertises hardware features to user-space via HWCAPs, and by emulating access to the CPUs id registers. The cpufeature code has a sanitised system-wide view of an id register, and a sanitised user-space view of an id register, where some features use their 'safe' value instead of the hardware value. It is currently possible for a HWCAP to be advertised where the user-space view of the id register does not show the feature as supported. Erratum workaround need to remove both the HWCAP, and the feature from the user-space view of the id register. This involves duplicating the code, and spreading it over cpufeature.c and cpu_errata.c. Make the HWCAP code use the user-space view of id registers. This ensures the values never diverge, and allows erratum workaround to remove HWCAP by modifying the user-space view of the id register. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20220909165938.3931307-2-james.morse@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64/sysreg: Convert ID_AA64AFRn_EL1 to automatic generationMark Brown2-3/+16
Convert ID_AA64AFRn_EL1 to automatic generation as per DDI0487I.a, no functional changes. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220910163354.860255-7-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64/sysreg: Convert ID_AA64DFR1_EL1 to automatic generationMark Brown2-2/+4
Convert ID_AA64FDR1_EL1 to automatic generation as per DDI0487I.a, no functional changes. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220910163354.860255-6-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64/sysreg: Convert ID_AA64FDR0_EL1 to automatic generationMark Brown2-24/+63
Convert ID_AA64DFR0_EL1 to automatic generation as per DDI0487I.a, no functional changes. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220910163354.860255-5-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64/sysreg: Use feature numbering for PMU and SPE revisionsMark Brown4-16/+16
Currently the kernel refers to the versions of the PMU and SPE features by the version of the architecture where those features were updated but the ARM refers to them using the FEAT_ names for the features. To improve consistency and help with updating for newer features and since v9 will make our current naming scheme a bit more confusing update the macros identfying features to use the FEAT_ based scheme. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220910163354.860255-4-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64/sysreg: Add _EL1 into ID_AA64DFR0_EL1 definition namesMark Brown12-63/+63
Normally we include the full register name in the defines for fields within registers but this has not been followed for ID registers. In preparation for automatic generation of defines add the _EL1s into the defines for ID_AA64DFR0_EL1 to follow the convention. No functional changes. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220910163354.860255-3-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64/sysreg: Align field names in ID_AA64DFR0_EL1 with architectureMark Brown12-62/+62
The naming scheme the architecture uses for the fields in ID_AA64DFR0_EL1 does not align well with kernel conventions, using as it does a lot of MixedCase in various arrangements. In preparation for automatically generating the defines for this register rename the defines used to match what is in the architecture. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220910163354.860255-2-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: rework BTI exception handlingMark Rutland3-5/+22
If a BTI exception is taken from EL1, the entry code will treat this as an unhandled exception and will panic() the kernel. This is inconsistent with the way we handle FPAC exceptions, which have a dedicated handler and only necessarily kill the thread from which the exception was taken from, and we don't log all the information that could be relevant to debug the issue. The code in do_bti() has: BUG_ON(!user_mode(regs)); ... and it seems like the intent was to call this for EL1 BTI exceptions, as with FPAC, but this was omitted due to an oversight. This patch adds separate EL0 and EL1 BTI exception handlers, with the latter calling die() directly to report the original context the BTI exception was taken from. This matches our handling of FPAC exceptions. Prior to this patch, a BTI failure is reported as: | Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00131-g7d937ff0221d-dirty #9 | Hardware name: linux,dummy-virt (DT) | pstate: 20400809 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c) | pc : test_bti_callee+0x4/0x10 | lr : test_bti_caller+0x1c/0x28 | sp : ffff80000800bdf0 | x29: ffff80000800bdf0 x28: 0000000000000000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: ffff80000a2b8000 x22: 0000000000000000 x21: 0000000000000000 | x20: ffff8000099fa5b0 x19: ffff800009ff7000 x18: fffffbfffda37000 | x17: 3120676e696d7573 x16: 7361202c6e6f6974 x15: 0000000041a90000 | x14: 0040000000000041 x13: 0040000000000001 x12: ffff000001a90000 | x11: fffffbfffda37480 x10: 0068000000000703 x9 : 0001000040000000 | x8 : 0000000000090000 x7 : 0068000000000f03 x6 : 0060000000000f83 | x5 : ffff80000a2b6000 x4 : ffff0000028d0000 x3 : ffff800009f78378 | x2 : 0000000000000000 x1 : 0000000040210000 x0 : ffff8000080257e4 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00131-g7d937ff0221d-dirty #9 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace.part.0+0xcc/0xe0 | show_stack+0x18/0x5c | dump_stack_lvl+0x64/0x80 | dump_stack+0x18/0x34 | panic+0x170/0x360 | arm64_exit_nmi.isra.0+0x0/0x80 | el1h_64_sync_handler+0x64/0xd0 | el1h_64_sync+0x64/0x68 | test_bti_callee+0x4/0x10 | smp_cpus_done+0xb0/0xbc | smp_init+0x7c/0x8c | kernel_init_freeable+0x128/0x28c | kernel_init+0x28/0x13c | ret_from_fork+0x10/0x20 With this patch applied, a BTI failure is reported as: | Internal error: Oops - BTI: 0000000034000002 [#1] PREEMPT SMP | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00132-g0ad98265d582-dirty #8 | Hardware name: linux,dummy-virt (DT) | pstate: 20400809 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c) | pc : test_bti_callee+0x4/0x10 | lr : test_bti_caller+0x1c/0x28 | sp : ffff80000800bdf0 | x29: ffff80000800bdf0 x28: 0000000000000000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: ffff80000a2b8000 x22: 0000000000000000 x21: 0000000000000000 | x20: ffff8000099fa5b0 x19: ffff800009ff7000 x18: fffffbfffda37000 | x17: 3120676e696d7573 x16: 7361202c6e6f6974 x15: 0000000041a90000 | x14: 0040000000000041 x13: 0040000000000001 x12: ffff000001a90000 | x11: fffffbfffda37480 x10: 0068000000000703 x9 : 0001000040000000 | x8 : 0000000000090000 x7 : 0068000000000f03 x6 : 0060000000000f83 | x5 : ffff80000a2b6000 x4 : ffff0000028d0000 x3 : ffff800009f78378 | x2 : 0000000000000000 x1 : 0000000040210000 x0 : ffff800008025804 | Call trace: | test_bti_callee+0x4/0x10 | smp_cpus_done+0xb0/0xbc | smp_init+0x7c/0x8c | kernel_init_freeable+0x128/0x28c | kernel_init+0x28/0x13c | ret_from_fork+0x10/0x20 | Code: d50323bf d53cd040 d65f03c0 d503233f (d50323bf) Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20220913101732.3925290-6-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: rework FPAC exception handlingMark Rutland3-9/+14
If an FPAC exception is taken from EL1, the entry code will call do_ptrauth_fault(), where due to: BUG_ON(!user_mode(regs)) ... the kernel will report a problem within do_ptrauth_fault() rather than reporting the original context the FPAC exception was taken from. The pt_regs and ESR value reported will be from within do_ptrauth_fault() and the code dump will be for the BRK in BUG_ON(), which isn't sufficient to debug the cause of the original exception. This patch makes the reporting better by having separate EL0 and EL1 FPAC exception handlers, with the latter calling die() directly to report the original context the FPAC exception was taken from. Note that we only need to prevent kprobes of the EL1 FPAC handler, since the EL0 FPAC handler cannot be called recursively. For consistency with do_el0_svc*(), I've named the split functions do_el{0,1}_fpac() rather than do_el{0,1}_ptrauth_fault(). I've also clarified the comment to not imply there are casues other than FPAC exceptions. Prior to this patch FPAC exceptions are reported as: | kernel BUG at arch/arm64/kernel/traps.c:517! | Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00130-g9c8a180a1cdf-dirty #12 | Hardware name: FVP Base RevC (DT) | pstate: 00400009 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : do_ptrauth_fault+0x3c/0x40 | lr : el1_fpac+0x34/0x54 | sp : ffff80000a3bbc80 | x29: ffff80000a3bbc80 x28: ffff0008001d8000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000020400009 x22: ffff800008f70fa4 x21: ffff80000a3bbe00 | x20: 0000000072000000 x19: ffff80000a3bbcb0 x18: fffffbfffda37000 | x17: 3120676e696d7573 x16: 7361202c6e6f6974 x15: 0000000081a90000 | x14: 0040000000000041 x13: 0040000000000001 x12: ffff000001a90000 | x11: fffffbfffda37480 x10: 0068000000000703 x9 : 0001000080000000 | x8 : 0000000000090000 x7 : 0068000000000f03 x6 : 0060000000000783 | x5 : ffff80000a3bbcb0 x4 : ffff0008001d8000 x3 : 0000000072000000 | x2 : 0000000000000000 x1 : 0000000020400009 x0 : ffff80000a3bbcb0 | Call trace: | do_ptrauth_fault+0x3c/0x40 | el1h_64_sync_handler+0xc4/0xd0 | el1h_64_sync+0x64/0x68 | test_pac+0x8/0x10 | smp_init+0x7c/0x8c | kernel_init_freeable+0x128/0x28c | kernel_init+0x28/0x13c | ret_from_fork+0x10/0x20 | Code: 97fffe5e a8c17bfd d50323bf d65f03c0 (d4210000) With this patch applied FPAC exceptions are reported as: | Internal error: Oops - FPAC: 0000000072000000 [#1] PREEMPT SMP | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc3-00132-g78846e1c4757-dirty #11 | Hardware name: FVP Base RevC (DT) | pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : test_pac+0x8/0x10 | lr : 0x0 | sp : ffff80000a3bbe00 | x29: ffff80000a3bbe00 x28: 0000000000000000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: ffff80000a2c8000 x22: 0000000000000000 x21: 0000000000000000 | x20: ffff8000099fa5b0 x19: ffff80000a007000 x18: fffffbfffda37000 | x17: 3120676e696d7573 x16: 7361202c6e6f6974 x15: 0000000081a90000 | x14: 0040000000000041 x13: 0040000000000001 x12: ffff000001a90000 | x11: fffffbfffda37480 x10: 0068000000000703 x9 : 0001000080000000 | x8 : 0000000000090000 x7 : 0068000000000f03 x6 : 0060000000000783 | x5 : ffff80000a2c6000 x4 : ffff0008001d8000 x3 : ffff800009f88378 | x2 : 0000000000000000 x1 : 0000000080210000 x0 : ffff000001a90000 | Call trace: | test_pac+0x8/0x10 | smp_init+0x7c/0x8c | kernel_init_freeable+0x128/0x28c | kernel_init+0x28/0x13c | ret_from_fork+0x10/0x20 | Code: d50323bf d65f03c0 d503233f aa1f03fe (d50323bf) Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20220913101732.3925290-5-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: consistently pass ESR_ELx to die()Mark Rutland3-15/+15
Currently, bug_handler() and kasan_handler() call die() with '0' as the 'err' value, whereas die_kernel_fault() passes the ESR_ELx value. For consistency, this patch ensures we always pass the ESR_ELx value to die(). As this is only called for exceptions taken from kernel mode, there should be no user-visible change as a result of this patch. For UNDEFINED exceptions, I've had to modify do_undefinstr() and its callers to pass the ESR_ELx value. In all cases the ESR_ELx value had already been read and was available. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Mark Brown <broonie@kernel.org> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220913101732.3925290-4-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: die(): pass 'err' as longMark Rutland2-4/+4
Recently, we reworked a lot of code to consistentlt pass ESR_ELx as a 64-bit quantity. However, we missed that this can be passed into die() and __die() as the 'err' parameter where it is truncated to a 32-bit int. As notify_die() already takes 'err' as a long, this patch changes die() and __die() to also take 'err' as a long, ensuring that the full value of ESR_ELx is retained. At the same time, die() is updated to consistently log 'err' as a zero-padded 64-bit quantity. Subsequent patches will pass the ESR_ELx value to die() for a number of exceptions. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20220913101732.3925290-3-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: report EL1 UNDEFs betterMark Rutland1-1/+3
If an UNDEFINED exception is taken from EL1, and do_undefinstr() doesn't find any suitable undef_hook, it will call: BUG_ON(!user_mode(regs)) ... and the kernel will report a failure witin do_undefinstr() rather than reporting the original context that the UNDEFINED exception was taken from. The pt_regs and ESR value reported within the BUG() handler will be from within do_undefinstr() and the code dump will be for the BRK in BUG_ON(), which isn't sufficient to debug the cause of the original exception. This patch makes the reporting better by having do_undefinstr() call die() directly in this case to report the original context from which the UNDEFINED exception was taken. Prior to this patch, an undefined instruction is reported as: | kernel BUG at arch/arm64/kernel/traps.c:497! | Internal error: Oops - BUG: 0 [#1] PREEMPT SMP | Modules linked in: | CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-rc3-00127-geff044f1b04e-dirty #3 | Hardware name: linux,dummy-virt (DT) | pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : do_undefinstr+0x28c/0x2ac | lr : do_undefinstr+0x298/0x2ac | sp : ffff800009f63bc0 | x29: ffff800009f63bc0 x28: ffff800009f73c00 x27: ffff800009644a70 | x26: ffff8000096778a8 x25: 0000000000000040 x24: 0000000000000000 | x23: 00000000800000c5 x22: ffff800009894060 x21: ffff800009f63d90 | x20: 0000000000000000 x19: ffff800009f63c40 x18: 0000000000000006 | x17: 0000000000403000 x16: 00000000bfbfd000 x15: ffff800009f63830 | x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000019 | x11: 0101010101010101 x10: 0000000000161b98 x9 : 0000000000000000 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 | x5 : ffff800009f761d0 x4 : 0000000000000000 x3 : ffff80000a2b80f8 | x2 : 0000000000000000 x1 : ffff800009f73c00 x0 : 00000000800000c5 | Call trace: | do_undefinstr+0x28c/0x2ac | el1_undef+0x2c/0x4c | el1h_64_sync_handler+0x84/0xd0 | el1h_64_sync+0x64/0x68 | setup_arch+0x550/0x598 | start_kernel+0x88/0x6ac | __primary_switched+0xb8/0xc0 | Code: 17ffff95 a9425bf5 17ffffb8 a9025bf5 (d4210000) With this patch applied, an undefined instruction is reported as: | Internal error: Oops - Undefined instruction: 0 [#1] PREEMPT SMP | Modules linked in: | CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-rc3-00128-gf27cfcc80e52-dirty #5 | Hardware name: linux,dummy-virt (DT) | pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : setup_arch+0x550/0x598 | lr : setup_arch+0x50c/0x598 | sp : ffff800009f63d90 | x29: ffff800009f63d90 x28: 0000000081000200 x27: ffff800009644a70 | x26: ffff8000096778c8 x25: 0000000000000040 x24: 0000000000000000 | x23: 0000000000000100 x22: ffff800009f69a58 x21: ffff80000a2b80b8 | x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000006 | x17: 0000000000403000 x16: 00000000bfbfd000 x15: ffff800009f63830 | x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000019 | x11: 0101010101010101 x10: 0000000000161b98 x9 : 0000000000000000 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000008 x4 : 0000000000000010 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 | Call trace: | setup_arch+0x550/0x598 | start_kernel+0x88/0x6ac | __primary_switched+0xb8/0xc0 | Code: b4000080 90ffed80 912ac000 97db745f (00000000) Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20220913101732.3925290-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-16arm64: dts: rockchip: Add RK3399 NanoPi R4S Enterprise EditionTianling Shen2-0/+30
The only diffrence against the standrard edition is that the enterprise one has a built-in EEPROM chip which stores a globally unique MAC address. Signed-off-by: Tianling Shen <cnsztl@gmail.com> Link: https://lore.kernel.org/r/20220915022511.4267-2-cnsztl@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-16arm64: dts: rockchip: add i2s0 I2S/PDM/TDM 8ch controller to px30Quentin Schulz1-0/+22
The Rockchip PX30 SoC has three I2S controllers, i2s1 and i2s2 are 2-channel I2S/PCM controllers handled by the same controller driver, and i2s0 a 8-channel I2S/PCM/TDM controller handled by another controller driver. This adds the device tree node required to enable I2S0 on PX30. This was tested in a 2-channel I2S with TX BCLK/LRCK for both TX and RX (rockchip,trcm-sync-tx-only) setup on a soon-to-be-released board. Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://lore.kernel.org/r/20220916091746.35108-1-foss+kernel@0leil.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-16arm64: support huge vmalloc mappingsKefeng Wang1-0/+1
As commit 559089e0a93d ("vmalloc: replace VM_NO_HUGE_VMAP with VM_ALLOW_HUGE_VMAP"), the use of hugepage mappings for vmalloc is an opt-in strategy, so it is saftly to support huge vmalloc mappings on arm64, for now, it is used in kvmalloc() and alloc_large_system_hash(). Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Link: https://lore.kernel.org/r/20220911044423.139229-1-wangkefeng.wang@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-15Merge tag 'arm-soc/for-6.1/devicetree-arm64' of https://github.com/Broadcom/stblinux into arm/dtArnd Bergmann2-0/+131
This pull request contains Broadcom ARM64-based SoC changes for 6.1, please pull the following: - Rafal adds the BCM4908 LED controller node and describes all 32 LED pins, he also adds support for the Asus GC-AC5300 LEDs * tag 'arm-soc/for-6.1/devicetree-arm64' of https://github.com/Broadcom/stblinux: arm64: dts: broadcom: bcm4908: add Asus GT-AC5300 LEDs arm64: dts: broadcom: bcm4908: add LEDs controller block arm64: dts: broadcom: bcm4908: add remaining LED pins Link: https://lore.kernel.org/r/20220915023044.2350782-3-f.fainelli@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-15Merge tag 'arm-soc/for-6.1/devicetree' of https://github.com/Broadcom/stblinux into arm/dtArnd Bergmann11-19/+40
This pull request contains Broadcom ARM-based SoC Device Tree updates for 6.1, please pull the following: - Rafal improves the BCM5301X PCIe DT nodes schema validation by flagging the PCIe controller with a missing "device_type" property - William merges BCM4908 within BCMBCA since this chip is part of the Broadcom Broadband Carrier Access group and follows the architecture of those chips * tag 'arm-soc/for-6.1/devicetree' of https://github.com/Broadcom/stblinux: arm64: bcmbca: Merge ARCH_BCM4908 to ARCH_BCMBCA arm64: dts: Add BCM4908 generic board dts arm64: dts: Move BCM4908 dts to bcmbca folder arm64: dts: bcmbca: update BCM4908 board dts files dt-bindings: arm64: bcmbca: Update BCM4908 description dt-bindings: arm64: bcmbca: Merge BCM4908 into BCMBCA ARM: dts: BCM5301X: Add basic PCI controller properties Link: https://lore.kernel.org/r/20220915023044.2350782-2-f.fainelli@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-15Merge tag 'arm-soc/for-6.1/defconfig-arm64' of https://github.com/Broadcom/stblinux into arm/defconfigArnd Bergmann1-1/+0
This pull request contains Broadcom ARM64 defconfig changes for 6.1, please pull the following: - William completes the removal of ARCH_BCM4908 by removing that Kconfig entry from the defconfig since it is being deleted after having been transitional through 6.0 * tag 'arm-soc/for-6.1/defconfig-arm64' of https://github.com/Broadcom/stblinux: arm64: defconfig: remove BCM4908 Link: https://lore.kernel.org/r/20220915023044.2350782-1-f.fainelli@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-15arm64: tegra: Add GPCDMA support for Tegra I2CAkhil R3-0/+96
Add dma properties to support GPCDMA for I2C in Tegra 186 and later chips Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Add iommus for HDA on Tegra234Mohan Kumar1-0/+1
Add the iommus property to the HDA node on Tegra234. Signed-off-by: Mohan Kumar <mkumard@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Enable HDA node for Jetson AGX OrinMohan Kumar1-0/+1
Enable HDA node for the Jetson AGX Orin platform. Signed-off-by: Mohan Kumar <mkumard@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Add context isolation domains on Tegra234Mikko Perttunen1-0/+18
Add Host1x context isolation domains on Tegra234. On Tegra234 we have two IOMMUs that are connected to Host1x-channel programmed engines, so we have to include domains for each of them. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Fixup iommu-map property formattingThierry Reding2-18/+16
Make sure that each phandle-array is enclosed in a set of angular brackets and properly indent each entry. Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: dts: tegra: smaug: Add Wi-Fi nodeDiogo Ivo1-0/+19
The Google Pixel C contains a BRCM4354 Wi-Fi + BT module. Add a DT node for its Wi-Fi functionality. Tested on Pixel C. Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: dts: tegra: smaug: Add Bluetooth nodeDiogo Ivo1-0/+17
The Google Pixel C contains a BRCM4354 Wi-Fi + BT module. Add a DT node for its BT functionality. Tested on Pixel C. Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Enable MGBE on Jetson AGX Orin Developer KitThierry Reding1-0/+21
A Multi-Gigabit Ethernet (MGBE) instance drives the primary Ethernet port on the Jetson AGX Orin Developer Kit. Enable it. Signed-off-by: Bhadram Varka <vbhadram@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Add MGBE nodes on Tegra234Thierry Reding1-0/+136
Add device tree nodes for the four instances of the Multi-Gigabit Ethernet (MGBE) IP found on NVIDIA Tegra234 SoCs. Signed-off-by: Bhadram Varka <vbhadram@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Fix up compatible for Tegra234 GPCDMAThierry Reding1-1/+0
There is no need to list the Tegra194-specific compatible for Tegra234 because the backwards-compatibility goes back all the way to Tegra186. Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Enable PCIe slots in P3737-0000 boardVidya Sagar1-0/+51
Enable PCIe controller nodes to enable respective PCIe slots on P3737-0000 board. Following is the ownership of slots by different PCIe controllers. Controller-1 : On-board Broadcom WiFi controller Controller-4 : M.2 Key-M slot Controller-5 : CEM form-factor x8 slot Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Add P2U and PCIe controller nodes to Tegra234 DTVidya Sagar1-0/+927
Add P2U (PIPE to UPHY) and PCIe controller nodes to device tree. The Tegra234 SoC contains 10 PCIe controllers and 24 P2U instances grouped into three different PHY bricks namely High-Speed IO (HSIO-8 P2Us) NVIDIA High Speed (NVHS-8 P2Us) and Gigabit Ethernet (GBE-8 P2Us) respectively. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: tegra: Add regulators required for PCIeVidya Sagar1-0/+36
Add regulator supplies required for PCIe functionality. The supplies include 1.8V, 3.3V and 12V. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: dts: qcom: sm8450: fix UFS PHY serdes sizeJohan Hovold1-1/+1
The size of the UFS PHY serdes register region is 0x1c4 and the corresponding 'reg' property should specifically not include the adjacent regions that are defined in the child node (e.g. tx and rx). Fixes: 07fa917a335e ("arm64: dts: qcom: sm8450: add ufs nodes") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220915143431.19842-2-johan+linaro@kernel.org
2022-09-15arm64: dts: mediatek: mt6795: Add CPUX system timer nodeAngeloGioacchino Del Regno1-0/+8
Add a node for mt6795-systimer: this is necessary to start the System Timer(s) for all cores, finally making CNTVCT_EL0 usable. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220729093536.27623-1-angelogioacchino.delregno@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2022-09-15arm64: dts: qcom: ipq8074: fix PCIe PHY serdes sizeJohan Hovold1-2/+2
The size of the PCIe PHY serdes register region is 0x1c4 and the corresponding 'reg' property should specifically not include the adjacent regions that are defined in the child node (e.g. tx and rx). Fixes: 33057e1672fe ("ARM: dts: ipq8074: Add pcie nodes") Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220915143431.19842-1-johan+linaro@kernel.org
2022-09-15Merge tag 'imx-fixes-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixesArnd Bergmann9-18/+31
i.MX fixes for 6.0, 2nd round: - A couple of TQMa8MPQL device tree fixes from Alexander Stein on button GPIOs and PCF85063 RTC alarm pinctrl. - Include phy-imx8-pcie.h header in tqma8mqml-mba8mx device tree to fix build errors when this SoM dtsi is included on customer carrier boards. - Remove GPU power domain reset from i.MX8MN device tree to fix a sporadical hang seen with GPUMIX powering up. - Correct CPLD_Dn GPIO label mapping for Toradex Verdin based Menlo board. - Add ARCH_NXP back to defconfig, which was dropped accidentally by commit 566e373fe047 ("arm64: Kconfig.platforms: Group NXP platforms together"). - Add missing #reset-cells for i.MX8ULP PCC clock controllers. - Update PMIC voltages for imx8mm-verdin board to fix an issue with one Toradex SKU that uses a consumer-grade chip that is capable of going up to 1.8GHz at 1.00V. - A series of imx8mp-venice-gw74xx device tree changes from Tim Harvey to fix things on CAN STBY polarity, KSZ9477 CPU uplink port and phy-mode. * tag 'imx-fixes-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: arm64: dts: imx8mp-venice-gw74xx: fix port/phy validation arm64: dts: imx8mp-venice-gw74xx: fix ksz9477 cpu port arm64: dts: imx8mp-venice-gw74xx: fix CAN STBY polarity arm64: dts: tqma8mqml: Include phy-imx8-pcie.h header arm64: defconfig: enable ARCH_NXP arm64: dts: imx8mp-tqma8mpql-mba8mpxl: add missing pinctrl for RTC alarm arm64: dts: imx8mm-verdin: extend pmic voltages arm64: dts: imx8ulp: add #reset-cells for pcc arm64: dts: tqma8mpxl-ba8mpxl: Fix button GPIOs arm64: dts: imx8mn: remove GPU power domain reset arm64: dts: imx8mm: Reverse CPLD_Dn GPIO label mapping on MX8Menlo Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-09-15arm64: defconfig: Make TEGRA186_GPC_DMA built-inAkhil R1-1/+1
Make TEGRA186_GPC_DMA driver as built-in since the clients using the DMA (like I2C_TEGRA etc) are built-in. This would avoid the potential long delay probe deferral can cause. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-15arm64: dts: rockchip: Add HDMI supplies on rk3399-roc-pcMarkus Reichl1-2/+4
Add avdd-0v9-supply and avdd-1v8-supply to hdmi node for rk3399-roc-pc to silence dmesg warning and match the name of the 1v8 supply to the circuit sheet. Signed-off-by: Markus Reichl <m.reichl@fivetechno.de> Link: https://lore.kernel.org/r/20220915111138.1108-1-m.reichl@fivetechno.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-15arm64: dts: rockchip: Support gru-scarlet sku{2,4} variantsBrian Norris1-1/+13
The Gru-Scarlet family includes a variety of SKU identifiers, using parts of a 3-bit space {0..7}. SKU2 and SKU4 devices (under a few different manufacturer names) also use the Innolux display. Without this, a SKU2 device may non-deterministically (depending on the matching order of DTBs and bootloader behavior) select either one of the INX DTBs (rk3399-gru-scarlet-dumo.dtb or rk3399-gru-scarlet-inx.dtb) or the KingDisplay DTB (rk3399-gru-scarlet-kd.dtb), to ill effect. For reference, the original vendor tree source: CHROMIUM: arm64: dts: rockchip: add sku{0,2,4} compatibility https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f6ed665c9e2eb37fb2680debbb36ec9fb0e8fb97 CHROMIUM: arm64: dts: rockchip: scarlet: add SKU0 device tree https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9987c8776f4b087d135d761e59f7fa6cc83fc7fc Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20220817123350.2.I5f4fd0808a927b08e267c189712fb4a85931fd3b@changeid Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-15arm64: tegra: Enable Tegra SPI & QSPI in deconfigKrishna Yarlagadda1-0/+2
Jetson AGX board has flash device on QSPI controller and SPI instance on 40-pin expander. Enable Tegra SPI & QSPI drivers in defconfig as modules. Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2022-09-14arm64: dts: qcom: sa8295p-adp: add missing gpio-ranges in PMIC GPIOsKrzysztof Kozlowski1-0/+4
The Qualcomm PMIC GPIO bindings require gpio-ranges property: qcom/sa8295p-adp.dtb: pmic@8: gpio@c000: 'gpio-ranges' is a required property Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220908081050.29751-5-krzysztof.kozlowski@linaro.org
2022-09-14arm64: dts: qcom: sa8295p-adp: add fallback compatible to PMIC GPIOsKrzysztof Kozlowski1-4/+4
Bindings require all PMIC GPIO nodes to have two compatibles - specific followed by SPMI or SSBI fallback: qcom/sa8295p-adp.dtb: pmic@8: gpio@c000:compatible: ['qcom,pm8150-gpio'] is too short Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220908081050.29751-4-krzysztof.kozlowski@linaro.org
2022-09-14arm64: dts: qcom: msm8996-xiaomi: align PMIC GPIO pin configuration with DT schemaKrzysztof Kozlowski2-18/+14
Bindings expect PMIC GPIO pin configuration nodes to be named with '-state' suffix: qcom/msm8996-xiaomi-scorpio.dtb: pmic@0: gpio@c000: 'irled-default', 'keypad-default' do not match any of the regexes: '-state$', 'pinctrl-[0-9]+' Drop also additional indentation via "pinconf" to make the code a bit smaller. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220908081050.29751-3-krzysztof.kozlowski@linaro.org
2022-09-14arm64: dts: qcom: msm8994-msft-lumia-octagon: align resin node name with bindingsKrzysztof Kozlowski1-1/+1
Bindings expect resin node to be named "resin": qcom/msm8992-msft-lumia-octagon-talkman.dtb: pmic@0: pon@800: Unevaluated properties are not allowed ('volwnkey' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220908081050.29751-2-krzysztof.kozlowski@linaro.org
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.