On Thursday 21 April 2016 11:28:15 Tomasz Nowicki wrote: > On 19.04.2016 15:06, Arnd Bergmann wrote: > > On Monday 18 April 2016 21:31:54 Tomasz Nowicki wrote: > >> > >> Basically the whole content of pci-thunder-ecam.c and pci-thunder-pem.c. > >> > >> pci-thunder-ecam.c contains config space accessors. Similar for > >> pci-thunder-pem.c but it also has extra init call (it is now called > >> thunder_pem_init) which finds and maps related registers. > > > > They seem to do much more than just override the accessors, they actually > > change the contents of the config space as well. Is that really necessary > > on ACPI based systems as well? > > Yes, the pci-thunder-ecam.c accessors are meant to emulate config space > capabilities. They are necessary to synthesize EA capabilities (fixed > PCI BARs), it wont work without this, for ACPI boot as well. Why is that? I thought the BARs never get reassigned when using ACPI, so I'm surprised it's actually needed. Maybe I misunderstood what you mean by fixed PCI BARs. > > Another idea: how about moving all of this logic into ACPI and calling > > some AML method to access the config space if the devices are that > > far out of spec. > > Do you mean Linux specific way to call non-standard config space > accessors? Then non-standard accessors are going to AML methods which > are called from common code which handles quirks via unified API ? What I really meant was a standardized way to do handle hardware that is in some way or another not compliant with PNP0A08: We could have a different hardware ID for this and let all the first-generation ARM servers and also anything else using ACPI with nonstandard PCI use the same method across operating systems. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
