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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 1 Dec 2016 20:18:48 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Linux PCI <linux-pci@...r.kernel.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Gabriele Paoloni <gabriele.paoloni@...wei.com>,
        Duc Dang <dhdang@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Lv Zheng <lv.zheng@...el.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2] PCI: Add information about describing PCI in ACPI

On Fri, Dec 02, 2016 at 01:28:50AM +0100, Rafael J. Wysocki wrote:
> On Fri, Dec 2, 2016 at 12:27 AM, Bjorn Helgaas <helgaas@...nel.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?

You're right, there's no real hurry, and the rate of change is a good
indication that we need to let things settle out for a while.