| Message ID | 20241211-power-supply-extensions-v6-0-9d9dc3f3d387@weissschuh.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | power: supply: extension API | expand |
Am 11.12.24 um 20:57 schrieb Thomas Weißschuh: > 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. > Further usecases are fuel gauges and the existing battery_info > properties. > > When testing, please enable lockdep to make sure the locking is correct. > > The series is based on the linux-power-supply/for-next branch. > It also depends on some recent fixes not yet available in the for-next > branch [0]. > > [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 v6: > - Drop alreay picked up ACPI battery hook rename patch > - Only return bool from power_supply_property_is_writeable() > - Improve naming for test_power symbols > - Integrate cros_charge-control fixes from the psy/fixes branch > - Add sysfs UAPI for extension discovery > - Use __must_check on API > - Make power_supply_for_each_extension() safer. > (And uglier, ideas welcome) Maybe we can use a do { ... } while (0) construct here. > - Link to v5: https://lore.kernel.org/r/20241205-power-supply-extensions-v5-0-f0f996db4347@weissschuh.net > > Changes in v5: > - Drop already picked up patches > - Simplify power_supply_ext_has_property() > - Handle failure of power_supply_update_sysfs_and_hwmon() > - Reduce some locking scopes > - Add missing locking to power_supply_show_charge_behaviour() > - Improve sanity checks in power_supply_register_extension() > - Implement writeable property in test_power battery > - Rename ACPI battery hook messages for clarity > - Link to v4: https://lore.kernel.org/r/20241111-power-supply-extensions-v4-0-7240144daa8e@weissschuh.net > > Changes in v4: > - Drop RFC state > - Integrate locking commit > - Reregister hwmon device > - Link to v3: https://lore.kernel.org/r/20240904-power-supply-extensions-v3-0-62efeb93f8ec@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 (4): > power: supply: core: implement extension API > power: supply: test-power: implement a power supply extension > power: supply: cros_charge-control: implement a power supply extension > power: supply: core: add UAPI to discover currently used extensions > > Documentation/ABI/testing/sysfs-class-power | 9 ++ > drivers/power/supply/cros_charge-control.c | 200 ++++++++++++---------------- > drivers/power/supply/power_supply.h | 19 +++ > drivers/power/supply/power_supply_core.c | 177 ++++++++++++++++++++++-- > drivers/power/supply/power_supply_sysfs.c | 36 ++++- > drivers/power/supply/test_power.c | 113 ++++++++++++++++ > include/linux/power_supply.h | 35 +++++ > 7 files changed, 467 insertions(+), 122 deletions(-) > --- > base-commit: 810dde9dad8222f3b831cf5179927fc66fc6a006 > change-id: 20240602-power-supply-extensions-07d949f509d9 > > Best regards,
On 2024-12-12 15:27:52+0100, Armin Wolf wrote: > Am 11.12.24 um 20:57 schrieb Thomas Weißschuh: > > > Introduce a mechanism for drivers to extend the properties implemented > > by a power supply. [..] > > --- > > Changes in v6: > > - Drop alreay picked up ACPI battery hook rename patch > > - Only return bool from power_supply_property_is_writeable() > > - Improve naming for test_power symbols > > - Integrate cros_charge-control fixes from the psy/fixes branch > > - Add sysfs UAPI for extension discovery > > - Use __must_check on API > > - Make power_supply_for_each_extension() safer. > > (And uglier, ideas welcome) > > Maybe we can use a do { ... } while (0) construct here. I don't think so. The macro needs to expand to a dangling loop condition. So whatever statement comes after gets executed in the loop. [..]
On Wed, 11 Dec 2024 20:57:54 +0100, Thomas Weißschuh wrote: > 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. > > [...] Applied, thanks! [1/4] power: supply: core: implement extension API commit: 6037802bbae892f3ad0c7b4c4faee39b967e32b0 [2/4] power: supply: test-power: implement a power supply extension commit: 9d76d5de87bbf03c6e483565030b562dc42c7bff Best regards,
On Wed, 11 Dec 2024 20:57:54 +0100, Thomas Weißschuh wrote: > 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. > > [...] Applied, thanks! [4/4] power: supply: core: add UAPI to discover currently used extensions commit: 288a2cabcf6bb35532e8b2708829bdc2b85bc690 Best regards,
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. Further usecases are fuel gauges and the existing battery_info properties. When testing, please enable lockdep to make sure the locking is correct. The series is based on the linux-power-supply/for-next branch. It also depends on some recent fixes not yet available in the for-next branch [0]. [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 v6: - Drop alreay picked up ACPI battery hook rename patch - Only return bool from power_supply_property_is_writeable() - Improve naming for test_power symbols - Integrate cros_charge-control fixes from the psy/fixes branch - Add sysfs UAPI for extension discovery - Use __must_check on API - Make power_supply_for_each_extension() safer. (And uglier, ideas welcome) - Link to v5: https://lore.kernel.org/r/20241205-power-supply-extensions-v5-0-f0f996db4347@weissschuh.net Changes in v5: - Drop already picked up patches - Simplify power_supply_ext_has_property() - Handle failure of power_supply_update_sysfs_and_hwmon() - Reduce some locking scopes - Add missing locking to power_supply_show_charge_behaviour() - Improve sanity checks in power_supply_register_extension() - Implement writeable property in test_power battery - Rename ACPI battery hook messages for clarity - Link to v4: https://lore.kernel.org/r/20241111-power-supply-extensions-v4-0-7240144daa8e@weissschuh.net Changes in v4: - Drop RFC state - Integrate locking commit - Reregister hwmon device - Link to v3: https://lore.kernel.org/r/20240904-power-supply-extensions-v3-0-62efeb93f8ec@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 (4): power: supply: core: implement extension API power: supply: test-power: implement a power supply extension power: supply: cros_charge-control: implement a power supply extension power: supply: core: add UAPI to discover currently used extensions Documentation/ABI/testing/sysfs-class-power | 9 ++ drivers/power/supply/cros_charge-control.c | 200 ++++++++++++---------------- drivers/power/supply/power_supply.h | 19 +++ drivers/power/supply/power_supply_core.c | 177 ++++++++++++++++++++++-- drivers/power/supply/power_supply_sysfs.c | 36 ++++- drivers/power/supply/test_power.c | 113 ++++++++++++++++ include/linux/power_supply.h | 35 +++++ 7 files changed, 467 insertions(+), 122 deletions(-) --- base-commit: 810dde9dad8222f3b831cf5179927fc66fc6a006 change-id: 20240602-power-supply-extensions-07d949f509d9 Best regards,