linux-kernel - Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 08 Mar 2016 12:34:10 +0200
From:	Felipe Balbi <balbi@...nel.org>
To:	Krzysztof Opasiak <k.opasiak@...sung.com>,
	Felipe Ferreri Tonello <eu@...ipetonello.com>,
	linux-usb@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org,
	Michal Nazarewicz <mina86@...a86.com>,
	Clemens Ladisch <clemens@...isch.de>
Subject: Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes


Hi,

Krzysztof Opasiak <k.opasiak@...sung.com> writes:
> [ text/plain ]
>
>
> 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.

heh, seems like usb libraries tend to get forked with an 'x' appended to
their name. But thanks for the note.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)