linux-kernel - Re: [PATCH 1/3 v2] dt-bindings: PCI: s32g: Add NXP PCIe controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <eba7d968-209d-4acb-ba41-4bebf03e96ba@app.fastmail.com>
Date: Wed, 08 Oct 2025 10:26:35 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Manivannan Sadhasivam" <mani@...nel.org>,
 "Lorenzo Pieralisi" <lpieralisi@...nel.org>
Cc: "Vincent Guittot" <vincent.guittot@...aro.org>,
 "Chester Lin" <chester62515@...il.com>,
 "Matthias Brugger" <mbrugger@...e.com>,
 "Ghennadi Procopciuc" <ghennadi.procopciuc@....nxp.com>,
 "NXP S32 Linux Team" <s32@....com>, bhelgaas@...gle.com,
 jingoohan1@...il.com,
 Krzysztof Wilczyński <kwilczynski@...nel.org>,
 "Rob Herring" <robh@...nel.org>, krzk+dt@...nel.org,
 "Conor Dooley" <conor+dt@...nel.org>, Ionut.Vicovan@....com,
 "Larisa Grigore" <larisa.grigore@....com>,
 "Ghennadi Procopciuc" <Ghennadi.Procopciuc@....com>,
 ciprianmarian.costea@....com, "Bogdan Hamciuc" <bogdan.hamciuc@....com>,
 "Frank Li" <Frank.li@....com>, linux-arm-kernel@...ts.infradead.org,
 linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
 "Niklas Cassel" <cassel@...nel.org>
Subject: Re: [PATCH 1/3 v2] dt-bindings: PCI: s32g: Add NXP PCIe controller

On Wed, Oct 8, 2025, at 00:28, Manivannan Sadhasivam wrote:
> On Tue, Oct 07, 2025 at 05:41:55PM +0200, Lorenzo Pieralisi wrote:
>> On Mon, Sep 22, 2025 at 11:51:07AM +0530, Manivannan Sadhasivam wrote:
>> 
>> [...]
>> 
>> > > +                  /*
>> > > +                   * non-prefetchable memory, with best case size and
>> > > +                   * alignment
>> > > +                   */
>> > > +                  <0x82000000 0x0 0x00000000 0x58 0x00000000 0x7 0xfffe0000>;
>> > 
>> > s/0x82000000/0x02000000
>> > 
>> > And the PCI address really starts from 0x00000000? I don't think so.
>> 
>> Isn't the DWC ATU programmed to make sure that the PCI memory window DT
>> provides _is_ the PCI "bus" memory base address ?
>> 
>> It is a question, I don't know the DWC inner details fully.
>> 
>> I don't get what you mean by "I don't think so". Either the host controller
>> AXI<->PCI translation is programmable, then the PCI base address is what
>> we decide it is or it isn't.
>> 
>
> As per the binding, I/O PCI address already starts from 0x0. How can you have
> two OB mappings with same PCI address?

I/O space and memory space can use the same bus addresses,
since they are disambiguated by the type in the actual PCIe
transactions.

We usually assume that I/O space port numbers start at 0 (as done
here), while PCI memory ranges are identity-mapped to the CPU
physical address they are mapped at, but in this case the physical
address window is outside of the low 4GB range, so an identity map
at 0x58.0x00000000 woulds prevent the use of 32-bit BARs, and
mapping something in the low bus address range is the only
possibility.

On the other hand, what looks like a bug to me is that the CPU
physical address range for the PCI BAR space overlaps with the
the physical addresses for RAM at 0x80000000 and on-chip devices
at 0x40000000. This probably works fine as long as the total
PCI memory space assignment stays below 0x40000000 but would
fail once addresses actually start clashing.

Maybe the memory space can be split into two windows like

 <0x82000000 0x0 0x00000000 0x58 0x00000000 0x0 0x40000000>, //  1GB 32-bit non-pref
 <0xc2000000 0x1 0x00000000 0x59 0x00000000 0x6 0x00000000>; // 24GB 64-bit pref

The 64-bit window could be either prefetchable or
non-prefetchable in this case. If there is only one programmable
window for memory space, that would probably have to be
limited to 1GB non-prefetchable for the normal 32-bit BARs.

       Arnd