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:
- 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