linux-kernel - Re: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

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]

Message-ID: <CAB=otbR1BFgq+sBeNhKkXYfSUMdH-m-ahTeMu0FFV1r8Z9Q6oQ@mail.gmail.com>
Date:	Mon, 16 Feb 2015 00:40:11 +0200
From:	Ruslan Bilovol <ruslan.bilovol@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Krzysztof Opasiak <k.opasiak@...sung.com>,
	Peter Chen <peter.chen@...escale.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Balbi, Felipe" <balbi@...com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	Andrzej Pietrasiewicz <andrzej.p@...sung.com>
Subject: Re: [PATCH 1/2] usb: gadget: udc-core: independent registration of
 gadgets and gadget drivers

Hi Alan,

On Mon, Feb 9, 2015 at 10:00 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> On Mon, 9 Feb 2015, Krzysztof Opasiak wrote:
>
>> > Why bother matching by name?  Why not simply take the first
>> > available
>> > UDC?
>>
>> Because you may have more than one udc. This would allow to pick one by
>> name just like using configfs interface.
>
> Clearly it would be more flexible to allow the user to do the matching,
> the way configfs does (sysfs too).
>
>> > > Main feature of my path is not only deferred binding of gadget
>> > driver,
>> > > but also possibility to register/unregister udc at any time.
>> > > This is useful for user who can load, for example, udc module
>> > > if needed and unload it safely, not touching gadget driver.
>> >
>> > We can already do that with the existing code.  There's no need for
>> > a
>> > patch.
>> >
>> > Also, it's not clear that the existing gadget drivers will work
>> > properly if they are unbound from one UDC and then bound again to
>> > another one.  They were not written with that sort of thing in
>> > mind.
>> >
>>
>> What you have described is one of basics configfs features.
>> You should be able to bind and unbind your gadget whenever you want
>> and it should work properly after doing:
>>
>> ## create gadget
>> $ echo "udc.0" > UDC
>> $ echo "" > UDC
>> $ echo "udc.1" > UDC
>>
>> Function shouldn't care which udc it has been bound previously.
>> Only current one is important and on each unbind each function
>> should cleanup its state and prepare to be bound to another udc.
>> Configfs interface doesn't prohibit this and I haven't seen any
>> info about such restriction.
>
> It's not prohibited, but it also was never required.  Therefore it may
> not be implemented in all gadget drivers.
>
>>  If some function is not working in
>> such situation there is a bug in that function and it should be fixed.
>
> That's fine.  I wasn't pointing out a fundamental limitation, just a
> fact that will have to be taken into account.
>
> Anyway, instead of going through all this, why not do what I suggested
> earlier (see http://marc.info/?l=linux-usb&m=139888691230119&w=2) and
> create a "gadget" bus type?  That would give userspace explicit control
> over which gadget driver was bound to which UDC.
>
> Or maybe that's not a very good fit with the existing code, since most
> gadget drivers assume they will be bound to only one UDC at a time.  So
> instead, why not create a sysfs interface that allows userspace to
> control which gadget drivers are bound to which UDCs?
>
> As I recall, the original problem people were complaining about was
> deferred probing.  They didn't need fancy matching; all they wanted was
> the ability to bind a gadget driver to a UDC some time after the gadget
> driver was loaded and initialized.  Something simple like Robert
> Baldyga's patch is enough to do that.

I looked over my patch and see that it doesn't automatically rebind
gadget driver to another available UDC after previous UDC is unbound.
The Gadget Bus mentioned previously is good thing but so far it seems there
is no users of such approach. So I left only deferred registration
from my patch.
I still keep it inside of udc-core since we also need to keep tracking UDC name
if somebody wanted to bind gadget driver to specific UDC and it looks
like good place to maintain this. I'll send second version of patches soon

-- 
Best regards,
Ruslan Bilvol
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/