Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Mark Brown
2016-11-21T17:18:41Z

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]

On Thu, Nov 17, 2016 at 05:46:13PM +1100, NeilBrown wrote:
> On Thu, Nov 17 2016, Mark Brown wrote:

> > To me that's pretty much what's being done here, the code just happens
> > to sit in USB instead but fundamentally it's just a blob of helper code,
> > you could replace the notifier with a callback if that's the big concern
> > here.

> It is a lot more than "just a blob of helper code". It duplicates
> existing infrastructure instead of fixing and using the
> infrastructure.... but I've said all this before. Repeatedly.

My read on that is that the question of what we want to be responsible
for aggregating the information about what power the system is allowed
to draw from a given USB port hasn't been resolved yet and that apart
from that you're fairly close. It seems to me like that's really what
the difference between your two positions is. Fixing the existing
notifiers implies that things have to be aggregated in the power supply
drivers but Baolin is proposing doing that in the USB code instead. It
does seem at least worth considering if that's a good idea since the
current situation doesn't look terribly thought through.

There are a whole bunch of things that need to be sorted out whatever
the decision is like the extcon related cleanups you mentioned in your
mail the other day (steps 1 and 2), it seems like those could be moved
forwards independently.

By the way it occurred to me recently that we have a use case for
multiple USB ports that could supply power - USB C. Things with more
than one port like things in a laptop form factor are going to want to
be able to use all of them interchangably for power support (likely only
one at a time, at least initially, but still more than one port).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]