On Mon, Nov 14 2016, Mark Brown wrote:

On Mon, Nov 14, 2016 at 03:21:13PM +1100, NeilBrown wrote:

quoted

On Thu, Nov 10 2016, Baolin Wang wrote:

quoted

quoted

Fourth, we need integrate all charger plugin/out
event in one framework, not from extcon, maybe type-c in future.

quoted

Why not extcon?  Given that a charger is connected by an external
connector, extcon seems like exactly the right thing to use.

quoted

Obviously extcon doesn't report the current that was negotiated, but
that is best kept separate.  The battery charger can be advised of the
available current either via extcon or separately via the usb
subsystem.  Don't conflate the two.

Conflating the two seems like the whole point here.  We're looking for
something that sits between the power supply code and the USB code and
tells the power supply code what it's allowed to do which is the result
of a combination of physical cable detection and USB protocol.  It seems
reasonable that extcon drivers ought to be part of this but it doesn't
seem like they are the whole story.

I don't think "between the power supply code and the USB code" is where
this thing sits. I think it sits inside the power-supply driver.
We already have extcon which sits between the phy and the power_supply
code, and the usb_notifier which sits between the USB code and the
power supply code.  We don't need another go-between.

If we have extcon able to deliver reliable information about cable type,
and if with have the usb notifier able to deliver reliable information
about negotiated current, and if the power supply manager is able to
register with the correct extcon and the correct usb notifier, then the
power supply manager *could* handle all the notifications and make the
correct determinations and set the current limits itself.  All this
could be done entirely internally, without the help of any new
subsystem.
Do you agree?

Clearly doing it that way would result in lots of code duplication and
would mean that each driver probably gets its own private set of bugs,
but it would be possible.  Just undesirable.

So yes, it makes perfect to provide common code which handles the
registrations, and captures the events, and translates the different
events into current levels and feeds those back to the driver.  This
isn't some new subsystem, this is just a resource, provided by a
library, that power drivers can allocate and initialize if the want to.

To quote myself:

5/ Now that all cable connection notifications are sent over extcon and
   all vbus_draw notifications are sent over the usb_phy notifier, write
   some support code that a power supply client can use to be told what
   power is available.
   e.g. a battery charger driver would call:
       register_power_client(.....)
   or similar, providing a phandle (or similar) for the usb phy and a
   function to call back when the available current changes (or maybe a
   work_struct containing the function pointer)

   register_power_client() would then register with extcon and separately
   with the usb_phy notifier.  When the different events arrive it
   calculates what ranges of currents are expected and calls the
   call-back function with those details.

NeilBrown