Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Mon, 18 Jul 2005 13:51:35 -0400
On Monday 18 July 2005 01:09 pm, Nate Lawson wrote:
> 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:

Note that my patch did _not_ just return the first CID, I'm pretty sure it 
returned the first CID that matched the prefix 'PNP' to match the behavior of 
acpi_isa_pnp_probe(), and thus it would actually have been very 
deterministic.

> 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.

You missed the fact that I've already chucked out that local patch and have 
just committed the one-line change to mss.c.

> 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.

This is the direction I want to take for any devices that have an acpi 
attachment.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
Received on Mon Jul 18 2005 - 15:52:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:39 UTC