lkml.org 
[lkml]   [2013]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] PCI / ACPI: Rework ACPI device nodes lookup for the PCI bus type
    Date
    On Thursday, January 03, 2013 02:44:32 PM Bjorn Helgaas wrote:
    > On Thu, Jan 3, 2013 at 1:17 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
    > > On Thursday, January 03, 2013 08:16:26 AM Bjorn Helgaas wrote:
    > >> On Fri, Dec 28, 2012 at 2:29 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
    > >> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    > >> >
    > >> > As the kernel Bugzilla report #42696 indicates, it generally is not
    > >> > sufficient to use _ADR to get an ACPI device node corresponding to
    > >> > the given PCI device, because there may be multiple objects with
    > >> > matching _ADR in the ACPI namespace (this probably is against the
    > >> > spec, but it evidently happens in practice).
    > >>
    > >> I don't see anything in sec 6.1.1 (_ADR) that precludes having
    > >> multiple objects that contain the same _ADR. Do you have any other
    > >> pointers?
    > >
    > > Section 6.1 implicitly means that. It says that for PCI devices _ADR
    > > must be present to identify which device is represented by the given
    > > ACPI node. Next, Section 6.1.1 says that the parent bus should be inferred
    > > from the location of the _ADR object's device package in the ACPI namespace,
    > > so clearly, if that's under the PCI root bridge ACPI node, the _ADR
    > > corresponds to a PCI device's bus address.
    >
    > I agree that for namespace Devices below a PCI host bridge, the _ADR
    > value and its position in the hierarchy is required to be sufficient
    > to identify a PCI device and function (or the set of all functions on
    > a device #).
    >
    > > Then, Table 6-139 specifies the format of _ADR for PCI devices as being
    > > euqivalent to devfn, which means that if two nodes with the same _ADR are
    > > present in one scope (under one parent), then it is impossible to distinguish
    > > between them and that's against Section 6.1.
    >
    > This is the bit I don't understand. Where's the requirement that we
    > be able to distinguish between two namespace nodes with the same _ADR?

    According to the spec we can't (if they are under the same parent) and that's
    the whole problem.

    > Linux assumes we can start from a PCI device and identify a single
    > related ACPI namespace node, e.g., in acpi_pci_find_device(). But all
    > I see in the spec is a requirement that we can start from an ACPI
    > namespace node and find a PCI device. So I'm not sure
    > acpi_pci_find_device() is based on a valid assumption.

    I think it is.

    Suppose that we have two namespace nodes with the same _ADR under one parent
    (PCI bridge ACPI node) and they both contain things like _PS0 and _PS3. Which
    one of these are we supposed to use for the power management of the
    corresponding PCI device? Because they both would point to the same device,
    right?

    > Let's say we want to provide _SUN and _UID. _SUN is a slot number
    > that may apply to several PCI functions, while _UID probably refers to
    > a single PCI function. Is it legal to provide two namespace objects,
    > one with _ADR 0x0003ffff and _SUN, and another with _ADR 0x00030000
    > and _UID?

    I don't think it is valid to do that.

    Thanks,
    Rafael


    --
    I speak only for myself.
    Rafael J. Wysocki, Intel Open Source Technology Center.


    \
     
     \ /
      Last update: 2013-01-04 00:21    [W:3.811 / U:0.648 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site