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

[Hans de Goede <hansg@kernel.org>]

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