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: <3d480f73-15b4-4fb8-8d2b-f9961c1736ca@app.fastmail.com>
Date: Wed, 08 Oct 2025 19:56:44 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Manivannan Sadhasivam" <mani@...nel.org>
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 8, 2025, at 17:19, Manivannan Sadhasivam wrote:
> On Wed, Oct 08, 2025 at 10:35:34AM +0200, Arnd Bergmann wrote:
>> On Wed, Oct 8, 2025, at 10:26, Arnd Bergmann wrote:
>> > 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.
>> 
>> I got confused here myself, but what I should have said is that
>> having the DMA address for the RAM overlap the BAR space
>> as seen from PCI is problematic as the PCI host bridge
>> cannot tell PCI P2P transfers from DMA to RAM, so one
>> of them will be broken here.
>> 
>
> No. The IP just sets up the outbound mapping here for the entire 'ranges'. When
> P2P happens, it will use the inbound mapping translation.

That is not my impression from reading the code: At least for
the case where both devices are on the same bridge and they
use map_type=PCI_P2PDMA_MAP_BUS_ADDR, I would expect the DMA
to use the plain PCI bus address, not going through the
dma-ranges+ranges translation that would apply when they are
on different host bridges.

> So your concern would be valid if the 'dma-ranges' (for which inbound
> translation happens) overlapped with the RAM/MMIO range. But that is not the
> case here.

dma-ranges should normally list all the memory controllers, so in
this case at least the 0x80000000..0xffffffff range of PCI bus
addresses must be routed from the host bridge to RAM. If a BAR
is assigned to the same numbers, I would expect a PCI bridge
to direct a DMA transfer downstream to that BAR instead
of upstream to the CPU even before it gets to the host bridge.

      Arnd