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

[M. Warner Losh]

In message: <42D9DA05.1020806 at root.org>
            Nate Lawson <nate at root.org> writes:
: M. Warner Losh wrote:
: > <the refs are wrong for this reply>
: > Nate writes:
: > 
: >>I really think the driver is broken and the API is fine for this.  I 
: >>don't like the hack of returning a random CID for checks against the 
: >>HID.  Drivers down the road may come to rely on this and then every BIOS 
: >>that has a different order for CIDs becomes a potential breakage point.
: > 
: > 
: > They alredy do rely on this.  When they support pnp, they call the
: > ISA_PNP_PROBE routine.  When they don't then your observation doesn't
: > matter because the order of the IDs doesn't matter: their non-zeroness
: > does.
: > 
: > 
: >>Drivers should not rely on isa_get_logicalid() to determine a boolean 
: >>"is PNP?"
: > 
: > 
: > Actually, that's the interface.  We have to follow it, even if you
: > think it is stupid.  It is how we do things.  When we don't have a
: > logicalid, we return 0.  When drivers don't support pnp devices, it
: > uses the existance of a non-zero pnpid to know the device isn't for
: > them.  It has been this way since 3.0.
: > 
: > Warner
: 
: 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?

That might not be a bad idea.  I'm not sure the right thing to do is.
I know this would break at least one sound driver, but I believe that
sound driver is broken anyway.

Warner