Hi, On Tue, Aug 29, 2017 at 01:53:24PM +0200, Hans de Goede wrote: > 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). Makes sense to me. -- Sebastian
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
