On 03/08/2016 08:43 AM, Felipe Balbi wrote: (...) >>>> This is necessary because this driver is actually wrong in which is >>>> asking for the host to power itself. This is not specified on USB-MIDI >>>> specification, neither makes any sense since this configuration is >>>> device specific. >>>> >>>> What is your suggestion to make it configurable? Maybe at compile-time? >>>> I really don't know what is the best solution if this is not something >>>> you like it. >>> >>> well, you could use our configfs-based gadget interface. You don't >>> really need to use gmidi.ko at all. In fact, we wanna do away with any >>> static modules and rely only on configfs. If configfs doesn't let you >>> change what you want/need, then we can talk about adding support for >>> those. >>> >>> bMaxPower and bmAttributes sound like good things to have configurable >>> over configfs but beware of what the USB specification says about them, >>> we cannot let users violate the spec by passing bogus values on these >>> fields. >> >> I agree that we should move to configfs, but the truth is that these >> legacy devices are still useful. They just do one thing, mostly, but > > yes, they are useful as they are. They don't need to be changed to be > useful. Plus, you can have a gadget built with configfs that does only > one thing. And you can do that with a simple shell script. > >> its easy and simple to setup and use. So I think before we have some > > so is configfs. > >> sort of preset library of configfs-based gadget drivers, we still need >> these modules. > > there is already a library called libusbg. As libusbg itself is a little bit dead there is a fork called libusbgx[1] and it is still active;) It already has support for f_midi so it is ready to use. Footnotes: 1 - https://github.com/libusbgx/libusbgx Cheers, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
