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