On Mon, 26 Jan 2009 15:13:31 -0700 Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > 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. > The laptop in question is the Dell Latitude CPi and it does not have ACPI only the PnP BIOS. The both ids are reported as unrelated (two separate nodes in the /sys/bus/pnp/). I don't know how to set up the "compatible device identifiers" list. It is not defined in the include/linux/pnp.h. If I know that I will test this. > 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. > Currently, I iterate over pnpbios_protocol to find out if the second id exists. It is not elegant but works. Regards, Krzysztof -- 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
