From: peter.chen@freescale.com (Peter Chen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 14/14] usb: udc-core: add judgement logic for usb_gadget_connect
Date: Fri, 15 Mar 2013 20:26:59 +0800 [thread overview]
Message-ID: <20130315122658.GB32470@nchen-desktop> (raw)
In-Reply-To: <20130315103701.GA21445@arwen.pp.htv.fi>
On Fri, Mar 15, 2013 at 12:37:01PM +0200, Felipe Balbi wrote:
> > */
> > static inline int usb_gadget_disconnect(struct usb_gadget *gadget)
> > {
> > + int ret = 0;
> > +
> > if (!gadget->ops->pullup)
> > return -EOPNOTSUPP;
> > - return gadget->ops->pullup(gadget, 0);
> > +
> > + if (gadget->connection == 1)
> > + ret = gadget->ops->pullup(gadget, 0);
> > +
> > + if (!ret)
> > + gadget->connection --;
> > +
> > + return ret;
> > }
>
> this might be a good idea. But we already have something similar,
> although it's managed at composite device level.
Yes, I know, it should only be managed at one place at last.
> Maybe we need to move
> that to the gadget layer. Still, I don't want to let UDC drivers call
> usb_gadget_connect()/disconnect() directly.
>
> It's easy enough for udc-core to handle that.
Below are all cases I can think about pullup_dp
1. No vbus interrupt support udc driver, manage pullup at load/unload
gadget module.
2. For vbus interrupt supported udc driver, manage pullup at vbus interrupt
3. For gadget module, like uvc, it will call pullup_dp through its app.
Are there any cases? We need to design one solution to cover all
cases, then, we can try to delete the duplicate pullup calling at
all udc drivers, and make it be generic.
--
Best Regards,
Peter Chen
next prev parent reply other threads:[~2013-03-15 12:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-14 5:50 [PATCH 00/14] Add vbus status to udc-core Peter Chen
2013-03-14 5:50 ` [PATCH 01/14] usb: udc-core: introduce vbus_active for struct usb_gadget Peter Chen
2013-03-14 5:50 ` [PATCH 02/14] usb: chipidea: using common vbus_active Peter Chen
2013-03-14 5:50 ` [PATCH 03/14] usb: at91_udc: " Peter Chen
2013-03-14 5:50 ` [PATCH 04/14] usb: fsl_udc_core: " Peter Chen
2013-03-14 5:50 ` [PATCH 05/14] usb: lpc32xx_udc: " Peter Chen
2013-03-14 5:50 ` [PATCH 06/14] usb: mv_u3d_core: " Peter Chen
2013-03-14 5:50 ` [PATCH 07/14] usb: mv_udc: " Peter Chen
2013-03-14 5:50 ` [PATCH 08/14] usb: omap_udc: " Peter Chen
2013-03-14 5:50 ` [PATCH 09/14] usb: pch_udc: " Peter Chen
2013-03-14 5:50 ` [PATCH 10/14] usb: pxa25x_udc: " Peter Chen
2013-03-14 5:50 ` [PATCH 11/14] usb: pxa27x_udc: " Peter Chen
2013-03-14 5:50 ` [PATCH 12/14] usb: s3c2410_udc: " Peter Chen
2013-03-14 5:50 ` [PATCH 13/14] usb: udc-core: small cleanup for udc->gadget Peter Chen
2013-03-14 5:50 ` [PATCH 14/14] usb: udc-core: add judgement logic for usb_gadget_connect Peter Chen
2013-03-14 9:00 ` Felipe Balbi
2013-03-14 9:24 ` Peter Chen
2013-03-14 10:19 ` Felipe Balbi
2013-03-15 6:06 ` Peter Chen
2013-03-15 7:51 ` Felipe Balbi
2013-03-15 10:04 ` Peter Chen
2013-03-15 10:37 ` Felipe Balbi
2013-03-15 12:26 ` Peter Chen [this message]
2013-03-18 6:52 ` Peter Chen
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=20130315122658.GB32470@nchen-desktop \
--to=peter.chen@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox