mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: "Thomas Weißschuh" <linux@weissschuh.net>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Thomas Weißschuh" <thomas@weissschuh.net>,
	"Benson Leung" <bleung@chromium.org>,
	"Guenter Roeck" <groeck@chromium.org>
Cc: linux-kernel@vger.kernel.org, chrome-platform@lists.linux.dev,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH v6 0/4] power: supply: extension API
Date: Thu, 12 Dec 2024 15:27:52 +0100	[thread overview]
Message-ID: <2e2f4845-7500-40ec-985d-3a495842e020@gmx.de> (raw)
In-Reply-To: <20241211-power-supply-extensions-v6-0-9d9dc3f3d387@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,

  parent reply	other threads:[~2024-12-12 14:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-11 19:57 Thomas Weißschuh
2024-12-11 19:57 ` [PATCH v6 1/4] power: supply: core: implement " Thomas Weißschuh
2024-12-13 22:48   ` Armin Wolf
2024-12-11 19:57 ` [PATCH v6 2/4] power: supply: test-power: implement a power supply extension Thomas Weißschuh
2024-12-11 19:57 ` [PATCH v6 3/4] power: supply: cros_charge-control: " Thomas Weißschuh
2024-12-11 19:57 ` [PATCH v6 4/4] power: supply: core: add UAPI to discover currently used extensions Thomas Weißschuh
2024-12-13 22:50   ` Armin Wolf
2024-12-14  7:53   ` Thomas Weißschuh
2024-12-18 19:52   ` Nathan Chancellor
2024-12-18 20:29     ` Thomas Weißschuh
2024-12-18 22:11       ` Sebastian Reichel
2024-12-18 22:16         ` Thomas Weißschuh
2024-12-18 22:46           ` Sebastian Reichel
2024-12-12 14:27 ` Armin Wolf [this message]
2024-12-13 21:00   ` [PATCH v6 0/4] power: supply: extension API Thomas Weißschuh
2024-12-14  3:26 ` (subset) " Sebastian Reichel
2024-12-14 22:04 ` Sebastian Reichel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2e2f4845-7500-40ec-985d-3a495842e020@gmx.de \
    --to=w_armin@gmx.de \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=groeck@chromium.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=sre@kernel.org \
    --cc=thomas@weissschuh.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®