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
