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(-)
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,
--
Thomas Weißschuh <linux@weissschuh.net>
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!
[4/4] power: supply: core: add UAPI to discover currently used extensions
commit: 288a2cabcf6bb35532e8b2708829bdc2b85bc690
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
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,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
© 2016 - 2025 Red Hat, Inc.