[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170829121224.5djjfrj7azpp3gll@earth>
Date: Tue, 29 Aug 2017 14:12:24 +0200
From: Sebastian Reichel <sebastian.reichel@...labora.co.uk>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Wolfram Sang <wsa@...-dreams.de>,
Guenter Roeck <linux@...ck-us.net>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Darren Hart <dvhart@...radead.org>,
Andy Shevchenko <andy@...radead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Liam Breck <liam@...workimprov.net>,
Tony Lindgren <tony@...mide.com>, linux-i2c@...r.kernel.org,
linux-pm@...r.kernel.org, platform-driver-x86@...r.kernel.org,
linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org
Subject: Re: [PATCH v2 11/14] power: supply: bq24190_charger: Get
input_current_limit from our supplier
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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists