mss.c pcm fix to ' attach returned 6 ' load failure for v5.x
acpi and up
Nate Lawson
nate at root.org
Mon Jul 18 17:17:30 GMT 2005
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.
--
Nate
More information about the freebsd-current
mailing list