Re: Commit 4f2e2280862a ("RFC: arm: pci: Add PCI cam support to PCI-E ecam driver")

["Pali Rohár" <pali@kernel.org>]

Hello Mark!

On Thursday 20 January 2022 00:23:02 Mark Kettenis wrote:
> CAM is just a version of ECAM that only gives you access to the
> classic PCI config space (register offsets < 256).  This has very
> little to do with the classic "mode 1" and "mode 2" config space
> access methods of the x86 PCI host bridges.

Interesting... as I have not found anything about CAM in specs... That
is why I thought it must be some proprietary, vendor-specific or
non-standard access method.

"mode 1" is indirect access method and "mode 2" has mapped config space
into (io) memory space. But this "CAM" is neither "mode 1" nor "mode 2".
That is why it looked suspicious to me.

> I don't think there is a
> CAM standard at all, but some of the PCI host bridges found on PowerPC
> and SPARC hardware implemented a straight mapping of PCI config space
> into mmio space like that.

Interesting... But at least it looks like that U-Boot does not have
support for these kind of hardware.

Anyway, is not that mapping in that old hardware of PCI config space
into mmio space according to "mode 2" layout? I know that both "mode 1"
and "mode 2" are IO-space orientated, but on non-x86 HW there probably
does not have to be IO-space and same layout can be used also for
memory-space mapping.

> It is a little bit strange that crosvm implements CAM instead of ECAM,
> but I guess they don't care about passthrough of arbitrary PCIe
> devices.  And as long as all (emulated) PCIe devices only have
> registers with offsets < 256, this will work just fine.
> 
> And yes, you should check that the register offset is limited to
> 0..255.