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

From: M. Warner Losh <imp_at_bsdimp.com>
Date: Mon, 18 Jul 2005 15:35:04 -0600 (MDT)
In message: <200507181619.31189.jhb_at_FreeBSD.org>
            John Baldwin <jhb_at_FreeBSD.org> writes:
: On Saturday 16 July 2005 02:58 pm, M. Warner Losh wrote:
: > : dmesg excerpt ...
: > : mss_probe: bus acpi0 is probing device pcm0
: > : mss_probe: isa_get_logicalid() returned 0!
: >
: > This is the problem.  It shouldn't be probing there.  It doesn't in
: > current.  Chances are John beat me to it and we're arguing over
: > something that's been fixed...
: 
: I removed that probe in current.  The problem is that ACPI has HID values that 
: are strings like "ACPI0003" that don't fit the EISAID model, so for devices 
: like ACPI thermal zones that only have an ACPI HID, there's no PNP-compatible 
: HID or CID to return to the ISA drivers.  I think the proper solution is that 
: drivers that don't support ACPI-enumerate devices (recall that ACPI 
: enumerates PNPBIOS devices) need to stop having acpi attachments, and that 
: drivers that do need to use ISA_PNP_PROBE().  I think that the only embedded 
: sound controllers are PCI, so that probably all of the ISA PNP sound drivers 
: don't need acpi attachments but I could be wrong.

If we're going to return the string that we found, maybe it would be
better to return a pointer isa_pnp_id entry, and also pass in in the
length of the table entry so that drivers can store extra info for
each card.  PC Card already does this for its lookup routines, for
example, that that has worked out very well.  That way there isn't the
weird trip to a string, then a lookup based on that string.

Warner
Received on Mon Jul 18 2005 - 19:35:27 UTC

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