[RFC] HP laptop charge mode control via POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR

[RFC] HP laptop charge mode control via POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR

[Navon John Lukose]

Hi,

I have been looking at battery charge control on an HP laptop, and I would like
to check the right upstream direction before preparing a patch.

This is not a new userspace ABI. The kernel already has
POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR, and some existing drivers expose charge
modes without exposing charge thresholds. I am trying to confirm whether that is
the right interface for this HP firmware interface, and where the implementation
should live.

On this machine, Linux currently exposes no native battery charge thresholds:

  - no charge_control_start_threshold
  - no charge_control_end_threshold

The existing HP kernel drivers also do not expose this feature here:

  - hp-wmi does not expose battery charge mode control
  - hp-bioscfg is present, but does not expose Battery Health Manager or related
    battery threshold attributes on this machine

However, the firmware exposes working ACPI methods for charge mode control:

  - \SBCC 0x0000 -> normal charging / auto
  - \SBCO 0x0500 -> inhibit charge
  - \SBCO 0x0200 -> force discharge while on AC

These mappings have been tested from Linux by observing battery and adapter
state transitions:

  - auto allows normal charging
  - inhibit-charge leaves AC online and reports Not charging / zero current
  - force-discharge makes the battery path discharge while AC is connected

My current thinking is:

  - expose only POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR
  - support AUTO, INHIBIT_CHARGE, and FORCE_DISCHARGE
  - do not synthesize charge_control_*_threshold properties in the kernel
  - leave policies such as "resume below 75%, stop above 80%" to userspace

For driver placement, this seems HP-specific rather than generic power-supply
logic, so I think it should probably live under drivers/platform/x86/hp/ and
register a power_supply extension on the battery, similar to other platform
drivers that use power_supply_register_extension() from a battery hook.

Does that sound like the right direction?

In particular:

  1. Is POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR the right ABI for an HP platform that
     appears to expose only mode-based charging control?

  2. Should this be implemented as part of an existing HP driver such as hp-wmi,
     or as a small new HP-specific driver under drivers/platform/x86/hp/?

  3. What should the driver gate support on? For example, should this be gated
     by DMI quirks, HP WMI/BIOS GUID presence, ACPI method presence, or some
     combination of those?

Thanks,
Navon John Lukose

Re: [RFC] HP laptop charge mode control via POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR

[Hans de Goede]

Hi,

On 27-Apr-26 16:08, Navon John Lukose wrote:
> Hi,
> 
> I have been looking at battery charge control on an HP laptop, and I would like
> to check the right upstream direction before preparing a patch.
> 
> This is not a new userspace ABI. The kernel already has
> POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR, and some existing drivers expose charge
> modes without exposing charge thresholds. I am trying to confirm whether that is
> the right interface for this HP firmware interface, and where the implementation
> should live.
> 
> On this machine, Linux currently exposes no native battery charge thresholds:
> 
>   - no charge_control_start_threshold
>   - no charge_control_end_threshold
> 
> The existing HP kernel drivers also do not expose this feature here:
> 
>   - hp-wmi does not expose battery charge mode control
>   - hp-bioscfg is present, but does not expose Battery Health Manager or related
>     battery threshold attributes on this machine
> 
> However, the firmware exposes working ACPI methods for charge mode control:
> 
>   - \SBCC 0x0000 -> normal charging / auto
>   - \SBCO 0x0500 -> inhibit charge
>   - \SBCO 0x0200 -> force discharge while on AC
> 
> These mappings have been tested from Linux by observing battery and adapter
> state transitions:
> 
>   - auto allows normal charging
>   - inhibit-charge leaves AC online and reports Not charging / zero current
>   - force-discharge makes the battery path discharge while AC is connected
> 
> My current thinking is:
> 
>   - expose only POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR
>   - support AUTO, INHIBIT_CHARGE, and FORCE_DISCHARGE
>   - do not synthesize charge_control_*_threshold properties in the kernel
>   - leave policies such as "resume below 75%, stop above 80%" to userspace
> 
> For driver placement, this seems HP-specific rather than generic power-supply
> logic, so I think it should probably live under drivers/platform/x86/hp/ and
> register a power_supply extension on the battery, similar to other platform
> drivers that use power_supply_register_extension() from a battery hook.
> 
> Does that sound like the right direction?
> 
> In particular:
> 
>   1. Is POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR the right ABI for an HP platform that
>      appears to expose only mode-based charging control?

Yes, POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR was initially added for basically
the same settings on Lenovo ThinkPad laptops. Note these options are typically
used to implement battery "fuel-gauge" calibration functionality.

I guess inhibit charge could be used together with a userspace daemon
monitoring charge to implement a charge to 80% threshold. But that would be
a new way to use this API. Note I'm not saying it would be a wrong use,
just a new use.

>   2. Should this be implemented as part of an existing HP driver such as hp-wmi,
>      or as a small new HP-specific driver under drivers/platform/x86/hp/?

Is there a WMI object which will call 

>   - \SBCC 0x0000 -> normal charging / auto
>   - \SBCO 0x0500 -> inhibit charge
>   - \SBCO 0x0200 -> force discharge while on AC

when its control method is called with certain arguments ?  Typically
the answer to this will be yes, in which case you really should go
through that WMI object, so as to support more models where the
method names / args may be different.

>   3. What should the driver gate support on? For example, should this be gated
>      by DMI quirks, HP WMI/BIOS GUID presence, ACPI method presence, or some
>      combination of those?

That is a good question, if you can figure out how to access these methods
through some WMI object then doing so should be safe on any model with
that WMI object.  But firmware bugs do happen, so we may need some
heuristics on top of relying on the WMI object GUID.

Regards,

Hans

Re: [RFC] HP laptop charge mode control via POWER_SUPPLY_PROP_CHARGE_BEHAVIOUR

[Navon John Lukose]

Hi Hans,

Thanks, that was the right hint. The path from the EC to ACPI methods to WMI
has been fun to trace, and I learned quite a bit.

I checked the WMI path, and the charge methods are reachable through the
existing HP BIOS WMI GUID:

  5FB7F034-2C63-45E9-BE91-3D44E2C707E4

The _WDG entry exposes object "AA" as a method. In this firmware that maps to:

  \_SB.WMID.WMAA

and WMAA calls:

  \_SB.WMID.WHCM(Arg1, Arg2)

Inside WHCM, the command dispatch maps the charge-control methods like this:

  read  commandtype 0x1f -> \GBCC()
  read  commandtype 0x2b -> \GBCO()
  write commandtype 0x1f -> \SBCC(DDWD)
  write commandtype 0x2b -> \SBCO(DDWD)

Calling the WMI wrapper for the three modes works as expected:

  \SBCC 0x0000 -> normal charging / auto
  \SBCO 0x0500 -> inhibit charge
  \SBCO 0x0200 -> force discharge while on AC

So the raw ACPI methods do not need to be called directly; the existing HP BIOS
WMI transport reaches them.

Given that, I think the implementation can use hp_wmi_perform_query() with the
existing HPWMI_BIOS_GUID.

I am still unsure about where to put it. The smallest patch would be to add the
power_supply extension code directly to hp-wmi.c, but that file currently does
not have any battery-specific code paths. Should I add it to hp-wmi.c, add a
small HP-specific file under drivers/platform/x86/hp/, or is there another file
I missed?

Thanks,
Navon