usbd config file parse behaviour

[Sam Lawrance]

> On Tue, Mar 30, 2004 at 01:46:32AM -0700, M. Warner Losh wrote:
>> In message: <20040330083607.GC32646 at cicely12.cicely.de>
>>             Bernd Walter <ticso at cicely12.cicely.de> writes:
>> : On Mon, Mar 29, 2004 at 07:44:34PM -0700, M. Warner Losh wrote:
>> : > In message: <1080613926.1125.6.camel at dirk>
>> : >             Sam Lawrance
>> <samuel.lawrance at 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