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: > > > >> If we decide that "try HID first, then try CID" is the right > thing, > > > >> I think we should figure out how to make that work. Maybe that > > > >> means extending the driver model somehow. > > > > Don't think it's easy, especially no other bus needs it I guess. > > > > > > I agree it's probably not easy, but I think having the right > > > semantics is more important than fitting cleanly into the > > > driver model. But I know that without code, I'm just venting > > > hot air, not contributing to a solution. > > > > > > How's the ACPI driver model integration going, anyway? I seem > > > to recall some patches a while back, but I don't think they're > > > in the tree yet. > > > > > > > Do we really need the memory hotplug device returns > pnp0c01/pnp0c02? > > > > What's the purpose? > > > > > > I don't know. But I think Keith already determined that a BIOS > change > > > is not likely. I hate to ask for BIOS changes like this because > it > > > feels like asking them to avoid broken things in Linux. > > > > Ok my motherboard patch was dropped from -mm so I am broken again > but > > others are fixed. Is the answer that we do nothing about this > issues? > > > > I am pretty sure my SSDT table is valid if someone *cannot* point > out > > in the spec where my device is malformed by having both HID and CID > I > > will not be able even start the request to change the BIOS (it would > be > > a waste of my time). Sure having the CID of the memory device may > be > > overkill but is it wrong? > > 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. 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. If you take the two pass search, I have a feeling this will make acpi never be able to convert Linux driver model. 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. 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
