Linux Hardware Monitor development
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Antheas Kapenekakis <lkml@antheas.dev>,
	platform-driver-x86@vger.kernel.org
Cc: linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-pm@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>,
	Jean Delvare <jdelvare@suse.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Joaquin Ignacio Aramendia <samsagax@gmail.com>,
	Derek J Clark <derekjohn.clark@gmail.com>,
	Kevin Greenberg <kdgreenberg234@protonmail.com>,
	Joshua Tam <csinaction@pm.me>,
	Parth Menon <parthasarathymenon@gmail.com>,
	Eileen <eileen@one-netbook.com>
Subject: Re: [PATCH v4 05/13] power: supply: add inhibit-charge-s0 to charge_behaviour
Date: Mon, 17 Mar 2025 13:26:56 +0100	[thread overview]
Message-ID: <b1ac8a33-06ed-482a-b5f6-ca88eb3802a1@redhat.com> (raw)
In-Reply-To: <20250311165406.331046-6-lkml@antheas.dev>

Hi Antheas,

On 11-Mar-25 17:53, Antheas Kapenekakis wrote:
> OneXPlayer devices have a charge bypass

The term "charge bypass" is typically used for the case where the
external charger gets directly connected to the battery cells,
bypassing the charge-IC inside the device, in making
the external charger directly responsible for battery/charge
management.

Yet you name the feature inhibit charge, so I guess it simply
disables charging of the battery rather then doing an actual
chaerger-IC bypass ?

Assuming I have this correct, please stop using the term
charge-bypass as that has a specific (different) meaning.

> feature
> that allows the user to select between it being
> active always or only when the device is on.
> 
> Therefore, add attribute inhibit-charge-s0 to
> charge_behaviour to allow the user to select
> that bypass should only be on when the device is

Also don't use bypass here please.

> in the s0 state.
> 
> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com>
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> ---
>  Documentation/ABI/testing/sysfs-class-power | 11 ++++++-----
>  drivers/power/supply/power_supply_sysfs.c   |  1 +
>  drivers/power/supply/test_power.c           |  1 +
>  include/linux/power_supply.h                |  1 +
>  4 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power
> index 2a5c1a09a28f..4a187ca11f92 100644
> --- a/Documentation/ABI/testing/sysfs-class-power
> +++ b/Documentation/ABI/testing/sysfs-class-power
> @@ -508,11 +508,12 @@ Description:
>  		Access: Read, Write
>  
>  		Valid values:
> -			================ ====================================
> -			auto:            Charge normally, respect thresholds
> -			inhibit-charge:  Do not charge while AC is attached
> -			force-discharge: Force discharge while AC is attached
> -			================ ====================================
> +			================== =====================================
> +			auto:              Charge normally, respect thresholds
> +			inhibit-charge:    Do not charge while AC is attached
> +			inhibit-charge-s0: same as inhibit-charge but only in S0

Only in S0 suggests that charging gets disabled when the device is on / in-use,
I guess this is intended to avoid generating extra heat while the device is on?

What about when the device is suspended, should the battery charge then ?

On x86 we've 2 sorts of suspends S3, and the current name suggests that the
device will charge (no inhibit) then. But modern hw almost always uses
s0i3 / suspend to idle suspend and the name suggests charging would then
still be inhibited?

Also s0 is an ACPI specific term, so basically 2 remarks here:

1. The name should probably be "inhibit-charge-when-on" since the power_supply
   calls is platform agnositic and "S0" is not.

2. We need to clearly define what happens when the device is suspended and then
   make sure that the driver matches this (e.g. if we want to *not* inhibit during
   suspend we may need to turn this feature off during suspend).

Regards,

Hans



> +			force-discharge:   Force discharge while AC is attached
> +			================== =====================================
>  
>  What:		/sys/class/power_supply/<supply_name>/technology
>  Date:		May 2007
> diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c
> index edb058c19c9c..1a98fc26ce96 100644
> --- a/drivers/power/supply/power_supply_sysfs.c
> +++ b/drivers/power/supply/power_supply_sysfs.c
> @@ -140,6 +140,7 @@ static const char * const POWER_SUPPLY_SCOPE_TEXT[] = {
>  static const char * const POWER_SUPPLY_CHARGE_BEHAVIOUR_TEXT[] = {
>  	[POWER_SUPPLY_CHARGE_BEHAVIOUR_AUTO]		= "auto",
>  	[POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE]	= "inhibit-charge",
> +	[POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE_S0]	= "inhibit-charge-s0",
>  	[POWER_SUPPLY_CHARGE_BEHAVIOUR_FORCE_DISCHARGE]	= "force-discharge",
>  };
>  
> diff --git a/drivers/power/supply/test_power.c b/drivers/power/supply/test_power.c
> index 2a975a110f48..4bc5ab84a9d6 100644
> --- a/drivers/power/supply/test_power.c
> +++ b/drivers/power/supply/test_power.c
> @@ -214,6 +214,7 @@ static const struct power_supply_desc test_power_desc[] = {
>  		.property_is_writeable = test_power_battery_property_is_writeable,
>  		.charge_behaviours = BIT(POWER_SUPPLY_CHARGE_BEHAVIOUR_AUTO)
>  				   | BIT(POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE)
> +				   | BIT(POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE_S0)
>  				   | BIT(POWER_SUPPLY_CHARGE_BEHAVIOUR_FORCE_DISCHARGE),
>  	},
>  	[TEST_USB] = {
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 6ed53b292162..b1ca5e148759 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -212,6 +212,7 @@ enum power_supply_usb_type {
>  enum power_supply_charge_behaviour {
>  	POWER_SUPPLY_CHARGE_BEHAVIOUR_AUTO = 0,
>  	POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE,
> +	POWER_SUPPLY_CHARGE_BEHAVIOUR_INHIBIT_CHARGE_S0,
>  	POWER_SUPPLY_CHARGE_BEHAVIOUR_FORCE_DISCHARGE,
>  };
>  


  parent reply	other threads:[~2025-03-17 12:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-11 16:53 [PATCH v4 00/13] hwmon: (oxpsensors) Add devices, features, fix ABI and move to platform/x86 Antheas Kapenekakis
2025-03-11 16:53 ` [PATCH v4 01/13] hwmon: (oxp-sensors) Distinguish the X1 variants Antheas Kapenekakis
2025-03-11 16:53 ` [PATCH v4 02/13] hwmon: (oxp-sensors) Add all OneXFly variants Antheas Kapenekakis
2025-03-11 16:53 ` [PATCH v4 03/13] platform/x86: oxpec: Move hwmon/oxp-sensors to platform/x86 Antheas Kapenekakis
2025-03-11 16:53 ` [PATCH v4 04/13] ABI: testing: add tt_toggle and tt_led entries Antheas Kapenekakis
2025-03-11 16:53 ` [PATCH v4 05/13] power: supply: add inhibit-charge-s0 to charge_behaviour Antheas Kapenekakis
2025-03-16 11:40   ` Antheas Kapenekakis
2025-03-16 13:56     ` Guenter Roeck
2025-03-16 16:46       ` Antheas Kapenekakis
     [not found]         ` <CAFqHKTmYE+TYT9kpJXXoG0eZ36kJqrAfwQ397_7ssaYYsgh9KA@mail.gmail.com>
2025-03-16 17:03           ` Antheas Kapenekakis
2025-03-16 22:32         ` Guenter Roeck
2025-03-17 12:17         ` Hans de Goede
2025-03-17 12:26   ` Hans de Goede [this message]
2025-03-17 12:38     ` Antheas Kapenekakis
2025-03-17 13:31       ` Hans de Goede
2025-03-17 13:50         ` Antheas Kapenekakis
2025-03-17 14:03           ` Hans de Goede
2025-03-11 16:53 ` [PATCH v4 06/13] platform/x86: oxpec: Add charge threshold and behaviour to OneXPlayer Antheas Kapenekakis
2025-03-17 12:32   ` Hans de Goede
2025-03-17 12:40     ` Antheas Kapenekakis
2025-03-11 16:53 ` [PATCH v4 07/13] platform/x86: oxpec: Rename ec group to tt_toggle Antheas Kapenekakis
2025-03-11 16:54 ` [PATCH v4 08/13] platform/x86: oxpec: Add turbo led support to X1 devices Antheas Kapenekakis
2025-03-11 16:54 ` [PATCH v4 09/13] platform/x86: oxpec: Move pwm_enable read to its own function Antheas Kapenekakis
2025-03-11 16:54 ` [PATCH v4 10/13] platform/x86: oxpec: Move pwm value read/write to separate functions Antheas Kapenekakis
2025-03-11 16:54 ` [PATCH v4 11/13] platform/x86: oxpec: Move fan speed read to separate function Antheas Kapenekakis
2025-03-11 16:54 ` [PATCH v4 12/13] platform/x86: oxpec: Adhere to sysfs-class-hwmon and enable pwm on 2 Antheas Kapenekakis
2025-03-11 16:54 ` [PATCH v4 13/13] platform/x86: oxpec: Follow reverse xmas convention for tt_toggle Antheas Kapenekakis

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=b1ac8a33-06ed-482a-b5f6-ca88eb3802a1@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=corbet@lwn.net \
    --cc=csinaction@pm.me \
    --cc=derekjohn.clark@gmail.com \
    --cc=eileen@one-netbook.com \
    --cc=jdelvare@suse.com \
    --cc=kdgreenberg234@protonmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lkml@antheas.dev \
    --cc=parthasarathymenon@gmail.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=samsagax@gmail.com \
    /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