From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 30 20:11:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0786416A4D1 for ; Tue, 30 Mar 2004 20:11:48 -0800 (PST) Received: from sam.stral.net (unknown [210.11.200.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA56C43D4C for ; Tue, 30 Mar 2004 20:11:46 -0800 (PST) (envelope-from boris@brooknet.com.au) Received: from localhost.localdomain ([127.0.0.1] helo=webmail.bensley.net) by sam.stral.net with esmtp (Exim 3.36 #1 (Debian)) id 1B8X4F-000560-00; Wed, 31 Mar 2004 14:11:07 +1000 Received: from 134.148.20.33 (proxying for 134.148.100.124) (SquirrelMail authenticated user sam); by webmail.bensley.net with HTTP; Wed, 31 Mar 2004 14:11:07 +1000 (EST) 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> Date: Wed, 31 Mar 2004 14:11:07 +1000 (EST) From: "Sam Lawrance" To: ticso@cicely.de User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Mailman-Approved-At: Wed, 31 Mar 2004 04:54:38 -0800 cc: ticso@cicely12.cicely.de cc: samuel.lawrance@studentmail.newcastle.edu.au cc: freebsd-hackers@freebsd.org Subject: Re: usbd config file parse behaviour X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 04:11:48 -0000 > On Tue, Mar 30, 2004 at 01:46:32AM -0700, M. Warner Losh wrote: >> In message: <20040330083607.GC32646@cicely12.cicely.de> >> Bernd Walter writes: >> : On Mon, Mar 29, 2004 at 07:44:34PM -0700, M. Warner Losh wrote: >> : > In message: <1080613926.1125.6.camel@dirk> >> : > Sam Lawrance >> 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