[Added Adam and linux-acpi] On Monday 26 January 2009 02:21:29 am Krzysztof Helt wrote: > There is brain-damaged sound chip which is identified by two separate > PNP ids. This was done probably to keep backward compatibility (the > first id is for the old type of chip, the second id gives only one > additional io range required for newer chips). > > How to does properly detect such a device using the PNP framework? > Is there any way to specify two PNP ids as one device? > > Is it better to iterate over a pnpbios protocol of the first device to > find out if there is the second id? This way has an advantage that I can > distinguish between old chip (no the second id found) and newer chips > (the second id found). Hi Krzysztof, Systems with the old chip probably report the device with a single PNP ID. For PNPBIOS, that would be the "device product identifier." For ACPI, it would be the _HID. Systems with the new chip should report both PNP IDs. The PNPBIOS device product identifier or the ACPI _HID should be the new ID, and the older ID for backward compatibility should be reported in the PNPBIOS "compatible device identifiers" list or the ACPI _CID. The driver would list both IDs in the pnp_device_id table, and it looks like the driver probe routine gets called with the ID that matched. I don't see any drivers that actually do this, but I think the probe routine should be able to look at the ID that matched and determine whether the additional I/O range is present. Oops, looking at match_device() in drivers/pnp/driver.c, I think we look at all the device IDs supported by the driver, but we only look at the first ID associated with the device. That means an old driver that only knows about the old device ID would fail to claim a new device (the new device will have the new ID first and old IDs in the compatibility list). That looks like a bug in the PNP core -- the old driver should be able to claim any new compatible devices. Let me know if you think you're seeing this bug, and I'll look into it some more. Bjorn -- 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
