Date:	Thu, 1 Oct 2015 12:58:49 -0500
From:	Felipe Balbi <balbi@...com>
To:	Mark Brown <broonie@...nel.org>
CC:	Felipe Balbi <balbi@...com>, Baolin Wang <baolin.wang@...aro.org>,
	Greg KH <gregkh@...uxfoundation.org>, <sre@...nel.org>,
	<dbaryshkov@...il.com>, <dwmw2@...radead.org>,
	<peter.chen@...escale.com>, <stern@...land.harvard.edu>,
	<r.baldyga@...sung.com>, <sojka@...ica.cz>,
	<yoshihiro.shimoda.uh@...esas.com>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <sameo@...ux.intel.com>,
	<lee.jones@...aro.org>, <ckeepax@...nsource.wolfsonmicro.com>,
	<patches@...nsource.wolfsonmicro.com>, <linux-pm@...r.kernel.org>,
	<device-mainlining@...ts.linuxfoundation.org>
Subject: Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

Hi,

On Thu, Oct 01, 2015 at 06:43:08PM +0100, Mark Brown wrote:
> On Thu, Oct 01, 2015 at 12:29:32PM -0500, Felipe Balbi wrote:
> 
> > 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).
> 
> What's the advantage of pushing this to userspace?  By the time we
> provide enough discoverability to enable userspace to configure itself
> it seems like we'd have enough information to do the job anyway.

you're going to be dealing with a setup where each vendor does one thing
differently. Some will have it all in the SoC part of a single IP (dwc3 can be
configured that way), some will push it out to companion IC, some might even use
some mostly discrete setup and so on...

We're gonna be dealing with a decision that involves information from multiple
subsystems (USB, regulator, hwmon, power supply to name a few).

We tried doing it all in the kernel back in N800, N810 and N900/N9 days and it's
just plain difficult. To make matters worse, N900 had two USB PHYs, one for
actual runtime use and another just for detecting the charger type on the other
end.

On top of all that, we still need to figure out what to do when a particular
configuration gets chosen, and what to do when the bus goes into the different
suspend levels.

It's going to be a lot of policy getting added to the kernel. On top of all
that, when Type C and power delivery is finally a thing, there will an entire
new stack for USB C commands (using the Type C CC pins or modulated on VBUS for
legacy connectors) which we will have to add to the kernel. And different
devices will support different charging profiles (there are at least 6 of those,
IIRC).

With all these different things going on, it's best to do what e.g. NFC folks
did. Just a small set of hooks in the kernel, but actual implementation done by
a userspace daemon. This makes it even easier for middleware development since
we can provide a higher level API for middleware to talk to the charging daemon.

Another benefit is that this charging daemon can also give hints to power
management policy that e.g. we're charging at 10W or 100W and we can e.g. switch
to performance governor safely even though battery is rather low.

Anyway, there's really a lot that needs to happen and shuving it all in the
kernel is, IMHO, the wrong decision. I would be much happier with minimal safety
requirements in the kernel and let a userspace daemon (which we should certainly
provide a reference implementation) figure out what to do. This might be better
for things like Chromebooks and Android phones too which might make completely
different decisions given a certain charging profile.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists