Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752592AbcCGLAH (ORCPT ); Mon, 7 Mar 2016 06:00:07 -0500 Received: from mga04.intel.com ([192.55.52.120]:64662 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752474AbcCGK74 (ORCPT ); Mon, 7 Mar 2016 05:59:56 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,550,1449561600"; d="asc'?scan'208";a="931256958" From: Felipe Balbi To: Felipe Ferreri Tonello , linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Michal Nazarewicz , Clemens Ladisch Subject: Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes In-Reply-To: <56DD4C84.1090506@felipetonello.com> 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> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.0.90.3 (x86_64-pc-linux-gnu) Date: Mon, 07 Mar 2016 12:59:07 +0200 Message-ID: <87ziuaimf8.fsf@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4816 Lines: 132 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 =3D 1; >>>>> module_param(out_ports, uint, S_IRUGO); >>>>> MODULE_PARM_DESC(out_ports, "Number of MIDI output ports"); >>>>>=20=20 >>>>> +static unsigned int bmAttributes =3D USB_CONFIG_ATT_ONE; >>>>> +module_param(bmAttributes, uint, S_IRUGO); >>>>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's >>>> bmAttributes parameter"); >>>>> + >>>>> +static unsigned int MaxPower =3D 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 :) >>=20 >> do you really ? Why do you have a 98-character line, then ? >>=20 >>> What do you mean by reloading the module? >>=20 >> modprobe g_midi MaxPower=3D4 >> modprobe -r g_midi >> modprobe g_midi MaxPower=3D10 >>=20 >> 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. > >>=20 >>>>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config =3D { >>>>> .label =3D "MIDI Gadget", >>>>> .bConfigurationValue =3D 1, >>>>> /* .iConfiguration =3D DYNAMIC */ >>>>> - .bmAttributes =3D 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. >>=20 >> 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 =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW3V78AAoJEIaOsuA1yqREKeQP/29WBL3UeA1EVMOPmmwNId+d ZklOvjRzPBNE2Vu3Hn7HtrDniJyjntR9vH4Xv1nMeHLPkj4F/jX4pKwk3c42xvg1 vCIv+zbru9YnEXm2IDqlq2YEj0IAmdVHKKgvzX33YJa8CehinprCnyFDVciapRet yRxjtt4LRetwd8wFiVgZgwENwec1K2/d8SIogK0wrI333F8eXE2sSj0HddihCVP6 gkwsNkEvYpzSCO6zc08PMGGHMFxQerHkHwLyhET2TyZWQdJopawGuVuVfJBnBHs/ eFBmdY2kJgZI6SsTMEUmv2XZXN0u6nQsCEUJ7UqyYybs1eXZA55oJ7jOPvGsHnkZ 1RLJdS7NSOpvuWP59OXiDN+RXTPwF3PEgvkjxyvPBnS7mr+pEm5wVYQhDllq1BWQ 90KVTUzXpAy38GizMj1OkX3gNr6BbKBWwZRqUcctyjtw4tIEw/VdZOtrmqgCcfQR by8tOE9w73xPYb+o/Ccgx2vfWLxf36BfgF8htkEbIWTTMT9PFNXBIMOGAz+1H3B3 dc87KgSsA9Qa7hYjiNobdMF5aafdHES0VdUXOVzGrWTSqLmv5tRBOTpeCjjc0FaK pTakhyyBcjaMhx8wws+OYDKwUDOkPKRlUlpeMNDoP5nqZZvch+OfUZ7Id13CM6+1 SBFc4lg2KkVy+0gDthMe =luUM -----END PGP SIGNATURE----- --=-=-=--