summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-07-08arm64: debug: split hardware breakpoint exception entryAda Couprie Diaz
Currently all debug exceptions share common entry code and are routed to `do_debug_exception()`, which calls dynamically-registered handlers for each specific debug exception. This is unfortunate as different debug exceptions have different entry handling requirements, and it would be better to handle these distinct requirements earlier. Hardware breakpoints exceptions are generated by the hardware after user configuration. As such, they can be exploited when training branch predictors outside of the userspace VA range: they still need to call `arm64_apply_bp_hardening()` if needed to mitigate against this attack. However, they do not need to handle the Cortex-A76 erratum #1463225 as it only applies to single stepping exceptions. It does not set an address in FAR_EL1 either, only the hardware watchpoint does. As the hardware breakpoint handler only returns 0 and never triggers the call to `arm64_notify_die()`, we can call it directly from `entry-common.c`. Split the hardware breakpoint exception entry, adjust the function signature, and handling of the Cortex-A76 erratum to fit the behaviour of the exception. Move the call to `arm64_apply_bp_hardening()` to `entry-common.c` so that we can do it as early as possible, and only for the exceptions coming from EL0, where it is needed. This is safe to do as it is `noinstr`, as are all the functions it may call. `el0_ia()` and `el0_pc()` already call it this way. Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Tested-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Reviewed-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250707114109.35672-8-ada.coupriediaz@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-08arm64: entry: Add entry and exit functions for debug exceptionsAda Couprie Diaz
Move the `debug_exception_enter()` and `debug_exception_exit()` functions from mm/fault.c, as they are needed to split the debug exceptions entry paths from the current unified one. Make them externally visible in include/asm/exception.h until the caller in mm/fault.c is cleaned up. Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Tested-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Reviewed-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250707114109.35672-7-ada.coupriediaz@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-08arm64: debug: remove break/step handler registration infrastructureAda Couprie Diaz
Remove all infrastructure for the dynamic registration previously used by software breakpoints and stepping handlers. Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Tested-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Reviewed-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250707114109.35672-6-ada.coupriediaz@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-08arm64: debug: call step handlers staticallyAda Couprie Diaz
Software stepping checks for the correct handler by iterating over a list of dynamically registered handlers and calling all of them until one handles the exception. This is the only generic way to handle software stepping handlers in arm64 as the exception does not provide an immediate that could be checked, contrary to software breakpoints. However, the registration mechanism is not exported and has only two current users : the KGDB stepping handler, and the uprobe single step handler. Given that one comes from user mode and the other from kernel mode, call the appropriate one by checking the source EL of the exception. Add a stand-in that returns DBG_HOOK_ERROR when the configuration options are not enabled. Remove `arch_init_uprobes()` as it is not useful anymore and is specific to arm64. Unify the naming of the handler to XXX_single_step_handler(), making it clear they are related. Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Tested-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Reviewed-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250707114109.35672-5-ada.coupriediaz@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-08arm64: debug: call software breakpoint handlers staticallyAda Couprie Diaz
Software breakpoints pass an immediate value in ESR ("comment") that can be used to call a specialized handler (KGDB, KASAN...). We do so in two different ways : - During early boot, `early_brk64` statically checks against known immediates and calls the corresponding handler, - During init, handlers are dynamically registered into a list. When called, the generic software breakpoint handler will iterate over the list to find the appropriate handler. The dynamic registration does not provide any benefit here as it is not exported and all its uses are within the arm64 tree. It also depends on an RCU list, whose safe access currently relies on the non-preemptible state of `do_debug_exception`. Replace the list iteration logic in `call_break_hooks` to call the breakpoint handlers statically if they are enabled, like in `early_brk64`. Expose the handlers in their respective headers to be reachable from `arch/arm64/kernel/debug-monitors.c` at link time. Unify the naming of the software breakpoint handlers to XXX_brk_handler(), making it clear they are related and to differentiate from the hardware breakpoints. Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Tested-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Reviewed-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20250707114109.35672-4-ada.coupriediaz@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-08arm64: refactor aarch32_break_handler()Ada Couprie Diaz
`aarch32_break_handler()` is called in `do_el0_undef()` when we are trying to handle an exception whose Exception Syndrome is unknown. It checks if the instruction hit might be a 32-bit arm break (be it A32 or T2), and sends a SIGTRAP to userspace if it is so that it can be handled. However, this is badly represented in the naming of the function, and is not consistent with the other functions called with the same logic in `do_el0_undef()`. Rename it `try_handle_aarch32_break()` and change the return value to a boolean to align with the logic of the other tentative handlers in `do_el0_undef()`, the previous error code being ignored anyway. Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Tested-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250707114109.35672-3-ada.coupriediaz@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-08arm64: debug: clean up single_step_handler logicAda Couprie Diaz
Remove the unnecessary boolean which always checks if the handler was found and return early instead. Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com> Tested-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250707114109.35672-2-ada.coupriediaz@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-08arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Enable serial NOR FLASHLad Prabhakar
Enable MT25QU512ABB8E12 FLASH connected to XSPI. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250704140823.163572-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-07-08arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable serial NOR FLASHLad Prabhakar
Enable MT25QU512ABB8E12 FLASH connected to XSPI. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250704140823.163572-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-07-08arm64: dts: renesas: r9a09g057: Add XSPI nodeLad Prabhakar
Add XSPI node to RZ/V2H(P) ("R9A09G057") SoC DTSI. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250704140823.163572-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-07-08arm64: dts: renesas: r9a09g056: Add XSPI nodeLad Prabhakar
Add XSPI node to RZ/V2N ("R9A09G056") SoC DTSI. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250704140823.163572-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-07-08arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Fix pinctrl node name for GBETH1Lad Prabhakar
Rename the GBETH1 pinctrl node from "eth0" to "eth1" to avoid duplicate node names in the DT and correctly reflect the label "eth1_pins". Fixes: f111192baa80 ("arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable GBETH") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250703235544.715433-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-07-08arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Fix pinctrl node name for GBETH1Lad Prabhakar
Rename the GBETH1 pinctrl node from "eth0" to "eth1" to avoid duplicate node names in the DT and correctly reflect the label "eth1_pins". Fixes: 802292ee27a7 ("arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Enable GBETH") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250703235544.715433-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-07-08arm64: dts: renesas: r8a779g3-sparrow-hawk-fan-pwm: Add missing install targetNiklas Söderlund
The target to consider the dtbo file for installation is missing, add it. Fixes: a719915e76f2 ("arm64: dts: renesas: r8a779g3: Add Retronix R-Car V4H Sparrow Hawk board support") Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/20250701112612.3957799-2-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-07-08arm64: dts: renesas: rzg3e-smarc-som: Enable eth{0-1} (GBETH) interfacesJohn Madieu
Enable the Gigabit Ethernet Interfaces (GBETH) populated on the RZ/G3E SMARC EVK Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250702005706.1200059-5-john.madieu.xa@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-07-08arm64: dts: renesas: r9a09g047e57-smarc: Add gpio keysBiju Das
RZ/G3E SMARC EVK has 3 user buttons called USER_SW1, USER_SW2 and USER_SW3 and SLEEP button with NMI support. Add a DT node in device tree to instantiate the gpio-keys driver for these buttons. The system can enter into STR state by pressing the sleep button and wakeup from STR is done by pressing power button. The USER_SW{1,2,3} configured as wakeup-source, so it can wakeup the system during s2idle. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250702092755.70847-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-07-07Merge tag 'tsa_x86_bugs_for_6.16' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull CPU speculation fixes from Borislav Petkov: "Add the mitigation logic for Transient Scheduler Attacks (TSA) TSA are new aspeculative side channel attacks related to the execution timing of instructions under specific microarchitectural conditions. In some cases, an attacker may be able to use this timing information to infer data from other contexts, resulting in information leakage. Add the usual controls of the mitigation and integrate it into the existing speculation bugs infrastructure in the kernel" * tag 'tsa_x86_bugs_for_6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/process: Move the buffer clearing before MONITOR x86/microcode/AMD: Add TSA microcode SHAs KVM: SVM: Advertise TSA CPUID bits to guests x86/bugs: Add a Transient Scheduler Attacks mitigation x86/bugs: Rename MDS machinery to something more generic
2025-07-07KVM: arm64: Expose new KVM cap for cacheable PFNMAPAnkit Agrawal
Introduce a new KVM capability to expose to the userspace whether cacheable mapping of PFNMAP is supported. The ability to safely do the cacheable mapping of PFNMAP is contingent on S2FWB and ARM64_HAS_CACHE_DIC. S2FWB allows KVM to avoid flushing the D cache, ARM64_HAS_CACHE_DIC allows KVM to avoid flushing the icache and turns icache_inval_pou() into a NOP. The cap would be false if those requirements are missing and is checked by making use of kvm_arch_supports_cacheable_pfnmap. This capability would allow userspace to discover the support. It could for instance be used by userspace to prevent live-migration across FWB and non-FWB hosts. CC: Catalin Marinas <catalin.marinas@arm.com> CC: Jason Gunthorpe <jgg@nvidia.com> CC: Oliver Upton <oliver.upton@linux.dev> CC: David Hildenbrand <david@redhat.com> Suggested-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20250705071717.5062-7-ankita@nvidia.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-07KVM: arm64: Allow cacheable stage 2 mapping using VMA flagsAnkit Agrawal
KVM currently forces non-cacheable memory attributes (either Normal-NC or Device-nGnRE) for a region based on pfn_is_map_memory(), i.e. whether or not the kernel has a cacheable alias for it. This is necessary in situations where KVM needs to perform CMOs on the region but is unnecessarily restrictive when hardware obviates the need for CMOs. KVM doesn't need to perform any CMOs on hardware with FEAT_S2FWB and CTR_EL0.DIC. As luck would have it, there are implementations in the wild that need to map regions of a device with cacheable attributes to function properly. An example of this is Nvidia's Grace Hopper/Blackwell systems where GPU memory is interchangeable with DDR and retains properties such as cacheability, unaligned accesses, atomics and handling of executable faults. Of course, for this to work in a VM the GPU memory needs to have a cacheable mapping at stage-2. Allow cacheable stage-2 mappings to be created on supporting hardware when the VMA has cacheable memory attributes. Check these preconditions during memslot creation (in addition to fault handling) to potentially 'fail-fast' as a courtesy to userspace. CC: Oliver Upton <oliver.upton@linux.dev> CC: Sean Christopherson <seanjc@google.com> Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Suggested-by: David Hildenbrand <david@redhat.com> Tested-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20250705071717.5062-6-ankita@nvidia.com [ Oliver: refine changelog, squash kvm_supports_cacheable_pfnmap() patch ] Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-07KVM: arm64: Block cacheable PFNMAP mappingAnkit Agrawal
Fixes a security bug due to mismatched attributes between S1 and S2 mapping. Currently, it is possible for a region to be cacheable in the userspace VMA, but mapped non cached in S2. This creates a potential issue where the VMM may sanitize cacheable memory across VMs using cacheable stores, ensuring it is zeroed. However, if KVM subsequently assigns this memory to a VM as uncached, the VM could end up accessing stale, non-zeroed data from a previous VM, leading to unintended data exposure. This is a security risk. Block such mismatch attributes case by returning EINVAL when userspace try to map PFNMAP cacheable. Only allow NORMAL_NC and DEVICE_*. CC: Oliver Upton <oliver.upton@linux.dev> CC: Catalin Marinas <catalin.marinas@arm.com> CC: Sean Christopherson <seanjc@google.com> Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: David Hildenbrand <david@redhat.com> Tested-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20250705071717.5062-4-ankita@nvidia.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-07arm: dts: ti: omap: Fixup pinheader typoAlbin Törnqvist
This commit fixes a typo introduced in commit ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names"). gpio0_7 is located on the P9 header on the BBB. This was verified with a BeagleBone Black by toggling the pin and checking with a multimeter that it corresponds to pin 42 on the P9 header. Signed-off-by: Albin Törnqvist <albin.tornqvist@codiax.se> Link: https://lore.kernel.org/r/20250624114839.1465115-2-albin.tornqvist@codiax.se Fixes: ee368a10d0df ("ARM: dts: am335x-boneblack.dts: unique gpio-line-names") Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2025-07-07ARM: dts: am335x-pdu001: Fix RS-485 transceiver switchingFelix Brack
The wiring of the RS-485 transceiver of UART0 of the PDU-001 board allows sending or receiving date exclusively. In other words: no character transmitted will ever be received. Hence the tx-filter counter in the OMAP serial driver can't work correctly as it relies on receiving the transmitted characters. This in turn will prevent reception of data unless we disable the tx-filter counter. This patch disables the tx-filter counter by enabling the DTS setting rs485-rx-during-tx. This might sound like the opposite to be done but it uses the enabling of rs485-rx-during-tx not for receiving the data transmitted but for disabling the tx-fiter counter. Tested-by: Felix Brack <fb@ltec.ch> Signed-off-by: Felix Brack <fb@ltec.ch> Link: https://lore.kernel.org/r/20250529135324.182868-1-fb@ltec.ch Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2025-07-07x86/itmt: Add debugfs file to show core prioritiesMario Limonciello
Multiple drivers can report priorities to ITMT. To aid in debugging any issues with the values reported by drivers introduce a debugfs file to read out the values. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/20250609200518.3616080-14-superm1@kernel.org
2025-07-07x86/process: Clear hardware feedback history for AMD processorsPerry Yuan
Incorporate a mechanism within the context switching code to reset the hardware history for AMD processors. Specifically, when a task is switched in, the class ID is read and the hardware workload classification history of the CPU firmware is reset. Then, the workload classification for the next running thread is begun. [ bp: Massage commit message. ] Signed-off-by: Perry Yuan <perry.yuan@amd.com> Co-developed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/20250609200518.3616080-10-superm1@kernel.org
2025-07-07ASoC: soc-dapm: cleanupsMark Brown
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>: This is prepare to hiding snd_soc_dapm_context inside soc-dapm.c
2025-07-07x86/msr-index: Add AMD workload classification MSRsPerry Yuan
Introduce new MSR registers for AMD hardware feedback support. They provide workload classification and configuration capabilities. Signed-off-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/20250609200518.3616080-4-superm1@kernel.org
2025-07-07ARM: dts: marvell: kirkwood: use recent scl/sda gpio bindingsWolfram Sang
We have dedictaded bindings for scl/sda nowadays. Switch away from the deprecated plain 'gpios' property. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2025-07-07arm: orion: use string choices helperKuninori Morimoto
We can use string choices helper, let's use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2025-07-07KVM: arm64: Assume non-PFNMAP/MIXEDMAP VMAs can be mapped cacheableAnkit Agrawal
Despite its name, kvm_is_device_pfn() is actually used to determine if a given PFN has a kernel mapping that can be used to perform cache maintenance, as it calls pfn_is_map_memory() internally. Expand the helper into its single callsite and further condition the check on the VMA having either VM_PFNMAP or VM_MIXEDMAP set. VMAs that set neither of these flags must always contain Normal, struct page backed memory with valid aliases in the kernel address space. Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: David Hildenbrand <david@redhat.com> Tested-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20250705071717.5062-3-ankita@nvidia.com [ Oliver: fixed typos, refined changelog ] Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-07KVM: arm64: Rename the device variable to s2_force_noncacheableAnkit Agrawal
To perform cache maintenance on a region of memory, KVM/arm64 relies on that region having a cacheable alias in the kernel's address space which can be used with CMO instructions. The 'device' variable is somewhat of a misnomer, as it actually indicates whether or not the stage-2 alias is allowed to have cacheable memory attributes. The resulting stage-2 memory attributes are further modified by VM_ALLOW_ANY_UNCACHED, selecting between Normal-NC or Device-nGnRE depending on what the endpoint supports. Rename the to s2_force_noncacheable such that its purpose is a bit more obvious. CC: Catalin Marinas <catalin.marinas@arm.com> Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: David Hildenbrand <david@redhat.com> Tested-by: Donald Dutile <ddutile@redhat.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20250705071717.5062-2-ankita@nvidia.com [ Oliver: addressed typos, wound up rewriting changelog ] Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-07arm64: defconfig: Enable Tegra HSP and BPMPThierry Reding
Selecting the IVC, HSP and BPMP drivers via Kconfig is problematic because it can create conflicting configurations. Instead, enable them in the default configuration. Link: https://lore.kernel.org/r/20250506133118.1011777-12-thierry.reding@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-07arm64: dts: mediatek: mt8395-genio-1200-evk: Add MT6359 PMIC key supportLouis-Alexis Eyraud
Add in mt8395-genio-1200-evk devicetree file a sub node in pmic for the mt6359-keys compatible to add the Power and Home MT6359 PMIC keys support. Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://lore.kernel.org/r/20250703-add-mt6359-pmic-keys-support-v1-3-21a4d2774e34@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07arm64: dts: mediatek: mt8390-genio-common: Add Home MT6359 PMIC key supportLouis-Alexis Eyraud
Add in mt8390-genio-common dtsi file the support of Home MT6359 PMIC key. Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Link: https://lore.kernel.org/r/20250703-add-mt6359-pmic-keys-support-v1-2-21a4d2774e34@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07arm64: dts: mediatek: mt7988a-bpi-r4: add gpio ledsFrank Wunderlich
Bananapi R4 has a green and a blue led which can be switched by gpio. Green led is for running state so default on. Green led also shares pin with eeprom writeprotect where led off allows writing to eeprom. Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250706132213.20412-14-linux@fw-web.de [Angelo: Fixed missing dt-bindings/leds/common.h header inclusion] Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07ARM: dts: imx6-karo: Replace license text comment with SPDX identifierBence Csókás
Replace verbatim license text with a `SPDX-License-Identifier` The comment header mis-attributes this license to be "X11", but the license text does not include the last line "Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.". Therefore, this license is actually equivalent to the SPDX "MIT" license (confirmed by text diffing). Cc: Lothar Waßmann <LW@KARO-electronics.de> Acked-By: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Bence Csókás <csokas.bence@prolan.hu> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-07-07arm64: dts: s32g: Add USB device tree information for s32g2/s32g3Dan Carpenter
This adds the USB support for the s32g2 and s32g3 SoCs. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/e3e5041e-254d-44c3-b645-532d4d7a8f9e@sabinyo.mountain Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-07arm64: dts: mediatek: mt7988a-bpi-r4: drop unused pinsFrank Wunderlich
Pins were moved from SoC dtsi to Board level dtsi without cleaning up to needed ones. Drop the unused pins now. Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250706132213.20412-13-linux@fw-web.de Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07arm64: dts: mediatek: mt7988a-bpi-r4: add proc-supply for cciFrank Wunderlich
CCI requires proc-supply. Add it on board level. Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250706132213.20412-12-linux@fw-web.de Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07arm64: dts: mediatek: mt7988: add cci nodeFrank Wunderlich
Add cci devicetree node for cpu frequency scaling. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250706132213.20412-9-linux@fw-web.de Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07arm64: dts: airoha: en7581: Add ethernet nodes to EN7581 SoC evaluation boardLorenzo Bianconi
Introduce ethernet controller nodes to EN7581 SoC and EN7581 evaluation board. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/20250520-en7581-net-v1-1-5317f8e829ad@kernel.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07arm64: dts: mediatek: mt8192-asurada-spherion: Mark trackpads as ↵Laura Nao
fail-needs-probe Different Spherion variants use different trackpads on the same I2C2 bus. Instead of enabling all of them by default, mark them as "fail-needs-probe" and let the implementation determine which one is actually present. Additionally, move the trackpad pinctrl entry back to the individual trackpad nodes. Signed-off-by: Laura Nao <laura.nao@collabora.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250318102259.189289-3-laura.nao@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07arm64: dts: mediatek: mt8186: Add Squirtle ChromebooksChen-Yu Tsai
Add a device tree for the MT8186 based Squirtle Chromebooks, also known as the Acer Chromebook Spin 311 (R724T). The device is a 2-in-1 convertible. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20250617082004.1653492-7-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07arm64: dts: mediatek: mt8186: Merge Voltorb device treesChen-Yu Tsai
There are only two different SKUs of Voltorb, and the only difference between them is whether a touchscreen is present or not. This can be detected by a simple I2C transfer to the address, instead of having separate device trees. Merge the two device trees together and simplify the compatible string list. The dtsi is still kept separate since there is an incoming device that shares the same design, but with slightly difference components. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20250617082004.1653492-6-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07arm64: dts: mediatek: mt8186-steelix: Mark second source components for probingChen-Yu Tsai
Steelix design has two possible trackpad component sources. Currently they are all marked as available, along with having workarounds for shared pinctrl muxing and GPIOs. Instead, mark them all as "fail-needs-probe" and have the implementation try to probe which one is present. Also remove the shared resource workaround by moving the pinctrl entry for the trackpad interrupt line back into the individual trackpad nodes. Cc: stable+noautosel@kernel.org # Needs accompanying new driver to work Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20250617082004.1653492-5-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2025-07-07Merge tag 'pm-runtime-6.17-rc1' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm into gpio/for-next Runtime PM updates related to autosuspend for 6.17 Make several autosuspend functions mark last busy stamp and update the documentation accordingly (Sakari Ailus).
2025-07-07Merge tag 'gpio-mmio-remove-bgpio-pdata-for-v6.17-rc1' into gpio/for-nextBartosz Golaszewski
Immutable branch between GPIO, MFD and ARM-SoC for v6.17-rc1 Remove struct bgpio_pdata after converting its users to generic device properties.
2025-07-07arm64: dts: freescale: imx8mm-verdin: Keep LDO5 always onFrancesco Dolcini
LDO5 regulator is used to power the i.MX8MM NVCC_SD2 I/O supply, that is used for the SD2 card interface and also for some GPIOs. When the SD card interface is not enabled the regulator subsystem could turn off this supply, since it is not used anywhere else, however this will also remove the power to some other GPIOs, for example one I/O that is used to power the ethernet phy, leading to a non working ethernet interface. [ 31.820515] On-module +V3.3_1.8_SD (LDO5): disabling [ 31.821761] PMIC_USDHC_VSELECT: disabling [ 32.764949] fec 30be0000.ethernet end0: Link is Down Fix this keeping the LDO5 supply always on. Cc: stable@vger.kernel.org Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Fixes: f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-07-07ARM: s3c: crag6410: use generic device properties for gpio-mmioBartosz Golaszewski
The GPIO device in crag6410 is registered with struct bgpio_pdata passed as platform_data to the gpio-mmio driver. We want to remove the bgpio_pdata from the kernel and the gpio-mmio driver is now also able to get the relevant values from the software node. Set up device properties and switch to using platform_device_info to register the device as platform_add_devices() doesn't allow us to pass device properties to the driver model. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-5-ebf34d273497@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07ARM: omap1: ams-delta: use generic device properties for gpio-mmioBartosz Golaszewski
The two latch GPIO devices in ams-delta are registered with struct bgpio_pdata passed as platform_data to the gpio-mmio driver. We want to remove the bgpio_pdata from the kernel and the gpio-mmio driver is now also able to get the relevant values from the software node. Set up device properties and switch to using platform_device_info to register the devices as platform_add_devices() doesn't allow us to pass device properties to the driver model. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-4-ebf34d273497@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: reg: use new GPIO line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the legacy generic gpio-reg module to using them. We have to update the two legacy ARM platforms that use it at the same time as they call the set_multiple() callbacks directly (they shouldn't but it's old technical debt I suppose). Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250623-gpiochip-set-rv-gpio-v3-1-90f0e170a846@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>