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: <4143977f-1e70-4a63-b23b-78f87d9fdcde@app.fastmail.com>
Date: Wed, 08 Oct 2025 10:35:34 +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 10:26, 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:
> 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

s/CPU physical/PCI bus/

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

With a bit of luck, the host bridge ends up doing a DMA instead
of a P2P transfer, but I would not want to rely on that.

      Arnd