| Message ID | 20220130204557.15662-2-hdegoede@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | power-suppy/i2c/extcon: Fix charger setup on Xiaomi Mi Pad 2 and Lenovo Yogabook | expand |
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?
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@linux.intel.com> I don't see any blocking issues with the bq25890 part neither, so Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> for the BQ25890 part.
Hi Andy, Thank you for the reviews. On 1/31/22 14:37, 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? Yes that would be better and together with some of the other tweaks you've suggested I believe that this warrants a version 5. So I'll address a v5 addressing all your comment. Regards, Hans
diff --git a/drivers/power/supply/bq24190_charger.c b/drivers/power/supply/bq24190_charger.c index 06c34b09349c..c8a06ee6bd51 100644 --- a/drivers/power/supply/bq24190_charger.c +++ b/drivers/power/supply/bq24190_charger.c @@ -1206,8 +1206,16 @@ static void bq24190_input_current_limit_work(struct work_struct *work) struct bq24190_dev_info *bdi = container_of(work, struct bq24190_dev_info, input_current_limit_work.work); + union power_supply_propval val; + int ret; - power_supply_set_input_current_limit_from_supplier(bdi->charger); + ret = power_supply_get_property_from_supplier(bdi->charger, + POWER_SUPPLY_PROP_CURRENT_MAX, + &val); + if (ret == 0) + bq24190_charger_set_property(bdi->charger, + POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT, + &val); } /* Sync the input-current-limit with our parent supply (if we have one) */ diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c index ec838c9bcc0a..df4471e50d33 100644 --- a/drivers/power/supply/power_supply_core.c +++ b/drivers/power/supply/power_supply_core.c @@ -376,46 +376,49 @@ int power_supply_is_system_supplied(void) } EXPORT_SYMBOL_GPL(power_supply_is_system_supplied); -static int __power_supply_get_supplier_max_current(struct device *dev, - void *data) +struct psy_get_supplier_prop_data { + struct power_supply *psy; + enum power_supply_property psp; + union power_supply_propval *val; +}; + +static int __power_supply_get_supplier_property(struct device *dev, void *_data) { - union power_supply_propval ret = {0,}; struct power_supply *epsy = dev_get_drvdata(dev); - struct power_supply *psy = data; + struct psy_get_supplier_prop_data *data = _data; - if (__power_supply_is_supplied_by(epsy, psy)) - if (!epsy->desc->get_property(epsy, - POWER_SUPPLY_PROP_CURRENT_MAX, - &ret)) - return ret.intval; + if (__power_supply_is_supplied_by(epsy, data->psy)) + if (!epsy->desc->get_property(epsy, data->psp, data->val)) + return 1; /* Success */ - return 0; + return 0; /* Continue iterating */ } -int power_supply_set_input_current_limit_from_supplier(struct power_supply *psy) +int power_supply_get_property_from_supplier(struct power_supply *psy, + enum power_supply_property psp, + union power_supply_propval *val) { - union power_supply_propval val = {0,}; - int curr; - - if (!psy->desc->set_property) - return -EINVAL; + struct psy_get_supplier_prop_data data = { + .psy = psy, + .psp = psp, + .val = val, + }; + int ret; /* * This function is not intended for use with a supply with multiple - * suppliers, we simply pick the first supply to report a non 0 - * max-current. + * suppliers, we simply pick the first supply to report the psp. */ - curr = class_for_each_device(power_supply_class, NULL, psy, - __power_supply_get_supplier_max_current); - if (curr <= 0) - return (curr == 0) ? -ENODEV : curr; - - val.intval = curr; + ret = class_for_each_device(power_supply_class, NULL, &data, + __power_supply_get_supplier_property); + if (ret < 0) + return ret; + if (ret == 0) + return -ENODEV; - return psy->desc->set_property(psy, - POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT, &val); + return 0; } -EXPORT_SYMBOL_GPL(power_supply_set_input_current_limit_from_supplier); +EXPORT_SYMBOL_GPL(power_supply_get_property_from_supplier); int power_supply_set_battery_charged(struct power_supply *psy) { diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h index e218041cc000..006111917d1a 100644 --- a/include/linux/power_supply.h +++ b/include/linux/power_supply.h @@ -597,8 +597,9 @@ power_supply_temp2resist_simple(struct power_supply_resistance_temp_table *table int table_len, int temp); extern void power_supply_changed(struct power_supply *psy); extern int power_supply_am_i_supplied(struct power_supply *psy); -extern int power_supply_set_input_current_limit_from_supplier( - struct power_supply *psy); +int power_supply_get_property_from_supplier(struct power_supply *psy, + enum power_supply_property psp, + union power_supply_propval *val); extern int power_supply_set_battery_charged(struct power_supply *psy); #ifdef CONFIG_POWER_SUPPLY
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. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/power/supply/bq24190_charger.c | 10 ++++- drivers/power/supply/power_supply_core.c | 57 +++++++++++++----------- include/linux/power_supply.h | 5 ++- 3 files changed, 42 insertions(+), 30 deletions(-)