On Fri, Dec 2, 2016 at 12:27 AM, Bjorn Helgaas <helg...@kernel.org> wrote: > On Thu, Dec 01, 2016 at 11:37:39PM +0100, Rafael J. Wysocki wrote: >> On Thursday, December 01, 2016 04:36:04 PM Bjorn Helgaas wrote: >> > On Tue, Nov 29, 2016 at 03:39:48PM -0600, Bjorn Helgaas wrote: >> > > Here's another stab at this writeup. I'd appreciate any comments! >> > > >> > > Changes from v1 to v2: >> > > - Consumer/Producer is defined for Extended Address Space descriptors; >> > > should be ignored for QWord/DWord/Word Address Space descriptors >> > > - New arches may use Extended Address Space descriptors in PNP0A03 for >> > > bridge registers, including ECAM (if the arch adds support for this) >> > > - Add more details about MCFG and _CBA (Lv's suggestion) >> > > - Incorporate Rafael's suggestions >> > > >> > > --- >> > > >> > > Bjorn Helgaas (1): >> > > PCI: Add information about describing PCI in ACPI >> > > >> > > >> > > Documentation/PCI/00-INDEX | 2 >> > > Documentation/PCI/acpi-info.txt | 180 >> > > +++++++++++++++++++++++++++++++++++++++ >> > > 2 files changed, 182 insertions(+) >> > > create mode 100644 Documentation/PCI/acpi-info.txt >> > >> > It's very late in the cycle, but I'm considering trying to squeeze >> > this into v4.9 on the grounds that: >> > >> > - It's only a documentation change and can't break anything, and >> > >> > - Distributing it more widely may help the arm64 firmware ecosystem >> > >> > But I don't want to disseminate misleading or incorrect information, >> > so if it needs clarification or wordsmithing, or even just maturation, >> > I'll wait until v4.10. >> > >> > The Consumer/Producer stuff, in particular, doesn't seem 100% settled >> > yet. Your thoughts, and especially your improvements, are welcome! >> >> Well, what's the drawback if it doesn't go into 4.9? > > Only that it's not as easily accessible. ARM64 ACPI firmware is brand > new. Neither the firmware nor the kernel developers, nor even the > hardware designers, have the benefit of all the x86/ia64 history, so I > wrote this to try to come to a common understanding of what Linux > expects. > > The first generation of ARM64 hardware is already in the field, and it > has teething problems in hardware, firmware, and kernel. For example, > the current MCFG quirk situation: the ECAM hardware doesn't work quite > per spec, the ACPI firmware doesn't describe the address space > completely, and we don't really have consensus on how the firmware > should communicate register space to the kernel. > > We're hoping the second generation can fix some of these problems, and > I think this is the time to try to influence that.
Well, I would be super-careful if I were you, then. :-) I'm not sure if squeezing it into 4.9.0 buys you anything here. If you get it into 4.10-rc, you can request -stable to pick it up (at least in principle) and then it will show up in 4.9.y at one point which should suffice I suppose? Thanks, Rafael