On Mon, Jan 29, 2007 at 10:25:12AM -0500, Alan Stern wrote:
> On Sun, 28 Jan 2007, Oleg Verych wrote:
[]
> >
> > {{vID, dID}, #working_configuration, #woring_interface }, obviously.
> >
> > To be honest, i can't understand, why you don't understand this.
>
> Part of the problem is that I find it difficult to follow your English.
> This isn't meant as a complaint! Your English is infinitely better than
> my Czech. But sometimes it is hard to grasp your intention.
Sorry.
> Also you sometimes leave out or skip over important aspects of the
> reasoning. Like here, for instance. It may have been obvious to you why
> you wanted to add #working_configuration and #working_interface values to
> the ID table, but it wasn't -- and still isn't -- entirely clear to me
> why you want them.
Maybe i'm wrong with fast solution proposing. I want them, because
it seems, that current binding of device (with IDs,#confs,#interfs) to
(USB interface) driver is done after guessing device's setup (default
is conf#1, interface#1, i think).
What if one-prupose device, like ti-usb-serial require its one operation
in different setup, and driver's author know it? I would like to have
such _option_, as device driver _have_ option to choose device it can
talk to -- ID tables.
> > I
> > think to provide all configuration path, without jumping thru air
> > isn't such a bad idea.
>
> Well, consider what you have just proposed. For example, let's say we
> have this entry in an ID table:
>
> vID=0x1234, dID=0x5678, #working_config=3, #working_interface=5.
I agree, this may be silly and stupid. But if you have understood
shortcomings of the current USB device configuration chain, please propose
The Good Solution(tm). Otherwise, if i didn't convince you design
issues, find another reason to support your point of view,
> Cases where the driver does care about the config value or interface
> number occur so rarely
this one is not acceped.
Also, i think usb_set_configuration() must be renamed to
sysfs_usb_set_coniguration(). One, that you have wrote for drivers,
and such approach must be removed. 100% configured device, must be
delivered to (USB interface) driver, and if this driver wants to have
{conf#n, interface#k}, please do as it wants on higher levels of setup.
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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
