linux-kernel - power_supply cooling interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <164f2458-fb66-f238-7143-bdbe1e200870@linaro.org>
Date:   Wed, 6 Jul 2022 13:54:55 +0100
From:   Caleb Connolly <caleb.connolly@...aro.org>
To:     Sebastian Reichel <sre@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Amit Kucheria <amitk@...nel.org>,
        Zhang Rui <rui.zhang@...el.com>, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: power_supply cooling interface

Hi,

I've been working on a driver for the charger found in most Snapdragon 845 
phones (the OnePlus 6, SHIFT6mq, PocoPhone F1, etc). I wanted to include support 
for the POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT property.

My understanding is that it exposes the current limit as a cooling device so 
that userspace (or frameworks like DTPM) can optimise for performance in a 
thermally constrained device by limiting the input current and thus reducing the 
heat generated by the charger circuitry, a similar idea was applied on the Pixel C:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4496d52b3430cb3c4c16d03cdd5f4ee97ad1241

However, reading through the sysfs docs for cooling devices, and looking at the 
implementation in power_supply_core.c, it seems like the behavior here is wrong 
in a few ways:
  1. The values should scale from 0: no cooling to max_state: max cooling, but 
the power_supply docs and the only existing implementation (the smbb driver) 
just export the current_limit, such that increasing cur_state would increase the 
current limit, not decrease it.
  2. (unsure?)The scale is completely different to most other cooling devices, 
most cooling devices don't seem to have a max state much beyond the double 
digits, but CHARGE_CONTROL_LIMIT is on the scale of uA, so approaches like 
incrementing the cooling state by 1 don't really work.
  3. The value exposed is current, not power, making it tricky for something 
like the DTPM framework to make good use of it, and making it harder to 
correlate a particular "amount" of cooling with a change in thermal headroom.

I don't really know what the right approach is here, one idea might be to have 
the power_supply cooling device implementation try and be more intelligent. 
Scaling based on the power rather than current and exposing some smaller range 
so that at maximum cooling the device doesn't just stop charging entirely 
(unless we've hit some thermal trip?).

Maybe a way to determine the amount of thermal headroom you can expect by 
adjusting the current limit on a particular charger / device like a power 
efficiency curve might be useful too, although gathering that data might be 
difficult to do.

I'll include the POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT and 
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX properties in my driver, as the 
maximum current allowed and whatever the maximum is right now.

-- 
Kind Regards,
Caleb (they/he)