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: Sat, 16 Jul 2005 11:22:14 -0600 (MDT)
In message: <4.3.2.7.2.20050716114020.01f0fcb8_at_mail.qconline.com>
            Harry Coin <harrycoin_at_qconline.com> writes:
: 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.

They arne't.  The CARDS are put to sleep.  However, PNPBIOS devices
can't be put to sleep, in general.  PCI resources aren't put to
sleep.  Your probe routine should, in the non-pnp case, only be
looking at the hinted resources for that device.

: So that these probe routines will only be called after the 
: field is clear  and they can rummage around the register space looking for 

probe routines aren't supposed to do that.  Probe routines are
supposed to answer the question 'Is this hardware at the specified
location.'  identify routines are allowed to go looking, but even they
are supposed to only look at 'alternative enumeration techniques'
rather than 'probing through the address space'.  Such probing was
banished in FreeBSD 3.0.

: 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.

Where is this manual of which you speak?  I'd sure like to change it
to be right.

: (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.)

I don't understand what you are suggesting here.

: 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).

I don't understand this either.  Please be more specific.  I'm coming
to the conversation late.

: 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.

I've already said that this isn't needed, and likely indicates some
abuse of the model.  I suspect that the abuse is that the probe
routine bogusly goes and looks for resources not assigned to it in the
hopes of finding hardware.

Warner
Received on Sat Jul 16 2005 - 15:21:58 UTC

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