On Thu, 25 Jan 2007, Oleg Verych wrote: > 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.
> 2. p.0 goes atomicaly for device with particular ID and must have full > control of plugged/(un)bound device. > > 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 ;) Nonsense. The device uses a new Product ID, not a new Vendor ID. The USB IF charges money only for vendor IDs. > And this ID > game is major issue, i think. Not interfaces, not configurations were > choosen, but IDs. I think changing the ID is appropriate. By loading new firmware, you have effectively changed the way the device works. And since it is now a different sort of device, it should have a new ID. > 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. Why the *same* routine? Since the ID is different (which you can easily check), you should run a different routine. > 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. That is indeed a bad design. The first configuration should be one that people will want to use, not something useless. > > > 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? Yes. The word "_interfaces_" means the same thing as "*interfaces*" or "<emph>interfaces</emph>". Think of it as the word "interfaces" with an underline. > According to p.1 this design is OK. I have one device, *one* interface, > (some) configurations. In short: one purpose, some states. If you have multiple configurations then you must have multiple interfaces. Each interface can belong to only one configuration. For example, interface 0 in config #1 is different from interface 0 in config #2. > > 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 There will be a problem if you try to write another driver of this sort. The "generic" driver should bind to any device except the ones claimed by your driver. This means your driver has to be probed first. But drivers get probed in the order they are registered, and the "generic" driver always gets registered first because it is built into usbcore. To fix this we would need a way to re-order the list of drivers. Perhaps by some sort of priority level. 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
