From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shaohua Li Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3] Date: Fri, 15 Sep 2006 09:39:55 +0800 Message-ID: <1158284395.20560.30.camel@sli10-conroe.sh.intel.com> References: <200609130851.16028.bjorn.helgaas@hp.com> <1158202876.20560.14.camel@sli10-conroe.sh.intel.com> <200609141036.07599.bjorn.helgaas@hp.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mga01.intel.com ([192.55.52.88]:33843 "EHLO mga01.intel.com") by vger.kernel.org with ESMTP id S1751422AbWIOBjb (ORCPT ); Thu, 14 Sep 2006 21:39:31 -0400 In-Reply-To: <200609141036.07599.bjorn.helgaas@hp.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Bjorn Helgaas Cc: kmannth@us.ibm.com, "Moore, Robert" , Len Brown , Mattia Dongili , Andrew Morton , lkml , linux acpi , KAMEZAWA Hiroyuki 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