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

["Andrew P. Lentvorski" <bsder@allcaps.org>]

On 1/16/20 5:02 AM, Felipe Balbi wrote:

>>>>> When I set my gadget up on my Beaglebone Black (uname -a: Linux
>>>>> beaglebone 4.14.108-ti-r113 #1 SMP PREEMPT Wed Jul 31 00:01:10 UTC
>>>>> 2019 armv7l GNU/Linux).
>>>>>
>>>>> I get (output from lsusb):
>>>>>
>>>>> iInterface 5 HID Interface
>>>>>
>>>>>
>>>>> But I want it to be something like:
>>>>>
>>>>> iInterface 4 LPC-LINK2 CMSIS-DAP V5.224
> 
> Why? Oh, you want your beaglebone to behave as a CMSIS-DAP to trick some
> other SW?
> 
> Do we need to support that upstream, though? It seems like this is a
> one-off thing. Does anybody else need to configure interface string
> descriptor?

I ... don't know, actually.  That's probably a good question.

What I *can* tell you is that a quick survey of the various USB devices
in my office with lsusb shows the majority of iInterface are 0x00, but
that everything else is a smattering of all manner of stuff: "Integrated
Camera", "Bulk Control Interface", "Volume Control", "Firmware Upgrade
Port", etc.

Microchip's PIC32 USB HID sample code sets the value to 0x00.

USB Complete (5th Edition) also shows this as 0x00 on page 267 for a
configuration_descriptor for a vendor-specific HID.


>> C) This is an actual bug *that should be fixed* and isn't that way
>> intentionally for some Linux reason.
> 
> Up until now, it has been intentional. Currently, I don't see a need to
> change it. 

Clearly, some HID devices *are* using this field.  So, this probably
should be made changeable if we want the HID gadget to be maximally useful.

As for the technical details I can see from the code:


A bit of code archaeology shows that .iInterface was expected to be
dynamic as of the origin commit for f_hid.c (commit
71adf118946957839a13aa4d1094183e05c6c094).  This still persists in the
file today.


The allocation of usb_gstrings_attach comes in at Nov 6, 2014 as of
(commit 5ca8d3ec9970f4798e68bd21a9d44db3d0ff4da7) with the message:

"Before configfs is integrated the usb_gstrings_attach() interface
must be used."

This looks like a case of something that simply got lost in the shuffle
in the upgrade path to configfs, and I'm just the first poor slob who
tripped over the oversight.


However, I'm a little concerned as to why this was set *at all* (which
seems to be what is actually tripping me up), and I'd be interested as
to what drove the specific choice of 0x05 "HID Interface".  I don't see
this in any spec anywhere obvious and this seems to be a deliberate
change from previous behavior.

If this isn't user configurable, then it's probably a highly
questionable choice to give this any default value other than 0x00.
This would have been quite a bit easier to code, too, so I'm *really*
scratching my head about this.


> I may be persuaded otherwise, but I need to see arguments
> other than "I want to trick some SW into thinking I'm something else".

Obviously I'm biased and scratching my own itch, but why would you
consider that not to be an important argument?

Being able to fake being a particular piece of USB hardware that's
currently tied to some ancient Windows binary driver is a great way to
insert Linux into industrial and lab control pipelines.  Giving a
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.

My end target isn't "CMSIS-DAP"--there are a zillion really cheap
CMSIS-DAP devices so emulating CMSIS-DAP would be mostly pointless
pedantry (although perhaps a good usb gadget tutorial).  CMSIS-DAP just
happens to be a really good test case as it is an extremely well
documented HID-based protocol and has extensive tests to validate it.
Consequently, I can be sure that most bugs and difficulties are
localized to my gadget implementation code or the gadget driver.



Anyhow, let me know whether I should attack the problem or not.  I
suspect my biggest issue is simply that I will have to do all the work
on a Beaglebone Black as I really don't know of any other way to test
that gadget subsystem.  This will probably be okay if I can build it as
a module--if I have to do a full kernel build it will probably demand
that I set up a cross-compiling environment (and that isn't trivial).


Thanks,
-a