Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760096AbbBIKar (ORCPT ); Mon, 9 Feb 2015 05:30:47 -0500 Received: from mail-by2on0106.outbound.protection.outlook.com ([207.46.100.106]:51669 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759481AbbBIKap (ORCPT ); Mon, 9 Feb 2015 05:30:45 -0500 Date: Mon, 9 Feb 2015 16:46:19 +0800 From: Peter Chen To: Ruslan Bilovol CC: Alan Stern , "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 Message-ID: <20150209084615.GA22006@shlinux2> References: <1422494734-9499-2-git-send-email-ruslan.bilovol@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-EOPAttributedMessage: 0 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=peter.chen@freescale.com; samsung.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:192.88.168.50;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(209900001)(339900001)(11905935001)(51704005)(377454003)(24454002)(15975445007)(77096005)(50986999)(54356999)(85426001)(2950100001)(46102003)(97756001)(77156002)(62966003)(50466002)(76176999)(23726002)(86362001)(92566002)(105606002)(106466001)(33716001)(46406003)(47776003)(19580395003)(19580405001)(6806004)(15395725005)(104016003)(87936001)(110136001)(33656002)(6606295002);DIR:OUT;SFP:1102;SCL:1;SRVR:BL2PR03MB323;H:tx30smr01.am.freescale.net;FPR:;SPF:Fail;MLV:sfv;LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB323; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004);SRVR:BL2PR03MB323; X-Forefront-PRVS: 04825EA361 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB323; X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2015 09:57:44.5904 (UTC) X-MS-Exchange-CrossTenant-Id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=710a03f5-10f6-4d38-9ff4-a80b81da590d;Ip=[192.88.168.50] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB323 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4040 Lines: 95 On Sun, Feb 08, 2015 at 09:04:32PM +0200, 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. > > > > >> Signed-off-by: Ruslan Bilovol > >> --- > >> drivers/usb/gadget/udc/udc-core.c | 113 +++++++++++++++++++++++++++++++++++--- > >> 1 file changed, 105 insertions(+), 8 deletions(-) > >> > >> diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c > >> index e31d574..4c9412b 100644 > >> --- a/drivers/usb/gadget/udc/udc-core.c > >> +++ b/drivers/usb/gadget/udc/udc-core.c > >> @@ -43,13 +43,23 @@ struct usb_udc { > >> struct usb_gadget_driver *driver; > >> struct usb_gadget *gadget; > >> struct device dev; > >> + bool bind_by_name; > >> + struct list_head list; > >> +}; > >> + > >> +struct pending_gadget_driver { > >> + struct usb_gadget_driver *driver; > >> + char *udc_name; > >> struct list_head list; > >> }; > > > > 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 > > 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. > Another example is USB device controllers that consist of pair of > HS+SS controllers, each one having its own udc driver. In this case > it's possible to switch SS/HS by registering/unregistering corresponding > udc and not touching gadget driver. > > I did all of this inside of udc-core because it looks like to be best place for > udc <-> gadget driver housekeeping. Also it is verified on lot of combinations > of udc and gadget drivers that can be built-in or build as modules > 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/ 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. -- Best Regards, Peter Chen -- 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/