From: Felipe Balbi <balbi@ti.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Felipe Balbi <balbi@ti.com>, Baolin Wang <baolin.wang@linaro.org>,
<sre@kernel.org>, <dbaryshkov@gmail.com>, <dwmw2@infradead.org>,
<peter.chen@freescale.com>, <stern@rowland.harvard.edu>,
<r.baldyga@samsung.com>, <sojka@merica.cz>,
<yoshihiro.shimoda.uh@renesas.com>, <linux-usb@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <sameo@linux.intel.com>,
<lee.jones@linaro.org>, <ckeepax@opensource.wolfsonmicro.com>,
<broonie@kernel.org>, <patches@opensource.wolfsonmicro.com>,
<linux-pm@vger.kernel.org>,
<device-mainlining@lists.linuxfoundation.org>
Subject: Re: [PATCH v4 1/5] gadget: Introduce the notifier functions
Date: Fri, 2 Oct 2015 12:27:30 -0500 [thread overview]
Message-ID: <20151002172730.GK5552@saruman.tx.rr.com> (raw)
In-Reply-To: <20151002054107.GB18406@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 3668 bytes --]
Hi,
On Fri, Oct 02, 2015 at 07:41:07AM +0200, Greg KH wrote:
> On Thu, Oct 01, 2015 at 12:29:32PM -0500, Felipe Balbi wrote:
> > On Thu, Sep 24, 2015 at 10:39:23AM -0700, Baolin Wang wrote:
> > > The usb charger framework is based on usb gadget. The usb charger
> > > need to be notified the state changing of usb gadget to confirm the
> > > usb charger state.
> > >
> > > Thus this patch adds a notifier mechanism for usb gadget to report a
> > > event to usb charger when the usb gadget state is changed.
> > >
> > > Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> > > ---
> > > drivers/usb/gadget/udc/udc-core.c | 32 ++++++++++++++++++++++++++++++++
> > > include/linux/usb/gadget.h | 18 ++++++++++++++++++
> > > 2 files changed, 50 insertions(+)
> > >
> > > diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c
> > > index f660afb..4238fc3 100644
> > > --- a/drivers/usb/gadget/udc/udc-core.c
> > > +++ b/drivers/usb/gadget/udc/udc-core.c
> > > @@ -129,6 +129,32 @@ void usb_gadget_giveback_request(struct usb_ep *ep,
> > > }
> > > EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
> > >
> > > +int usb_gadget_register_notify(struct usb_gadget *gadget,
> > > + struct notifier_block *nb)
> > > +{
> > > + int ret;
> > > +
> > > + mutex_lock(&gadget->lock);
> > > + ret = raw_notifier_chain_register(&gadget->nh, nb);
> > > + mutex_unlock(&gadget->lock);
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL_GPL(usb_gadget_register_notify);
> > > +
> > > +int usb_gadget_unregister_notify(struct usb_gadget *gadget,
> > > + struct notifier_block *nb)
> > > +{
> > > + int ret;
> > > +
> > > + mutex_lock(&gadget->lock);
> > > + ret = raw_notifier_chain_unregister(&gadget->nh, nb);
> >
> > Greg, this is the kind of thing I wanted to avoid adding more of.
> >
> > I was wondering if you would accept subsystems using kdbus for
> > this sort of notification. I'm okay waiting for kdbus for another
> > couple merge windows (if we have to) before that's merged, but
> > if we take this raw notifier approach now, we will end up having
> > to support it forever.
>
> kdbus is userspace <-> userspace messages, it doesn't do kernel <->
> userspace messages, sorry.
oh well, tough luck :-)
having a more well-constructed notification method to userspace would be a
little better, but I guess we will have to resort to sysfs_notify() or something
like that.
> > Also, because soon enough we will have to support USB Power Delivery
> > with Type C connector, this is bound to change in the coming months.
> >
> > Frankly, I wanted all of this to be decided in userland with the
> > kernel just providing notification and basic safety checks (we don't
> > want to allow a bogus userspace daemon frying anybody's devices).
> >
> > How would you feel about that ?
>
> I agree I don't like new notifier chains being added, but as this is all
> in-kernel, we can change the api in the future and there would not be a
> problem, right?
not necessarily. This will, eventually, get exposed to userspace. At minimum for
adding eye candy to the UI. Chaging battery icon or whatever. The danger here is
that when that something gets exposed, we will have to support it for the next
30 years :-)
> And yeah, I'm worried about the USB Power delivery patches, I haven't
> seen them yet, but I hear about different groups doing different things
> here, and that worries me.
my worries exactly :-) This is why I'm looking for a flexible enough approach
which puts as little into the kernel as necessary.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-10-02 17:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-24 17:39 [PATCH v4 0/5] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2015-09-24 17:39 ` [PATCH v4 1/5] gadget: Introduce the notifier functions Baolin Wang
2015-10-01 17:29 ` Felipe Balbi
2015-10-01 17:43 ` Mark Brown
2015-10-01 17:58 ` Felipe Balbi
2015-10-01 18:01 ` Felipe Balbi
2015-10-02 16:47 ` Mark Brown
2015-10-02 17:23 ` Felipe Balbi
2015-10-02 18:49 ` Mark Brown
2015-10-02 19:11 ` Felipe Balbi
2015-10-04 22:55 ` Mark Brown
2015-10-05 15:15 ` Felipe Balbi
2015-10-05 16:18 ` Mark Brown
2015-10-05 16:29 ` Felipe Balbi
2015-10-07 16:44 ` [Device-mainlining] " Bjorn Andersson
2015-10-08 15:51 ` Pavel Machek
2015-10-02 5:41 ` Greg KH
2015-10-02 17:27 ` Felipe Balbi [this message]
2015-10-08 15:50 ` Pavel Machek
2015-10-09 21:17 ` Felipe Balbi
2015-10-12 16:56 ` Mark Brown
2016-04-09 16:01 ` Pavel Machek
2015-09-24 17:39 ` [PATCH v4 2/5] gadget: Introduce the usb charger framework Baolin Wang
2015-09-24 17:39 ` [PATCH v4 3/5] gadget: Support for " Baolin Wang
2015-09-24 17:39 ` [PATCH v4 4/5] gadget: Integrate with the usb gadget supporting for usb charger Baolin Wang
2015-09-24 17:39 ` [PATCH v4 5/5] power: wm831x_power: Support USB charger current limit management Baolin Wang
-- strict thread matches above, loose matches on Subject: below --
2015-08-19 9:13 [PATCH v4 0/5] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2015-08-19 9:13 ` [PATCH v4 1/5] gadget: Introduce the notifier functions Baolin Wang
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=20151002172730.GK5552@saruman.tx.rr.com \
--to=balbi@ti.com \
--cc=baolin.wang@linaro.org \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.wolfsonmicro.com \
--cc=dbaryshkov@gmail.com \
--cc=device-mainlining@lists.linuxfoundation.org \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
--cc=peter.chen@freescale.com \
--cc=r.baldyga@samsung.com \
--cc=sameo@linux.intel.com \
--cc=sojka@merica.cz \
--cc=sre@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=yoshihiro.shimoda.uh@renesas.com \
/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
Powered by JetHome