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. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
