linux-toradex.git/arch/sparc/kernel/pci.c, branch v6.19

sparc/PCI: Correct 64-bit non-pref -> pref BAR resources

2026-01-07T20:22:32+00:00

SPARC T5-2 dts describes some PCI BARs as 64-bit resources without the
pref(etchable) bit (0x83... vs 0xc3... in assigned-addresses) for address
ranges above the 4G threshold. Such resources cannot be placed into a
non-prefetchable PCI bridge window that is capable only of 32-bit
addressing. As such, it looks like the platform is improperly described by
the dts.

The kernel detects this problem (see the IORESOURCE_PREFETCH check in
pci_find_parent_resource()) and fails to assign these BAR resources to the
resource tree due to lack of a compatible bridge window.

Prior to 754babaaf333 ("sparc/PCI: Remove pcibios_enable_device() as they
do nothing extra") SPARC arch code did not test whether device resources
were successfully in the resource tree when enabling a device, effectively
hiding the problem. After removing the arch-specific enable code,
pci_enable_resources() refuses to enable the device when it finds not all
mem resources are assigned, and therefore mpt3sas can't be enabled:

pci 0001:04:00.0: reg 0x14: [mem 0x801110000000-0x80111000ffff 64bit]
pci 0001:04:00.0: reg 0x1c: [mem 0x801110040000-0x80111007ffff 64bit]
pci 0001:04:00.0: BAR 1 [mem 0x801110000000-0x80111000ffff 64bit]: can't claim; no compatible bridge window
pci 0001:04:00.0: BAR 3 [mem 0x801110040000-0x80111007ffff 64bit]: can't claim; no compatible bridge window
mpt3sas 0001:04:00.0: BAR 1 [mem size 0x00010000 64bit]: not assigned; can't enable device

For clarity, this filtered log only shows failures for one mpt3sas device
but other devices fail similarly. In the reported case, the end result with
all the failures is an unbootable system.

Things appeared to "work" before 754babaaf333 ("sparc/PCI: Remove
pcibios_enable_device() as they do nothing extra") because the resource
tree is agnostic to whether PCI BAR resources are properly in the tree or
not. So as long as there was a parent resource (e.g. a root bus resource)
that contains the address range, the resource tree code just places
resource request underneath it without any consideration to the
intermediate BAR resource. While it worked, it's incorrect setup still.

Add an OF fixup to set the IORESOURCE_PREFETCH flag for a 64-bit PCI
resource that has the end address above 4G requiring placement into the
prefetchable window. Also log the issue.

Fixes: 754babaaf333 ("sparc/PCI: Remove pcibios_enable_device() as they do nothing extra")
Reported-by: Nathaniel Roach
Closes: https://github.com/sparclinux/issues/issues/22
Signed-off-by: Ilpo Järvinen
Signed-off-by: Bjorn Helgaas
Tested-by: Nathaniel Roach
Link: https://patch.msgid.link/20251124170411.3709-1-ilpo.jarvinen@linux.intel.com

sparc/PCI: Remove pcibios_enable_device() as they do nothing extra

2025-09-16T16:18:44+00:00

Under arch/sparc/ there are multiple copies of pcibios_enable_device() but
none of those seem to do anything extra beyond what pci_enable_resources()
is supposed to do. These functions could lead to inconsistencies in
behavior, especially now as pci_enable_resources() and the bridge window
resource flags behavior are going to be altered by upcoming changes.

Remove all pcibios_enable_device() from arch/sparc/ so that PCI core can
simply call into pci_enable_resources() instead using its __weak version
of pcibios_enable_device().

Signed-off-by: Ilpo Järvinen 
Signed-off-by: Bjorn Helgaas 
Link: https://patch.msgid.link/20250829131113.36754-3-ilpo.jarvinen@linux.intel.com

sparc: replace zero-length array with flexible-array member

2025-01-17T15:33:27+00:00

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1],
introduced in C99:

struct foo {
	int stuff;
	struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last, which is beneficial
to cultivate a high-quality code.[2]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Zhang Kunbo 
Reviewed-by: Andreas Larsson 
Link: https://lore.kernel.org/r/20241218074439.3271397-1-zhangkunbo@huawei.com
Signed-off-by: Andreas Larsson

sparc: Fix typos

2024-02-16T15:50:25+00:00

Fix typos, most reported by "codespell arch/sparc".  Only touches
comments, no code changes.

Signed-off-by: Bjorn Helgaas 
Cc: sparclinux@vger.kernel.org
Reviewed-by: Randy Dunlap 
Signed-off-by: Andreas Larsson 
Link: https://lore.kernel.org/r/20240103231605.1801364-9-helgaas@kernel.org

sparc: Explicitly include correct DT includes

2023-08-28T18:30:57+00:00

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Acked-by: Sam Ravnborg 
Link: https://lore.kernel.org/all/20230718143211.1066810-1-robh@kernel.org/
Signed-off-by: Rob Herring

PCI: Introduce pci_dev_for_each_resource()

2023-04-04T15:43:52+00:00

Instead of open-coding it everywhere introduce a tiny helper that can be
used to iterate over each resource of a PCI device, and convert the most
obvious users into it.

While at it drop doubled empty line before pdev_sort_resources().

No functional changes intended.

Suggested-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20230330162434.35055-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Mika Westerberg 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Krzysztof Wilczyński

sparc: Use generic pci_mmap_resource_range()

2022-07-29T17:09:32+00:00

The main feature of the sparc-specific implementation of
pci_mmap_resource_range() is that it allows mapping the entire PCI I/O
space for a PCI host bridge using the /proc/bus/pci interface on a bridge
device.

The generic implementation cannot do this, but it also appears that this
got broken for sparc by commit 9eff02e2042f ("PCI: check mmap range of
/proc/bus/pci files too"), which enforces that each address is part of a
BAR for kernels after 2.6.28.

Remove it all, assuming that the corresponding user space code has already
been changed to access /dev/ioport instead a long time ago.  Add
pci_iobar_pfn() to make it possible to map I/O resources. This is adapted
from the powerpc version.

Link: https://lore.kernel.org/lkml/1519887203.622.3.camel@infradead.org/t/
Link: https://lore.kernel.org/r/20220715153617.3393420-2-arnd@kernel.org
Signed-off-by: Arnd Bergmann 
Signed-off-by: Bjorn Helgaas

PCI: Remove pci_mmap_page_range() wrapper

2022-07-29T17:08:44+00:00

The ARCH_GENERIC_PCI_MMAP_RESOURCE symbol came up in a recent discussion,
and I noticed that this was left behind by an unfinished cleanup from 2017.

The only architecture that still relies on providing its own
pci_mmap_page_range() helper instead of using the generic
pci_mmap_resource_range() is sparc. Presumably the reasons for this have
not changed, but at least this can be simplified by converting sparc to use
the same interface as the others.

The only difference between the two is the device-specific offset that gets
added to or subtracted from vma->vm_pgoff.

Change the only caller of pci_mmap_page_range() in common code to subtract
this offset and call the modern interface, while adding it back in the
sparc implementation to preserve the existing behavior.

This removes the complexities of the dual interfaces from the common code,
and keeps it all specific to the sparc architecture code. According to
David Miller, the sparc code lets user space poke into the VGA I/O port
registers by mmapping the I/O space of the parent bridge device, which is
something that the generic pci_mmap_resource_range() code apparently does
not.

Link: https://lore.kernel.org/lkml/1519887203.622.3.camel@infradead.org/t/
Link: https://lore.kernel.org/lkml/20220714214657.2402250-3-shorne@gmail.com/
Link: https://lore.kernel.org/r/20220715153617.3393420-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann 
Signed-off-by: Bjorn Helgaas 
Cc: David Woodhouse 
Cc: David S. Miller 
Cc: Stafford Horne

PCI: Rename pcibios_add_device() to pcibios_device_add()

2021-09-21T20:26:09+00:00

The general convention for pcibios_* hooks is that they're named after the
corresponding pci_* function they provide a hook for. The exception is
pcibios_add_device() which provides a hook for pci_device_add().

Rename pcibios_add_device() to pcibios_device_add() so it matches
pci_device_add().

Also, remove the export of the microblaze version. The only caller must be
compiled as a built-in so there's no reason for the export.

Link: https://lore.kernel.org/r/20210913152709.48013-1-oohall@gmail.com
Signed-off-by: Oliver O'Halloran 
Signed-off-by: Bjorn Helgaas 
Acked-by: Niklas Schnelle 	# s390

sparc: use for_each_child_of_node() macro

2020-08-06T00:51:51+00:00

Use for_each_child_of_node() macro instead of open coding it.

Signed-off-by: Qinglang Miao 
Signed-off-by: David S. Miller