On Thu, 2006-09-14 at 10:55 -0700, keith mannthey wrote: > On Thu, 2006-09-14 at 11:01 +0800, Shaohua Li wrote: > > On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote: > > > On Tuesday 12 September 2006 19:27, keith mannthey wrote: > > > > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote: > > > > > > On Thu, 2006-09-07 at 09:25 -0600, 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. > > Lets work on the assumption it is valid until someone points out in a > spec that says it isn't. > > > 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. > Any solution depends on the mem hotplug device being loaded. This > doesn't appear to be _HID before _CID specific issue . > > > If you take the two pass search, I have a feeling this will make acpi > > never be able to convert Linux driver model. > > I am not trying to break forward work but what I do want is a solution > to my problem. > > > If you really want to workaround the issue, I prefer have a blacklist or > > something to let ACPI not use the _CID for your device, but please don't > > mess the ACPI core itself. > > My fist pass to fix the problem was I guess a hack of sorts that caused > others problems (motherboard add return != 0 on unknown devices). I > don't want another Keith grown hack that breaks other people. > > Can you elaborate on what you think would be safe way to do what you > propose since the ACPI core (can't/won't?) be fixed? I can imagine a > couple of different ways to fix this but I would like some feedback > before I go off and work on the 3rd pass of this fix. > > 1. Make the memory device get scanned before the motherboard device > somehow. Implicitly reorder the devices in the list. Perhaps a priority > sorted of sorts to have _HID device always before _CID devices during > the scan? This will change the scan order of ACPI device, and sounds too hack to me. > 2. Have the motherboard device (if it finds the right acpi device type) > hook into the memory device somehow. > > 3. Some special blacklist of the motherboard device on my specific > system. Either one of the two looks ok. Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
