Date:	Fri, 15 Sep 2006 09:39:55 +0800
From:	Shaohua Li <shaohua.li@...el.com>
To:	Bjorn Helgaas <bjorn.helgaas@...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 Thu, 2006-09-14 at 10:36 -0600, Bjorn Helgaas wrote:
> 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.
We don't see such issue before, don't think it's generic. We did have
some devices with _CID, like a pcie root bridge claims pnp0a03 (pci root
bridge), but they are really compatible.

> 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.
I'd prefer don't do ACPI core change in this stage and just workaround
Keith's issue till we find this is really a generic problem.

> 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. 
After we convert acpi core to Linux driver model, we have the
capability. But not sure if this can help Keith.

Thanks,
Shaohua
-
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/

Powered by blists - more mailing lists