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@xxxxxxxxxxxxxx>
> > ---
>
> Acked-by: Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx>
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
