public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Felipe Ferreri Tonello <eu@felipetonello.com>, linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	Michal Nazarewicz <mina86@mina86.com>,
	Clemens Ladisch <clemens@ladisch.de>
Subject: Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes
Date: Tue, 08 Mar 2016 09:43:17 +0200	[thread overview]
Message-ID: <87h9ghife2.fsf@intel.com> (raw)
In-Reply-To: <56DD6241.2000308@felipetonello.com>

[-- Attachment #1: Type: text/plain, Size: 3981 bytes --]


Hi,

Felipe Ferreri Tonello <eu@felipetonello.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

  reply	other threads:[~2016-03-08  7:44 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02 19:40 [PATCH 0/5] MIDI USB Gadget improvements Felipe F. Tonello
2016-03-02 19:40 ` [PATCH 1/5] usb: gadget: f_midi: refactor state machine Felipe F. Tonello
2016-03-02 21:09   ` Clemens Ladisch
2016-03-03  8:57     ` Felipe Ferreri Tonello
2016-03-03 11:38       ` Clemens Ladisch
2016-03-03 16:30         ` Felipe Ferreri Tonello
2016-03-04  8:07           ` Clemens Ladisch
2016-03-04 18:39             ` Felipe Ferreri Tonello
2016-03-04 18:43               ` Clemens Ladisch
2016-03-02 19:40 ` [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function Felipe F. Tonello
2016-03-04  7:20   ` Felipe Balbi
2016-03-04 18:49     ` Felipe Ferreri Tonello
2016-03-07  7:32       ` Felipe Balbi
2016-03-07  9:28         ` Felipe Ferreri Tonello
2016-03-08  7:37           ` Felipe Balbi
2016-03-08 13:46             ` Felipe Ferreri Tonello
2016-03-08 14:01               ` Felipe Balbi
2016-03-08 15:40                 ` Felipe Ferreri Tonello
2016-03-09  7:22                   ` Felipe Balbi
2016-03-02 19:40 ` [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes Felipe F. Tonello
2016-03-04  7:16   ` Felipe Balbi
2016-03-04 18:46     ` Felipe Ferreri Tonello
2016-03-07  7:34       ` Felipe Balbi
2016-03-07  9:40         ` Felipe Ferreri Tonello
2016-03-07 10:59           ` Felipe Balbi
2016-03-07 11:13             ` Felipe Ferreri Tonello
2016-03-08  7:43               ` Felipe Balbi [this message]
2016-03-08 10:14                 ` Krzysztof Opasiak
2016-03-08 10:34                   ` Felipe Balbi
2016-03-08 13:54                 ` Felipe Ferreri Tonello
2016-03-08 14:04                   ` Felipe Balbi
2016-03-08 14:15                   ` Krzysztof Opasiak
2016-03-08 14:20                     ` Felipe Balbi
2016-03-08 15:24                       ` Felipe Ferreri Tonello
2016-03-02 19:40 ` [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes Felipe F. Tonello
2016-03-04  7:13   ` Felipe Balbi
2016-03-04 19:17   ` Michal Nazarewicz
2016-03-04 20:17     ` Felipe Ferreri Tonello
2016-03-05 16:28       ` Michal Nazarewicz
2016-03-05 19:39         ` Greg KH
2016-03-05 23:53           ` Felipe Ferreri Tonello
2016-03-06  3:02             ` Greg KH
2016-03-05 23:57         ` Felipe Ferreri Tonello
2016-03-07  7:35           ` Felipe Balbi
2016-03-07  9:32             ` Felipe Ferreri Tonello
2016-03-08  7:44               ` Felipe Balbi
2016-03-02 19:40 ` [PATCH 5/5] usb: gadget: f_midi: updated copyright Felipe F. Tonello
2016-03-04  7:13   ` Felipe Balbi
2016-03-04 18:41     ` Felipe Ferreri Tonello
2016-03-07  7:36       ` Felipe Balbi
2016-03-07  9:23         ` Felipe Ferreri Tonello
2016-03-04  7:11 ` [PATCH 0/5] MIDI USB Gadget improvements Felipe Balbi
2016-03-04 18:43   ` Felipe Ferreri Tonello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h9ghife2.fsf@intel.com \
    --to=balbi@kernel.org \
    --cc=clemens@ladisch.de \
    --cc=eu@felipetonello.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mina86@mina86.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox