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

On Monday 11 July 2005 11:15 am, Harry Coin wrote:
> The architecture / driver manual has this item:
>
> "That means that absolutely every driver, even the ones not supporting any
> PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID table
> to return failure on unknown PnP
> devices."
> (http://www.google.com/search?num=100&hl=en&lr=&newwindow=1&q=freebsd+archi
>tect+isa+driver)
>
> However in mss.c, routine mss_probe we have in the non pnp device detection
> routine
>
> if (isa_get_logicalid(dev)) return ENXIO;
>
> which causes the acpi driver to fail to attach multiple times, and to
> ratchet up x in the pcmx device before giving up.  Often this leads to the
> isa routine not calling the pnp version of the probe routine and the whole
> pcm load fails or loads the first and only sound driver on a pcm number
> like 3 or 6.  Booting without ACPI gives normal results.
>
> The fix in mss.c is:
>
> static struct isa_pnp_id mss_ids[] = {
>          {0}
> };
>
> static int
> mss_probe(device_t dev)
> {
>          u_char tmp, tmpx;
>          int flags, irq, drq, result = ENXIO, setres = 0;
>          struct mss_info *mss;
>          result = ISA_PNP_PROBE(device_get_parent(dev), dev, mss_ids);
>          if (result!=ENOENT) return ENXIO; /* only continue if the device
> is not pnp */
>          /* old way- not so good for ACPI: if (isa_get_logicalid(dev))
> return ENXIO; */
>
> Sincerely,
>
> Harry Coin

If this is broken then there are a lot of drivers that need fixing.  It sounds 
like ACPI needs fixing instead.  I don't see why pcm's unit number would go 
up, however, as a device reverts back to 'unknown' with a unit of -1 when a 
probe() function fails.  Can you provide more details such as a verbose dmesg 
for both the ACPI and non-ACPI cases without your change?

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org