On Thu, Jan 25, 2007 at 02:42:17PM -0500, Alan Stern wrote:
> 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.
Yea, nonsense. (device IDs are) Not sold, but resold ;)
> > 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.
let this be [0]
> > 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.
Well, ti usb-serial driver...
> > 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.
(I have it underline sometimes, when i'm in X terminal emulatior)
I mean connection of that word with USB description, unless this is
irony.
> > 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.
I accept, that i've wrote that with this picture in mind
deviceDescriptor->bNumInterfaces->bNumConfigurations
pic.1
(shame on me, but i only have read USB-in-a- nutshell.pdf [by Copyright
2002, Craig Peacock <[EMAIL PROTECTED]> Third Release] back
in summer and adopted request_firmare() to one usb-serial driver).
This picture
deviceDescriptor->bNumConfigurations->bNumInterfaces
pic.2
is actual, what USB has. This changes nothing. Even worse.
That doc., i have mensioned, pages 19-20 describes _interfaces_ in
particular, as posibility to have fax/scanner/printer device. I think
it's much similar to "effectively changed the way the device works":
- phone <-> paper
- paper -> paper
- computer -> paper
And this is suggested to implement as interfaces. So, as for me, [0]
and this are much similar. Why? Because this machine may have one box,
(at least) 2 cables (hardware interfaces to completely different
things), paper, no computer-driven mode of operation.
And yet it doesn't "effectively changing the way the device works"?
My opinion -- No, it *does* change. But interfaces on the picture
above, and device descriptors aren't on the same abstraction level.
Yet bloody usb-stick (with no cables at all) requires awful things in
the USB subsystem to happen. While USB<->RS* cables may be
distinguished as two different ones, and it equals to number of the
cable in machine above, yet on operation level this is only one
device, one configuration, one interface. Let this be [1].
In short:
deviceDescriptor->Operation = bNumInterface[!s]->Operation
(buggy software) (featured buggy hardware)
=[0] =[1]
pic.3
I think, linux-usb "in-short" you can imagine. My veiw of it is as:
deviceDescriptor-> bNumInterfaces +->Operation
+->Operation ...
(usb-core) (*drivers*)
pic.4
Do you see gap in pic.4 ? It was patched slightly in 2.6.19.
Patch
+++ bNumConfigurations +++
Shows, that it's very hard to do something with the gap, because
*drivers* in pic.4 are not device drivers as it should be, but operation
*managers*.
I know, that linux is developing on-demand by volunteers. Anyway i
refuse to accept deep cave in the design, design of configuration or
basic design, which must be utilized by anything, that may finally send
bytes.
I think drivers (in my understanding) must begin in deviceDescriptor
and any merging of bNumConfigurations and/or bNumInterfaces must
happen further: in one file kernel object or many, doesn't mater.
> > > 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.
I think core/generic.c is good one to start with, but
> But drivers get probed in the order they are registered, and the
> "generic" driver always gets registered first because it is built into
> usbcore.
this is the same as in pic.3: comparing apples with bananas -- everything
equals everything.
> To fix this we would need a way to re-order the list of drivers. Perhaps
> by some sort of priority level.
Here, i mean, that i just will know about such kind of driver to study.
I don't now, if i have expressed, what i feel. But maybe there is
something, that will help you to understand me.
> Alan Stern
>
Thanks.
____
-------------------------------------------------------------------------
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
