Date: Wed, 31 Mar 2004 14:11:07 +1000 (EST) From: "Sam Lawrance" <boris@brooknet.com.au> To: ticso@cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: usbd config file parse behaviour Message-ID: <39883.134.148.20.33.1080706267.squirrel@134.148.20.33> In-Reply-To: <20040330090601.GE32646@cicely12.cicely.de> References: <1080613926.1125.6.camel@dirk> <20040329.194434.48530053.imp@bsdimp.com> <20040330083607.GC32646@cicely12.cicely.de> <20040330.014632.132641792.imp@bsdimp.com> <20040330090601.GE32646@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, Mar 30, 2004 at 01:46:32AM -0700, M. Warner Losh wrote: >> In message: <20040330083607.GC32646@cicely12.cicely.de> >> Bernd Walter <ticso@cicely12.cicely.de> writes: >> : On Mon, Mar 29, 2004 at 07:44:34PM -0700, M. Warner Losh wrote: >> : > In message: <1080613926.1125.6.camel@dirk> >> : > Sam Lawrance >> <samuel.lawrance@studentmail.newcastle.edu.au> writes: >> : > : On Sun, 2004-03-28 at 20:47, Bernd Walter wrote: >> : > : > On Sun, Mar 28, 2004 at 01:31:03AM -0700, M. Warner Losh wrote: >> : > : > > Btw, any interest in making it possible to kldload a usb >> module and >> : > : > > having device attach to it? Right now the usb code assumes >> that you >> : > : > > can unplug the device and replug it back in. I have at least >> two >> : > : > > devices on my laptop that can't be removed (bluetooth and >> memory stick >> : > : > > reader), so I can't dynamically load drivers for them... >> : > : > >> : > : > I'll think about it. >> : > : > Reprobing is not so much an issue as selecting an interface for >> it. >> : > : >> : > : would this done by filling in uhub_driver_added() to find a better >> : > : driver match for a device and reattaching? >> : > >> : > Yes. Actually, it also requires some changes to newbus as well to >> : > allow for rebidding of devices. And there's some minor resetting of >> : > the device that likely needs to happen, but that's lower priority. >> : >> : Don't forget that we already have a driver for every USB device: >> ugen(4) >> : We need a better trigger to reprobe drivers - thats the real problem. >> >> No. That's not the real problem here. The real problem here is that >> uhub doesn't implement the driver_added callback correctly. The ugen >> issue, while interesting, can be overcome by not having ugen in the >> kernel. > > Not having ugen in the kernel is not an option. > I can't say that I really like the problems introduced by ugen, but > since I have no better idea and ugen is widely used - even by me. > >> When ugen is in the kernel, we do need to do the rebid thing in >> newbus, which we don't do, but there's little point in fixing one w/o >> fixing the other. > > You can't kldload a new driver and reshuffeling all ugen instances. > They are possibly used and probing for USB devices requires exclusive > access in many cases. > > I'm more thinking about some kind of userland tool that allows > retriggering an USB device in a controlled way. > Such a feature is required for some types of firmware downloaders too. > Intelligent USB chips requireing firmware download could disconneect > and reconnect themself from the bus e.g. the TI-TUSB* family, but > there are still others in the wild. > I've seen firmware downloaders to do evil things as reseting an USB > ports on their own, which is quite dangerously as it introduces a > race for having multiple devices with address 0 (the default for > freshly attached ones). I agree that it's bad to yank a device from under ugen automatically and reattach it to a better match. How about adding a new ioctl on /dev/usb, eg USB_REPROBE to reset a device if a better match exists? Could tack an option on to usbdevs to call it on requested devices. -Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39883.134.148.20.33.1080706267.squirrel>