Subject: Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on
 bmAttributes
To: Felipe Balbi <balbi@kernel.org>,
        Felipe Ferreri Tonello <eu@felipetonello.com>,
        linux-usb@vger.kernel.org
References: <1456947640-20673-1-git-send-email-eu@felipetonello.com>
 <1456947640-20673-4-git-send-email-eu@felipetonello.com>
 <87wppi67c5.fsf@ti.com>
 <270D9ECD-1810-48BC-BBE9-9C9DD5E44D4F@felipetonello.com>
 <87egbmkah0.fsf@intel.com> <56DD4C84.1090506@felipetonello.com>
 <87ziuaimf8.fsf@intel.com> <56DD6241.2000308@felipetonello.com>
 <87h9ghife2.fsf@intel.com>
Cc: linux-kernel@vger.kernel.org, Michal Nazarewicz <mina86@mina86.com>,
        Clemens Ladisch <clemens@ladisch.de>
From: Krzysztof Opasiak <k.opasiak@samsung.com>
Message-id: <56DEA61F.1060100@samsung.com>
Date: Tue, 08 Mar 2016 11:14:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-version: 1.0
In-reply-to: <87h9ghife2.fsf@intel.com>
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1907
Lines: 54


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