Message ID | 20240904-power-supply-extensions-v3-0-62efeb93f8ec@weissschuh.net |
---|---|
Headers | show |
Series | power: supply: extension API | expand |
Hi, On 9/4/24 9:25 PM, Thomas Weißschuh wrote: > The function only takes a desc as parameter, align the naming. > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Thanks, patch looks good to me: Reviewed-by: Hans de Goede <hdegoede@redhat.com> Regards, Hans > --- > drivers/power/supply/power_supply_core.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c > index 8f6025acd10a..cff68c4fd63c 100644 > --- a/drivers/power/supply/power_supply_core.c > +++ b/drivers/power/supply/power_supply_core.c > @@ -1183,8 +1183,8 @@ bool power_supply_battery_bti_in_range(struct power_supply_battery_info *info, > } > EXPORT_SYMBOL_GPL(power_supply_battery_bti_in_range); > > -static bool psy_has_property(const struct power_supply_desc *psy_desc, > - enum power_supply_property psp) > +static bool psy_desc_has_property(const struct power_supply_desc *psy_desc, > + enum power_supply_property psp) > { > bool found = false; > int i; > @@ -1209,7 +1209,7 @@ int power_supply_get_property(struct power_supply *psy, > return -ENODEV; > } > > - if (psy_has_property(psy->desc, psp)) > + if (psy_desc_has_property(psy->desc, psp)) > return psy->desc->get_property(psy, psp, val); > else if (power_supply_battery_info_has_prop(psy->battery_info, psp)) > return power_supply_battery_info_get_prop(psy->battery_info, psp, val); > @@ -1308,7 +1308,7 @@ static int psy_register_thermal(struct power_supply *psy) > return 0; > > /* Register battery zone device psy reports temperature */ > - if (psy_has_property(psy->desc, POWER_SUPPLY_PROP_TEMP)) { > + if (psy_desc_has_property(psy->desc, POWER_SUPPLY_PROP_TEMP)) { > /* Prefer our hwmon device and avoid duplicates */ > struct thermal_zone_params tzp = { > .no_hwmon = IS_ENABLED(CONFIG_POWER_SUPPLY_HWMON) > @@ -1361,7 +1361,7 @@ __power_supply_register(struct device *parent, > pr_warn("%s: Expected proper parent device for '%s'\n", > __func__, desc->name); > > - if (psy_has_property(desc, POWER_SUPPLY_PROP_USB_TYPE) && > + if (psy_desc_has_property(desc, POWER_SUPPLY_PROP_USB_TYPE) && > (!desc->usb_types || !desc->num_usb_types)) > return ERR_PTR(-EINVAL); > >
Hi, On 9/4/24 9:25 PM, Thomas Weißschuh wrote: > Instead of only registering properties from the psy_desc itself, > also register the ones from the battery. > Use power_supply_has_property() for this test which makes the logic also > easier to read. > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Thanks, patch looks good to me: Reviewed-by: Hans de Goede <hdegoede@redhat.com> Regards, Hans > --- > drivers/power/supply/power_supply_hwmon.c | 52 +++++++++++++++---------------- > 1 file changed, 26 insertions(+), 26 deletions(-) > > diff --git a/drivers/power/supply/power_supply_hwmon.c b/drivers/power/supply/power_supply_hwmon.c > index baacefbdf768..1c1ad3e1d81f 100644 > --- a/drivers/power/supply/power_supply_hwmon.c > +++ b/drivers/power/supply/power_supply_hwmon.c > @@ -8,6 +8,8 @@ > #include <linux/power_supply.h> > #include <linux/slab.h> > > +#include "power_supply.h" > + > struct power_supply_hwmon { > struct power_supply *psy; > unsigned long *props; > @@ -347,9 +349,28 @@ static const struct hwmon_chip_info power_supply_hwmon_chip_info = { > .info = power_supply_hwmon_info, > }; > > +static const enum power_supply_property power_supply_hwmon_props[] = { > + POWER_SUPPLY_PROP_CURRENT_AVG, > + POWER_SUPPLY_PROP_CURRENT_MAX, > + POWER_SUPPLY_PROP_CURRENT_NOW, > + POWER_SUPPLY_PROP_POWER_AVG, > + POWER_SUPPLY_PROP_POWER_NOW, > + POWER_SUPPLY_PROP_TEMP, > + POWER_SUPPLY_PROP_TEMP_MAX, > + POWER_SUPPLY_PROP_TEMP_MIN, > + POWER_SUPPLY_PROP_TEMP_ALERT_MIN, > + POWER_SUPPLY_PROP_TEMP_ALERT_MAX, > + POWER_SUPPLY_PROP_TEMP_AMBIENT, > + POWER_SUPPLY_PROP_TEMP_AMBIENT_ALERT_MIN, > + POWER_SUPPLY_PROP_TEMP_AMBIENT_ALERT_MAX, > + POWER_SUPPLY_PROP_VOLTAGE_AVG, > + POWER_SUPPLY_PROP_VOLTAGE_MIN, > + POWER_SUPPLY_PROP_VOLTAGE_MAX, > + POWER_SUPPLY_PROP_VOLTAGE_NOW, > +}; > + > int power_supply_add_hwmon_sysfs(struct power_supply *psy) > { > - const struct power_supply_desc *desc = psy->desc; > struct power_supply_hwmon *psyhw; > struct device *dev = &psy->dev; > struct device *hwmon; > @@ -375,32 +396,11 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy) > goto error; > } > > - for (i = 0; i < desc->num_properties; i++) { > - const enum power_supply_property prop = desc->properties[i]; > - > - switch (prop) { > - case POWER_SUPPLY_PROP_CURRENT_AVG: > - case POWER_SUPPLY_PROP_CURRENT_MAX: > - case POWER_SUPPLY_PROP_CURRENT_NOW: > - case POWER_SUPPLY_PROP_POWER_AVG: > - case POWER_SUPPLY_PROP_POWER_NOW: > - case POWER_SUPPLY_PROP_TEMP: > - case POWER_SUPPLY_PROP_TEMP_MAX: > - case POWER_SUPPLY_PROP_TEMP_MIN: > - case POWER_SUPPLY_PROP_TEMP_ALERT_MIN: > - case POWER_SUPPLY_PROP_TEMP_ALERT_MAX: > - case POWER_SUPPLY_PROP_TEMP_AMBIENT: > - case POWER_SUPPLY_PROP_TEMP_AMBIENT_ALERT_MIN: > - case POWER_SUPPLY_PROP_TEMP_AMBIENT_ALERT_MAX: > - case POWER_SUPPLY_PROP_VOLTAGE_AVG: > - case POWER_SUPPLY_PROP_VOLTAGE_MIN: > - case POWER_SUPPLY_PROP_VOLTAGE_MAX: > - case POWER_SUPPLY_PROP_VOLTAGE_NOW: > + for (i = 0; i < ARRAY_SIZE(power_supply_hwmon_props); i++) { > + const enum power_supply_property prop = power_supply_hwmon_props[i]; > + > + if (power_supply_has_property(psy, prop)) > set_bit(prop, psyhw->props); > - break; > - default: > - break; > - } > } > > name = psy->desc->name; >
Introduce a mechanism for drivers to extend the properties implemented by a power supply. Motivation ---------- Various drivers, mostly in platform/x86 extend the ACPI battery driver with additional sysfs attributes to implement more UAPIs than are exposed through ACPI by using various side-channels, like WMI, nonstandard ACPI or EC communication. While the created sysfs attributes look similar to the attributes provided by the powersupply core, there are various deficiencies: * They don't show up in uevent payload. * They can't be queried with the standard in-kernel APIs. * They don't work with triggers. * The extending driver has to reimplement all of the parsing, formatting and sysfs display logic. * Writing a extension driver is completely different from writing a normal power supply driver. * ~Properties can not be properly overriden.~ (Overriding is now explicitly forbidden) The proposed extension API avoids all of these issues. An extension is just a "struct power_supply_ext" with the same kind of callbacks as in a normal "struct power_supply_desc". The API is meant to be used via battery_hook_register(), the same way as the current extensions. When testing, please enable lockdep to make sure the locking is correct. Contents -------- * Patch 1 to 5 are preparation patches. * Patch 6 implements the extension API itself. * Patch 7 implements a locking scheme for the extension API. * Patch 8 adds extension support to test_power.c * Patch 9 converts the in-tree cros_charge-control driver to the extension API. Open issues ----------- * Newly registered properties will not show up in hwmon. To do that properly would require some changes in the hwmon core. As far as I know, no current driver would extend the hwmon properties anyways. * As this is only useful with the hooks of CONFIG_ACPI_BATTERY, should it also be gated behind this or another config? * Is an rw_semaphore acceptable? [0] https://lore.kernel.org/lkml/20240528-cros_ec-charge-control-v2-0-81fb27e1cff4@weissschuh.net/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> --- Changes in v3: - Make naming more consistent - Readd locking - Allow multiple active extensions - Allow passing a "void *ext_data" when registering - Switch example driver from system76 to cros_charge-control - Link to v2: https://lore.kernel.org/r/20240608-power-supply-extensions-v2-0-2dcd35b012ad@weissschuh.net Changes in v2: - Drop locking patch, let's figure out the API first - Allow registration of multiple extensions - Pass extension to extension callbacks as parameter - Disallow property overlap between extensions and core psy - Drop system76/pdx86 maintainers, as the system76 changes are only RFC state anyways - Link to v1: https://lore.kernel.org/r/20240606-power-supply-extensions-v1-0-b45669290bdc@weissschuh.net --- Thomas Weißschuh (9): power: supply: core: rename psy_has_property() to psy_desc_has_property() power: supply: core: register thermal zone for battery power: supply: hwmon: register battery properties power: supply: sysfs: register battery properties power: supply: sysfs: rework uevent property loop power: supply: core: implement extension API power: supply: core: add locking around extension access power: supply: test-power: implement a power supply extension power: supply: cros_charge-control: use power_supply extensions drivers/power/supply/cros_charge-control.c | 207 +++++++++++------------------ drivers/power/supply/power_supply.h | 18 +++ drivers/power/supply/power_supply_core.c | 169 +++++++++++++++++++++-- drivers/power/supply/power_supply_hwmon.c | 52 ++++---- drivers/power/supply/power_supply_leds.c | 2 + drivers/power/supply/power_supply_sysfs.c | 65 +++++---- drivers/power/supply/test_power.c | 104 +++++++++++++++ include/linux/power_supply.h | 33 +++++ 8 files changed, 453 insertions(+), 197 deletions(-) --- base-commit: d8abb73f584772eaafa95a447c90f1c02dba0dec change-id: 20240602-power-supply-extensions-07d949f509d9 Best regards,