Date: Wed, 10 Sep 1997 22:12:53 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: perhaps@yes.no (Eivind Eklund) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support Message-ID: <199709102012.WAA22589@labinfo.iet.unipi.it> In-Reply-To: <199709101826.UAA02417@bitbox.follo.net> from "Eivind Eklund" at Sep 10, 97 08:25:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> With the integration of the PnP drivers yesterday, I thought it was > time to play around a little, and attempted to convert a driver to use > PnP in addition to the normal ISA probes. The PnP support seems like > a nice piece of work - most of it was exceedingly simple. > > However, I had the following problems, and wonder if there is a stock > solution to them (they might just result from me not RTSLing well > enough, but answers might be enlightening to others too): > > (1) I wanted the driver to be able to work with both PnP and ISA > cards. However, the ISA probe mess up the card (or the internal I can tell you how I solved the problem with the sound driver: I have the probe routine scan the descriptors for the same type of device, and skip (and return with a 'not found' code) the ISA probe if a PnP unit at the same address ranges has been found. Since PnP devices are probed first this works as expected. If the PnP attach routine was also recording the resource usage as isa devices do, this scan would not be necessary. I think the appropriate tests are in function haveseen_isadev(), but since I do not know the details, nor I know if the code assumes a statically built table of devices, I did not call these functions and build a special-purpose one (in the case of sound driver this is necessary in any case since many sound cards emulate both a SB and a MSS and while the driver supports one of the two modes we want to be sure that the other one is not used as well. > (2) I found no way to report that the driver was unable to attach if > the probe came out true. This might be me thinking approaching this the idea is that probe should do all the test and attach should not go wrong. As you say this is not a good approach IMHO, the attach routine should be able to return an error code. With the current status of the code, a driver failing to attach should unregister resource usage on its own. > (3) The card reports as unknown0 <description>. I assume this can be dvp->dev.id_driver->name is what goes in place of "unknown", dvp->pd_name is the "description" dvp->dev should be initialized from the corresponding isa device entry in the attach routine. dvp->pd_name is in the PnP device descriptor. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709102012.WAA22589>