From: Peter Chen <peter.chen@freescale.com>
To: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Balbi, Felipe" <balbi@ti.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
<andrzej.p@samsung.com>, <r.baldyga@samsung.com>
Subject: Re: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
Date: Mon, 9 Feb 2015 16:46:19 +0800 [thread overview]
Message-ID: <20150209084615.GA22006@shlinux2> (raw)
In-Reply-To: <CAB=otbTTmKsfzQL1CQX0aGTWCqxtzuDxZuS_F7fnLJu6185Osg@mail.gmail.com>
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 <stern@rowland.harvard.edu> 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 <ruslan.bilovol@gmail.com>
> >> ---
> >> 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
next prev parent reply other threads:[~2015-02-09 10:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-29 1:25 [PATCH 0/2] usb/gadget: independent registration of gadgets and gadget Ruslan Bilovol
2015-01-29 1:25 ` [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers Ruslan Bilovol
2015-01-29 15:56 ` Alan Stern
2015-02-08 19:04 ` Ruslan Bilovol
2015-02-09 8:46 ` Peter Chen [this message]
2015-02-09 16:35 ` Alan Stern
2015-02-09 18:06 ` Krzysztof Opasiak
2015-02-09 18:17 ` Krzysztof Opasiak
2015-02-09 20:00 ` Alan Stern
2015-02-09 23:46 ` Ruslan Bilovol
2015-02-10 8:47 ` Krzysztof Opasiak
2015-02-15 22:43 ` Ruslan Bilovol
2015-02-16 8:07 ` Andrzej Pietrasiewicz
2015-02-17 21:02 ` Ruslan Bilovol
2015-02-18 7:21 ` Andrzej Pietrasiewicz
2015-02-15 22:40 ` Ruslan Bilovol
2015-01-29 1:25 ` [PATCH 2/2] usb: gadget: legacy: don't use __init/__exit attributes for bind/unbind path Ruslan Bilovol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150209084615.GA22006@shlinux2 \
--to=peter.chen@freescale.com \
--cc=andrzej.p@samsung.com \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=r.baldyga@samsung.com \
--cc=ruslan.bilovol@gmail.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.