linux.git/arch/powerpc/kernel, branch v7.0

powerpc/powernv/iommu: iommu incorrectly bypass DMA APIs

2026-04-01T16:38:55+00:00

In a PowerNV environment, for devices that supports DMA mask less than
64 bit but larger than 32 bits, iommu is incorrectly bypassing DMA
APIs while allocating and mapping buffers for DMA operations.

Devices are failing with ENOMEN during probe with the following messages

amdgpu 0000:01:00.0: [drm] Detected VRAM RAM=4096M, BAR=4096M
amdgpu 0000:01:00.0: [drm] RAM width 128bits GDDR5
amdgpu 0000:01:00.0: iommu: 64-bit OK but direct DMA is limited by 0
amdgpu 0000:01:00.0: dma_iommu_get_required_mask: returning bypass mask 0xfffffffffffffff
amdgpu 0000:01:00.0:  4096M of VRAM memory ready
amdgpu 0000:01:00.0:  32570M of GTT memory ready.
amdgpu 0000:01:00.0: (-12) failed to allocate kernel bo
amdgpu 0000:01:00.0: [drm] Debug VRAM access will use slowpath MM access
amdgpu 0000:01:00.0: [drm] GART: num cpu pages 4096, num gpu pages 65536
amdgpu 0000:01:00.0: [drm] PCIE GART of 256M enabled (table at 0x000000F4FFF80000).
amdgpu 0000:01:00.0: (-12) failed to allocate kernel bo
amdgpu 0000:01:00.0: (-12) create WB bo failed
amdgpu 0000:01:00.0: amdgpu_device_wb_init failed -12
amdgpu 0000:01:00.0: amdgpu_device_ip_init failed
amdgpu 0000:01:00.0: Fatal error during GPU init
amdgpu 0000:01:00.0: finishing device.
amdgpu 0000:01:00.0: probe with driver amdgpu failed with error -12
amdgpu 0000:01:00.0:  ttm finalized

Fixes: 1471c517cf7d ("powerpc/iommu: bypass DMA APIs for coherent allocations for pre-mapped memory")
Suggested-by: Ritesh Harjani (IBM) 
Reviewed-by: Ritesh Harjani (IBM) 
Reported-by: Dan Horák 
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5039
Tested-by: Dan Horak 
Closes: https://lore.kernel.org/linuxppc-dev/20260313142351.609bc4c3efe1184f64ca5f44@danny.cz/
Signed-off-by: Gaurav Batra 
Closes: https://lore.kernel.org/linuxppc-dev/20260313142351.609bc4c3efe1184f64ca5f44@danny.cz/
[Maddy: Fixed tags]
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20260331223022.47488-1-gbatra@linux.ibm.com

Merge tag 'powerpc-7.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

2026-03-15T18:36:11+00:00

Pull powerpc fixes from Madhavan Srinivasan:

 - Fix KUAP warning in VMX usercopy path

 - Fix lockdep warning during PCI enumeration

 - Fix to move CMA reservations to arch_mm_preinit

 - Fix to check current->mm is alive before getting user callchain

Thanks to Aboorva Devarajan, Christophe Leroy (CS GROUP), Dan Horák,
Nicolin Chen, Nilay Shroff, Qiao Zhao, Ritesh Harjani (IBM), Saket Kumar
Bhaskar, Sayali Patil, Shrikanth Hegde, Venkat Rao Bagalkote, and Viktor
Malik.

* tag 'powerpc-7.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/iommu: fix lockdep warning during PCI enumeration
  powerpc/selftests/copyloops: extend selftest to exercise __copy_tofrom_user_power7_vmx
  powerpc: fix KUAP warning in VMX usercopy path
  powerpc, perf: Check that current->mm is alive before getting user callchain
  powerpc/mem: Move CMA reservations to arch_mm_preinit

powerpc/iommu: fix lockdep warning during PCI enumeration

2026-03-13T06:43:35+00:00

Commit a75b2be249d6 ("iommu: Add iommu_driver_get_domain_for_dev()
helper") introduced iommu_driver_get_domain_for_dev() for driver
code paths that hold iommu_group->mutex while attaching a device
to an IOMMU domain.

The same commit also added a lockdep assertion in
iommu_get_domain_for_dev() to ensure that callers do not hold
iommu_group->mutex when invoking it.

On powerpc platforms, when PCI device ownership is switched from
BLOCKED to the PLATFORM domain, the attach callback
spapr_tce_platform_iommu_attach_dev() still calls
iommu_get_domain_for_dev(). This happens while iommu_group->mutex
is held during domain switching, which triggers the lockdep warning
below during PCI enumeration:

WARNING: drivers/iommu/iommu.c:2252 at iommu_get_domain_for_dev+0x38/0x80, CPU#2: swapper/0/1
Modules linked in:
CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc2+ #35 PREEMPT
Hardware name: IBM,9105-22A Power11 (architected) 0x820200 0xf000007 of:IBM,FW1120.00 (RB1120_115) hv:phyp pSeries
NIP:  c000000000c244c4 LR: c00000000005b5a4 CTR: c00000000005b578
REGS: c00000000a7bf280 TRAP: 0700   Not tainted  (7.0.0-rc2+)
MSR:  8000000002029033   CR: 22004422  XER: 0000000a
CFAR: c000000000c24508 IRQMASK: 0
GPR00: c00000000005b5a4 c00000000a7bf520 c000000001dc8100 0000000000000001
GPR04: c00000000f972f10 0000000000000000 0000000000000000 0000000000000001
GPR08: 0000001ffbc60000 0000000000000001 0000000000000000 0000000000000000
GPR12: c00000000005b578 c000001fffffe480 c000000000011618 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: ffffffffffffefff 0000000000000000 c000000002d30eb0 0000000000000001
GPR24: c0000000017881f8 0000000000000000 0000000000000001 c00000000f972e00
GPR28: c00000000bbba0d0 0000000000000000 c00000000bbba0d0 c00000000f972e00
NIP [c000000000c244c4] iommu_get_domain_for_dev+0x38/0x80
LR [c00000000005b5a4] spapr_tce_platform_iommu_attach_dev+0x2c/0x98
Call Trace:
 iommu_get_domain_for_dev+0x68/0x80 (unreliable)
 spapr_tce_platform_iommu_attach_dev+0x2c/0x98
 __iommu_attach_device+0x44/0x220
 __iommu_device_set_domain+0xf4/0x194
 __iommu_group_set_domain_internal+0xec/0x228
 iommu_setup_default_domain+0x5f4/0x6a4
 __iommu_probe_device+0x674/0x724
 iommu_probe_device+0x50/0xb4
 iommu_add_device+0x48/0x198
 pci_dma_dev_setup_pSeriesLP+0x198/0x4f0
 pcibios_bus_add_device+0x80/0x464
 pci_bus_add_device+0x40/0x100
 pci_bus_add_devices+0x54/0xb0
 pcibios_init+0xd8/0x140
 do_one_initcall+0x8c/0x598
 kernel_init_freeable+0x3ec/0x850
 kernel_init+0x34/0x270
 ret_from_kernel_user_thread+0x14/0x1c

Fix this by using iommu_driver_get_domain_for_dev() instead of
iommu_get_domain_for_dev() in spapr_tce_platform_iommu_attach_dev(),
which is the appropriate helper for callers holding the group mutex.

Cc: stable@vger.kernel.org
Fixes: a75b2be249d6 ("iommu: Add iommu_driver_get_domain_for_dev() helper")
Closes: https://patchwork.ozlabs.org/project/linuxppc-dev/patch/d5c834ff-4c95-44dd-8bef-57242d63aeee@linux.ibm.com/
Signed-off-by: Nilay Shroff 
Reviewed-by: Nicolin Chen 
Tested-by: Venkat Rao Bagalkote 
[Maddy: Added Closes, tested and reviewed by tags]
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20260310082129.3630996-1-nilay@linux.ibm.com

powerpc/mem: Move CMA reservations to arch_mm_preinit

2026-03-12T05:27:31+00:00

commit 4267739cabb8 ("arch, mm: consolidate initialization of SPARSE memory model"),
changed the initialization order of "pageblock_order" from...
start_kernel()
    - setup_arch()
       - initmem_init()
         - sparse_init()
           - set_pageblock_order();  // this sets the pageblock_order
       - xxx_cma_reserve();

to...
start_kernel()
    - setup_arch()
       - xxx_cma_reserve();
    - mm_core_init_early()
       - free_area_init()
          - sparse_init()
             - set_pageblock_order() // this sets the pageblock_order.

So this means, pageblock_order is not initialized before these cma
reservation function calls, hence we are seeing CMA failures like...

[    0.000000] kvm_cma_reserve: reserving 3276 MiB for global area
[    0.000000] cma: pageblock_order not yet initialized. Called during early boot?
[    0.000000] cma: Failed to reserve 3276 MiB
....
[    0.000000][    T0] cma: pageblock_order not yet initialized. Called during early boot?
[    0.000000][    T0] cma: Failed to reserve 1024 MiB

This patch moves these CMA reservations to arch_mm_preinit() which
happens in mm_core_init() (which happens after pageblock_order is
initialized), but before the memblock moves the free memory to buddy.

Fixes: 4267739cabb8 ("arch, mm: consolidate initialization of SPARSE memory model")
Suggested-by: Mike Rapoport 
Reported-and-tested-by: Sourabh Jain 
Closes: https://lore.kernel.org/linuxppc-dev/4c338a29-d190-44f3-8874-6cfa0a031f0b@linux.ibm.com/
Signed-off-by: Ritesh Harjani (IBM) 
Tested-by: Dan Horák 
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/6e532cf0db5be99afbe20eed699163d5e86cd71f.1772303986.git.ritesh.list@gmail.com

Merge tag 'powerpc-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

2026-03-11T15:35:31+00:00

Pull powerpc fixes from Madhavan Srinivasan:
 - Correct MSI allocation tracking
 - Always use 64 bits PTE for powerpc/e500
 - Fix inline assembly for clang build on PPC32
 - Fixes for clang build issues in powerpc64/ftrace
 - Fixes for powerpc64/bpf JIT and tailcall support
 - Cleanup MPC83XX devicetrees
 - Fix keymile vendor prefix
 - Fix to use big-endian types for crash variables

Thanks to Abhishek Dubey, Christophe Leroy (CS GROUP), Hari Bathini,
Heiko Schocher, J. Neuschäfer, Mahesh Salgaonkar, Nam Cao, Nilay Shroff,
Rob Herring (Arm), Saket Kumar Bhaskar, Sourabh Jain, Stan Johnson, and
Venkat Rao Bagalkote.

* tag 'powerpc-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (23 commits)
  powerpc/pseries: Correct MSI allocation tracking
  powerpc: dts: mpc83xx: Add unit addresses to /memory
  powerpc: dts: mpc8315erdb: Add missing #cells properties to SPI bus
  powerpc: dts: mpc8315erdb: Rename LED nodes to comply with schema
  powerpc: dts: mpc8315erdb: Use IRQ_TYPE_* macros
  powerpc: dts: mpc8313erdb: Use IRQ_TYPE_* macros
  powerpc: 83xx: km83xx: Fix keymile vendor prefix
  dt-bindings: powerpc: Add Freescale/NXP MPC83xx SoCs
  powerpc64/bpf: fix kfunc call support
  powerpc64/bpf: fix handling of BPF stack in exception callback
  powerpc64/bpf: remove BPF redzone protection in trampoline stack
  powerpc64/bpf: use consistent tailcall offset in trampoline
  powerpc64/bpf: fix the address returned by bpf_get_func_ip
  powerpc64/bpf: do not increment tailcall count when prog is NULL
  powerpc64/ftrace: workaround clang recording GEP in __patchable_function_entries
  powerpc64/ftrace: fix OOL stub count with clang
  powerpc64: make clang cross-build friendly
  powerpc/crash: adjust the elfcorehdr size
  powerpc/kexec/core: use big-endian types for crash variables
  powerpc/prom_init: Fixup missing #size-cells on PowerMac media-bay nodes
  ...

powerpc64/ftrace: workaround clang recording GEP in __patchable_function_entries

2026-03-07T10:32:25+00:00

Support for -fpatchable-function-entry on ppc64le was added in Clang
with [1]. However, when no prefix NOPs are specified - as is the case
with CONFIG_PPC_FTRACE_OUT_OF_LINE - the first NOP is emitted at LEP,
but Clang records the Global Entry Point (GEP) unlike GCC which does
record the Local Entry Point (LEP). Issue [2] has been raised to align
Clang's behavior with GCC. As a temporary workaround to ensure ftrace
initialization works as expected with Clang, derive the LEP using
ppc_function_entry() for kernel symbols and by looking for the below
module GEP sequence for module addresses, until [2] is resolved:

	ld	r2, -8(r12)
	add	r2, r2, r12

[1] https://github.com/llvm/llvm-project/pull/151569
[2] https://github.com/llvm/llvm-project/issues/163706

Signed-off-by: Hari Bathini 
Tested-by: Venkat Rao Bagalkote 
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20260127084926.34497-4-hbathini@linux.ibm.com

Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux

2026-03-07T04:27:13+00:00

Pull Kbuild fixes from Nathan Chancellor:

 - Split out .modinfo section from ELF_DETAILS macro, as that macro may
   be used in other areas that expect to discard .modinfo, breaking
   certain image layouts

 - Adjust genksyms parser to handle optional attributes in certain
   declarations, necessary after commit 07919126ecfc ("netfilter:
   annotate NAT helper hook pointers with __rcu")

 - Include resolve_btfids in external module build created by
   scripts/package/install-extmod-build when it may be run on external
   modules

 - Avoid removing objtool binary with 'make clean', as it is required
   for external module builds

* tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux:
  kbuild: Leave objtool binary around with 'make clean'
  kbuild: install-extmod-build: Package resolve_btfids if necessary
  genksyms: Fix parsing a declarator with a preceding attribute
  kbuild: Split .modinfo out from ELF_DETAILS

powerpc/prom_init: Fixup missing #size-cells on PowerMac media-bay nodes

2026-03-04T05:37:36+00:00

Similar to other PowerMac mac-io devices, the media-bay node is missing the
"#size-cells" property.

Depends-on: commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling")
Reported-by: Stan Johnson 
Signed-off-by: Rob Herring (Arm) 
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20251029174047.1620073-1-robh@kernel.org

powerpc/e500: Always use 64 bits PTE

2026-03-04T05:35:06+00:00

Today there are two PTE formats for e500:
- The 64 bits format, used
 - On 64 bits kernel
 - On 32 bits kernel with 64 bits physical addresses
 - On 32 bits kernel with support of huge pages
- The 32 bits format, used in other cases

Maintaining two PTE formats means unnecessary maintenance burden
because every change needs to be implemented and tested for both
formats.

Remove the 32 bits PTE format. The memory usage increase due to
larger PTEs is minimal (approx. 0,1% of memory).

This also means that from now on huge pages are supported also
with 32 bits physical addresses.

Signed-off-by: Christophe Leroy 
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/04a658209ea78dcc0f3dbde6b2c29cf1939adfe9.1767721208.git.chleroy@kernel.org

powerpc/pci: Initialize msi_addr_mask for OF-created PCI devices

2026-03-03T16:29:15+00:00

Recent changes replaced the use of no_64bit_msi with msi_addr_mask.  As a
result, msi_addr_mask is now expected to be initialized to DMA_BIT_MASK(64)
when a pci_dev is set up. However, this initialization was missed on
powerpc due to differences in the device initialization path compared to
other (x86) architecture. Due to this, now PCI device probe method fails on
powerpc system.

On powerpc systems, struct pci_dev instances are created from device tree
nodes via of_create_pci_dev(). Because msi_addr_mask was not initialized
there, it remained zero. Later, during MSI setup, msi_verify_entries()
validates the programmed MSI address against pdev->msi_addr_mask. Since the
mask was not set correctly, the validation fails, causing PCI driver probe
failures for devices on powerpc systems.

Initialize pdev->msi_addr_mask to DMA_BIT_MASK(64) in of_create_pci_dev()
so that MSI address validation succeeds and device probe works as expected.

Fixes: 386ced19e9a3 ("PCI/MSI: Convert the boolean no_64bit_msi flag to a DMA address mask")
Signed-off-by: Nilay Shroff 
Signed-off-by: Bjorn Helgaas 
Tested-by: Venkat Rao Bagalkote 
Tested-by: Nam Cao 
Reviewed-by: Nam Cao 
Reviewed-by: Vivian Wang 
Acked-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20260220070239.1693303-2-nilay@linux.ibm.com