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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
