From owner-freebsd-new-bus Tue Nov 23 1:43:11 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 3AB0F14F49 for ; Tue, 23 Nov 1999 01:43:07 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-132.skylink.it [194.185.55.132]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id KAA27163; Tue, 23 Nov 1999 10:42:40 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id KAA00640; Tue, 23 Nov 1999 10:28:46 +0100 (CET) (envelope-from hibma@skylink.it) Date: Tue, 23 Nov 1999 10:28:46 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: Doug Rabson Cc: FreeBSD Newbus Mailing List Subject: Re: cvs commit: src/sys/pci pcisupport.c pci.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > The reason for them being there in the first place is that every > > > motherboard comes with USB kit and this way it looks more pretty (peter). > > > The real solution will be to define some method of detaching a driver > > > after it has attached. > > > > Duh, detaching a __stub__ after it has attached. > > Probably we will track the priority which a driver probed at and if it > wasn't zero, detach the driver when a new driver is loaded, before the > reprobe. This would allow the new driver to bid for the hardware. You'll get an awefull lot of disconnects in that case (1). It would be highly inappropriate in the case of USB, disconnecting the Zip drive if you load the mouse driver. Requesting the maximum priority at which the driver might attach is the minimum you can do to avoid detaches.(2) It would be even better if you could first do a non-intrusive probe on _possible_ targets before detaching them (3). I've been playing with the idea of cloning devices (if DEVICE_REPROBABLE returns true) and probing on those clones. The only problem I had was that I had no clue on where to stick those clones. Maybe we should create a new device with the same ivars and make it quiet during the reprobe instead of a clone. foreach(devclass_get_devices(dc)) if (DEVICE_REPROBABLE(odevice) ndevice = clone_device(odevice) # or ndevice = devclass_add_device(dc) # and copy ivars, resources. priority = DEVICE_PROBE(ndevice) if (priority > device_get_priority(odevice)) # or was it X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: FreeBSD Newbus Mailing List Cc: Doug Rabson Subject: device_get_softc(devclass_get_unit(devclass, unit)) != devclass_get_softc(devclass, unit) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Executed _during_attach_, a sc = devclass_get_softc(devclass, unit); returns NULL, but a sc = device_get_softc(devclass_get_unit(devclass, unit)); returns the softc. The statements are equivalent but the result is inconsistent. I suggest removing the limitation if (!dev || dev->state < DS_ATTACHED) return NULL; from devclass_get_softc (diff below). Reason: if you do initialisation (for example CAM, XPT_SCAN_BUS in my case), you will end up in the routines that need this function before attach is finished and state >= DS_ATTACHED. Second, none of the other functions uses this limitation (devclass_get_devices(), devclass_get_unit()). Let me know your thoughts. Nick -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ Index: subr_bus.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_bus.c,v retrieving revision 1.46 diff -u -u -w -r1.46 subr_bus.c --- subr_bus.c 1999/11/18 06:05:30 1.46 +++ subr_bus.c 1999/11/26 20:25:58 @@ -432,11 +432,13 @@ { device_t dev; - if (unit < 0 || unit >= dc->maxunit) + if (dc == NULL || unit < 0 || unit >= dc->maxunit) return NULL; + dev = dc->devices[unit]; - if (!dev || dev->state < DS_ATTACHED) + if (dev == NULL) return NULL; + return dev->softc; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message