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: <zdqmmpawrntlbebmeb3ey3z3rpxzmlanqqqp4stmbrouwelbx7@s5qt5f53553x>
Date: Wed, 8 Oct 2025 08:14:41 -0700
From: Manivannan Sadhasivam <mani@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Lorenzo Pieralisi <lpieralisi@...nel.org>, 
	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 08, 2025 at 10:26:35AM +0200, Arnd Bergmann wrote:
> 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.
> 

The DWC IP does the address match translation for OB regions, so I mistakenly
assumed that the PCI addresses has to be unique. But it is the other way around,
the CPU addresses has to be unique. So as long as the CPU addresses doesn't
overlap, we are fine.

Sorry for the confusion.

> 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.
> 

Agree.

> 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.

I don't understand the overlap issue here. The outbound address translation only
cares about the CPU address and as long as that doesn't overlap with MMIO/RAM,
we should be fine.

Am I missing something?

- Mani

-- 
மணிவண்ணன் சதாசிவம்