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, 03 Jan 2013 23:38:02 +0100
From:	"Rafael J. Wysocki" <>
To:	Bjorn Helgaas <>
Cc:	ACPI Devel Maling List <>,
	Len Brown <>,
	LKML <>,
	Peter Wu <>
Subject: Re: [PATCH] PCI / ACPI: Rework ACPI device nodes lookup for the PCI bus type

On Thursday, January 03, 2013 02:44:32 PM Bjorn Helgaas wrote:
> On Thu, Jan 3, 2013 at 1:17 PM, Rafael J. Wysocki <> 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 <> wrote:
> >> > From: Rafael J. Wysocki <>
> >> >
> >> > 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,

> 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.


I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists