On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:

On 19.09.2016 17:45, Bjorn Helgaas wrote:

quoted

On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:

quoted

ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
compliant with ECAM standard. It uses non-standard configuration space
accessors (see pci_thunder_pem_ops) and custom configuration space granulation
(see bus_shift = 24). In order to access configuration space and
probe PEM as ACPI based PCI host controller we need to add MCFG quirk
infrastructure. This involves:
1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
  code.
2. New quirk entries for each PEM segment. Each contains platform IDs,
  mentioned pci_thunder_pem_ops and CFG resources.

Quirk is considered for ThunderX silicon pass2.x only which is identified
via MCFG revision 1.

Is it really the case that silicon pass2.x has MCFG revision 1, and
silicon pass1.x has MCFG revision 2?  That just seems backwards.

It is weird but silicon pass2.x is more common and it had MCFG
revision 1 from the beginning. Unless it is allowed to use MCFG
revision 0 ? Then we could use MCFG revision 0 for pass1.x

There's no reason to avoid revision 0.  The question is really what
firmware is already in the field.  We need to accommodate that.  We don't
want a situation where kernel version X only works with firmware version Y,
but kernel version X+1 only works with firmware version Y+1.

Bjorn