Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761043AbbBIQgC (ORCPT ); Mon, 9 Feb 2015 11:36:02 -0500 Received: from netrider.rowland.org ([192.131.102.5]:53849 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1760850AbbBIQgA (ORCPT ); Mon, 9 Feb 2015 11:36:00 -0500 Date: Mon, 9 Feb 2015 11:35:59 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Ruslan Bilovol , Peter Chen cc: "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Balbi, Felipe" , "gregkh@linuxfoundation.org" , Subject: Re: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers In-Reply-To: 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: 3349 Lines: 85 On Sun, 8 Feb 2015, Ruslan Bilovol wrote: > Hi Alan, > > On Thu, Jan 29, 2015 at 5:56 PM, Alan Stern wrote: > > On Thu, 29 Jan 2015, Ruslan Bilovol wrote: > > > >> Change behavior during registration of gadgets and > >> gadget drivers in udc-core. Instead of previous > >> approach when for successful probe of usb gadget driver > >> at least one usb gadget should be already registered > >> use another one where gadget drivers and gadgets > >> can be registered in udc-core independently. > >> > >> Independent registration of gadgets and gadget drivers > >> is useful for built-in into kernel gadget and gadget > >> driver case - because it's possible that gadget is > >> really probed only on late_init stage (due to deferred > >> probe) whereas gadget driver's probe is silently failed > >> on module_init stage due to no any UDC added. > >> > >> Also it is useful for modules case - now there is no > >> difference what module to insert first: gadget module > >> or gadget driver one. > > > > It's possible to do all this much more simply. In fact, I posted a > > patch some time ago to do exactly this (but I can't find a copy of it > > anywhere). > > Unfortunately I didn't find your patch. > > You don't need all this stuff. What's the point of keeping track of > > names? If there are any unbound gadget drivers pending, a newly > > registered UDC should bind to the first one available. > > It's because gadget driver may be bound to usb_gadget in two ways: > - standard way - in this case any available udc will be picked up > - by name of udc, in this case only matching udc will be picked up Where did this "by name" feature come from? You did not mention it in the patch description. Why bother matching by name? Why not simply take the first available UDC? > 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. On Mon, 9 Feb 2015, Peter Chen wrote: > In fact, both I and Robert Baldyga posted patches to try fix this > problem. > > http://marc.info/?l=linux-usb&m=139287784610046&w=2 > http://lwn.net/Articles/601839/ That's right. The patch I wrote was a lot like Robert's patch (the marc.info URL above). His approach can be simplified a little; the "attached" field isn't needed if the driver_list holds only unbound gadget drivers. > I tried to use Robert's solution (fix some bugs) in internal tree, but > the mass storage gadget still has problems to work if unload udc first. > The possible reason should be: it has two places to call > usb_composite_unregister. The mass-storage gadget driver can be fixed, if necessary. 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/