All of lore.kernel.org
 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 [PATCH v6 0/4] power: supply: extension API 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.