Re: [PATCH v2 11/14] power: supply: bq24190_charger: Get input_current_limit from our supplier

From: Hans de Goede
Date: Tue Aug 29 2017 - 07:53:32 EST


Hi,

Thank you for your reviews / queuing!

On 29-08-17 13:40, Sebastian Reichel wrote:
Hi,

On Tue, Aug 15, 2017 at 10:04:59PM +0200, Hans de Goede wrote:
On some devices the USB Type-C port power (USB PD 2.0) negotiation is
done by a separate port-controller IC, while the current limit is
controlled through another (charger) IC.

It has been decided to model this by modelling the external Type-C
power brick (adapter/charger) as a power-supply class device which
supplies the charger-IC, with its voltage-now and current-max representing
the negotiated voltage and max current draw.

This commit adds support for this to the bq24190_charger driver by calling
power_supply_set_input_current_limit_from_supplier helper if the
"input-current-limit-from-supplier" device-property is set.

Note this replaces the functionality to get the current-limit from an
extcon device, which will be removed in a follow-up commit.

I'm fine with the general approach, but ...

[...]
+ bdi->input_current_limit_from_supplier =
+ device_property_read_bool(dev,
+ "input-current-limit-from-supplier");
[...]

I wonder if we actually need this. I think we can just enable it
unconditionally when we have a parent power supply providing the
information.

I was thinking the same when implementing this, so this is fine with
me. I think it is best to just unconditionally call
power_supply_set_input_current_limit_from_supplier from the
external_power_changed callback, that will only get called if we've
a parent supply and that function will check that the parent has
a current-max property itself.

Please let me know if just unconditionally calling
power_supply_set_input_current_limit_from_supplier from the
external_power_changed callback is ok with you then I will do that
for v3 of the patch-set (from which I will drop the patches you've
already queued).

Regards,

Hans