[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yffnnom1qTRFbo/o@smile.fi.intel.com>
Date: Mon, 31 Jan 2022 15:43:58 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Hans de Goede <hdegoede@...hat.com>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Mark Gross <markgross@...nel.org>,
Andy Shevchenko <andy@...nel.org>,
Wolfram Sang <wsa@...nel.org>,
Lee Jones <lee.jones@...aro.org>,
Sebastian Reichel <sre@...nel.org>,
MyungJoo Ham <myungjoo.ham@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Ard Biesheuvel <ardb@...nel.org>, Len Brown <lenb@...nel.org>,
linux-acpi@...r.kernel.org, Yauhen Kharuzhy <jekhor@...il.com>,
Tsuchiya Yuto <kitakar@...il.com>,
Fabio Aiuto <fabioaiuto83@...il.com>,
platform-driver-x86@...r.kernel.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [PATCH v4 01/20] power: supply: core: Refactor
power_supply_set_input_current_limit_from_supplier()
On Mon, Jan 31, 2022 at 03:37:16PM +0200, Andy Shevchenko wrote:
> On Sun, Jan 30, 2022 at 09:45:38PM +0100, Hans de Goede wrote:
> > Some (USB) charger ICs have variants with USB D+ and D- pins to do their
> > own builtin charger-type detection, like e.g. the bq24190 and bq25890 and
> > also variants which lack this functionality, e.g. the bq24192 and bq25892.
> >
> > In case the charger-type; and thus the input-current-limit detection is
> > done outside the charger IC then we need some way to communicate this to
> > the charger IC. In the past extcon was used for this, but if the external
> > detection does e.g. full USB PD negotiation then the extcon cable-types do
> > not convey enough information.
> >
> > For these setups it was decided to model the external charging "brick"
> > and the parameters negotiated with it as a power_supply class-device
> > itself; and power_supply_set_input_current_limit_from_supplier() was
> > introduced to allow drivers to get the input-current-limit this way.
> >
> > But in some cases psy drivers may want to know other properties, e.g. the
> > bq25892 can do "quick-charge" negotiation by pulsing its current draw,
> > but this should only be done if the usb_type psy-property of its supplier
> > is set to DCP (and device-properties indicate the board allows higher
> > voltages).
> >
> > Instead of adding extra helper functions for each property which
> > a psy-driver wants to query from its supplier, refactor
> > power_supply_set_input_current_limit_from_supplier() into a
> > more generic power_supply_get_property_from_supplier() function.
>
> ...
>
> > + ret = power_supply_get_property_from_supplier(bdi->charger,
> > + POWER_SUPPLY_PROP_CURRENT_MAX,
> > + &val);
> > + if (ret == 0)
>
> Can it be as simple as
>
> if (ret)
> return;
>
> ...
>
>
> ?
>
> Or did I misunderstand the meaning of 0?
Despite on this comment being addressed or not, FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
I don't see any blocking issues with the bq25890 part neither, so
Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
for the BQ25890 part.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists