linux-kernel - Re: [PATCH v4 4/5] power: supply: add ChromeOS EC based charge control driver

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-prev] [day] [month] [year] [list]

Message-ID: <933f6510-2496-4ff9-af50-dd3ff35ddffd@t-8ch.de>
Date: Thu, 20 Jun 2024 22:34:28 +0200
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Sebastian Reichel <sebastian.reichel@...labora.com>
Cc: Benson Leung <bleung@...omium.org>, 
	Guenter Roeck <groeck@...omium.org>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Len Brown <lenb@...nel.org>, Robert Moore <robert.moore@...el.com>, 
	Tzung-Bi Shih <tzungbi@...nel.org>, chrome-platform@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	linux-pm@...r.kernel.org, Mario Limonciello <mario.limonciello@....com>, 
	Dustin Howett <dustin@...ett.net>, Stephen Horvath <s.horvath@...look.com.au>, 
	Rajas Paranjpe <paranjperajas@...il.com>, linux-acpi@...r.kernel.org, acpica-devel@...ts.linux.dev, 
	Matt Hartley <matt.hartley@...il.com>
Subject: Re: [PATCH v4 4/5] power: supply: add ChromeOS EC based charge
 control driver

Hi Sebastian,

On 2024-06-20 00:24:23+0000, Sebastian Reichel wrote:
> On Sun, Jun 16, 2024 at 09:03:32PM GMT, Thomas Weißschuh wrote:
> > The ChromeOS Embedded Controller implements a command to control charge
> > thresholds and behaviour.
> > 
> > Use it to implement the standard Linux charge_control_start_threshold,
> > charge_control_end_threshold and charge_behaviour sysfs UAPIs.
> > 
> > The driver is designed to be probed via the cros_ec mfd device.
> > 
> > Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
> > ---
> 
> Acked-by: Sebastian Reichel <sebastian.reichel@...labora.com>

Thanks!

<snip>

Would you also take a look at patch 5,
"power: supply: cros_charge-control: don't load if Framework control is present"?

I'm still wondering what the best solution for the two different EC APIs
would be. Maybe you have an idea?

In short:

Framework laptops have a downstream charge control API in their EC.
This drivers binds to the upstream CrOS EC APIs, which does work on
Framework laptops.
If the downstream API is used, it overrides the functionality of the
upstream API.

Choices I see:
* Ignore the incompatibility and just load the driver (maybe log something)
* Detect if the downstream API is actively used during probing
  (If enabled by UEFI) and either
  * don't load the driver
  * disable the current downstream API configuration, so the driver works
  * disable the downstream API and take over its configuration into the
    upstream driver
* Detect if the downstream API is present at all and don't load the
  driver (currently implemented)

The problem is that the downstream API is still usable and its usage
would break this driver.
On the other hand, disabling the driver forces users to manually specify
a kernel commandline, preventing most users from actually making use of it.

(For the future I plan on adapting the Framework EC firmware to avoid
this issue, but there is no telling how long it will take and if it is
accepted at all)

Thanks for any ideas,
Thomas