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

From: Harry Coin <harrycoin_at_qconline.com>
Date: Sat, 16 Jul 2005 12:11:50 -0500
At 10:30 AM 7/16/2005 -0600, M. Warner Losh wrote:

>Nate's right here.  It isn't needed.  The ISA_PNP_PROBE is for all
>devices that have a PNP ID.  Thse includes ISA PnP cards, PNP BIOS
>devices and ACPI devices.  So the device_is_pnp() isn't needed at all.
>
>Warner

I think all that's needed to wrap this up is for the powers that be to 
offer clarity about one thing, final decision about the case of arbitrary 
(beyond com1, etc.) non-pnp ISA devices probe routines.  A great many sound 
chips of various register demands are in this list.  (Admittedly older 
devices, but I ran into serious breakage of an isa pnp device driver 
because of interactions with the related non-pnp probe routine that 
supported earlier chipsets in the same family that were largely register 
compatible with the pnp versions).

Seems either

1) Document a way or make an OS change to make certain non-pnp isa probe 
routines are never called any time while pnp isa resources haven't been put 
to sleep.   So that these probe routines will only be called after the 
field is clear and they can rummage around the register space looking for 
their chips -- and they don't accidentally find compatible PCI versions 
previously or yet to be found by their PCI probe modern driver cousins. The 
isa part of the architecture manual ought to be updated to reflect how 
properly to do this.  (Are there cases where the non-pnp routines being 
called in the acpi context pass the currently iffy pnp-gate and find and 
enable operations of pnp chips that the pnp-routines don't have in their 
'acceptable id' list?  My hunch in the sound chip world is 'yes'. So this 
fix might break audio on systems that don't have the pnp ids in the pnp 
soundchip ISA_PROBE roster as yet.)

or

2) change non-pnp isa drivers to do as the architecture manual currently 
suggests, with inelegance that John noted (ISA_PNP_PROBE with the null list 
then continue only if no pnp id for the device).

or

3) make a device_is_pnp OS call that does 2 and avoids the inelegance, then 
update the architecture manual for isa drivers and also the isa drivers 
themselves.

or

4)  I can't think of a 4, but I'm sure there is a 4.  There's always a 4.

Please pick and announce!

Harry
Received on Sat Jul 16 2005 - 15:11:59 UTC

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