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

[Felipe Ferreri Tonello]

Hi,

On 08/03/16 14:20, Felipe Balbi wrote:
> 
> Hi,
> 
> Krzysztof Opasiak  writes:
>> [ text/plain ]
>>
>>
>> On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
>>  (...)
>>

> sort of preset library of configfs-based gadget drivers, we still need
> these modules.

 there is already a library called libusbg.
>>>
>>> By preset library I meant scripts or little programs that implement the
>>> legacy drivers we have.
>>>
>>
>> libusbgx implements an idea of gadget schemes[1]. That's simple
>> configuration files using libconfig syntax. I don't see any problems to
>> use it to create legacy gadget equivalents. Then you could simply load
>> it using usbg_import_gadget() in C code or gt[2] load from shell.
> 
> cool, bmAttributes and bMaxPower are already there. Nice.
> 

Yes! It is pretty awesome.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Ferreri Tonello]

Hi,

On 08/03/16 14:20, Felipe Balbi wrote:
> 
> Hi,
> 
> Krzysztof Opasiak  writes:
>> [ text/plain ]
>>
>>
>> On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
>>  (...)
>>

> sort of preset library of configfs-based gadget drivers, we still need
> these modules.

 there is already a library called libusbg.
>>>
>>> By preset library I meant scripts or little programs that implement the
>>> legacy drivers we have.
>>>
>>
>> libusbgx implements an idea of gadget schemes[1]. That's simple
>> configuration files using libconfig syntax. I don't see any problems to
>> use it to create legacy gadget equivalents. Then you could simply load
>> it using usbg_import_gadget() in C code or gt[2] load from shell.
> 
> cool, bmAttributes and bMaxPower are already there. Nice.
> 

Yes! It is pretty awesome.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Balbi]

Hi,

Krzysztof Opasiak  writes:
> [ text/plain ]
>
>
> On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
>  (...)
>
>>>
 sort of preset library of configfs-based gadget drivers, we still need
 these modules.
>>>
>>> there is already a library called libusbg.
>> 
>> By preset library I meant scripts or little programs that implement the
>> legacy drivers we have.
>> 
>
> libusbgx implements an idea of gadget schemes[1]. That's simple
> configuration files using libconfig syntax. I don't see any problems to
> use it to create legacy gadget equivalents. Then you could simply load
> it using usbg_import_gadget() in C code or gt[2] load from shell.

cool, bmAttributes and bMaxPower are already there. Nice.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Krzysztof Opasiak  writes:
> [ text/plain ]
>
>
> On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
>  (...)
>
>>>
 sort of preset library of configfs-based gadget drivers, we still need
 these modules.
>>>
>>> there is already a library called libusbg.
>> 
>> By preset library I meant scripts or little programs that implement the
>> legacy drivers we have.
>> 
>
> libusbgx implements an idea of gadget schemes[1]. That's simple
> configuration files using libconfig syntax. I don't see any problems to
> use it to create legacy gadget equivalents. Then you could simply load
> it using usbg_import_gadget() in C code or gt[2] load from shell.

cool, bmAttributes and bMaxPower are already there. Nice.

-- 
balbi


signature.asc
Description: PGP signature

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

[Krzysztof Opasiak]

On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
 (...)

>>
>>> sort of preset library of configfs-based gadget drivers, we still need
>>> these modules.
>>
>> there is already a library called libusbg.
> 
> By preset library I meant scripts or little programs that implement the
> legacy drivers we have.
> 

libusbgx implements an idea of gadget schemes[1]. That's simple
configuration files using libconfig syntax. I don't see any problems to
use it to create legacy gadget equivalents. Then you could simply load
it using usbg_import_gadget() in C code or gt[2] load from shell.

Footnotes:
1 - https://github.com/libusbgx/libusbgx/blob/master/doc/gadget_schemes.txt
2 - https://github.com/kopasiak/gt

Cheers,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

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

[Krzysztof Opasiak]

On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
 (...)

>>
>>> sort of preset library of configfs-based gadget drivers, we still need
>>> these modules.
>>
>> there is already a library called libusbg.
> 
> By preset library I meant scripts or little programs that implement the
> legacy drivers we have.
> 

libusbgx implements an idea of gadget schemes[1]. That's simple
configuration files using libconfig syntax. I don't see any problems to
use it to create legacy gadget equivalents. Then you could simply load
it using usbg_import_gadget() in C code or gt[2] load from shell.

Footnotes:
1 - https://github.com/libusbgx/libusbgx/blob/master/doc/gadget_schemes.txt
2 - https://github.com/kopasiak/gt

Cheers,
-- 
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
>>> 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.
>
> By preset library I meant scripts or little programs that implement the
> legacy drivers we have.

like this ?

https://github.com/libusbgx/libusbgx/blob/master/examples/gadget-midi.c

>>> Any suggestions on that?
>>>
>>> Do you want to support what I am proposing for gmidi.ko or just ignore
>>> it and move on to configfs?
>> 
>> I prefer to not touch these gadget drivers if at all necessary. If you
>> fixing a bug, then sure we must fix bugs. But you're not fixing a bug
>> and, on top of that, you're adding regressions and violating the USB
>> spec. This shows that you're writing these patches without knowing
>> (and/or even caring about) the specification at all.
>
> Yes, I see your point. My mistake was to not to enforce the first bit to
> be set enabling the user to break the USB spec. I didn't think of that

right, that was the problem.

> scenario. And that's why it's always useful to have kernel maintainers
> and others to provide such insights. :)

yeah, no problem ;-)

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
>>> 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.
>
> By preset library I meant scripts or little programs that implement the
> legacy drivers we have.

like this ?

https://github.com/libusbgx/libusbgx/blob/master/examples/gadget-midi.c

>>> Any suggestions on that?
>>>
>>> Do you want to support what I am proposing for gmidi.ko or just ignore
>>> it and move on to configfs?
>> 
>> I prefer to not touch these gadget drivers if at all necessary. If you
>> fixing a bug, then sure we must fix bugs. But you're not fixing a bug
>> and, on top of that, you're adding regressions and violating the USB
>> spec. This shows that you're writing these patches without knowing
>> (and/or even caring about) the specification at all.
>
> Yes, I see your point. My mistake was to not to enforce the first bit to
> be set enabling the user to break the USB spec. I didn't think of that

right, that was the problem.

> scenario. And that's why it's always useful to have kernel maintainers
> and others to provide such insights. :)

yeah, no problem ;-)

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Ferreri Tonello]

Hi Balbi,

On 08/03/16 07:43, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello  writes:
 @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
  module_param(out_ports, uint, S_IRUGO);
  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
  
 +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
 +module_param(bmAttributes, uint, S_IRUGO);
 +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>>> bmAttributes parameter");
 +
 +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
 +module_param(MaxPower, uint, S_IRUGO);
 +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>>> Descriptor's bMaxPower parameter");
>>>
>>> you didn't run checkpatch, did you ? Also, are you sure you will need
>>> to
>>> change this by simply reloading the module ? I'm not convinced.
>>
>> Yes I always run checkpatch :)
>
> do you really ? Why do you have a 98-character line, then ?
> 
> btw, you didn't reply this ^^
> 
 @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
.label  = "MIDI Gadget",
.bConfigurationValue = 1,
/* .iConfiguration = DYNAMIC */
 -  .bmAttributes   = USB_CONFIG_ATT_ONE,
>>>
>>> nack, nackety nack nack nack :-)
>>>
>>> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>>> give users the oportunity to violate USB spec.
>>
>> You are right. It needs to check the value before it assigns to
>> bmAttributes.
>
> why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
> case, I'm not convinced this is necessary at all.

 Right.

 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.

By preset library I meant scripts or little programs that implement the
legacy drivers we have.

> 
>> Any suggestions on that?
>>
>> Do you want to support what I am proposing for gmidi.ko or just ignore
>> it and move on to configfs?
> 
> I prefer to not touch these gadget drivers if at all necessary. If you
> fixing a bug, then sure we must fix bugs. But you're not fixing a bug
> and, on top of that, you're adding regressions and violating the USB
> spec. This shows that you're writing these patches without knowing
> (and/or even caring about) the specification at all.

Yes, I see your point. My mistake was to not to enforce the first bit to
be set enabling the user to break the USB spec. I didn't think of that
scenario. And that's why it's always useful to have kernel maintainers
and others to provide such insights. :)

Anyway, I see that this patch is not useful even if corrected.

> 
> Here's some enlightening presentation you probably wanna watch:
> 
> https://www.youtube.com/watch?v=fMeH7wqOwXA
> 
> TL;DR : this project is large and you need to convince me we need your
> code/patch.
> 

Felipe


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Ferreri Tonello]

Hi Balbi,

On 08/03/16 07:43, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello  writes:
 @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
  module_param(out_ports, uint, S_IRUGO);
  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
  
 +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
 +module_param(bmAttributes, uint, S_IRUGO);
 +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>>> bmAttributes parameter");
 +
 +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
 +module_param(MaxPower, uint, S_IRUGO);
 +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>>> Descriptor's bMaxPower parameter");
>>>
>>> you didn't run checkpatch, did you ? Also, are you sure you will need
>>> to
>>> change this by simply reloading the module ? I'm not convinced.
>>
>> Yes I always run checkpatch :)
>
> do you really ? Why do you have a 98-character line, then ?
> 
> btw, you didn't reply this ^^
> 
 @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
.label  = "MIDI Gadget",
.bConfigurationValue = 1,
/* .iConfiguration = DYNAMIC */
 -  .bmAttributes   = USB_CONFIG_ATT_ONE,
>>>
>>> nack, nackety nack nack nack :-)
>>>
>>> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>>> give users the oportunity to violate USB spec.
>>
>> You are right. It needs to check the value before it assigns to
>> bmAttributes.
>
> why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
> case, I'm not convinced this is necessary at all.

 Right.

 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.

By preset library I meant scripts or little programs that implement the
legacy drivers we have.

> 
>> Any suggestions on that?
>>
>> Do you want to support what I am proposing for gmidi.ko or just ignore
>> it and move on to configfs?
> 
> I prefer to not touch these gadget drivers if at all necessary. If you
> fixing a bug, then sure we must fix bugs. But you're not fixing a bug
> and, on top of that, you're adding regressions and violating the USB
> spec. This shows that you're writing these patches without knowing
> (and/or even caring about) the specification at all.

Yes, I see your point. My mistake was to not to enforce the first bit to
be set enabling the user to break the USB spec. I didn't think of that
scenario. And that's why it's always useful to have kernel maintainers
and others to provide such insights. :)

Anyway, I see that this patch is not useful even if corrected.

> 
> Here's some enlightening presentation you probably wanna watch:
> 
> https://www.youtube.com/watch?v=fMeH7wqOwXA
> 
> TL;DR : this project is large and you need to convince me we need your
> code/patch.
> 

Felipe


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Balbi]

Hi,

Krzysztof Opasiak  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


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Krzysztof Opasiak  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


signature.asc
Description: PGP signature

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

[Krzysztof Opasiak]

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 Institute Poland
Samsung Electronics

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

[Krzysztof Opasiak]

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 Institute Poland
Samsung Electronics

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
>>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>>  module_param(out_ports, uint, S_IRUGO);
>>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>>  
>>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>>> +module_param(bmAttributes, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>> bmAttributes parameter");
>>> +
>>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>>> +module_param(MaxPower, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>> Descriptor's bMaxPower parameter");
>>
>> you didn't run checkpatch, did you ? Also, are you sure you will need
>> to
>> change this by simply reloading the module ? I'm not convinced.
>
> Yes I always run checkpatch :)

 do you really ? Why do you have a 98-character line, then ?

btw, you didn't reply this ^^

>>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>> .label  = "MIDI Gadget",
>>> .bConfigurationValue = 1,
>>> /* .iConfiguration = DYNAMIC */
>>> -   .bmAttributes   = USB_CONFIG_ATT_ONE,
>>
>> nack, nackety nack nack nack :-)
>>
>> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>> give users the oportunity to violate USB spec.
>
> You are right. It needs to check the value before it assigns to
> bmAttributes.

 why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
 case, I'm not convinced this is necessary at all.
>>>
>>> Right.
>>>
>>> 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.

> Any suggestions on that?
>
> Do you want to support what I am proposing for gmidi.ko or just ignore
> it and move on to configfs?

I prefer to not touch these gadget drivers if at all necessary. If you
fixing a bug, then sure we must fix bugs. But you're not fixing a bug
and, on top of that, you're adding regressions and violating the USB
spec. This shows that you're writing these patches without knowing
(and/or even caring about) the specification at all.

Here's some enlightening presentation you probably wanna watch:

https://www.youtube.com/watch?v=fMeH7wqOwXA

TL;DR : this project is large and you need to convince me we need your
code/patch.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
>>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>>  module_param(out_ports, uint, S_IRUGO);
>>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>>  
>>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>>> +module_param(bmAttributes, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>> bmAttributes parameter");
>>> +
>>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>>> +module_param(MaxPower, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>> Descriptor's bMaxPower parameter");
>>
>> you didn't run checkpatch, did you ? Also, are you sure you will need
>> to
>> change this by simply reloading the module ? I'm not convinced.
>
> Yes I always run checkpatch :)

 do you really ? Why do you have a 98-character line, then ?

btw, you didn't reply this ^^

>>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>> .label  = "MIDI Gadget",
>>> .bConfigurationValue = 1,
>>> /* .iConfiguration = DYNAMIC */
>>> -   .bmAttributes   = USB_CONFIG_ATT_ONE,
>>
>> nack, nackety nack nack nack :-)
>>
>> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>> give users the oportunity to violate USB spec.
>
> You are right. It needs to check the value before it assigns to
> bmAttributes.

 why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
 case, I'm not convinced this is necessary at all.
>>>
>>> Right.
>>>
>>> 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.

> Any suggestions on that?
>
> Do you want to support what I am proposing for gmidi.ko or just ignore
> it and move on to configfs?

I prefer to not touch these gadget drivers if at all necessary. If you
fixing a bug, then sure we must fix bugs. But you're not fixing a bug
and, on top of that, you're adding regressions and violating the USB
spec. This shows that you're writing these patches without knowing
(and/or even caring about) the specification at all.

Here's some enlightening presentation you probably wanna watch:

https://www.youtube.com/watch?v=fMeH7wqOwXA

TL;DR : this project is large and you need to convince me we need your
code/patch.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Ferreri Tonello]

Hi Balbi, how are you?

On 07/03/16 10:59, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello  writes:
> "Felipe F. Tonello"  writes:
>> [ text/plain ]
>> This gadget uses a bmAttributes and MaxPower that requires the USB
> bus to be
>> powered from the host, which is not correct because this
> configuration is device
>> specific, not a USB-MIDI requirement.
>>
>> This patch adds two modules parameters, bmAttributes and MaxPower,
> that allows
>> the user to set those flags. The default values are what the gadget
> used to use
>> for backward compatibility.
>>
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/legacy/gmidi.c
> b/drivers/usb/gadget/legacy/gmidi.c
>> index fc2ac150f5ff..0553435cc360 100644
>> --- a/drivers/usb/gadget/legacy/gmidi.c
>> +++ b/drivers/usb/gadget/legacy/gmidi.c
>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>  module_param(out_ports, uint, S_IRUGO);
>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>  
>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>> +module_param(bmAttributes, uint, S_IRUGO);
>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
> bmAttributes parameter");
>> +
>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>> +module_param(MaxPower, uint, S_IRUGO);
>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
> Descriptor's bMaxPower parameter");
>
> you didn't run checkpatch, did you ? Also, are you sure you will need
> to
> change this by simply reloading the module ? I'm not convinced.

 Yes I always run checkpatch :)
>>>
>>> do you really ? Why do you have a 98-character line, then ?
>>>
 What do you mean by reloading the module?
>>>
>>> modprobe g_midi MaxPower=4
>>> modprobe -r g_midi
>>> modprobe g_midi MaxPower=10
>>>
>>> I'm not convinced this is a valid use-case. Specially since you can just
>>> provide several configurations and let the host choose the one it suits
>>> it best.
>>
>> Ok, I will further test it.
>>
>>>
>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>  .label  = "MIDI Gadget",
>>  .bConfigurationValue = 1,
>>  /* .iConfiguration = DYNAMIC */
>> -.bmAttributes   = USB_CONFIG_ATT_ONE,
>
> nack, nackety nack nack nack :-)
>
> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
> give users the oportunity to violate USB spec.

 You are right. It needs to check the value before it assigns to
 bmAttributes.
>>>
>>> why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
>>> case, I'm not convinced this is necessary at all.
>>
>> Right.
>>
>> 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 its
easy and simple to setup and use. So I think before we have some sort of
preset library of configfs-based gadget drivers, we still need these
modules.

Any suggestions on that?

Do you want to support what I am proposing for gmidi.ko or just ignore
it and move on to configfs?

Felipe


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Ferreri Tonello]

Hi Balbi, how are you?

On 07/03/16 10:59, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello  writes:
> "Felipe F. Tonello"  writes:
>> [ text/plain ]
>> This gadget uses a bmAttributes and MaxPower that requires the USB
> bus to be
>> powered from the host, which is not correct because this
> configuration is device
>> specific, not a USB-MIDI requirement.
>>
>> This patch adds two modules parameters, bmAttributes and MaxPower,
> that allows
>> the user to set those flags. The default values are what the gadget
> used to use
>> for backward compatibility.
>>
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/legacy/gmidi.c
> b/drivers/usb/gadget/legacy/gmidi.c
>> index fc2ac150f5ff..0553435cc360 100644
>> --- a/drivers/usb/gadget/legacy/gmidi.c
>> +++ b/drivers/usb/gadget/legacy/gmidi.c
>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>  module_param(out_ports, uint, S_IRUGO);
>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>  
>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>> +module_param(bmAttributes, uint, S_IRUGO);
>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
> bmAttributes parameter");
>> +
>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>> +module_param(MaxPower, uint, S_IRUGO);
>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
> Descriptor's bMaxPower parameter");
>
> you didn't run checkpatch, did you ? Also, are you sure you will need
> to
> change this by simply reloading the module ? I'm not convinced.

 Yes I always run checkpatch :)
>>>
>>> do you really ? Why do you have a 98-character line, then ?
>>>
 What do you mean by reloading the module?
>>>
>>> modprobe g_midi MaxPower=4
>>> modprobe -r g_midi
>>> modprobe g_midi MaxPower=10
>>>
>>> I'm not convinced this is a valid use-case. Specially since you can just
>>> provide several configurations and let the host choose the one it suits
>>> it best.
>>
>> Ok, I will further test it.
>>
>>>
>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>  .label  = "MIDI Gadget",
>>  .bConfigurationValue = 1,
>>  /* .iConfiguration = DYNAMIC */
>> -.bmAttributes   = USB_CONFIG_ATT_ONE,
>
> nack, nackety nack nack nack :-)
>
> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
> give users the oportunity to violate USB spec.

 You are right. It needs to check the value before it assigns to
 bmAttributes.
>>>
>>> why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
>>> case, I'm not convinced this is necessary at all.
>>
>> Right.
>>
>> 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 its
easy and simple to setup and use. So I think before we have some sort of
preset library of configfs-based gadget drivers, we still need these
modules.

Any suggestions on that?

Do you want to support what I am proposing for gmidi.ko or just ignore
it and move on to configfs?

Felipe


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
 "Felipe F. Tonello"  writes:
> [ text/plain ]
> This gadget uses a bmAttributes and MaxPower that requires the USB
 bus to be
> powered from the host, which is not correct because this
 configuration is device
> specific, not a USB-MIDI requirement.
>
> This patch adds two modules parameters, bmAttributes and MaxPower,
 that allows
> the user to set those flags. The default values are what the gadget
 used to use
> for backward compatibility.
>
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/legacy/gmidi.c
 b/drivers/usb/gadget/legacy/gmidi.c
> index fc2ac150f5ff..0553435cc360 100644
> --- a/drivers/usb/gadget/legacy/gmidi.c
> +++ b/drivers/usb/gadget/legacy/gmidi.c
> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>  module_param(out_ports, uint, S_IRUGO);
>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>  
> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
> +module_param(bmAttributes, uint, S_IRUGO);
> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
 bmAttributes parameter");
> +
> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
> +module_param(MaxPower, uint, S_IRUGO);
> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
 Descriptor's bMaxPower parameter");

 you didn't run checkpatch, did you ? Also, are you sure you will need
 to
 change this by simply reloading the module ? I'm not convinced.
>>>
>>> Yes I always run checkpatch :)
>> 
>> do you really ? Why do you have a 98-character line, then ?
>> 
>>> What do you mean by reloading the module?
>> 
>> modprobe g_midi MaxPower=4
>> modprobe -r g_midi
>> modprobe g_midi MaxPower=10
>> 
>> I'm not convinced this is a valid use-case. Specially since you can just
>> provide several configurations and let the host choose the one it suits
>> it best.
>
> Ok, I will further test it.
>
>> 
> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>   .label  = "MIDI Gadget",
>   .bConfigurationValue = 1,
>   /* .iConfiguration = DYNAMIC */
> - .bmAttributes   = USB_CONFIG_ATT_ONE,

 nack, nackety nack nack nack :-)

 USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
 give users the oportunity to violate USB spec.
>>>
>>> You are right. It needs to check the value before it assigns to
>>> bmAttributes.
>> 
>> why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
>> case, I'm not convinced this is necessary at all.
>
> Right.
>
> 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.

cheers

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
 "Felipe F. Tonello"  writes:
> [ text/plain ]
> This gadget uses a bmAttributes and MaxPower that requires the USB
 bus to be
> powered from the host, which is not correct because this
 configuration is device
> specific, not a USB-MIDI requirement.
>
> This patch adds two modules parameters, bmAttributes and MaxPower,
 that allows
> the user to set those flags. The default values are what the gadget
 used to use
> for backward compatibility.
>
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/legacy/gmidi.c
 b/drivers/usb/gadget/legacy/gmidi.c
> index fc2ac150f5ff..0553435cc360 100644
> --- a/drivers/usb/gadget/legacy/gmidi.c
> +++ b/drivers/usb/gadget/legacy/gmidi.c
> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>  module_param(out_ports, uint, S_IRUGO);
>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>  
> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
> +module_param(bmAttributes, uint, S_IRUGO);
> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
 bmAttributes parameter");
> +
> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
> +module_param(MaxPower, uint, S_IRUGO);
> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
 Descriptor's bMaxPower parameter");

 you didn't run checkpatch, did you ? Also, are you sure you will need
 to
 change this by simply reloading the module ? I'm not convinced.
>>>
>>> Yes I always run checkpatch :)
>> 
>> do you really ? Why do you have a 98-character line, then ?
>> 
>>> What do you mean by reloading the module?
>> 
>> modprobe g_midi MaxPower=4
>> modprobe -r g_midi
>> modprobe g_midi MaxPower=10
>> 
>> I'm not convinced this is a valid use-case. Specially since you can just
>> provide several configurations and let the host choose the one it suits
>> it best.
>
> Ok, I will further test it.
>
>> 
> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>   .label  = "MIDI Gadget",
>   .bConfigurationValue = 1,
>   /* .iConfiguration = DYNAMIC */
> - .bmAttributes   = USB_CONFIG_ATT_ONE,

 nack, nackety nack nack nack :-)

 USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
 give users the oportunity to violate USB spec.
>>>
>>> You are right. It needs to check the value before it assigns to
>>> bmAttributes.
>> 
>> why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
>> case, I'm not convinced this is necessary at all.
>
> Right.
>
> 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.

cheers

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Ferreri Tonello]

Hi Balbi,

On 07/03/16 07:34, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello  writes:
>> [ text/plain ]
>> Hi Balbi, 
>>
>> On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi  wrote:
>>>
>>> Hi,
>>>
>>> "Felipe F. Tonello"  writes:
 [ text/plain ]
 This gadget uses a bmAttributes and MaxPower that requires the USB
>>> bus to be
 powered from the host, which is not correct because this
>>> configuration is device
 specific, not a USB-MIDI requirement.

 This patch adds two modules parameters, bmAttributes and MaxPower,
>>> that allows
 the user to set those flags. The default values are what the gadget
>>> used to use
 for backward compatibility.

 Signed-off-by: Felipe F. Tonello 
 ---
  drivers/usb/gadget/legacy/gmidi.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

 diff --git a/drivers/usb/gadget/legacy/gmidi.c
>>> b/drivers/usb/gadget/legacy/gmidi.c
 index fc2ac150f5ff..0553435cc360 100644
 --- a/drivers/usb/gadget/legacy/gmidi.c
 +++ b/drivers/usb/gadget/legacy/gmidi.c
 @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
  module_param(out_ports, uint, S_IRUGO);
  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
  
 +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
 +module_param(bmAttributes, uint, S_IRUGO);
 +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>>> bmAttributes parameter");
 +
 +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
 +module_param(MaxPower, uint, S_IRUGO);
 +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>>> Descriptor's bMaxPower parameter");
>>>
>>> you didn't run checkpatch, did you ? Also, are you sure you will need
>>> to
>>> change this by simply reloading the module ? I'm not convinced.
>>
>> Yes I always run checkpatch :)
> 
> do you really ? Why do you have a 98-character line, then ?
> 
>> What do you mean by reloading the module?
> 
> modprobe g_midi MaxPower=4
> modprobe -r g_midi
> modprobe g_midi MaxPower=10
> 
> I'm not convinced this is a valid use-case. Specially since you can just
> provide several configurations and let the host choose the one it suits
> it best.

Ok, I will further test it.

> 
 @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
.label  = "MIDI Gadget",
.bConfigurationValue = 1,
/* .iConfiguration = DYNAMIC */
 -  .bmAttributes   = USB_CONFIG_ATT_ONE,
>>>
>>> nack, nackety nack nack nack :-)
>>>
>>> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>>> give users the oportunity to violate USB spec.
>>
>> You are right. It needs to check the value before it assigns to
>> bmAttributes.
> 
> why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
> case, I'm not convinced this is necessary at all.

Right.

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.

Felipe


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Ferreri Tonello]

Hi Balbi,

On 07/03/16 07:34, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello  writes:
>> [ text/plain ]
>> Hi Balbi, 
>>
>> On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi  wrote:
>>>
>>> Hi,
>>>
>>> "Felipe F. Tonello"  writes:
 [ text/plain ]
 This gadget uses a bmAttributes and MaxPower that requires the USB
>>> bus to be
 powered from the host, which is not correct because this
>>> configuration is device
 specific, not a USB-MIDI requirement.

 This patch adds two modules parameters, bmAttributes and MaxPower,
>>> that allows
 the user to set those flags. The default values are what the gadget
>>> used to use
 for backward compatibility.

 Signed-off-by: Felipe F. Tonello 
 ---
  drivers/usb/gadget/legacy/gmidi.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

 diff --git a/drivers/usb/gadget/legacy/gmidi.c
>>> b/drivers/usb/gadget/legacy/gmidi.c
 index fc2ac150f5ff..0553435cc360 100644
 --- a/drivers/usb/gadget/legacy/gmidi.c
 +++ b/drivers/usb/gadget/legacy/gmidi.c
 @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
  module_param(out_ports, uint, S_IRUGO);
  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
  
 +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
 +module_param(bmAttributes, uint, S_IRUGO);
 +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>>> bmAttributes parameter");
 +
 +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
 +module_param(MaxPower, uint, S_IRUGO);
 +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>>> Descriptor's bMaxPower parameter");
>>>
>>> you didn't run checkpatch, did you ? Also, are you sure you will need
>>> to
>>> change this by simply reloading the module ? I'm not convinced.
>>
>> Yes I always run checkpatch :)
> 
> do you really ? Why do you have a 98-character line, then ?
> 
>> What do you mean by reloading the module?
> 
> modprobe g_midi MaxPower=4
> modprobe -r g_midi
> modprobe g_midi MaxPower=10
> 
> I'm not convinced this is a valid use-case. Specially since you can just
> provide several configurations and let the host choose the one it suits
> it best.

Ok, I will further test it.

> 
 @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
.label  = "MIDI Gadget",
.bConfigurationValue = 1,
/* .iConfiguration = DYNAMIC */
 -  .bmAttributes   = USB_CONFIG_ATT_ONE,
>>>
>>> nack, nackety nack nack nack :-)
>>>
>>> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>>> give users the oportunity to violate USB spec.
>>
>> You are right. It needs to check the value before it assigns to
>> bmAttributes.
> 
> why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
> case, I'm not convinced this is necessary at all.

Right.

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.

Felipe


0x92698E6A.asc
Description: application/pgp-keys

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
> [ text/plain ]
> Hi Balbi, 
>
> On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi  wrote:
>>
>>Hi,
>>
>>"Felipe F. Tonello"  writes:
>>> [ text/plain ]
>>> This gadget uses a bmAttributes and MaxPower that requires the USB
>>bus to be
>>> powered from the host, which is not correct because this
>>configuration is device
>>> specific, not a USB-MIDI requirement.
>>>
>>> This patch adds two modules parameters, bmAttributes and MaxPower,
>>that allows
>>> the user to set those flags. The default values are what the gadget
>>used to use
>>> for backward compatibility.
>>>
>>> Signed-off-by: Felipe F. Tonello 
>>> ---
>>>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/gadget/legacy/gmidi.c
>>b/drivers/usb/gadget/legacy/gmidi.c
>>> index fc2ac150f5ff..0553435cc360 100644
>>> --- a/drivers/usb/gadget/legacy/gmidi.c
>>> +++ b/drivers/usb/gadget/legacy/gmidi.c
>>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>>  module_param(out_ports, uint, S_IRUGO);
>>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>>  
>>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>>> +module_param(bmAttributes, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>>bmAttributes parameter");
>>> +
>>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>>> +module_param(MaxPower, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>>Descriptor's bMaxPower parameter");
>>
>>you didn't run checkpatch, did you ? Also, are you sure you will need
>>to
>>change this by simply reloading the module ? I'm not convinced.
>
> Yes I always run checkpatch :)

do you really ? Why do you have a 98-character line, then ?

> What do you mean by reloading the module?

modprobe g_midi MaxPower=4
modprobe -r g_midi
modprobe g_midi MaxPower=10

I'm not convinced this is a valid use-case. Specially since you can just
provide several configurations and let the host choose the one it suits
it best.

>>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>> .label  = "MIDI Gadget",
>>> .bConfigurationValue = 1,
>>> /* .iConfiguration = DYNAMIC */
>>> -   .bmAttributes   = USB_CONFIG_ATT_ONE,
>>
>>nack, nackety nack nack nack :-)
>>
>>USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>>give users the oportunity to violate USB spec.
>
> You are right. It needs to check the value before it assigns to
> bmAttributes.

why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
case, I'm not convinced this is necessary at all.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
> [ text/plain ]
> Hi Balbi, 
>
> On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi  wrote:
>>
>>Hi,
>>
>>"Felipe F. Tonello"  writes:
>>> [ text/plain ]
>>> This gadget uses a bmAttributes and MaxPower that requires the USB
>>bus to be
>>> powered from the host, which is not correct because this
>>configuration is device
>>> specific, not a USB-MIDI requirement.
>>>
>>> This patch adds two modules parameters, bmAttributes and MaxPower,
>>that allows
>>> the user to set those flags. The default values are what the gadget
>>used to use
>>> for backward compatibility.
>>>
>>> Signed-off-by: Felipe F. Tonello 
>>> ---
>>>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/gadget/legacy/gmidi.c
>>b/drivers/usb/gadget/legacy/gmidi.c
>>> index fc2ac150f5ff..0553435cc360 100644
>>> --- a/drivers/usb/gadget/legacy/gmidi.c
>>> +++ b/drivers/usb/gadget/legacy/gmidi.c
>>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>>  module_param(out_ports, uint, S_IRUGO);
>>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>>  
>>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>>> +module_param(bmAttributes, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>>bmAttributes parameter");
>>> +
>>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>>> +module_param(MaxPower, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>>Descriptor's bMaxPower parameter");
>>
>>you didn't run checkpatch, did you ? Also, are you sure you will need
>>to
>>change this by simply reloading the module ? I'm not convinced.
>
> Yes I always run checkpatch :)

do you really ? Why do you have a 98-character line, then ?

> What do you mean by reloading the module?

modprobe g_midi MaxPower=4
modprobe -r g_midi
modprobe g_midi MaxPower=10

I'm not convinced this is a valid use-case. Specially since you can just
provide several configurations and let the host choose the one it suits
it best.

>>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>> .label  = "MIDI Gadget",
>>> .bConfigurationValue = 1,
>>> /* .iConfiguration = DYNAMIC */
>>> -   .bmAttributes   = USB_CONFIG_ATT_ONE,
>>
>>nack, nackety nack nack nack :-)
>>
>>USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>>give users the oportunity to violate USB spec.
>
> You are right. It needs to check the value before it assigns to
> bmAttributes.

why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
case, I'm not convinced this is necessary at all.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Ferreri Tonello]

Hi Balbi, 

On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi  wrote:
>
>Hi,
>
>"Felipe F. Tonello"  writes:
>> [ text/plain ]
>> This gadget uses a bmAttributes and MaxPower that requires the USB
>bus to be
>> powered from the host, which is not correct because this
>configuration is device
>> specific, not a USB-MIDI requirement.
>>
>> This patch adds two modules parameters, bmAttributes and MaxPower,
>that allows
>> the user to set those flags. The default values are what the gadget
>used to use
>> for backward compatibility.
>>
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/legacy/gmidi.c
>b/drivers/usb/gadget/legacy/gmidi.c
>> index fc2ac150f5ff..0553435cc360 100644
>> --- a/drivers/usb/gadget/legacy/gmidi.c
>> +++ b/drivers/usb/gadget/legacy/gmidi.c
>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>  module_param(out_ports, uint, S_IRUGO);
>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>  
>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>> +module_param(bmAttributes, uint, S_IRUGO);
>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>bmAttributes parameter");
>> +
>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>> +module_param(MaxPower, uint, S_IRUGO);
>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>Descriptor's bMaxPower parameter");
>
>you didn't run checkpatch, did you ? Also, are you sure you will need
>to
>change this by simply reloading the module ? I'm not convinced.

Yes I always run checkpatch :) 

What do you mean by reloading the module? 

>
>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>  .label  = "MIDI Gadget",
>>  .bConfigurationValue = 1,
>>  /* .iConfiguration = DYNAMIC */
>> -.bmAttributes   = USB_CONFIG_ATT_ONE,
>
>nack, nackety nack nack nack :-)
>
>USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>give users the oportunity to violate USB spec.

You are right. It needs to check the value before it assigns to bmAttributes. 

Felipe 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Felipe Ferreri Tonello]

Hi Balbi, 

On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi  wrote:
>
>Hi,
>
>"Felipe F. Tonello"  writes:
>> [ text/plain ]
>> This gadget uses a bmAttributes and MaxPower that requires the USB
>bus to be
>> powered from the host, which is not correct because this
>configuration is device
>> specific, not a USB-MIDI requirement.
>>
>> This patch adds two modules parameters, bmAttributes and MaxPower,
>that allows
>> the user to set those flags. The default values are what the gadget
>used to use
>> for backward compatibility.
>>
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/legacy/gmidi.c
>b/drivers/usb/gadget/legacy/gmidi.c
>> index fc2ac150f5ff..0553435cc360 100644
>> --- a/drivers/usb/gadget/legacy/gmidi.c
>> +++ b/drivers/usb/gadget/legacy/gmidi.c
>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>  module_param(out_ports, uint, S_IRUGO);
>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>  
>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>> +module_param(bmAttributes, uint, S_IRUGO);
>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>bmAttributes parameter");
>> +
>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>> +module_param(MaxPower, uint, S_IRUGO);
>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>Descriptor's bMaxPower parameter");
>
>you didn't run checkpatch, did you ? Also, are you sure you will need
>to
>change this by simply reloading the module ? I'm not convinced.

Yes I always run checkpatch :) 

What do you mean by reloading the module? 

>
>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>  .label  = "MIDI Gadget",
>>  .bConfigurationValue = 1,
>>  /* .iConfiguration = DYNAMIC */
>> -.bmAttributes   = USB_CONFIG_ATT_ONE,
>
>nack, nackety nack nack nack :-)
>
>USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>give users the oportunity to violate USB spec.

You are right. It needs to check the value before it assigns to bmAttributes. 

Felipe 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Felipe Balbi]

Hi,

"Felipe F. Tonello"  writes:
> [ text/plain ]
> This gadget uses a bmAttributes and MaxPower that requires the USB bus to be
> powered from the host, which is not correct because this configuration is 
> device
> specific, not a USB-MIDI requirement.
>
> This patch adds two modules parameters, bmAttributes and MaxPower, that allows
> the user to set those flags. The default values are what the gadget used to 
> use
> for backward compatibility.
>
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/legacy/gmidi.c 
> b/drivers/usb/gadget/legacy/gmidi.c
> index fc2ac150f5ff..0553435cc360 100644
> --- a/drivers/usb/gadget/legacy/gmidi.c
> +++ b/drivers/usb/gadget/legacy/gmidi.c
> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>  module_param(out_ports, uint, S_IRUGO);
>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>  
> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
> +module_param(bmAttributes, uint, S_IRUGO);
> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's bmAttributes 
> parameter");
> +
> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
> +module_param(MaxPower, uint, S_IRUGO);
> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration Descriptor's 
> bMaxPower parameter");

you didn't run checkpatch, did you ? Also, are you sure you will need to
change this by simply reloading the module ? I'm not convinced.

> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>   .label  = "MIDI Gadget",
>   .bConfigurationValue = 1,
>   /* .iConfiguration = DYNAMIC */
> - .bmAttributes   = USB_CONFIG_ATT_ONE,

nack, nackety nack nack nack :-)

USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
give users the oportunity to violate USB spec.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

"Felipe F. Tonello"  writes:
> [ text/plain ]
> This gadget uses a bmAttributes and MaxPower that requires the USB bus to be
> powered from the host, which is not correct because this configuration is 
> device
> specific, not a USB-MIDI requirement.
>
> This patch adds two modules parameters, bmAttributes and MaxPower, that allows
> the user to set those flags. The default values are what the gadget used to 
> use
> for backward compatibility.
>
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/legacy/gmidi.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/legacy/gmidi.c 
> b/drivers/usb/gadget/legacy/gmidi.c
> index fc2ac150f5ff..0553435cc360 100644
> --- a/drivers/usb/gadget/legacy/gmidi.c
> +++ b/drivers/usb/gadget/legacy/gmidi.c
> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>  module_param(out_ports, uint, S_IRUGO);
>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>  
> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
> +module_param(bmAttributes, uint, S_IRUGO);
> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's bmAttributes 
> parameter");
> +
> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
> +module_param(MaxPower, uint, S_IRUGO);
> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration Descriptor's 
> bMaxPower parameter");

you didn't run checkpatch, did you ? Also, are you sure you will need to
change this by simply reloading the module ? I'm not convinced.

> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>   .label  = "MIDI Gadget",
>   .bConfigurationValue = 1,
>   /* .iConfiguration = DYNAMIC */
> - .bmAttributes   = USB_CONFIG_ATT_ONE,

nack, nackety nack nack nack :-)

USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
give users the oportunity to violate USB spec.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe F. Tonello]

This gadget uses a bmAttributes and MaxPower that requires the USB bus to be
powered from the host, which is not correct because this configuration is device
specific, not a USB-MIDI requirement.

This patch adds two modules parameters, bmAttributes and MaxPower, that allows
the user to set those flags. The default values are what the gadget used to use
for backward compatibility.

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/legacy/gmidi.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/legacy/gmidi.c 
b/drivers/usb/gadget/legacy/gmidi.c
index fc2ac150f5ff..0553435cc360 100644
--- a/drivers/usb/gadget/legacy/gmidi.c
+++ b/drivers/usb/gadget/legacy/gmidi.c
@@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
 module_param(out_ports, uint, S_IRUGO);
 MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
 
+static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
+module_param(bmAttributes, uint, S_IRUGO);
+MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's bmAttributes 
parameter");
+
+static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
+module_param(MaxPower, uint, S_IRUGO);
+MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration Descriptor's 
bMaxPower parameter");
+
 /* Thanks to Grey Innovation for donating this product ID.
  *
  * DO NOT REUSE THESE IDs with a protocol-incompatible driver!!  Ever!!
@@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
.label  = "MIDI Gadget",
.bConfigurationValue = 1,
/* .iConfiguration = DYNAMIC */
-   .bmAttributes   = USB_CONFIG_ATT_ONE,
-   .MaxPower   = CONFIG_USB_GADGET_VBUS_DRAW,
+   /* .bmAttributes= DYNAMIC */
+   /* .MaxPower= DYNAMIC */
 };
 
 static int midi_bind_config(struct usb_configuration *c)
@@ -163,6 +171,8 @@ static int midi_bind(struct usb_composite_dev *cdev)
device_desc.iManufacturer = strings_dev[USB_GADGET_MANUFACTURER_IDX].id;
device_desc.iProduct = strings_dev[USB_GADGET_PRODUCT_IDX].id;
midi_config.iConfiguration = strings_dev[STRING_DESCRIPTION_IDX].id;
+   midi_config.bmAttributes = bmAttributes;
+   midi_config.MaxPower = MaxPower;
 
status = usb_add_config(cdev, _config, midi_bind_config);
if (status < 0)
-- 
2.7.2

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

[Felipe F. Tonello]

This gadget uses a bmAttributes and MaxPower that requires the USB bus to be
powered from the host, which is not correct because this configuration is device
specific, not a USB-MIDI requirement.

This patch adds two modules parameters, bmAttributes and MaxPower, that allows
the user to set those flags. The default values are what the gadget used to use
for backward compatibility.

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/legacy/gmidi.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/legacy/gmidi.c 
b/drivers/usb/gadget/legacy/gmidi.c
index fc2ac150f5ff..0553435cc360 100644
--- a/drivers/usb/gadget/legacy/gmidi.c
+++ b/drivers/usb/gadget/legacy/gmidi.c
@@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
 module_param(out_ports, uint, S_IRUGO);
 MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
 
+static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
+module_param(bmAttributes, uint, S_IRUGO);
+MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's bmAttributes 
parameter");
+
+static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
+module_param(MaxPower, uint, S_IRUGO);
+MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration Descriptor's 
bMaxPower parameter");
+
 /* Thanks to Grey Innovation for donating this product ID.
  *
  * DO NOT REUSE THESE IDs with a protocol-incompatible driver!!  Ever!!
@@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
.label  = "MIDI Gadget",
.bConfigurationValue = 1,
/* .iConfiguration = DYNAMIC */
-   .bmAttributes   = USB_CONFIG_ATT_ONE,
-   .MaxPower   = CONFIG_USB_GADGET_VBUS_DRAW,
+   /* .bmAttributes= DYNAMIC */
+   /* .MaxPower= DYNAMIC */
 };
 
 static int midi_bind_config(struct usb_configuration *c)
@@ -163,6 +171,8 @@ static int midi_bind(struct usb_composite_dev *cdev)
device_desc.iManufacturer = strings_dev[USB_GADGET_MANUFACTURER_IDX].id;
device_desc.iProduct = strings_dev[USB_GADGET_PRODUCT_IDX].id;
midi_config.iConfiguration = strings_dev[STRING_DESCRIPTION_IDX].id;
+   midi_config.bmAttributes = bmAttributes;
+   midi_config.MaxPower = MaxPower;
 
status = usb_add_config(cdev, _config, midi_bind_config);
if (status < 0)
-- 
2.7.2