| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <55ED6010.3020406@linaro.org> Date: Mon, 7 Sep 2015 11:59:44 +0200 From: Tomasz Nowicki <tomasz.nowicki@...aro.org> To: Lorenzo Pieralisi <lorenzo.pieralisi@....com>, Bjorn Helgaas <bhelgaas@...gle.com>, "Rafael J. Wysocki" <rjw@...ysocki.net> Cc: Hanjun Guo <hanjun.guo@...aro.org>, Liviu Dudau <Liviu.Dudau@....com>, Yijing Wang <wangyijing@...wei.com>, Will Deacon <Will.Deacon@....com>, Arnd Bergmann <arnd@...db.de>, Catalin Marinas <Catalin.Marinas@....com>, Jiang Liu <jiang.liu@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, "suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>, "msalter@...hat.com" <msalter@...hat.com>, "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org> Subject: Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory On 31.08.2015 13:01, Tomasz Nowicki wrote: > On 08.06.2015 17:14, Lorenzo Pieralisi wrote: >> On Mon, Jun 08, 2015 at 03:57:38AM +0100, Hanjun Guo wrote: >> >> [...] >> >>>>>>>>> Why can't we make use of the ECAM implementation used by >>>>>>>>> pci-host-generic >>>>>>>>> and drivers/pci/access.c? >>>>>>>> >>>>>>>> We had that question when I had posted MMCFG patch set separately, >>>>>>>> please see: >>>>>>>> https://lkml.org/lkml/2015/3/11/492 >>>>>>> >>>>>>> Yes, but the real question is, why do we need to have PCI config >>>>>>> space >>>>>>> up and running before a bus struct is even created ? I think the >>>>>>> reason is >>>>>>> the PCI configuration address space format (ACPI 6.0, Table 5-27, >>>>>>> page >>>>>>> 108): >>>>>>> >>>>>>> "PCI Configuration space addresses must be confined to devices on >>>>>>> PCI Segment Group 0, bus 0. This restriction exists to accommodate >>>>>>> access to fixed hardware prior to PCI bus enumeration". >>>>>>> >>>>>>> On HW reduced platforms I do not even think this is required at all, >>>>>>> we have to look into this to avoid code duplication that might well >>>>>>> turn out useless. >>>>>> >>>>>> This is only for the fixed hardware, which will be not available for >>>>>> ARM64 (reduced hardware mode), but in Generic Hardware Programming >>>>>> Model, we using OEM-provided ACPI Machine Language (AML) code to >>>>>> access >>>>>> generic hardware registers, this will be available for reduced >>>>>> hardware >>>>>> too. >>>>>> >>>>>> So in ACPI spec, it says: (ACPI 6.0 page 66, last paragraph) >>>>>> >>>>>> ACPI defines eight address spaces that may be accessed by generic >>>>>> hardware implementations. These include: >>>>>> * System I/O space >>>>>> * System memory space >>>>>> * PCI configuration space >>>>>> * Embedded controller space >>>>>> * System Management Bus (SMBus) space >>>>>> * CMOS >>>>>> * PCI BAR Target >>>>>> * IPMI space >>>>>> >>>>>> So if any device using the PCI address space for control, such >>>>>> as a system reset control device, its address space can be reside >>>>>> in PCI configuration space (who can prevent a OEM do that crazy >>>>>> thing? :) ), and it should be accessible before the PCI bus is >>>>>> created. >>>>> >>>>> Us, by changing attitude and questioning features whose usefulness >>>>> is questionable. I will look into this and raise the point, I am not >>>>> thrilled by the idea of adding another set of PCI accessor functions >>>>> and drivers because we have to access a register through PCI before >>>>> enumerating the bus (and on arm64 this is totally useless since >>>>> we are not meant to support fixed HW anyway). Maybe we can make acpica >>>>> code use a "special" stub (ACPI specific, PCI configuration space >>>>> address >>>>> space has restrictions anyway), I have to review this set in its >>>>> entirety to see how to do that (and I would kindly ask you to do >>>>> it too, before saying it is not possible to implement it). >>>> >>>> I'm willing to do that, actually, if we don't need a mechanism to >>>> access PCI config space before the bus is created, the code can be >>>> simplified a lot. >>> >>> After more investigation on the spec and the ACPI core code, I'm >>> still not convinced that accessing to PCI config space before PCI >>> bus creating is impossible, also there is no enough ARM64 hardware >>> to prove that too. But I think we can go in this way, reuse the >>> ECAM implementation by pci-host-generic for now, and implement the PCI >>> accessor functions before enumerating PCI bus when needed in the >>> future, does it make sense? >> >> You mean we rewrite the patch to make sure we can use the PCI host >> generic >> driver with MCFG and we leave the acpica PCI config call empty stubs on >> arm64 (as they are now) ? >> > > Hi Bjorn, Rafael, > > Lorenzo pointed out very important problem we are having with PCI config > space access for ARM64. Please refer to the above discussion and add > your 2 cents. Can we forget about accessing PCI config space (for > Hardware Reduced profile) before PCI bus creation? If not, do you see a > way to use drivers/pci/access.c accessors here, like acpica change? Any > opinion is very appreciated. > Kindly remainder. Thanks, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists