Hi,
This is the third iteration to improve handling of the 64-bit
attribute on non-prefetchable host bridge ranges. Previous version can
be found at [0][1].
This version is a small update over the previous version - changelog
below. If there is no futher feedback on the patches, please consider
merging them.
Thanks,
Punit
Changes:
v3:
* Improved commit log for clarity (Patch 1)
* Added Tested-by tags
v2:
* Check ranges PCI / bus addresses rather than CPU addresses
* (new) Restrict 32-bit size warnings on ranges that don't have the 64-bit attribute set
* Refactor the 32-bit size warning to the range parsing loop. This
change also prints the warnings right after the window mappings are
logged.
[0] https://lore.kernel.org/linux-arm-kernel/20210527150541.3130505-1-punitagrawal@gmail.com/
[1] https://lore.kernel.org/linux-pci/20210531221057.3406958-1-punitagrawal@gmail.com/
Punit Agrawal (4):
PCI: of: Clear 64-bit flag for non-prefetchable memory below 4GB
PCI: of: Relax the condition for warning about non-prefetchable memory
aperture size
PCI: of: Refactor the check for non-prefetchable 32-bit window
arm64: dts: rockchip: Update PCI host bridge window to 32-bit address
memory
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
drivers/pci/of.c | 17 ++++++++++++-----
2 files changed, 13 insertions(+), 6 deletions(-)
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Recently, an override was added for non-prefetchable host bridge
windows below 4GB that have the 64-bit address attribute set. As many
of the conditions for the check overlap with the check for
non-prefetchable window size, refactor the code to unify the ranges
validation into devm_of_pci_get_host_bridge_resources().
As an added benefit, the warning message is now printed right after
the range mapping giving the user a better indication of where the
issue is.
Signed-off-by: Punit Agrawal <redacted>
Tested-by: Alexandru Elisei <redacted>
Cc: Vidya Sagar <redacted>
---
drivers/pci/of.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
@@ -355,11 +355,15 @@ static int devm_of_pci_get_host_bridge_resources(struct device *dev,*io_base=range.cpu_addr;}elseif(resource_type(res)==IORESOURCE_MEM){if(!(res->flags&IORESOURCE_PREFETCH)){-if(res->flags&IORESOURCE_MEM_64)+if(res->flags&IORESOURCE_MEM_64){if(!upper_32_bits(range.pci_addr+range.size-1)){dev_warn(dev,"Clearing 64-bit flag for non-prefetchable memory below 4GB\n");res->flags&=~IORESOURCE_MEM_64;}+}else{+if(upper_32_bits(resource_size(res)))+dev_warn(dev,"Memory resource size exceeds max for 32 bits\n");+}}}
@@ -579,12 +583,6 @@ static int pci_parse_request_of_pci_ranges(struct device *dev,break;caseIORESOURCE_MEM:res_valid|=!(res->flags&IORESOURCE_PREFETCH);--if(!(res->flags&IORESOURCE_PREFETCH))-if(!(res->flags&IORESOURCE_MEM_64)&&-upper_32_bits(resource_size(res)))-dev_warn(dev,"Memory resource size exceeds max for 32 bits\n");-break;}}
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Commit fede8526cc48 ("PCI: of: Warn if non-prefetchable memory
aperture size is > 32-bit") introduced a warning for non-prefetchable
resources that need more than 32bits to resolve. It turns out that the
check is too restrictive and should be applicable to only resources
that are limited to host bridge windows that don't have the ability to
map 64-bit address space.
Relax the condition to only warn when the resource size requires >
32-bits and doesn't allow mapping to 64-bit addresses.
Link: https://lore.kernel.org/r/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com
Signed-off-by: Punit Agrawal <redacted>
Tested-by: Alexandru Elisei <redacted>
Cc: Vidya Sagar <redacted>
---
drivers/pci/of.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Some host bridges advertise non-prefetchable memory windows that are
entirely located below 4GB but are marked as 64-bit address memory.
Since commit 9d57e61bf723 ("of/pci: Add IORESOURCE_MEM_64 to resource
flags for 64-bit memory addresses"), the OF PCI range parser takes a
stricter view and treats 64-bit address ranges as advertised while
before such ranges were treated as 32-bit.
A PCI root port modelled as a PCI-to-PCI bridge cannot forward 64-bit
non-prefetchable memory ranges. As a result, the change in behaviour
due to the commit causes failure to allocate 32-bit BAR from a 64-bit
non-prefetchable window.
In order to not break platforms where non-prefetchable memory ranges
lie entirely below 4GB, clear the 64-bit flag.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com
Signed-off-by: Punit Agrawal <redacted>
Tested-by: Alexandru Elisei <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Rob Herring <robh+dt@kernel.org>
---
drivers/pci/of.c | 8 ++++++++
1 file changed, 8 insertions(+)
@@ -353,6 +353,14 @@ static int devm_of_pci_get_host_bridge_resources(struct device *dev,dev_warn(dev,"More than one I/O resource converted for %pOF. CPU base address for old range lost!\n",dev_node);*io_base=range.cpu_addr;+}elseif(resource_type(res)==IORESOURCE_MEM){+if(!(res->flags&IORESOURCE_PREFETCH)){+if(res->flags&IORESOURCE_MEM_64)+if(!upper_32_bits(range.pci_addr+range.size-1)){+dev_warn(dev,"Clearing 64-bit flag for non-prefetchable memory below 4GB\n");+res->flags&=~IORESOURCE_MEM_64;+}+}}pci_add_resource_offset(resources,res,res->start-range.pci_addr);
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
The PCIe host bridge on RK3399 advertises a single 64-bit memory
address range even though it lies entirely below 4GB.
Previously the OF PCI range parser treated 64-bit ranges more
leniently (i.e., as 32-bit), but since commit 9d57e61bf723 ("of/pci:
Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses")
the code takes a stricter view and treats the ranges as advertised in
the device tree (i.e, as 64-bit).
The change in behaviour causes failure when allocating bus addresses
to devices connected behind a PCI-to-PCI bridge that require
non-prefetchable memory ranges. The allocation failure was observed
for certain Samsung NVMe drives connected to RockPro64 boards.
Update the host bridge window attributes to treat it as 32-bit address
memory. This fixes the allocation failure observed since commit
9d57e61bf723.
Reported-by: Alexandru Elisei <redacted>
Link: https://lore.kernel.org/r/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Punit Agrawal <redacted>
Tested-by: Alexandru Elisei <redacted>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Rob Herring <robh+dt@kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
External email: Use caution opening links or attachments
Commit fede8526cc48 ("PCI: of: Warn if non-prefetchable memory
aperture size is > 32-bit") introduced a warning for non-prefetchable
resources that need more than 32bits to resolve. It turns out that the
check is too restrictive and should be applicable to only resources
that are limited to host bridge windows that don't have the ability to
map 64-bit address space.
I think the host bridge windows having the ability to map 64-bit address
space is different from restricting the non-prefetchable memory aperture
size to 32-bit.
Whether the host bridge uses internal translations or not to map the
non-prefetchable resources to 64-bit space, the size needs to be
programmed in the host bridge's 'Memory Limit Register (Offset 22h)'
which can represent sizes only fit into 32-bits.
Host bridges having the ability to map 64-bit address spaces gives
flexibility to utilize the vast 64-bit space for the (restrictive)
non-prefetchable memory (i.e. mapping non-prefetchable BARs of endpoints
to the 64-bit space in CPU's view) and get it translated internally and
put a 32-bit address on the PCIe bus finally.
- Vidya Sagar
quoted hunk
Relax the condition to only warn when the resource size requires >
32-bits and doesn't allow mapping to 64-bit addresses.
Link: https://lore.kernel.org/r/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com
Signed-off-by: Punit Agrawal <redacted>
Tested-by: Alexandru Elisei <redacted>
Cc: Vidya Sagar <redacted>
---
drivers/pci/of.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Marc Zyngier <maz@kernel.org> Date: 2021-06-09 16:08:39
Hi Punit,
On Mon, 07 Jun 2021 12:28:52 +0100,
Punit Agrawal [off-list ref] wrote:
Hi,
This is the third iteration to improve handling of the 64-bit
attribute on non-prefetchable host bridge ranges. Previous version can
be found at [0][1].
This version is a small update over the previous version - changelog
below. If there is no futher feedback on the patches, please consider
merging them.
Thanks for this. This brings my test machine back to life:
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Any chance this could hit upstream shortly? RK3399 is a fairly popular
SoC, and a number of us are running test boxes based on it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[+cc Leonardo]
On Mon, Jun 07, 2021 at 08:28:53PM +0900, Punit Agrawal wrote:
Some host bridges advertise non-prefetchable memory windows that are
entirely located below 4GB but are marked as 64-bit address memory.
Since commit 9d57e61bf723 ("of/pci: Add IORESOURCE_MEM_64 to resource
flags for 64-bit memory addresses"), the OF PCI range parser takes a
stricter view and treats 64-bit address ranges as advertised while
before such ranges were treated as 32-bit.
A PCI root port modelled as a PCI-to-PCI bridge cannot forward 64-bit
non-prefetchable memory ranges. As a result, the change in behaviour
due to the commit causes failure to allocate 32-bit BAR from a 64-bit
non-prefetchable window.
In order to not break platforms where non-prefetchable memory ranges
lie entirely below 4GB, clear the 64-bit flag.
I don't think we should care about the address width DT supplies for a
host bridge window. Prior to 9d57e61bf723, I don't think we *did*
care because of_bus_pci_get_flags() threw away that information.
My proposal for a commit log, including information about the problem
report and a "Fixes:" tag:
Alexandru and Qu reported this resource allocation failure on
ROCKPro64 v2 and ROCK Pi 4B, both based on the RK3399:
pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff 64bit]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: BAR 14: no space for [mem size 0x00100000]
pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
"BAR 14" is the PCI bridge's 32-bit non-prefetchable window, and our
PCI allocation code isn't smart enough to allocate it in a host
bridge window marked as 64-bit, even though this should work fine.
A DT host bridge description includes the windows from the CPU
address space to the PCI bus space. On a few architectures
(microblaze, powerpc, sparc), the DT may also describe PCI devices
themselves, including their BARs.
Before 9d57e61bf723 ("of/pci: Add IORESOURCE_MEM_64 to resource
flags for 64-bit memory addresses"), of_bus_pci_get_flags() ignored
the fact that some DT addresses described 64-bit windows and BARs.
That was a problem because the virtio virtual NIC has a 32-bit BAR
and a 64-bit BAR, and the driver couldn't distinguish them.
9d57e61bf723 set IORESOURCE_MEM_64 for those 64-bit DT ranges, which
fixed the virtio driver. But it also set IORESOURCE_MEM_64 for host
bridge windows, which exposed the fact that the PCI allocator isn't
smart enough to put 32-bit resources in those 64-bit windows.
Clear IORESOURCE_MEM_64 from host bridge windows since we don't need
that information.
Fixes: 9d57e61bf723 ("of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses")
Reported-at: https://lore.kernel.org/lkml/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com/
Reported-by: Alexandru Elisei [off-list ref]
Reported-by: Qu Wenruo [off-list ref]
@@ -353,6 +353,14 @@ static int devm_of_pci_get_host_bridge_resources(struct device *dev,dev_warn(dev,"More than one I/O resource converted for %pOF. CPU base address for old range lost!\n",dev_node);*io_base=range.cpu_addr;+}elseif(resource_type(res)==IORESOURCE_MEM){+if(!(res->flags&IORESOURCE_PREFETCH)){+if(res->flags&IORESOURCE_MEM_64)+if(!upper_32_bits(range.pci_addr+range.size-1)){+dev_warn(dev,"Clearing 64-bit flag for non-prefetchable memory below 4GB\n");+res->flags&=~IORESOURCE_MEM_64;+}+}
Why do we need to check IORESOURCE_PREFETCH, IORESOURCE_MEM_64, and
upper_32_bits()? If I understand this correctly, prior to
9d57e61bf723, IORESOURCE_MEM_64 was *never* set here. Isn't something
like this sufficient?
} else if (resource_type(res) == IORESOURCE_MEM) {
res->flags &= ~IORESOURCE_MEM_64;
}
I'm not sure we need a warning either. We didn't warn before
9d57e61bf723, and there's nothing the user needs to do anyway.
On Wed, Jun 09, 2021 at 12:36:08AM +0530, Vidya Sagar wrote:
On 6/7/2021 4:58 PM, Punit Agrawal wrote:
quoted
Commit fede8526cc48 ("PCI: of: Warn if non-prefetchable memory
aperture size is > 32-bit") introduced a warning for non-prefetchable
resources that need more than 32bits to resolve. It turns out that the
check is too restrictive and should be applicable to only resources
that are limited to host bridge windows that don't have the ability to
map 64-bit address space.
I think the host bridge windows having the ability to map 64-bit address
space is different from restricting the non-prefetchable memory aperture
size to 32-bit.
Whether the host bridge uses internal translations or not to map the
non-prefetchable resources to 64-bit space, the size needs to be programmed
in the host bridge's 'Memory Limit Register (Offset 22h)' which can
represent sizes only fit into 32-bits.
Host bridges having the ability to map 64-bit address spaces gives
flexibility to utilize the vast 64-bit space for the (restrictive)
non-prefetchable memory (i.e. mapping non-prefetchable BARs of endpoints to
the 64-bit space in CPU's view) and get it translated internally and put a
32-bit address on the PCIe bus finally.
The vastness of the 64-bit space in the CPU view only helps with
non-prefetchable memory if you have multiple host bridges with
different CPU-to-PCI translations. Each root bus can only carve up
4GB of PCI memory space for use by its non-prefetchable memory
windows.
Of course, if we're willing to give up the performance, there's
nothing to prevent us from using non-prefetchable space for
*prefetchable* resources, as in my example below.
I think the fede8526cc48 commit log is incorrect, or at least
incomplete:
As per PCIe spec r5.0, sec 7.5.1.3.8 only 32-bit BAR registers are defined
for non-prefetchable memory and hence a warning should be reported when
the size of them go beyond 32-bits.
7.5.1.3.8 is talking about non-prefetchable PCI-to-PCI bridge windows,
not BARs. AFAIK, 64-bit BARs may be non-prefetchable. The warning is
in pci_parse_request_of_pci_ranges(), which isn't looking at
PCI-to-PCI bridge windows; it's looking at PCI host bridge windows.
It's legal for a host bridge to have only non-prefetchable windows,
and prefetchable PCI BARs can be placed in them.
For example, we could have the following:
pci_bus 0000:00: root bus resource [mem 0x80000000-0x1_ffffffff] (6GB)
pci 0000:00:00.0: PCI bridge to [bus 01-7f]
pci 0000:00:00.0: bridge window [mem 0x80000000-0xbfffffff] (1GB)
pci 0000:00:00.0: bridge window [mem 0x1_00000000-0x1_7fffffff 64bit pref] (2GB)
pci 0000:00:00.1: PCI bridge to [bus 80-ff]
pci 0000:00:00.1: bridge window [mem 0xc0000000-0xffffffff] (1GB)
pci 0000:00:00.1: bridge window [mem 0x1_80000000-0x1_ffffffff 64bit pref] (2GB)
Here the host bridge window is 6GB and is not prefetchable. The
PCI-to-PCI bridge non-prefetchable windows are 1GB each and the bases
and limits fit in 32 bits. The prefetchable windows are 2GB each, and
we're allowed but not required to put these in prefetchable host
bridge windows.
So I'm not convinced this warning is valid to begin with. It may be
that this host bridge configuration isn't optimal, and we might want
an informational message, but I think it's *legal*.
quoted
Relax the condition to only warn when the resource size requires >
32-bits and doesn't allow mapping to 64-bit addresses.
Link: https://lore.kernel.org/r/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com
Signed-off-by: Punit Agrawal <redacted>
Tested-by: Alexandru Elisei <redacted>
Cc: Vidya Sagar <redacted>
---
drivers/pci/of.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Hi Punit,
On Mon, 7 Jun 2021 at 17:02, Punit Agrawal [off-list ref] wrote:
Hi,
This is the third iteration to improve handling of the 64-bit
attribute on non-prefetchable host bridge ranges. Previous version can
be found at [0][1].
This version is a small update over the previous version - changelog
below. If there is no futher feedback on the patches, please consider
merging them.
Thanks,
Punit
Thanks for your work, I have tested this on my RK3399 (Odroid N1) SBC.
It partially works on this board. So I looked into
RK3399TRM_V1.3_Part2 for more details.
17.6.7.1.45 Root Complex BAR Configuration Register
It looks like these config changes are related to the issue you are
trying to solve.
On this basis here are the code changes I made in the driver for testing.
[alarm@alarm linux-rockchip-5.y-devel]$ git diff
drivers/pci/controller/pcie-rockchip.h
drivers/pci/controller/pcie-rockchip.c
Hi,
Am Montag, 7. Juni 2021, 13:28:56 CEST schrieb Punit Agrawal:
The PCIe host bridge on RK3399 advertises a single 64-bit memory
address range even though it lies entirely below 4GB.
Previously the OF PCI range parser treated 64-bit ranges more
leniently (i.e., as 32-bit), but since commit 9d57e61bf723 ("of/pci:
Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses")
the code takes a stricter view and treats the ranges as advertised in
the device tree (i.e, as 64-bit).
The change in behaviour causes failure when allocating bus addresses
to devices connected behind a PCI-to-PCI bridge that require
non-prefetchable memory ranges. The allocation failure was observed
for certain Samsung NVMe drives connected to RockPro64 boards.
Update the host bridge window attributes to treat it as 32-bit address
memory. This fixes the allocation failure observed since commit
9d57e61bf723.
Reported-by: Alexandru Elisei <redacted>
Link: https://lore.kernel.org/r/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Punit Agrawal <redacted>
Tested-by: Alexandru Elisei <redacted>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Rob Herring <robh+dt@kernel.org>
just for clarity, should I just pick this patch separately for 5.13-rc to
make it easy for people using current kernel devicetrees, or should
this wait for the update mentioned in the cover-letter response
and should go all together through the PCI tree?
If so, I can provide an
Acked-by: Heiko Stuebner <heiko@sntech.de>
On Mon, 7 Jun 2021 20:28:52 +0900, Punit Agrawal wrote:
This is the third iteration to improve handling of the 64-bit
attribute on non-prefetchable host bridge ranges. Previous version can
be found at [0][1].
This version is a small update over the previous version - changelog
below. If there is no futher feedback on the patches, please consider
merging them.
[...]
Applied, thanks!
[4/4] arm64: dts: rockchip: Update PCI host bridge window to 32-bit address memory
commit: 8efe01b4386ab38a36b99cfdc1dc02c38a8898c3
Best regards,
--
Heiko Stuebner [off-list ref]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh+dt@kernel.org> Date: 2021-06-15 21:29:27
On Thu, Jun 10, 2021 at 3:50 PM Heiko Stübner [off-list ref] wrote:
Hi,
Am Montag, 7. Juni 2021, 13:28:56 CEST schrieb Punit Agrawal:
quoted
The PCIe host bridge on RK3399 advertises a single 64-bit memory
address range even though it lies entirely below 4GB.
Previously the OF PCI range parser treated 64-bit ranges more
leniently (i.e., as 32-bit), but since commit 9d57e61bf723 ("of/pci:
Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses")
the code takes a stricter view and treats the ranges as advertised in
the device tree (i.e, as 64-bit).
The change in behaviour causes failure when allocating bus addresses
to devices connected behind a PCI-to-PCI bridge that require
non-prefetchable memory ranges. The allocation failure was observed
for certain Samsung NVMe drives connected to RockPro64 boards.
Update the host bridge window attributes to treat it as 32-bit address
memory. This fixes the allocation failure observed since commit
9d57e61bf723.
Reported-by: Alexandru Elisei <redacted>
Link: https://lore.kernel.org/r/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Punit Agrawal <redacted>
Tested-by: Alexandru Elisei <redacted>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Rob Herring <robh+dt@kernel.org>
just for clarity, should I just pick this patch separately for 5.13-rc to
make it easy for people using current kernel devicetrees, or should
this wait for the update mentioned in the cover-letter response
and should go all together through the PCI tree?
This was dropped from v4, but should still be applied IMO.
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Am Dienstag, 15. Juni 2021, 23:29:12 CEST schrieb Rob Herring:
On Thu, Jun 10, 2021 at 3:50 PM Heiko Stübner [off-list ref] wrote:
quoted
Hi,
Am Montag, 7. Juni 2021, 13:28:56 CEST schrieb Punit Agrawal:
quoted
The PCIe host bridge on RK3399 advertises a single 64-bit memory
address range even though it lies entirely below 4GB.
Previously the OF PCI range parser treated 64-bit ranges more
leniently (i.e., as 32-bit), but since commit 9d57e61bf723 ("of/pci:
Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses")
the code takes a stricter view and treats the ranges as advertised in
the device tree (i.e, as 64-bit).
The change in behaviour causes failure when allocating bus addresses
to devices connected behind a PCI-to-PCI bridge that require
non-prefetchable memory ranges. The allocation failure was observed
for certain Samsung NVMe drives connected to RockPro64 boards.
Update the host bridge window attributes to treat it as 32-bit address
memory. This fixes the allocation failure observed since commit
9d57e61bf723.
Reported-by: Alexandru Elisei <redacted>
Link: https://lore.kernel.org/r/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Punit Agrawal <redacted>
Tested-by: Alexandru Elisei <redacted>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Rob Herring <robh+dt@kernel.org>
just for clarity, should I just pick this patch separately for 5.13-rc to
make it easy for people using current kernel devicetrees, or should
this wait for the update mentioned in the cover-letter response
and should go all together through the PCI tree?
This was dropped from v4, but should still be applied IMO.