[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZxJXZ9R-Qp9CNmJk@apocalypse>
Date: Fri, 18 Oct 2024 14:41:11 +0200
From: Andrea della Porta <andrea.porta@...e.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Andrea della Porta <andrea.porta@...e.com>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Florian Fainelli <florian.fainelli@...adcom.com>,
Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
Linus Walleij <linus.walleij@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Derek Kiernan <derek.kiernan@....com>,
Dragan Cvetic <dragan.cvetic@....com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Saravana Kannan <saravanak@...gle.com>,
Bjorn Helgaas <bhelgaas@...gle.com>, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-gpio@...r.kernel.org, netdev@...r.kernel.org,
linux-pci@...r.kernel.org, linux-arch@...r.kernel.org,
Lee Jones <lee@...nel.org>, Andrew Lunn <andrew@...n.ch>,
Stefan Wahren <wahrenst@....net>, Lizhi Hou <lizhi.hou@....com>
Subject: Re: [PATCH 03/11] PCI: of_property: Sanitize 32 bit PCI address
parsed from DT
Hi Bjorn,
On 20:08 Mon 07 Oct , Bjorn Helgaas wrote:
...
> It's common that PCI bus addresses are identical to CPU physical
> addresses, but by no means universal. More details in
> Documentation/core-api/dma-api-howto.rst
>
> > [2] I still think that the of_pci_set_address() function should be amended
> > to avoid generating invalid 64 address when 32 bit flag is set.
> >
> > As you noted, fixing [2] will incidentally also let [1] work: I think
> > we can try to solve [1] the proper way and maybe defer [2] for a separate
> > patch.
> > To solve [1] I've dropped this patch and tried to solve it from devicetree,
> > modifying the following mapping:
> >
> > pcie@...000: <0x3000000 0x1f 0x00 0x1f 0x00 0x00 0xfffffffc>;
> >
> > so we now have a 1:1 64 bit mapping from 0x1f_00000000 to 0x1f_00000000.
>
> That's the wrong thing to change. pcie@...000 is fine; it's pci@0
> that's incorrect.
>
> pcie@...000 is the host bridge, and its "ranges" must describe the
> address translation it performs between the primary (CPU) side and the
> secondary (PCI) side. Either this offset is built into the hardware
> and can't be changed, or the offset is configured by firmware and the
> DT has to match.
>
> So I think this description is correct:
>
> pcie@...000: <0x2000000 0x0 0x00000000 0x1f 0x00000000 0x0 0xfffffffc>;
>
> which means we have an aperture from CPU physical addresses to PCI bus
> addresses like this:
>
> Host bridge: [mem 0x1f_00000000-0x1f_fffffffb window] (bus address 0x00000000-0xfffffffb)
>
> > I thought it would result in something like this:
> >
> > pcie@...000: <0x3000000 0x1f 0x00 0x1f 0x00 0x00 0xfffffffc>;
> > pci@0 : <0x82000000 0x1f 0x00 0x82000000 0x1f 0x00 0x00 0x600000>;
> > dev@0,0 : <0x01 0x00 0x00 0x82010000 0x1f 0x00 0x00 0x400000>;
> > rp1@0 : <0xc0 0x40000000 0x01 0x00 0x00 0x00 0x400000>;
> >
> > but it fails instead (err: "can't assign; no space") in pci_assign_resource()
> > function trying to match the size using pci_clip_resource_to_region(). It turned
> > out that the clipping is done against 32 bit memory region 'pci_32_bit',and
> > this is failing because the original region addresses to be clipped wxxiereas 64
> > bit wide. The 'culprit' seems to be the function devm_of_pci_get_host_bridge_resources()
> > dropping IORESOURCE_MEM_64 on any memory resource, which seems to be a change
> > somewhat specific to a RK3399 case (see commit 3bd6b8271ee66), but I'm not sure
> > whether it can be considered generic.
>
> I think the problem is that we're building the pci@0 (Root Port)
> "ranges" incorrectly. pci@0 is a PCI-PCI bridge, which cannot do any
> address translation, so its parent and child address spaces must both
> be inside the pcie@...000 *child* address space.
>
> > Also, while taking a look at the resulting devicetree, I'm a bit confused by the
> > fact that the parent address generated by of_pci_prop_ranges() for the pci@0,0
> > bridge seems to be taken from the parent address of the pcie@...000 node. Shouldn't
> > it be taken from the child address of pcie@...000, instead?
>
> Yes, this is exactly the problem. The pci@0 parent and child
> addresses in "ranges" are both in the PCI address space. But we
> start with pdev->resource[N], which is a CPU address. To get the PCI
> address, we need to apply pci_bus_address(). If the host bridge
> windows are set up correctly, the window->offset used in
> pcibios_resource_to_bus() should yield the PCI bus address.
You mean something like this, I think:
@@ -129,7 +129,7 @@ static int of_pci_prop_ranges(struct pci_dev *pdev, struct of_changeset *ocs,
if (of_pci_get_addr_flags(&res[j], &flags))
continue;
- val64 = res[j].start;
+ val64 = pci_bus_address(pdev, &res[j] - pdev->resource);
of_pci_set_address(pdev, rp[i].parent_addr, val64, 0, flags,
false);
if (pci_is_bridge(pdev)) {
>
> I think it should look like this:
>
> pci@0: <0x82000000 0x0 0x00000000 0x82000000 0x0 0x00000000 0x0 0x600000>;
indeed, with the above patch applied, the result is exactly as you expected.
>
> By default lspci shows you the CPU addresses for BARs, so you should
> see something like this:
>
> 00:02.0 PCI bridge
> Memory behind bridge: 1f00000000-1ffffffffb
> Capabilities: [40] Express Root Port
>
> If you run "lspci -b", it will show you PCI bus addresses instead,
> which should look like this:
>
> 00:02.0 PCI bridge
> Memory behind bridge: 00000000-fffffffb
> Capabilities: [40] Express Root Port
>
> > > But I don't think it works in general because there's no requirement
> > > that the host bridge address translation be that simple. For example,
> > > if we have two host bridges, and we want each to have 2GB of 32-bit
> > > PCI address space starting at 0x0, it might look like this:
> > >
> > > 0x00000002_00000000 -> PCI 0x00000000 (subtract 0x00000002_00000000)
> > > 0x00000002_80000000 -> PCI 0x00000000 (subtract 0x00000002_80000000)
> > >
> > > In this case simply ignoring the high 32 bits of the CPU address isn't
> > > the correct translation for the second host bridge. I think we should
> > > look at each host bridge's "ranges", find the difference between its
> > > parent and child addresses, and apply the same difference to
> > > everything below that bridge.
> >
> > Not sure I've got this scenario straight: can you please provide the topology
> > and the bit setting (32/64 bit) for those ranges? Also, is this scenario coming
> > from a real use case or is it hypothetical?
>
> This scenario is purely hypothetical, but it's a legal topology that
> we should handle correctly. It's two host bridges, with independent
> PCI hierarchies below them:
>
> Host bridge A: [mem 0x2_00000000-0x2_7fffffff window] (bus address 0x00000000-0x7fffffff)
> Host bridge B: [mem 0x2_80000000-0x2_ffffffff window] (bus address 0x00000000-0x7fffffff)
>
> Bridge A has an MMIO aperture at CPU addresses
> 0x2_00000000-0x2_7fffffff, and when it initiates PCI transactions on
> its secondary side, the PCI address is CPU_addr - 0x2_00000000.
>
> Similarly, bridge B has an MMIO aperture at CPU addresses
> 0x2_80000000-0x2_ffffffff, and when it initiates PCI transactions on
> its secondary side, the PCI address is CPU_addr - 0x2_80000000.
>
> Both hierarchies use PCI bus addresses in the 0x00000000-0x7fffffff
> range. In a topology like this, you can't convert a bus address back
> to a CPU address unless you know which hierarchy it's in.
> pcibios_bus_to_resource() takes a pci_bus pointer, which tells you
> which hierarchy (and which host bridge address translation) to use.
Agreed. While I think about how to adjust that specific patch,i let's drop it from
this patchset since the aforementioned change is properly fixing the translation
issue.
>
> Bjora
Many thanks,
Andrea
Powered by blists - more mailing lists