linux-kernel - Re: [RFC/PATCH 1/5] usb: otg: add notifier support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201001260535.21689.david-b@pacbell.net>
Date:	Tue, 26 Jan 2010 05:35:21 -0800
From:	David Brownell <david-b@...bell.net>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Felipe Balbi <felipe.balbi@...ia.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Anton Vorontsov <avorontsov@...mvista.com>,
	Grazvydas Ignotas <notasas@...il.com>,
	Madhusudhan Chikkature <madhu.cr@...com>,
	linux-omap@...r.kernel.org, "Greg Kroah-Hartman" <gregkh@...e.de>
Subject: Re: [RFC/PATCH 1/5] usb: otg: add notifier support

On Tuesday 26 January 2010, Mark Brown wrote:
> On Tue, Jan 26, 2010 at 03:16:20AM -0800, David Brownell wrote:
> 
> > I'd vote to convert all the USB-to-charger interfaces so
> > they use notifiers.  After fixing the events ... see
> > comments below.  :)
> 
> Yes please - it's not just chargers either, this can also be used by
> PMICs which do power path management that includes USB.

Color me confused ... what do you mean by "power path"?

Do you mean something like "the board as a whole can take N mA of
current from USB", rather than specifically addressing a charger?

It's not uncommon to do things like use VBUS current to power the
USB circuitry, too.  That can leave less for other purposes.  All
of that being rather board-specific.

> > Those seem like the wrong events.  The right events for a charger
> > would be more along the lines of:
> 
> >  - For peripheral:  "you may use N milliAmperes now".
> >  - General:  "Don't Charge" (a.k.a. "use 0 mA").
> 
> > I don't see how "N" would be passed with those events ...
> 
> These are good for the peripheral side.  You do get to pass a void *
> along with the notifier value, that could be used to pass data like the
> current limit.

I don't think I saw that being done ... either in code, comments,
or documentation.  Passing N is fundamental.

> > A host *might* want to be able to say things like "supply
> > up to N milliAmperes now", e.g. to let a regulator choose
> > the most efficient mode.
> 
> Yes, they definitely want this - not just for efficiency but also to
> allow current limiting to protect the system from excessive current
> drain.

There are load bursting issues too.  All part of the USB spec;
a load that's OK for 1 millisecond might not be OK for 1 second.
ISTR the "supply N mA" refers to an average.  And there are some
limits to the capacitance that can practically be stuck on VBUS
output lines (which includes the cable).  Solvable problems, but
not always pretty if software has to think it through.

Thing is, supplying current is a bit more involved.  If the
board can't supply 300 mA, the USB configuration selection
mechanism has to know that, so it never selects peripheral
configurations which require that much current.

Or maybe these two ports can serve 500 mA, but not those two;
or their total can't exceed N (function of componentry and power
budgeting).

Ergo my desire to start with a straightforward problem whose
solution has real value (how much VBUS current may be consumed?),
and leave some of those other messes for later!

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/