Re: [PATCH V6 4/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version

[Tomasz Nowicki]

On 20.09.2016 15:08, Bjorn Helgaas wrote:
> On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:
> > On 19.09.2016 17:45, Bjorn Helgaas wrote:
> > > On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
> > > > 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.

Yes I agree. We have already deployed the firmware where:
pass2.x has MCFG revision 1
pass1.x has MCFG revision 2
so we need to stick to this.

Thanks,
Tomasz