Hi,
On 7/29/24 6:41 PM, Armin Wolf wrote:
> Am 29.07.24 um 12:02 schrieb Hans de Goede:
>
>> Hi,
>>
>> On 7/20/24 7:22 AM, Andres Salomon wrote:
>>> The Dell BIOS allows you to set custom charging modes, which is useful
>>> in particular for extending battery life. This adds support for tweaking
>>> those various settings from Linux via sysfs knobs. One might, for
>>> example, have their laptop plugged into power at their desk the vast
>>> majority of the time and choose fairly aggressive battery-saving
>>> settings (only charging once the battery drops to 50% and only charging
>>> up to 80%). When leaving for a trip, they might want to switch those
>>> settings to charge to 100% and charge any time power is available;
>>> rebooting into the BIOS to change those settings is a hassle.
>>>
>>> For the Custom charging type mode, we reuse the common
>>> charge_control_{start,end}_threshold sysfs power_supply entries. The
>>> BIOS also has a bunch of other charging modes with varying levels of
>>> usefulness, so this adds a new Dell-specific sysfs entry called
>>> 'charge_type' that's documented in sysfs-class-power-dell (and looks a
>>> lot like sysfs-class-power-wilco).
>>>
>>> This work is based on a patch by Perry Yuan <perry_yuan@xxxxxxxx> and
>>> Limonciello Mario <Mario_Limonciello@xxxxxxxx> submitted back in 2020:
>>> https://lore.kernel.org/all/20200729065424.12851-1-Perry_Yuan@xxxxxxxx/
>>> Both of their email addresses bounce, so I'm assuming they're no longer
>>> with the company. I've reworked most of the patch to make it smaller and
>>> cleaner.
>>>
>>> Signed-off-by: Andres Salomon <dilinger@xxxxxxxxxx>
>> Thank you for working on this and it is great to see the discussion
>> to improve the code between you and Pali going on.
>>
>> One concern which I have is that work is underway for both upower
>> and GNOME to add support for
>> /sys/class/power_supply/*/charge_[start|stop]_threshold
>>
>> to gnome-control-center.
>>
>> But if I understand things correctly then these limits will only
>> be honored when the charging-type is set to custom.
>>
>> So we need to do something to avoid userspace exposing those
>> controls when the charging-type is not custom.
>>
>> I think it would be best to not have the charge_[start|stop]_threshold
>> attributes visible when the charging mode is not custom.
>>
>> Regards,
>>
>> Hans
>
> Hi,
>
> the documentation of the "charge_type" sysfs attribute states that:
>
> "Custom" means that the charger uses the charge_control_* properties as
> configuration for some different algorithm.
>
> So i believe that "charge_[start|stop]_threshold" attributes should not be unregistered
> if "charge_type" is not "Custom" because:
>
> 1. The power supply subsystem does not allow that for power supplies, and i see little
> reason to deviate from this behavior here.
>
> 2. It is the responsibility of userspace to also set "charge_type" to "Custom" when using
> the "charge_[start|stop]_threshold" attributes.
>
> Maybe we could clarify what happens when "charge_[start|stop]_threshold" is written without
> "charge_type" being "Custom". This might help userspace to correctly switch to custom charging
> and set the charging thresholds.
>
> Basically, we could define that writes to "charge_[start|stop]_threshold" will get buffered by
> the driver if two conditions are met:
>
> 1. "charge_type" is not "Custom".
>
> 2. The hardware does not support setting the charging thresholds when "charge_type" is not "Custom".
>
> Userspace can then first set "charge_[start|stop]_threshold" and then switch to custom charging.
> This prevents any problems should the hardware have no default value for the charging thresholds
> when switching to custom charging for the first time.
Ah I did not realize this was already documented in this way. Yes if this is
already documented this way then the driver does not have to do anything.
Instead userspace consumers of the "charge_[start|stop]_threshold" user should
check (and if necessary / if they want to set) "charge_type" = "Custom" on
power_supply class devices which have a charge_type.
Regards,
Hans
