On Thu, 25 Jan 2007, Oleg Verych wrote:

> On Thu, Jan 25, 2007 at 04:17:03PM +0100, Oliver Neukum wrote:
> []
> > > 
> > > It is relatively new. As comment states, it doesn't guarantee
> > > anything, caller hangs in air...
> > 
> > Yes, unfortunately this is true. However, as I understand it, you are
> > helpless if you are called with the wrong configuration. So you don't really
> > lose anything.
> > If you wish to, you can return 0 from probe() and you'll be disconnected
> > from the device by the change of configuration.
> 
> Well, any kind of crutch may be used, still it's crutch.

Why call it a crutch?  It's a tool, designed to do what you want.

> > The alternative is a deep change to the API for one odd type of device.
> > Do you absolutely need an error return?
> 
> AFAIK, this is standard USB firmware update logic. Greg even
> co-authored a standard for this.

Sorry, I don't follow.  You mentioned two different sorts of firmware 
update procedures:

    1.  Send the firmware.  The device disconnects and then reconnects,
        using a new ID.

    2.  The device uses the same ID but has separate configurations, one
        for receiving the firmware and one for normal operation.

Which is the standard?

> As for me, driver must have full control of plugged device until it
> unplugged.

That is not how it works.  The standard Linux USB drivers do not have
full control over devices at all.  They control only _interfaces_, not
_devices_.

(Also, as Oliver pointed out, they have control only during the time they 
are bound to the device.  The user may unbind the driver whenever he feels 
like, without unplugging the device.)

There is a provision for a type of USB driver which _does_ control the
entire device.  But you may not want to use it, and it wasn't intended for
this sort of thing.  (It was meant for situations where you want to export
a USB device to another system.  For example: USB over TCP/IP, or a host
exporting a device to a virtualized guest.)  The only existing driver of
this sort is the "generic" driver, in drivers/usb/core/generic.c.

Alan Stern


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to