From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Benson Leung <bleung@chromium.org>,
Guenter Roeck <groeck@chromium.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
Robert Moore <robert.moore@intel.com>,
Tzung-Bi Shih <tzungbi@kernel.org>,
chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org,
Mario Limonciello <mario.limonciello@amd.com>,
Dustin Howett <dustin@howett.net>,
Stephen Horvath <s.horvath@outlook.com.au>,
Rajas Paranjpe <paranjperajas@gmail.com>,
linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev,
Matt Hartley <matt.hartley@gmail.com>
Subject: Re: [PATCH v4 4/5] power: supply: add ChromeOS EC based charge control driver
Date: Thu, 20 Jun 2024 22:34:28 +0200 [thread overview]
Message-ID: <933f6510-2496-4ff9-af50-dd3ff35ddffd@t-8ch.de> (raw)
In-Reply-To: <syoaiwmmxuz4ai6jomu42kvwocwozpzfbnjhvndlfqi6zkio4x@vrg6hle2httr>
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@weissschuh.net>
> > ---
>
> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.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
next prev parent reply other threads:[~2024-06-20 20:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-16 19:03 [PATCH v4 0/5] ChromeOS Embedded Controller " Thomas Weißschuh
2024-06-16 19:03 ` [PATCH v4 1/5] ACPI: battery: add devm_battery_hook_register() Thomas Weißschuh
2024-06-16 19:03 ` [PATCH v4 2/5] platform/chrome: Update binary interface for EC-based charge control Thomas Weißschuh
2024-06-16 19:03 ` [PATCH v4 3/5] platform/chrome: cros_ec_proto: Introduce cros_ec_get_cmd_versions() Thomas Weißschuh
2024-06-19 3:07 ` Tzung-Bi Shih
2024-06-16 19:03 ` [PATCH v4 4/5] power: supply: add ChromeOS EC based charge control driver Thomas Weißschuh
2024-06-19 22:24 ` Sebastian Reichel
2024-06-20 20:34 ` Thomas Weißschuh [this message]
2024-06-16 19:03 ` [PATCH v4 5/5] power: supply: cros_charge-control: don't load if Framework control is present Thomas Weißschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=933f6510-2496-4ff9-af50-dd3ff35ddffd@t-8ch.de \
--to=linux@weissschuh.net \
--cc=acpica-devel@lists.linux.dev \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=dustin@howett.net \
--cc=groeck@chromium.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=matt.hartley@gmail.com \
--cc=paranjperajas@gmail.com \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=s.horvath@outlook.com.au \
--cc=sebastian.reichel@collabora.com \
--cc=tzungbi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®