Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH V6 08/13] PCI: generic, thunder: update to use generic ECAM API | Date | Thu, 21 Apr 2016 11:36:53 +0200 |
| |
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
| |