From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <8950494.UV8UrWiFbx@wuerfel> References: <1460740008-19489-1-git-send-email-tn@semihalf.com> <3830999.dF71UWYsBP@wuerfel> <57189D2F.9070802@semihalf.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: <57189D2F.9070802@semihalf.com> Sender: linux-pci-owner@vger.kernel.org To: Tomasz Nowicki Cc: Jayachandran C , linux-arm-kernel@lists.infradead.org, Bjorn Helgaas , Will Deacon , Catalin Marinas , rafael@kernel.org, Hanjun Guo , Lorenzo Pieralisi , Sinan Kaya , jiang.liu@linux.intel.com, Jon Masters , linaro-acpi@lists.linaro.org, linux-pci@vger.kernel.org, Liviu.Dudau@arm.com, David Daney , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, robert.richter@caviumnetworks.com, Suravee.Suthikulpanit@amd.com, msalter@redhat.com, Wangyijing , Marcin Wojtas List-Id: linux-acpi@vger.kernel.org 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