Re: Unable to set "iInterface" in usb gadget via configfs

[Felipe Balbi <balbi@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4248 bytes --]


Hi Andrew,

"Andrew P. Lentvorski" <bsder@allcaps.org> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]