linux-kernel - Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

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]

Message-Id: <200609141036.07599.bjorn.helgaas@hp.com>
Date:	Thu, 14 Sep 2006 10:36:06 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Shaohua Li <shaohua.li@...el.com>
Cc:	kmannth@...ibm.com, "Moore, Robert" <robert.moore@...el.com>,
	Len Brown <lenb@...nel.org>,
	Mattia Dongili <malattia@...ux.it>,
	Andrew Morton <akpm@...l.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux acpi <linux-acpi@...r.kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception  code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

On Wednesday 13 September 2006 21:01, Shaohua Li wrote:
> On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > I think that your SSDT is valid.  I can't point to a specific
> > reference in the spec, but I think the "try _HID first, then try
> > _CID" strategy is clearly the intent.  Otherwise, there would be
> > no reason to separate _HID from _CID.

> The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> is valid or invalid. 

This problem is more general than just Keith's situation.  This
could happen with any device that has both _HID and _CID.  As
soon as you have both _HID and _CID, you can have a driver that
claims the _HID and another that claims the _CID.

The spec obviously anticipates this situation, which is why I
think the SSDT is valid from the ACPI spec point of view.

Now, if you have some definition of the programming model of
PNP0C01/PNP0C02, and the memory device doesn't conform to that
model, then I would agree that the SSDT is invalid.  But I
don't know where a PNP0C01/PNP0C02 programming model is defined.

The linux driver does nothing more than reserve the resources
of the device, so it doesn't use any programming model at all.
The memory device (in fact, any ACPI device at all) trivially
conforms to this "null programming model."

> The 'try _HID first then _CID' has another downside. It highly depends
> on the driver is loaded first and then load the device. See motherboard
> driver loads first and the mem hotplug driver isn't loaded, in this
> situation if you scan the mem hotplug device, the mechanism will fail as
> the two pass search will still bind motherboard driver to the device.

I agree, this is a problem that will have to be resolved.  And it's
really not just an ACPI problem.  A PCI driver can claim devices based
on a class or a vendor/device/subvendor/subdevice with wildcards.
Another driver can claim devices with a specific vendor/device/etc.
Some devices may match with both drivers.

PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
driver to release a device and bind another driver to it.  Maybe we
could do something similar for ACPI. 

Bjorn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/