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

["Arnd Bergmann" <arnd@arndb.de>]

On Thu, Oct 9, 2025, at 20:47, Manivannan Sadhasivam wrote:
> On Wed, Oct 08, 2025 at 07:56:44PM +0200, Arnd Bergmann wrote:
>> On Wed, Oct 8, 2025, at 17:19, Manivannan Sadhasivam wrote:
>>
>> 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.
>> 
>
> Right, but I don't get the overlap issue still. If the P2P client triggers a
> write to a P2P PCI address (let's assume 0x8000_0000), and if that address
> belongs to a an endpoint in a different domain, the host bridge should still
> forward it to the endpoint without triggering write to the RAM.

If 0x8000_0000 is an endpoint in a different domain, I would expect the
DMA transfer to go to the RAM at that address since the DMA has to leave
the PCI host bridge upstream by following its inbound windows.

This is not the problem I'm talking about though, since cross-domain
P2P is not particularly well-defined.

> Atleast, I don't see any concern from the outbound memory translation point of
> view.
>
> Please let me know if there is any gap in my understanding.

To clarify: I don't think that programming the output translation this
way is the problem here, but assigning memory resources to ambiguous
addresses is. The host bridge probe uses the 'ranges' both for
setting up the outbound window and the bus resources. 

If the PCI bus scan assigns address 0x8000_0000 to the memory BAR
of a device, and that device or any other one in the /same/
domain tries to DMA to DRAM at address 0x8000_0000, it would likely
reach the memory BAR instead of DRAM. If for some reason it does reach
DRAM after all, it would be unable to do a P2P DMA into the BAR when
it tries.

If the PCI scan already checks for overlap between the DT "ranges"
and other resources (DRAM or MMIO) before assigning a BAR, this may
be a non-issue, but I haven't found the code that does this.
Looking at pci_bus_allocate_dev_resources() it seems that it would
attempt to assign an overlapping address to a BAR but then fail
to claim it because of the resource conflict. If that is the
case, it would not actually have an ambiguous DMA routing
but instead the device would fail to be probed because of the
conflict.

    Arnd