Hi Andrew, "Andrew P. Lentvorski" <bsder@xxxxxxxxxxx> writes: > On 1/17/20 1:25 AM, Felipe Balbi wrote: > >> why? No behavior changed. Look at the very first commit on >> f_hid.c. commit 71adf118946957839a13aa4d1094183e05c6c094 contains the >> following: > > Oops. I missed that. Sorry for not being complete enough. My fault. > >> Now, if there's a real usecase for this. Something that can attract, as >> per Dave B., 3 or more users, then we can consider adding it >> upstream. Remember that if we add support for changing interface >> strings, it has to be implemented for *all* functions and validated on >> all functions, then properly documented as a configfs ABI which can >> never change anymore. > > Erg. I did not realize that this was not going to be limited to just > f_hid.c. Well, all functions use the same infrastructure :-) > That's ... ugly. Reeeally ugly. And a *LOT* of work. yes :-) > I can certainly see that "some devices do this" is nowhere close to > enough justification for that. right >>> control board the ability to now also be accessed via ethernet or >>> wireless (or even a better USB protocol) and thus now has an upgrade or >>> higher performance path is a *really* useful thing. And the Beaglebone >>> Black is a really good "protocol engine". Finally, after making the usb >>> gadget emulation work, I can probably blow a bunch of Windows machines >>> away completely since something like a Beaglebone Black is more than >>> sufficient to handle the control without any outside intervention. >> >> You're getting to a point where things start to get interesting. What >> exactly are you trying to do? > > I've got both a GPIB (with USB 1.0(!) only--as far as I can tell--talk > about a relic) and an industrial controller (unknown protocol but USB > tracing and a signal analyzer shows pretty much 1-1 so reverse > engineering it doesn't seem problematic) currently sitting on my desk. you've just made totally envious :-p > I have one system which has enough USB devices in it that it won't work > on a USB 3 system because the Intel USB 3 chipset allocates twice as > many endpoints per device and hits an internal limit--they want a USB > upgrade as an intermediate move to ethernet. I understand > I have a half-dozen other similar type requests queued behind these. > People are finally reaching a critical point where they can't keep > ancient hardware, ancient drivers, ancient Windows, and ancient > computers all running anymore--even VM's are starting to fail as too > many things have some level of timing baked into the driver (normally > unintentionally). > >>> Anyhow, let me know whether I should attack the problem or not. > > At this point, I suspect that the correct answer is "Keep an eye on this > while moving forward." that's a good approach for now > If I stumble over more drivers that are trying to use iInterface for > some reason, I will see if setting it to 0x00 makes things choose a > different path. Simply changing the default to effectively 0x00-unused > seems like a lot less work and might pick up 90% of the use cases. It > also means the scope would be limited to f_hid.c. If I hit this a > couple times, I'll have a lot more justification behind me. > > If I start seeing cases where I actually need to specify the iInterface > stuff, I'll come back with data and we can revisit this again. I > suspect that someone is eventually going to drop a CDC class device in > front of me, and that will give me more data, too. If ever I reach the > point where I have multiple devices working around this, hopefully you > will find my arguments far more persuasive. :) Definitely, if you find a couple more usecases where this is needed, then we have much stronger evidence that this will be needed for real. >> you could use dummy_hcd as well. > > Interesting. I did not know about this, but I will keep it in mind. > > Thanks for being so patient. Sorry for wasting your time only to come > back to "do nothing". no worries, you didn't waste my time at all. I had never considered the usecases you mentioned before this thread ;-) -- balbi
Attachment:
signature.asc
Description: PGP signature
