Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

[Bjorn Helgaas]

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.

Bjorn