From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Armin Wolf <W_Armin@gmx.de>
Cc: Hans de Goede <hansg@kernel.org>,
wse@tuxedocomputers.com, platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/7] platform/x86: uniwill-laptop: Properly initialize charging threshold
Date: Wed, 6 May 2026 16:42:08 +0300 (EEST) [thread overview]
Message-ID: <4766afa5-4128-a9fc-0792-b83e2fb48e6e@linux.intel.com> (raw)
In-Reply-To: <903a013e-a3fb-49ea-a6f9-ad6577d57a44@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]
On Sun, 3 May 2026, Armin Wolf wrote:
> Am 30.04.26 um 14:53 schrieb Ilpo Järvinen:
> > On Fri, 17 Apr 2026, Armin Wolf wrote:
> >
> > > The EC might initialize the charge threshold with 0 to signal that
> > > said threshold is uninitialized. Detect this and replace said value
> > > with 100 to signal the EC that we want to take control of battery
> > > charging. Also set the threshold to 100 if the EC-provided value
> > > is invalid.
> > >
> > > Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver")
> > > Reviewed-by: Werner Sembach <wse@tuxedocomputers.com>
> > > Signed-off-by: Armin Wolf <W_Armin@gmx.de>
> > > ---
> > > drivers/platform/x86/uniwill/uniwill-acpi.c | 28 ++++++++++++++++++++-
> > > 1 file changed, 27 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c
> > > b/drivers/platform/x86/uniwill/uniwill-acpi.c
> > > index faade4cf08be..8f16c94221aa 100644
> > > --- a/drivers/platform/x86/uniwill/uniwill-acpi.c
> > > +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c
> > > @@ -1404,7 +1404,12 @@ static int uniwill_get_property(struct power_supply
> > > *psy, const struct power_sup
> > > if (ret < 0)
> > > return ret;
> > > - val->intval = clamp_val(FIELD_GET(CHARGE_CTRL_MASK, regval),
> > > 0, 100);
> > > + regval = FIELD_GET(CHARGE_CTRL_MASK, regval);
> > > + if (!regval)
> > > + val->intval = 100;
> > > + else
> > > + val->intval = min(regval, 100);
> >
> > ...
> >
> > > + /*
> > > + * The charge control threshold might be initialized with 0 by
> > > + * the EC to signal that said threshold is uninitialized. We thus
> > > + * need to replace this value with 100 to signal that we want to
> > > + * take control of battery charging. For the sake of completeness
> > > + * we also set the charging threshold to 100 if the EC-provided
> > > + * value is invalid.
> > > + */
> > > + threshold = FIELD_GET(CHARGE_CTRL_MASK, value);
> > > + if (threshold == 0 || threshold > 100) {
> > > + FIELD_MODIFY(CHARGE_CTRL_MASK, &value, 100);
> >
> > AFAICT, this does exactly the same thing as the other code above (but
> > looks very different on surface). Wouldn't it make sense to have them
> > share code?
>
> I do not think that this would be a good idea. The two call sides are two
> different, creating a helper function for both would likely be very
> difficult.
Both seem to be sanitizing the charge control threshold (AFAICT, both map
0 and out-of-range values to 100) isn't that the case? Why cannot we have
uniwill_charge_ctrl_thres_sanitize() or something along those lines?
--
i.
next prev parent reply other threads:[~2026-05-06 13:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 5:09 [PATCH v2 0/7] platform/x86: uniwill-laptop: Charging-related improvements Armin Wolf
2026-04-17 5:09 ` [PATCH v2 1/7] platform/x86: uniwill-laptop: Properly initialize charging threshold Armin Wolf
2026-04-30 12:53 ` Ilpo Järvinen
2026-05-03 21:34 ` Armin Wolf
2026-05-06 13:42 ` Ilpo Järvinen [this message]
2026-05-12 23:22 ` Armin Wolf
2026-04-17 5:09 ` [PATCH v2 2/7] platform/x86: uniwill-laptop: Accept charging threshold of 0 Armin Wolf
2026-04-30 12:55 ` Ilpo Järvinen
2026-04-17 5:09 ` [PATCH v2 3/7] platform/x86: uniwill-laptop: Fix behavior of "force" module param Armin Wolf
2026-04-17 12:01 ` Werner Sembach
2026-04-30 12:57 ` Ilpo Järvinen
2026-04-17 5:09 ` [PATCH v2 4/7] platform/x86: uniwill-laptop: Do not enable the charging limit even when forced Armin Wolf
2026-04-17 12:01 ` Werner Sembach
2026-04-30 12:57 ` Ilpo Järvinen
2026-04-17 5:09 ` [PATCH v2 5/7] platform/x86: uniwill-laptop: Rework FN lock/super key suspend handling Armin Wolf
2026-04-30 13:11 ` Ilpo Järvinen
2026-04-17 5:09 ` [PATCH v2 6/7] platform/x86: uniwill-laptop: Mark EC_ADDR_OEM_4 as volatile Armin Wolf
2026-04-30 13:13 ` Ilpo Järvinen
2026-04-17 5:09 ` [PATCH v2 7/7] platform/x86: uniwill-laptop: Add support for battery charge modes Armin Wolf
2026-04-20 20:03 ` Werner Sembach
2026-04-30 13:22 ` Ilpo Järvinen
2026-04-30 13:41 ` Armin Wolf
2026-05-04 8:44 ` Werner Sembach
2026-05-06 7:47 ` Armin Wolf
2026-05-11 17:40 ` Werner Sembach
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=4766afa5-4128-a9fc-0792-b83e2fb48e6e@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=W_Armin@gmx.de \
--cc=hansg@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=wse@tuxedocomputers.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.