On Tuesday 27 January 2009 01:42:55 am Krzysztof Helt wrote: > On Mon, 26 Jan 2009 15:13:31 -0700 > Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > > 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/). Oh. That sounds like a BIOS bug. If there's only one actual chip, the BIOS should not report it as two separate devices. I guess it might report two devices if only one of them is enabled at a time. In that case, there might be a BIOS setup switch to toggle between them. Can you turn on CONFIG_PNP_DEBUG_MESSAGES and boot with the pnp.debug kernel parameter? Then collect the dmesg log and the output of "grep . /sys/devices/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. The compatible device identifiers list is built by the kernel based on the information from the BIOS. Drivers don't have to worry about it. > > 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. Can you point me to the driver? If this is a BIOS defect, we might be able to write a quirk to work around it so the driver doesn't have to get messy. 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
