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

[M. Warner Losh]

In message: <4.3.2.7.2.20050716124022.01f08460 at mail.qconline.com>
            Harry Coin <harrycoin at qconline.com> writes:
: Thank you. I should have been more clear.  I'm aware of this.  The driver 
: in question is the mss.c which indeed has a mss_probe non pnp routine 
: called, and which succeeds, with acpi as a parent -- which when the 
: following attach call is made fails.  Extensive documentation is upstream.

Yes.  Just read the thread.  Please delete the line that John
suggests, as has already been committed to current.  If there are PNP
ids we need to add to the pnp probe, we should add those and not
kludge around it.

: My thought is, if the current roster of non pnp isa drivers is not to be 
: touched, then the OS ought to avoid to call their probe routines unless the 
: pnp cards are all sleeping whether by acpi or whatever.   Also it is my 
: experience that there are quite a good many sound chips out there that are 
: pnp but are not in the roster of pnp devices in the pnp mss detect 
: driver.  The current setup will allow these devices to be probed and to 
: operate (maybe not as pcm0) via the non-pnp detect routine called from the 
: acpi.  A lucky side effect that helps some folk but which will go away if 
: this issue is cleaned up I fear.

Ummm, that's not the way things should work.  Sorry to disappoint you,
but John and I are telling you the same thing: don't have acpi
attachments that use isa_get_logicalid().

I've taken a look at the other drivers.  gusc and esscontrol seem to
also have this problem.

Of course, we should also fix the ACPI layer to do the right thing.
The right thing here is for isa_get_logicalid() to always return
non-zero because, by definition, all acpi devices have logical ids.
That's the real bug here, and the rest of your observations are
downstream effects that aren't important.

Warner