Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760224AbbBIUAQ (ORCPT ); Mon, 9 Feb 2015 15:00:16 -0500 Received: from netrider.rowland.org ([192.131.102.5]:41892 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1755840AbbBIUAN (ORCPT ); Mon, 9 Feb 2015 15:00:13 -0500 Date: Mon, 9 Feb 2015 15:00:12 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Krzysztof Opasiak cc: "'Ruslan Bilovol'" , "'Peter Chen'" , , , "'Balbi, Felipe'" , , Andrzej Pietrasiewicz Subject: RE: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers In-Reply-To: <100e01d04493$11a2fd40$34e8f7c0$%opasiak@samsung.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2978 Lines: 75 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. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/