John Baldwin wrote: > On Sunday 17 July 2005 12:09 am, Nate Lawson wrote: >>Rather than John's addition of returning an arbitrary CID, can we return >>~0 or some other obviously invalid HID so that drivers don't start >>depending on the order of CIDs? > > > Actually, drivers also use isa_get_logicalid() to get real actual PnP ID as > well (see usage in the pnpmss driver in the same file). I think that any > drivers that actually need to interface with ACPI do need to just use > ISA_PNP_PROBE(). Yes, there is no way for a driver to work correctly using just isa_get_logicalid() on all systems. The problem with this is that CID is a list of IDs, some private that will never match a driver like mss. For example, using bogus IDs: System1 _HID: none _CID: IBM008, PNP0C02, PNP0C01 If you just return the first CID in isa_get_logicalid() like your patch does, the device won't probe correctly since IBM008 is not matched by mss. However, on System2: System2 _HID: none _CID: PNP0C02, IBM008, PNP0C01 It works! Thus if a developer of mss only used System2 with your patch, there would be no problem until someone tried on System1. Using ISA_PNP_PROBE() solves this, like you say. To prevent this, should we even issue a warning if acpi_isa_get_logicalid() did not find a _HID but a _CID exists? > I think that drivers that don't implement devices ACPI > enumerates should stop attaching to ACPI as well. Finally, it may be that > ISA_PNP_PROBE() needs to return a string version of the PNP ID that was > actually probed so that drivers can do extra tests. First though, we should > go through removing extra acpi attachments for drivers for ISA PNP cards > since ACPI enumerates the equivalent of PNP BIOS, not ISA PNP. This sounds good. -- NateReceived on Mon Jul 18 2005 - 15:17:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:39 UTC