On Thu, Jan 25, 2007 at 11:39:33AM -0500, Alan Stern wrote: > On Thu, 25 Jan 2007, Oleg Verych wrote:
0. Here i will mean first ever driver's job -- setting up device. Was it bound by user or not -- doesn't mater. 1. USB defines interfaces and configurations of them. > > 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. 2. p.0 goes atomicaly for device with particular ID and must have full control of plugged/(un)bound device. > > > 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. AFAIK this was in Greg's paper. And this is how it usualy implemented. Small ROM for bootloader, anything else is `goto RAM'. And this smells like marketing thing: more ID sold, more bucks you have ;) And this ID game is major issue, i think. Not interfaces, not configurations were choosen, but IDs. 3. This and p.2 forces driver to issue reset and wait for "another" device with another ID to be configured further with *same* routine. > 2. The device uses the same ID but has separate configurations, one > for receiving the firmware and one for normal operation. 4. p.3 is done and in particular case of TI USB, where external firmware is in due, after device reappears with new ID it has config #1 and this config is absolutely anonymous. All, linux driver author doing is just requesting of changing it to #2 to have usb-serial operation. So, what #1 is doing -- i don't know. > 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_. 5. Are _interfaces_ alias of USB interfaces here? According to p.1 this design is OK. I have one device, *one* interface, (some) configurations. In short: one purpose, some states. And if this and p. 5 is true, how p.3 could have happen? I don't know how power states of usb-device driven hardware are changing in existing drivers, i believe, that i've read about something like this: #1 -- working config #2 -- powerstates (of further hardware). > (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.) OK, assuming p.0 here. > 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. I must study that. Thanks > 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
