* [PATCH 0/6] platform/x86: uniwill-laptop: Charging-related improvements
@ 2026-04-06 19:36 Armin Wolf
2026-04-06 19:36 ` [PATCH 1/6] platform/x86: uniwill-laptop: Properly initialize charging threshold Armin Wolf
` (5 more replies)
0 siblings, 6 replies; 22+ messages in thread
From: Armin Wolf @ 2026-04-06 19:36 UTC (permalink / raw)
To: hansg, ilpo.jarvinen; +Cc: wse, platform-driver-x86, linux-kernel
This patch series contains various charging-related improvements
for the uniwill-laptop driver. The first two patches fix some minor
issues inside the charging threshold code, while the third patch
fixes an issue inside the module initialization code. The next two
patches contain some preparations for the last patch. Said patch
introduces support for controlling the charging modes available
on many Uniwill-based devices not sold by Intel.
All patches have been tested on a Tuxedo InfinityBook Pro 15 Gen10 AMD
and work just fine.
Armin Wolf (6):
platform/x86: uniwill-laptop: Properly initialize charging threshold
platform/x86: uniwill-laptop: Accept charging threshold of 0
platform/x86: uniwill-laptop: Fix behavior of "force" module param
platform/x86: uniwill-laptop: Rework FN lock/super key suspend
handling
platform/x86: uniwill-laptop: Mark EC_ADDR_OEM_4 as volatile
platform/x86: uniwill-laptop: Add support for battery charge modes
.../admin-guide/laptops/uniwill-laptop.rst | 25 +-
drivers/platform/x86/uniwill/uniwill-acpi.c | 431 ++++++++++++++----
drivers/platform/x86/uniwill/uniwill-wmi.c | 5 +-
3 files changed, 374 insertions(+), 87 deletions(-)
--
2.39.5
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 1/6] platform/x86: uniwill-laptop: Properly initialize charging threshold 2026-04-06 19:36 [PATCH 0/6] platform/x86: uniwill-laptop: Charging-related improvements Armin Wolf @ 2026-04-06 19:36 ` Armin Wolf 2026-04-08 22:59 ` Werner Sembach 2026-04-06 19:36 ` [PATCH 2/6] platform/x86: uniwill-laptop: Accept charging threshold of 0 Armin Wolf ` (4 subsequent siblings) 5 siblings, 1 reply; 22+ messages in thread From: Armin Wolf @ 2026-04-06 19:36 UTC (permalink / raw) To: hansg, ilpo.jarvinen; +Cc: wse, platform-driver-x86, linux-kernel 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") 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); + return 0; default: return -EINVAL; @@ -1499,11 +1504,32 @@ static int uniwill_remove_battery(struct power_supply *battery, struct acpi_batt static int uniwill_battery_init(struct uniwill_data *data) { + unsigned int value, threshold; int ret; if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) return 0; + ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); + if (ret < 0) + return ret; + + /* + * 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); + ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); + if (ret < 0) + return ret; + } + ret = devm_mutex_init(data->dev, &data->battery_lock); if (ret < 0) return ret; -- 2.39.5 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/6] platform/x86: uniwill-laptop: Properly initialize charging threshold 2026-04-06 19:36 ` [PATCH 1/6] platform/x86: uniwill-laptop: Properly initialize charging threshold Armin Wolf @ 2026-04-08 22:59 ` Werner Sembach 2026-04-10 17:27 ` Armin Wolf 0 siblings, 1 reply; 22+ messages in thread From: Werner Sembach @ 2026-04-08 22:59 UTC (permalink / raw) To: Armin Wolf, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 06.04.26 um 21:36 schrieb Armin Wolf: > 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") > 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) personal preference: explicitly compair to the uninitialized-value "0" with == for better readability, but don't know if that is the normal coding style for the kernel > + val->intval = 100; > + else > + val->intval = min(regval, 100); > + We silently correct invalid values here. Wouldn't it be better to detect that something is off? > return 0; > default: > return -EINVAL; > @@ -1499,11 +1504,32 @@ static int uniwill_remove_battery(struct power_supply *battery, struct acpi_batt > > static int uniwill_battery_init(struct uniwill_data *data) > { > + unsigned int value, threshold; > int ret; > > if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) > return 0; > > + ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); > + if (ret < 0) > + return ret; > + > + /* > + * 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); > + ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); > + if (ret < 0) > + return ret; > + } > + > ret = devm_mutex_init(data->dev, &data->battery_lock); > if (ret < 0) > return ret; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/6] platform/x86: uniwill-laptop: Properly initialize charging threshold 2026-04-08 22:59 ` Werner Sembach @ 2026-04-10 17:27 ` Armin Wolf 2026-04-10 20:26 ` Werner Sembach 0 siblings, 1 reply; 22+ messages in thread From: Armin Wolf @ 2026-04-10 17:27 UTC (permalink / raw) To: Werner Sembach, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 09.04.26 um 00:59 schrieb Werner Sembach: > > Am 06.04.26 um 21:36 schrieb Armin Wolf: >> 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") >> 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) > personal preference: explicitly compair to the uninitialized-value "0" > with == for better readability, but don't know if that is the normal > coding style for the kernel Hi, AFAIK the default kernel coding style encourages people to write NULL/0 checks as !value. However i am not sure if this only applies to NULL checks. Ilpo, what is your preference in this case? >> + val->intval = 100; >> + else >> + val->intval = min(regval, 100); >> + > We silently correct invalid values here. Wouldn't it be better to > detect that something is off? The ACPI code on my device suggests that values equal to or larger than 100 will be interpreted as "charging limit is disabled", so i think we should replicate this assumption inside the driver. Thanks, Armin Wolf >> return 0; >> default: >> return -EINVAL; >> @@ -1499,11 +1504,32 @@ static int uniwill_remove_battery(struct >> power_supply *battery, struct acpi_batt >> static int uniwill_battery_init(struct uniwill_data *data) >> { >> + unsigned int value, threshold; >> int ret; >> if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >> return 0; >> + ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); >> + if (ret < 0) >> + return ret; >> + >> + /* >> + * 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); >> + ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); >> + if (ret < 0) >> + return ret; >> + } >> + >> ret = devm_mutex_init(data->dev, &data->battery_lock); >> if (ret < 0) >> return ret; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/6] platform/x86: uniwill-laptop: Properly initialize charging threshold 2026-04-10 17:27 ` Armin Wolf @ 2026-04-10 20:26 ` Werner Sembach 0 siblings, 0 replies; 22+ messages in thread From: Werner Sembach @ 2026-04-10 20:26 UTC (permalink / raw) To: Armin Wolf, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 10.04.26 um 19:27 schrieb Armin Wolf: > Am 09.04.26 um 00:59 schrieb Werner Sembach: > >> >> Am 06.04.26 um 21:36 schrieb Armin Wolf: >>> 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") >>> 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) >> personal preference: explicitly compair to the uninitialized-value "0" with >> == for better readability, but don't know if that is the normal coding style >> for the kernel > > Hi, > > AFAIK the default kernel coding style encourages people to write NULL/0 checks > as !value. However i am not sure > if this only applies to NULL checks. Ilpo, what is your preference in this case? ok > >>> + val->intval = 100; >>> + else >>> + val->intval = min(regval, 100); >>> + >> We silently correct invalid values here. Wouldn't it be better to detect that >> something is off? > > The ACPI code on my device suggests that values equal to or larger than 100 > will be interpreted as > "charging limit is disabled", so i think we should replicate this assumption > inside the driver. ok then: Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> > > Thanks, > Armin Wolf > >>> return 0; >>> default: >>> return -EINVAL; >>> @@ -1499,11 +1504,32 @@ static int uniwill_remove_battery(struct >>> power_supply *battery, struct acpi_batt >>> static int uniwill_battery_init(struct uniwill_data *data) >>> { >>> + unsigned int value, threshold; >>> int ret; >>> if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >>> return 0; >>> + ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); >>> + if (ret < 0) >>> + return ret; >>> + >>> + /* >>> + * 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); >>> + ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); >>> + if (ret < 0) >>> + return ret; >>> + } >>> + >>> ret = devm_mutex_init(data->dev, &data->battery_lock); >>> if (ret < 0) >>> return ret; ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 2/6] platform/x86: uniwill-laptop: Accept charging threshold of 0 2026-04-06 19:36 [PATCH 0/6] platform/x86: uniwill-laptop: Charging-related improvements Armin Wolf 2026-04-06 19:36 ` [PATCH 1/6] platform/x86: uniwill-laptop: Properly initialize charging threshold Armin Wolf @ 2026-04-06 19:36 ` Armin Wolf 2026-04-08 23:01 ` Werner Sembach 2026-04-06 19:36 ` [PATCH 3/6] platform/x86: uniwill-laptop: Fix behavior of "force" module param Armin Wolf ` (3 subsequent siblings) 5 siblings, 1 reply; 22+ messages in thread From: Armin Wolf @ 2026-04-06 19:36 UTC (permalink / raw) To: hansg, ilpo.jarvinen; +Cc: wse, platform-driver-x86, linux-kernel The power supply sysfs ABI states that: Not all hardware is capable of setting this to an arbitrary percentage. Drivers will round written values to the nearest supported value. Reading back the value will show the actual threshold set by the driver. The driver currently violates this ABI by rejecting a charging threshold of 0. Fix this by clamping this value to 1. Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") Signed-off-by: Armin Wolf <W_Armin@gmx.de> --- drivers/platform/x86/uniwill/uniwill-acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c index 8f16c94221aa..5551f193c2c1 100644 --- a/drivers/platform/x86/uniwill/uniwill-acpi.c +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c @@ -1424,11 +1424,11 @@ static int uniwill_set_property(struct power_supply *psy, const struct power_sup switch (psp) { case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: - if (val->intval < 1 || val->intval > 100) + if (val->intval < 0 || val->intval > 100) return -EINVAL; return regmap_update_bits(data->regmap, EC_ADDR_CHARGE_CTRL, CHARGE_CTRL_MASK, - val->intval); + max(val->intval, 1)); default: return -EINVAL; } -- 2.39.5 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/6] platform/x86: uniwill-laptop: Accept charging threshold of 0 2026-04-06 19:36 ` [PATCH 2/6] platform/x86: uniwill-laptop: Accept charging threshold of 0 Armin Wolf @ 2026-04-08 23:01 ` Werner Sembach 0 siblings, 0 replies; 22+ messages in thread From: Werner Sembach @ 2026-04-08 23:01 UTC (permalink / raw) To: Armin Wolf, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 06.04.26 um 21:36 schrieb Armin Wolf: > The power supply sysfs ABI states that: > > Not all hardware is capable of setting this to an arbitrary > percentage. Drivers will round written values to the nearest > supported value. Reading back the value will show the actual > threshold set by the driver. > > The driver currently violates this ABI by rejecting a charging > threshold of 0. Fix this by clamping this value to 1. > > Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") > Signed-off-by: Armin Wolf <W_Armin@gmx.de> > --- > drivers/platform/x86/uniwill/uniwill-acpi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c > index 8f16c94221aa..5551f193c2c1 100644 > --- a/drivers/platform/x86/uniwill/uniwill-acpi.c > +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c > @@ -1424,11 +1424,11 @@ static int uniwill_set_property(struct power_supply *psy, const struct power_sup > > switch (psp) { > case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: > - if (val->intval < 1 || val->intval > 100) > + if (val->intval < 0 || val->intval > 100) > return -EINVAL; > > return regmap_update_bits(data->regmap, EC_ADDR_CHARGE_CTRL, CHARGE_CTRL_MASK, > - val->intval); > + max(val->intval, 1)); looks good Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> > default: > return -EINVAL; > } ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 3/6] platform/x86: uniwill-laptop: Fix behavior of "force" module param 2026-04-06 19:36 [PATCH 0/6] platform/x86: uniwill-laptop: Charging-related improvements Armin Wolf 2026-04-06 19:36 ` [PATCH 1/6] platform/x86: uniwill-laptop: Properly initialize charging threshold Armin Wolf 2026-04-06 19:36 ` [PATCH 2/6] platform/x86: uniwill-laptop: Accept charging threshold of 0 Armin Wolf @ 2026-04-06 19:36 ` Armin Wolf 2026-04-08 23:08 ` Werner Sembach 2026-04-06 19:36 ` [PATCH 4/6] platform/x86: uniwill-laptop: Rework FN lock/super key suspend handling Armin Wolf ` (2 subsequent siblings) 5 siblings, 1 reply; 22+ messages in thread From: Armin Wolf @ 2026-04-06 19:36 UTC (permalink / raw) To: hansg, ilpo.jarvinen; +Cc: wse, platform-driver-x86, linux-kernel Users might want to force-enable all possible features even on machines with a valid device descriptor. Until now the "force" module param was ignored on such machines. Fix this to make it easier to test for support of new features. Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") Signed-off-by: Armin Wolf <W_Armin@gmx.de> --- drivers/platform/x86/uniwill/uniwill-acpi.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c index 5551f193c2c1..7c7ea0e76966 100644 --- a/drivers/platform/x86/uniwill/uniwill-acpi.c +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c @@ -2481,8 +2481,6 @@ static int __init uniwill_init(void) if (!force) return -ENODEV; - /* Assume that the device supports all features */ - device_descriptor.features = UINT_MAX; pr_warn("Loading on a potentially unsupported device\n"); } else { /* @@ -2500,6 +2498,12 @@ static int __init uniwill_init(void) device_descriptor = *descriptor; } + if (force) { + /* Assume that the device supports all features */ + device_descriptor.features = UINT_MAX; + pr_warn("Enabling potentially unsupported features\n"); + } + ret = platform_driver_register(&uniwill_driver); if (ret < 0) return ret; -- 2.39.5 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] platform/x86: uniwill-laptop: Fix behavior of "force" module param 2026-04-06 19:36 ` [PATCH 3/6] platform/x86: uniwill-laptop: Fix behavior of "force" module param Armin Wolf @ 2026-04-08 23:08 ` Werner Sembach 2026-04-10 17:32 ` Armin Wolf 0 siblings, 1 reply; 22+ messages in thread From: Werner Sembach @ 2026-04-08 23:08 UTC (permalink / raw) To: Armin Wolf, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 06.04.26 um 21:36 schrieb Armin Wolf: > Users might want to force-enable all possible features even on > machines with a valid device descriptor. Until now the "force" > module param was ignored on such machines. Fix this to make > it easier to test for support of new features. > > Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") > Signed-off-by: Armin Wolf <W_Armin@gmx.de> > --- > drivers/platform/x86/uniwill/uniwill-acpi.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c > index 5551f193c2c1..7c7ea0e76966 100644 > --- a/drivers/platform/x86/uniwill/uniwill-acpi.c > +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c > @@ -2481,8 +2481,6 @@ static int __init uniwill_init(void) > if (!force) > return -ENODEV; > > - /* Assume that the device supports all features */ > - device_descriptor.features = UINT_MAX; > pr_warn("Loading on a potentially unsupported device\n"); > } else { > /* > @@ -2500,6 +2498,12 @@ static int __init uniwill_init(void) > device_descriptor = *descriptor; > } > > + if (force) { > + /* Assume that the device supports all features */ > + device_descriptor.features = UINT_MAX; > + pr_warn("Enabling potentially unsupported features\n"); > + } > + this should already exclude the potentially harmfull "charging threshold" > ret = platform_driver_register(&uniwill_driver); > if (ret < 0) > return ret; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] platform/x86: uniwill-laptop: Fix behavior of "force" module param 2026-04-08 23:08 ` Werner Sembach @ 2026-04-10 17:32 ` Armin Wolf 2026-04-10 20:30 ` Werner Sembach 0 siblings, 1 reply; 22+ messages in thread From: Armin Wolf @ 2026-04-10 17:32 UTC (permalink / raw) To: Werner Sembach, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 09.04.26 um 01:08 schrieb Werner Sembach: > > Am 06.04.26 um 21:36 schrieb Armin Wolf: >> Users might want to force-enable all possible features even on >> machines with a valid device descriptor. Until now the "force" >> module param was ignored on such machines. Fix this to make >> it easier to test for support of new features. >> >> Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") >> Signed-off-by: Armin Wolf <W_Armin@gmx.de> >> --- >> drivers/platform/x86/uniwill/uniwill-acpi.c | 8 ++++++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c >> b/drivers/platform/x86/uniwill/uniwill-acpi.c >> index 5551f193c2c1..7c7ea0e76966 100644 >> --- a/drivers/platform/x86/uniwill/uniwill-acpi.c >> +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c >> @@ -2481,8 +2481,6 @@ static int __init uniwill_init(void) >> if (!force) >> return -ENODEV; >> - /* Assume that the device supports all features */ >> - device_descriptor.features = UINT_MAX; >> pr_warn("Loading on a potentially unsupported device\n"); >> } else { >> /* >> @@ -2500,6 +2498,12 @@ static int __init uniwill_init(void) >> device_descriptor = *descriptor; >> } >> + if (force) { >> + /* Assume that the device supports all features */ >> + device_descriptor.features = UINT_MAX; >> + pr_warn("Enabling potentially unsupported features\n"); >> + } >> + > this should already exclude the potentially harmfull "charging threshold" I decided to keep this patch small so that it can be picked up by the stable team without much fuss. Personally i believe that the charging limit should be dealt with inside the last patch where we add support for the (safe) charging modes. Thanks, Armin Wolf >> ret = platform_driver_register(&uniwill_driver); >> if (ret < 0) >> return ret; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] platform/x86: uniwill-laptop: Fix behavior of "force" module param 2026-04-10 17:32 ` Armin Wolf @ 2026-04-10 20:30 ` Werner Sembach 2026-04-10 21:45 ` Armin Wolf 0 siblings, 1 reply; 22+ messages in thread From: Werner Sembach @ 2026-04-10 20:30 UTC (permalink / raw) To: Armin Wolf, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 10.04.26 um 19:32 schrieb Armin Wolf: > Am 09.04.26 um 01:08 schrieb Werner Sembach: > >> >> Am 06.04.26 um 21:36 schrieb Armin Wolf: >>> Users might want to force-enable all possible features even on >>> machines with a valid device descriptor. Until now the "force" >>> module param was ignored on such machines. Fix this to make >>> it easier to test for support of new features. >>> >>> Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") >>> Signed-off-by: Armin Wolf <W_Armin@gmx.de> >>> --- >>> drivers/platform/x86/uniwill/uniwill-acpi.c | 8 ++++++-- >>> 1 file changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c >>> b/drivers/platform/x86/uniwill/uniwill-acpi.c >>> index 5551f193c2c1..7c7ea0e76966 100644 >>> --- a/drivers/platform/x86/uniwill/uniwill-acpi.c >>> +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c >>> @@ -2481,8 +2481,6 @@ static int __init uniwill_init(void) >>> if (!force) >>> return -ENODEV; >>> - /* Assume that the device supports all features */ >>> - device_descriptor.features = UINT_MAX; >>> pr_warn("Loading on a potentially unsupported device\n"); >>> } else { >>> /* >>> @@ -2500,6 +2498,12 @@ static int __init uniwill_init(void) >>> device_descriptor = *descriptor; >>> } >>> + if (force) { >>> + /* Assume that the device supports all features */ >>> + device_descriptor.features = UINT_MAX; >>> + pr_warn("Enabling potentially unsupported features\n"); >>> + } >>> + >> this should already exclude the potentially harmfull "charging threshold" > > I decided to keep this patch small so that it can be picked up by the stable team > without much fuss. Personally i believe that the charging limit should be > dealt with > inside the last patch where we add support for the (safe) charging modes. Stable should get this protection too, and it is just one more line. Could even be an own patch with just that line > > Thanks, > Armin Wolf > >>> ret = platform_driver_register(&uniwill_driver); >>> if (ret < 0) >>> return ret; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3/6] platform/x86: uniwill-laptop: Fix behavior of "force" module param 2026-04-10 20:30 ` Werner Sembach @ 2026-04-10 21:45 ` Armin Wolf 0 siblings, 0 replies; 22+ messages in thread From: Armin Wolf @ 2026-04-10 21:45 UTC (permalink / raw) To: Werner Sembach, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 10.04.26 um 22:30 schrieb Werner Sembach: > > Am 10.04.26 um 19:32 schrieb Armin Wolf: >> Am 09.04.26 um 01:08 schrieb Werner Sembach: >> >>> >>> Am 06.04.26 um 21:36 schrieb Armin Wolf: >>>> Users might want to force-enable all possible features even on >>>> machines with a valid device descriptor. Until now the "force" >>>> module param was ignored on such machines. Fix this to make >>>> it easier to test for support of new features. >>>> >>>> Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") >>>> Signed-off-by: Armin Wolf <W_Armin@gmx.de> >>>> --- >>>> drivers/platform/x86/uniwill/uniwill-acpi.c | 8 ++++++-- >>>> 1 file changed, 6 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c >>>> b/drivers/platform/x86/uniwill/uniwill-acpi.c >>>> index 5551f193c2c1..7c7ea0e76966 100644 >>>> --- a/drivers/platform/x86/uniwill/uniwill-acpi.c >>>> +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c >>>> @@ -2481,8 +2481,6 @@ static int __init uniwill_init(void) >>>> if (!force) >>>> return -ENODEV; >>>> - /* Assume that the device supports all features */ >>>> - device_descriptor.features = UINT_MAX; >>>> pr_warn("Loading on a potentially unsupported device\n"); >>>> } else { >>>> /* >>>> @@ -2500,6 +2498,12 @@ static int __init uniwill_init(void) >>>> device_descriptor = *descriptor; >>>> } >>>> + if (force) { >>>> + /* Assume that the device supports all features */ >>>> + device_descriptor.features = UINT_MAX; >>>> + pr_warn("Enabling potentially unsupported features\n"); >>>> + } >>>> + >>> this should already exclude the potentially harmfull "charging >>> threshold" >> >> I decided to keep this patch small so that it can be picked up by the >> stable team >> without much fuss. Personally i believe that the charging limit >> should be dealt with >> inside the last patch where we add support for the (safe) charging >> modes. > > Stable should get this protection too, and it is just one more line. > > Could even be an own patch with just that line > Agree, i will do this in the v2 series. Thanks, Armin Wolf >> >> Thanks, >> Armin Wolf >> >>>> ret = platform_driver_register(&uniwill_driver); >>>> if (ret < 0) >>>> return ret; > ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 4/6] platform/x86: uniwill-laptop: Rework FN lock/super key suspend handling 2026-04-06 19:36 [PATCH 0/6] platform/x86: uniwill-laptop: Charging-related improvements Armin Wolf ` (2 preceding siblings ...) 2026-04-06 19:36 ` [PATCH 3/6] platform/x86: uniwill-laptop: Fix behavior of "force" module param Armin Wolf @ 2026-04-06 19:36 ` Armin Wolf 2026-04-10 15:30 ` Werner Sembach 2026-04-06 19:36 ` [PATCH 5/6] platform/x86: uniwill-laptop: Mark EC_ADDR_OEM_4 as volatile Armin Wolf 2026-04-06 19:36 ` [PATCH 6/6] platform/x86: uniwill-laptop: Add support for battery charge modes Armin Wolf 5 siblings, 1 reply; 22+ messages in thread From: Armin Wolf @ 2026-04-06 19:36 UTC (permalink / raw) To: hansg, ilpo.jarvinen; +Cc: wse, platform-driver-x86, linux-kernel Currently the supend handling for the FN lock and super key enable features saves the whole values of the affected registers instead of the individual feature state. This duplicates the register access logic from the associated sysfs attributes. Rework the suspend handling to reuse said register access logic and only store the individual feature state as a boolean value. Signed-off-by: Armin Wolf <W_Armin@gmx.de> --- drivers/platform/x86/uniwill/uniwill-acpi.c | 117 ++++++++++++-------- 1 file changed, 73 insertions(+), 44 deletions(-) diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c index 7c7ea0e76966..4d149b39d94e 100644 --- a/drivers/platform/x86/uniwill/uniwill-acpi.c +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c @@ -341,8 +341,8 @@ struct uniwill_data { struct acpi_battery_hook hook; unsigned int last_charge_ctrl; struct mutex battery_lock; /* Protects the list of currently registered batteries */ - unsigned int last_status; - unsigned int last_switch_status; + bool last_fn_lock_state; + bool last_super_key_enable_state; struct mutex super_key_lock; /* Protects the toggling of the super key lock state */ struct list_head batteries; struct mutex led_lock; /* Protects writes to the lightbar registers */ @@ -619,11 +619,22 @@ static const struct regmap_config uniwill_ec_config = { .use_single_write = true, }; +static int uniwill_write_fn_lock(struct uniwill_data *data, bool status) +{ + unsigned int value; + + if (status) + value = FN_LOCK_STATUS; + else + value = 0; + + return regmap_update_bits(data->regmap, EC_ADDR_BIOS_OEM, FN_LOCK_STATUS, value); +} + static ssize_t fn_lock_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { struct uniwill_data *data = dev_get_drvdata(dev); - unsigned int value; bool enable; int ret; @@ -631,21 +642,15 @@ static ssize_t fn_lock_store(struct device *dev, struct device_attribute *attr, if (ret < 0) return ret; - if (enable) - value = FN_LOCK_STATUS; - else - value = 0; - - ret = regmap_update_bits(data->regmap, EC_ADDR_BIOS_OEM, FN_LOCK_STATUS, value); + ret = uniwill_write_fn_lock(data, enable); if (ret < 0) return ret; return count; } -static ssize_t fn_lock_show(struct device *dev, struct device_attribute *attr, char *buf) +static int uniwill_read_fn_lock(struct uniwill_data *data, bool *status) { - struct uniwill_data *data = dev_get_drvdata(dev); unsigned int value; int ret; @@ -653,23 +658,31 @@ static ssize_t fn_lock_show(struct device *dev, struct device_attribute *attr, c if (ret < 0) return ret; - return sysfs_emit(buf, "%d\n", !!(value & FN_LOCK_STATUS)); -} + *status = !!(value & FN_LOCK_STATUS); -static DEVICE_ATTR_RW(fn_lock); + return 0; +} -static ssize_t super_key_enable_store(struct device *dev, struct device_attribute *attr, - const char *buf, size_t count) +static ssize_t fn_lock_show(struct device *dev, struct device_attribute *attr, char *buf) { struct uniwill_data *data = dev_get_drvdata(dev); - unsigned int value; - bool enable; + bool status; int ret; - ret = kstrtobool(buf, &enable); + ret = uniwill_read_fn_lock(data, &status); if (ret < 0) return ret; + return sysfs_emit(buf, "%d\n", status); +} + +static DEVICE_ATTR_RW(fn_lock); + +static int uniwill_write_super_key_enable(struct uniwill_data *data, bool status) +{ + unsigned int value; + int ret; + guard(mutex)(&data->super_key_lock); ret = regmap_read(data->regmap, EC_ADDR_SWITCH_STATUS, &value); @@ -680,20 +693,33 @@ static ssize_t super_key_enable_store(struct device *dev, struct device_attribut * We can only toggle the super key lock, so we return early if the setting * is already in the correct state. */ - if (enable == !(value & SUPER_KEY_LOCK_STATUS)) - return count; + if (status == !(value & SUPER_KEY_LOCK_STATUS)) + return 0; + + return regmap_write_bits(data->regmap, EC_ADDR_TRIGGER, TRIGGER_SUPER_KEY_LOCK, + TRIGGER_SUPER_KEY_LOCK); +} + +static ssize_t super_key_enable_store(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) +{ + struct uniwill_data *data = dev_get_drvdata(dev); + bool enable; + int ret; - ret = regmap_write_bits(data->regmap, EC_ADDR_TRIGGER, TRIGGER_SUPER_KEY_LOCK, - TRIGGER_SUPER_KEY_LOCK); + ret = kstrtobool(buf, &enable); + if (ret < 0) + return ret; + + ret = uniwill_write_super_key_enable(data, enable); if (ret < 0) return ret; return count; } -static ssize_t super_key_enable_show(struct device *dev, struct device_attribute *attr, char *buf) +static int uniwill_read_super_key_enable(struct uniwill_data *data, bool *status) { - struct uniwill_data *data = dev_get_drvdata(dev); unsigned int value; int ret; @@ -701,7 +727,22 @@ static ssize_t super_key_enable_show(struct device *dev, struct device_attribute if (ret < 0) return ret; - return sysfs_emit(buf, "%d\n", !(value & SUPER_KEY_LOCK_STATUS)); + *status = !(value & SUPER_KEY_LOCK_STATUS); + + return 0; +} + +static ssize_t super_key_enable_show(struct device *dev, struct device_attribute *attr, char *buf) +{ + struct uniwill_data *data = dev_get_drvdata(dev); + bool status; + int ret; + + ret = uniwill_read_super_key_enable(data, &status); + if (ret < 0) + return ret; + + return sysfs_emit(buf, "%d\n", status); } static DEVICE_ATTR_RW(super_key_enable); @@ -1715,10 +1756,10 @@ static int uniwill_suspend_fn_lock(struct uniwill_data *data) return 0; /* - * The EC_ADDR_BIOS_OEM is marked as volatile, so we have to restore it + * EC_ADDR_BIOS_OEM is marked as volatile, so we have to restore it * ourselves. */ - return regmap_read(data->regmap, EC_ADDR_BIOS_OEM, &data->last_status); + return uniwill_read_fn_lock(data, &data->last_fn_lock_state); } static int uniwill_suspend_super_key(struct uniwill_data *data) @@ -1727,10 +1768,10 @@ static int uniwill_suspend_super_key(struct uniwill_data *data) return 0; /* - * The EC_ADDR_SWITCH_STATUS is marked as volatile, so we have to restore it + * EC_ADDR_SWITCH_STATUS is marked as volatile, so we have to restore it * ourselves. */ - return regmap_read(data->regmap, EC_ADDR_SWITCH_STATUS, &data->last_switch_status); + return uniwill_read_super_key_enable(data, &data->last_super_key_enable_state); } static int uniwill_suspend_battery(struct uniwill_data *data) @@ -1787,27 +1828,15 @@ static int uniwill_resume_fn_lock(struct uniwill_data *data) if (!uniwill_device_supports(data, UNIWILL_FEATURE_FN_LOCK)) return 0; - return regmap_update_bits(data->regmap, EC_ADDR_BIOS_OEM, FN_LOCK_STATUS, - data->last_status); + return uniwill_write_fn_lock(data, data->last_fn_lock_state); } static int uniwill_resume_super_key(struct uniwill_data *data) { - unsigned int value; - int ret; - if (!uniwill_device_supports(data, UNIWILL_FEATURE_SUPER_KEY)) return 0; - ret = regmap_read(data->regmap, EC_ADDR_SWITCH_STATUS, &value); - if (ret < 0) - return ret; - - if ((data->last_switch_status & SUPER_KEY_LOCK_STATUS) == (value & SUPER_KEY_LOCK_STATUS)) - return 0; - - return regmap_write_bits(data->regmap, EC_ADDR_TRIGGER, TRIGGER_SUPER_KEY_LOCK, - TRIGGER_SUPER_KEY_LOCK); + return uniwill_write_super_key_enable(data, data->last_super_key_enable_state); } static int uniwill_resume_battery(struct uniwill_data *data) -- 2.39.5 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 4/6] platform/x86: uniwill-laptop: Rework FN lock/super key suspend handling 2026-04-06 19:36 ` [PATCH 4/6] platform/x86: uniwill-laptop: Rework FN lock/super key suspend handling Armin Wolf @ 2026-04-10 15:30 ` Werner Sembach 2026-04-10 17:33 ` Armin Wolf 0 siblings, 1 reply; 22+ messages in thread From: Werner Sembach @ 2026-04-10 15:30 UTC (permalink / raw) To: Armin Wolf, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 06.04.26 um 21:36 schrieb Armin Wolf: > Currently the supend handling for the FN lock and super key enable *suspend Other then this typo lgtm: Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> > features saves the whole values of the affected registers instead of > the individual feature state. This duplicates the register access > logic from the associated sysfs attributes. > > Rework the suspend handling to reuse said register access logic and > only store the individual feature state as a boolean value. > > Signed-off-by: Armin Wolf<W_Armin@gmx.de> > --- > drivers/platform/x86/uniwill/uniwill-acpi.c | 117 ++++++++++++-------- > 1 file changed, 73 insertions(+), 44 deletions(-) > > diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c > index 7c7ea0e76966..4d149b39d94e 100644 > --- a/drivers/platform/x86/uniwill/uniwill-acpi.c > +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c > @@ -341,8 +341,8 @@ struct uniwill_data { > struct acpi_battery_hook hook; > unsigned int last_charge_ctrl; > struct mutex battery_lock; /* Protects the list of currently registered batteries */ > - unsigned int last_status; > - unsigned int last_switch_status; > + bool last_fn_lock_state; > + bool last_super_key_enable_state; > struct mutex super_key_lock; /* Protects the toggling of the super key lock state */ > struct list_head batteries; > struct mutex led_lock; /* Protects writes to the lightbar registers */ > @@ -619,11 +619,22 @@ static const struct regmap_config uniwill_ec_config = { > .use_single_write = true, > }; > > +static int uniwill_write_fn_lock(struct uniwill_data *data, bool status) > +{ > + unsigned int value; > + > + if (status) > + value = FN_LOCK_STATUS; > + else > + value = 0; > + > + return regmap_update_bits(data->regmap, EC_ADDR_BIOS_OEM, FN_LOCK_STATUS, value); > +} > + > static ssize_t fn_lock_store(struct device *dev, struct device_attribute *attr, const char *buf, > size_t count) > { > struct uniwill_data *data = dev_get_drvdata(dev); > - unsigned int value; > bool enable; > int ret; > > @@ -631,21 +642,15 @@ static ssize_t fn_lock_store(struct device *dev, struct device_attribute *attr, > if (ret < 0) > return ret; > > - if (enable) > - value = FN_LOCK_STATUS; > - else > - value = 0; > - > - ret = regmap_update_bits(data->regmap, EC_ADDR_BIOS_OEM, FN_LOCK_STATUS, value); > + ret = uniwill_write_fn_lock(data, enable); > if (ret < 0) > return ret; > > return count; > } > > -static ssize_t fn_lock_show(struct device *dev, struct device_attribute *attr, char *buf) > +static int uniwill_read_fn_lock(struct uniwill_data *data, bool *status) > { > - struct uniwill_data *data = dev_get_drvdata(dev); > unsigned int value; > int ret; > > @@ -653,23 +658,31 @@ static ssize_t fn_lock_show(struct device *dev, struct device_attribute *attr, c > if (ret < 0) > return ret; > > - return sysfs_emit(buf, "%d\n", !!(value & FN_LOCK_STATUS)); > -} > + *status = !!(value & FN_LOCK_STATUS); > > -static DEVICE_ATTR_RW(fn_lock); > + return 0; > +} > > -static ssize_t super_key_enable_store(struct device *dev, struct device_attribute *attr, > - const char *buf, size_t count) > +static ssize_t fn_lock_show(struct device *dev, struct device_attribute *attr, char *buf) > { > struct uniwill_data *data = dev_get_drvdata(dev); > - unsigned int value; > - bool enable; > + bool status; > int ret; > > - ret = kstrtobool(buf, &enable); > + ret = uniwill_read_fn_lock(data, &status); > if (ret < 0) > return ret; > > + return sysfs_emit(buf, "%d\n", status); > +} > + > +static DEVICE_ATTR_RW(fn_lock); > + > +static int uniwill_write_super_key_enable(struct uniwill_data *data, bool status) > +{ > + unsigned int value; > + int ret; > + > guard(mutex)(&data->super_key_lock); > > ret = regmap_read(data->regmap, EC_ADDR_SWITCH_STATUS, &value); > @@ -680,20 +693,33 @@ static ssize_t super_key_enable_store(struct device *dev, struct device_attribut > * We can only toggle the super key lock, so we return early if the setting > * is already in the correct state. > */ > - if (enable == !(value & SUPER_KEY_LOCK_STATUS)) > - return count; > + if (status == !(value & SUPER_KEY_LOCK_STATUS)) > + return 0; > + > + return regmap_write_bits(data->regmap, EC_ADDR_TRIGGER, TRIGGER_SUPER_KEY_LOCK, > + TRIGGER_SUPER_KEY_LOCK); > +} > + > +static ssize_t super_key_enable_store(struct device *dev, struct device_attribute *attr, > + const char *buf, size_t count) > +{ > + struct uniwill_data *data = dev_get_drvdata(dev); > + bool enable; > + int ret; > > - ret = regmap_write_bits(data->regmap, EC_ADDR_TRIGGER, TRIGGER_SUPER_KEY_LOCK, > - TRIGGER_SUPER_KEY_LOCK); > + ret = kstrtobool(buf, &enable); > + if (ret < 0) > + return ret; > + > + ret = uniwill_write_super_key_enable(data, enable); > if (ret < 0) > return ret; > > return count; > } > > -static ssize_t super_key_enable_show(struct device *dev, struct device_attribute *attr, char *buf) > +static int uniwill_read_super_key_enable(struct uniwill_data *data, bool *status) > { > - struct uniwill_data *data = dev_get_drvdata(dev); > unsigned int value; > int ret; > > @@ -701,7 +727,22 @@ static ssize_t super_key_enable_show(struct device *dev, struct device_attribute > if (ret < 0) > return ret; > > - return sysfs_emit(buf, "%d\n", !(value & SUPER_KEY_LOCK_STATUS)); > + *status = !(value & SUPER_KEY_LOCK_STATUS); > + > + return 0; > +} > + > +static ssize_t super_key_enable_show(struct device *dev, struct device_attribute *attr, char *buf) > +{ > + struct uniwill_data *data = dev_get_drvdata(dev); > + bool status; > + int ret; > + > + ret = uniwill_read_super_key_enable(data, &status); > + if (ret < 0) > + return ret; > + > + return sysfs_emit(buf, "%d\n", status); > } > > static DEVICE_ATTR_RW(super_key_enable); > @@ -1715,10 +1756,10 @@ static int uniwill_suspend_fn_lock(struct uniwill_data *data) > return 0; > > /* > - * The EC_ADDR_BIOS_OEM is marked as volatile, so we have to restore it > + * EC_ADDR_BIOS_OEM is marked as volatile, so we have to restore it > * ourselves. > */ > - return regmap_read(data->regmap, EC_ADDR_BIOS_OEM, &data->last_status); > + return uniwill_read_fn_lock(data, &data->last_fn_lock_state); > } > > static int uniwill_suspend_super_key(struct uniwill_data *data) > @@ -1727,10 +1768,10 @@ static int uniwill_suspend_super_key(struct uniwill_data *data) > return 0; > > /* > - * The EC_ADDR_SWITCH_STATUS is marked as volatile, so we have to restore it > + * EC_ADDR_SWITCH_STATUS is marked as volatile, so we have to restore it > * ourselves. > */ > - return regmap_read(data->regmap, EC_ADDR_SWITCH_STATUS, &data->last_switch_status); > + return uniwill_read_super_key_enable(data, &data->last_super_key_enable_state); > } > > static int uniwill_suspend_battery(struct uniwill_data *data) > @@ -1787,27 +1828,15 @@ static int uniwill_resume_fn_lock(struct uniwill_data *data) > if (!uniwill_device_supports(data, UNIWILL_FEATURE_FN_LOCK)) > return 0; > > - return regmap_update_bits(data->regmap, EC_ADDR_BIOS_OEM, FN_LOCK_STATUS, > - data->last_status); > + return uniwill_write_fn_lock(data, data->last_fn_lock_state); > } > > static int uniwill_resume_super_key(struct uniwill_data *data) > { > - unsigned int value; > - int ret; > - > if (!uniwill_device_supports(data, UNIWILL_FEATURE_SUPER_KEY)) > return 0; > > - ret = regmap_read(data->regmap, EC_ADDR_SWITCH_STATUS, &value); > - if (ret < 0) > - return ret; > - > - if ((data->last_switch_status & SUPER_KEY_LOCK_STATUS) == (value & SUPER_KEY_LOCK_STATUS)) > - return 0; > - > - return regmap_write_bits(data->regmap, EC_ADDR_TRIGGER, TRIGGER_SUPER_KEY_LOCK, > - TRIGGER_SUPER_KEY_LOCK); > + return uniwill_write_super_key_enable(data, data->last_super_key_enable_state); > } > > static int uniwill_resume_battery(struct uniwill_data *data) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 4/6] platform/x86: uniwill-laptop: Rework FN lock/super key suspend handling 2026-04-10 15:30 ` Werner Sembach @ 2026-04-10 17:33 ` Armin Wolf 0 siblings, 0 replies; 22+ messages in thread From: Armin Wolf @ 2026-04-10 17:33 UTC (permalink / raw) To: Werner Sembach, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 10.04.26 um 17:30 schrieb Werner Sembach: > > Am 06.04.26 um 21:36 schrieb Armin Wolf: >> Currently the supend handling for the FN lock and super key enable > > *suspend > > Other then this typo lgtm: > > Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Good catch, will fix. Thanks, Armin Wolf > >> features saves the whole values of the affected registers instead of >> the individual feature state. This duplicates the register access >> logic from the associated sysfs attributes. >> >> Rework the suspend handling to reuse said register access logic and >> only store the individual feature state as a boolean value. >> >> Signed-off-by: Armin Wolf<W_Armin@gmx.de> >> --- >> drivers/platform/x86/uniwill/uniwill-acpi.c | 117 ++++++++++++-------- >> 1 file changed, 73 insertions(+), 44 deletions(-) >> >> diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c >> b/drivers/platform/x86/uniwill/uniwill-acpi.c >> index 7c7ea0e76966..4d149b39d94e 100644 >> --- a/drivers/platform/x86/uniwill/uniwill-acpi.c >> +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c >> @@ -341,8 +341,8 @@ struct uniwill_data { >> struct acpi_battery_hook hook; >> unsigned int last_charge_ctrl; >> struct mutex battery_lock; /* Protects the list of currently >> registered batteries */ >> - unsigned int last_status; >> - unsigned int last_switch_status; >> + bool last_fn_lock_state; >> + bool last_super_key_enable_state; >> struct mutex super_key_lock; /* Protects the toggling of the >> super key lock state */ >> struct list_head batteries; >> struct mutex led_lock; /* Protects writes to the >> lightbar registers */ >> @@ -619,11 +619,22 @@ static const struct regmap_config >> uniwill_ec_config = { >> .use_single_write = true, >> }; >> +static int uniwill_write_fn_lock(struct uniwill_data *data, bool >> status) >> +{ >> + unsigned int value; >> + >> + if (status) >> + value = FN_LOCK_STATUS; >> + else >> + value = 0; >> + >> + return regmap_update_bits(data->regmap, EC_ADDR_BIOS_OEM, >> FN_LOCK_STATUS, value); >> +} >> + >> static ssize_t fn_lock_store(struct device *dev, struct >> device_attribute *attr, const char *buf, >> size_t count) >> { >> struct uniwill_data *data = dev_get_drvdata(dev); >> - unsigned int value; >> bool enable; >> int ret; >> @@ -631,21 +642,15 @@ static ssize_t fn_lock_store(struct device >> *dev, struct device_attribute *attr, >> if (ret < 0) >> return ret; >> - if (enable) >> - value = FN_LOCK_STATUS; >> - else >> - value = 0; >> - >> - ret = regmap_update_bits(data->regmap, EC_ADDR_BIOS_OEM, >> FN_LOCK_STATUS, value); >> + ret = uniwill_write_fn_lock(data, enable); >> if (ret < 0) >> return ret; >> return count; >> } >> -static ssize_t fn_lock_show(struct device *dev, struct >> device_attribute *attr, char *buf) >> +static int uniwill_read_fn_lock(struct uniwill_data *data, bool >> *status) >> { >> - struct uniwill_data *data = dev_get_drvdata(dev); >> unsigned int value; >> int ret; >> @@ -653,23 +658,31 @@ static ssize_t fn_lock_show(struct device >> *dev, struct device_attribute *attr, c >> if (ret < 0) >> return ret; >> - return sysfs_emit(buf, "%d\n", !!(value & FN_LOCK_STATUS)); >> -} >> + *status = !!(value & FN_LOCK_STATUS); >> -static DEVICE_ATTR_RW(fn_lock); >> + return 0; >> +} >> -static ssize_t super_key_enable_store(struct device *dev, struct >> device_attribute *attr, >> - const char *buf, size_t count) >> +static ssize_t fn_lock_show(struct device *dev, struct >> device_attribute *attr, char *buf) >> { >> struct uniwill_data *data = dev_get_drvdata(dev); >> - unsigned int value; >> - bool enable; >> + bool status; >> int ret; >> - ret = kstrtobool(buf, &enable); >> + ret = uniwill_read_fn_lock(data, &status); >> if (ret < 0) >> return ret; >> + return sysfs_emit(buf, "%d\n", status); >> +} >> + >> +static DEVICE_ATTR_RW(fn_lock); >> + >> +static int uniwill_write_super_key_enable(struct uniwill_data *data, >> bool status) >> +{ >> + unsigned int value; >> + int ret; >> + >> guard(mutex)(&data->super_key_lock); >> ret = regmap_read(data->regmap, EC_ADDR_SWITCH_STATUS, &value); >> @@ -680,20 +693,33 @@ static ssize_t super_key_enable_store(struct >> device *dev, struct device_attribut >> * We can only toggle the super key lock, so we return early if >> the setting >> * is already in the correct state. >> */ >> - if (enable == !(value & SUPER_KEY_LOCK_STATUS)) >> - return count; >> + if (status == !(value & SUPER_KEY_LOCK_STATUS)) >> + return 0; >> + >> + return regmap_write_bits(data->regmap, EC_ADDR_TRIGGER, >> TRIGGER_SUPER_KEY_LOCK, >> + TRIGGER_SUPER_KEY_LOCK); >> +} >> + >> +static ssize_t super_key_enable_store(struct device *dev, struct >> device_attribute *attr, >> + const char *buf, size_t count) >> +{ >> + struct uniwill_data *data = dev_get_drvdata(dev); >> + bool enable; >> + int ret; >> - ret = regmap_write_bits(data->regmap, EC_ADDR_TRIGGER, >> TRIGGER_SUPER_KEY_LOCK, >> - TRIGGER_SUPER_KEY_LOCK); >> + ret = kstrtobool(buf, &enable); >> + if (ret < 0) >> + return ret; >> + >> + ret = uniwill_write_super_key_enable(data, enable); >> if (ret < 0) >> return ret; >> return count; >> } >> -static ssize_t super_key_enable_show(struct device *dev, struct >> device_attribute *attr, char *buf) >> +static int uniwill_read_super_key_enable(struct uniwill_data *data, >> bool *status) >> { >> - struct uniwill_data *data = dev_get_drvdata(dev); >> unsigned int value; >> int ret; >> @@ -701,7 +727,22 @@ static ssize_t super_key_enable_show(struct >> device *dev, struct device_attribute >> if (ret < 0) >> return ret; >> - return sysfs_emit(buf, "%d\n", !(value & SUPER_KEY_LOCK_STATUS)); >> + *status = !(value & SUPER_KEY_LOCK_STATUS); >> + >> + return 0; >> +} >> + >> +static ssize_t super_key_enable_show(struct device *dev, struct >> device_attribute *attr, char *buf) >> +{ >> + struct uniwill_data *data = dev_get_drvdata(dev); >> + bool status; >> + int ret; >> + >> + ret = uniwill_read_super_key_enable(data, &status); >> + if (ret < 0) >> + return ret; >> + >> + return sysfs_emit(buf, "%d\n", status); >> } >> static DEVICE_ATTR_RW(super_key_enable); >> @@ -1715,10 +1756,10 @@ static int uniwill_suspend_fn_lock(struct >> uniwill_data *data) >> return 0; >> /* >> - * The EC_ADDR_BIOS_OEM is marked as volatile, so we have to >> restore it >> + * EC_ADDR_BIOS_OEM is marked as volatile, so we have to restore it >> * ourselves. >> */ >> - return regmap_read(data->regmap, EC_ADDR_BIOS_OEM, >> &data->last_status); >> + return uniwill_read_fn_lock(data, &data->last_fn_lock_state); >> } >> static int uniwill_suspend_super_key(struct uniwill_data *data) >> @@ -1727,10 +1768,10 @@ static int uniwill_suspend_super_key(struct >> uniwill_data *data) >> return 0; >> /* >> - * The EC_ADDR_SWITCH_STATUS is marked as volatile, so we have >> to restore it >> + * EC_ADDR_SWITCH_STATUS is marked as volatile, so we have to >> restore it >> * ourselves. >> */ >> - return regmap_read(data->regmap, EC_ADDR_SWITCH_STATUS, >> &data->last_switch_status); >> + return uniwill_read_super_key_enable(data, >> &data->last_super_key_enable_state); >> } >> static int uniwill_suspend_battery(struct uniwill_data *data) >> @@ -1787,27 +1828,15 @@ static int uniwill_resume_fn_lock(struct >> uniwill_data *data) >> if (!uniwill_device_supports(data, UNIWILL_FEATURE_FN_LOCK)) >> return 0; >> - return regmap_update_bits(data->regmap, EC_ADDR_BIOS_OEM, >> FN_LOCK_STATUS, >> - data->last_status); >> + return uniwill_write_fn_lock(data, data->last_fn_lock_state); >> } >> static int uniwill_resume_super_key(struct uniwill_data *data) >> { >> - unsigned int value; >> - int ret; >> - >> if (!uniwill_device_supports(data, UNIWILL_FEATURE_SUPER_KEY)) >> return 0; >> - ret = regmap_read(data->regmap, EC_ADDR_SWITCH_STATUS, &value); >> - if (ret < 0) >> - return ret; >> - >> - if ((data->last_switch_status & SUPER_KEY_LOCK_STATUS) == (value >> & SUPER_KEY_LOCK_STATUS)) >> - return 0; >> - >> - return regmap_write_bits(data->regmap, EC_ADDR_TRIGGER, >> TRIGGER_SUPER_KEY_LOCK, >> - TRIGGER_SUPER_KEY_LOCK); >> + return uniwill_write_super_key_enable(data, >> data->last_super_key_enable_state); >> } >> static int uniwill_resume_battery(struct uniwill_data *data) ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 5/6] platform/x86: uniwill-laptop: Mark EC_ADDR_OEM_4 as volatile 2026-04-06 19:36 [PATCH 0/6] platform/x86: uniwill-laptop: Charging-related improvements Armin Wolf ` (3 preceding siblings ...) 2026-04-06 19:36 ` [PATCH 4/6] platform/x86: uniwill-laptop: Rework FN lock/super key suspend handling Armin Wolf @ 2026-04-06 19:36 ` Armin Wolf 2026-04-10 15:35 ` Werner Sembach 2026-04-06 19:36 ` [PATCH 6/6] platform/x86: uniwill-laptop: Add support for battery charge modes Armin Wolf 5 siblings, 1 reply; 22+ messages in thread From: Armin Wolf @ 2026-04-06 19:36 UTC (permalink / raw) To: hansg, ilpo.jarvinen; +Cc: wse, platform-driver-x86, linux-kernel It turned out that EC_ADDR_OEM_4 also contains bits with a volatile nature. Mark the whole register as volatile to prepare for the usage of said bits. This also means that we now have to save/restore the touchpad toggle state ourself. Signed-off-by: Armin Wolf <W_Armin@gmx.de> --- drivers/platform/x86/uniwill/uniwill-acpi.c | 70 ++++++++++++++++++--- 1 file changed, 60 insertions(+), 10 deletions(-) diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c index 4d149b39d94e..a116e2ec6453 100644 --- a/drivers/platform/x86/uniwill/uniwill-acpi.c +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c @@ -343,6 +343,7 @@ struct uniwill_data { struct mutex battery_lock; /* Protects the list of currently registered batteries */ bool last_fn_lock_state; bool last_super_key_enable_state; + bool last_touchpad_toggle_enable_state; struct mutex super_key_lock; /* Protects the toggling of the super key lock state */ struct list_head batteries; struct mutex led_lock; /* Protects writes to the lightbar registers */ @@ -598,6 +599,7 @@ static bool uniwill_volatile_reg(struct device *dev, unsigned int reg) case EC_ADDR_PWM_2: case EC_ADDR_TRIGGER: case EC_ADDR_SWITCH_STATUS: + case EC_ADDR_OEM_4: case EC_ADDR_CHARGE_CTRL: case EC_ADDR_USB_C_POWER_PRIORITY: return true; @@ -747,11 +749,22 @@ static ssize_t super_key_enable_show(struct device *dev, struct device_attribute static DEVICE_ATTR_RW(super_key_enable); +static int uniwill_write_touchpad_toggle_enable(struct uniwill_data *data, bool status) +{ + unsigned int value; + + if (status) + value = 0; + else + value = TOUCHPAD_TOGGLE_OFF; + + return regmap_update_bits(data->regmap, EC_ADDR_OEM_4, TOUCHPAD_TOGGLE_OFF, value); +} + static ssize_t touchpad_toggle_enable_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { struct uniwill_data *data = dev_get_drvdata(dev); - unsigned int value; bool enable; int ret; @@ -759,30 +772,39 @@ static ssize_t touchpad_toggle_enable_store(struct device *dev, struct device_at if (ret < 0) return ret; - if (enable) - value = 0; - else - value = TOUCHPAD_TOGGLE_OFF; - - ret = regmap_update_bits(data->regmap, EC_ADDR_OEM_4, TOUCHPAD_TOGGLE_OFF, value); + ret = uniwill_write_touchpad_toggle_enable(data, enable); if (ret < 0) return ret; return count; } +static int uniwill_read_touchpad_toggle_enable(struct uniwill_data *data, bool *status) +{ + unsigned int value; + int ret; + + ret = regmap_read(data->regmap, EC_ADDR_OEM_4, &value); + if (ret < 0) + return ret; + + *status = !(value & TOUCHPAD_TOGGLE_OFF); + + return 0; +} + static ssize_t touchpad_toggle_enable_show(struct device *dev, struct device_attribute *attr, char *buf) { struct uniwill_data *data = dev_get_drvdata(dev); - unsigned int value; + bool status; int ret; - ret = regmap_read(data->regmap, EC_ADDR_OEM_4, &value); + ret = uniwill_read_touchpad_toggle_enable(data, &status); if (ret < 0) return ret; - return sysfs_emit(buf, "%d\n", !(value & TOUCHPAD_TOGGLE_OFF)); + return sysfs_emit(buf, "%d\n", status); } static DEVICE_ATTR_RW(touchpad_toggle_enable); @@ -1774,6 +1796,18 @@ static int uniwill_suspend_super_key(struct uniwill_data *data) return uniwill_read_super_key_enable(data, &data->last_super_key_enable_state); } +static int uniwill_suspend_touchpad_toggle(struct uniwill_data *data) +{ + if (!uniwill_device_supports(data, UNIWILL_FEATURE_TOUCHPAD_TOGGLE)) + return 0; + + /* + * EC_ADDR_OEM_4 is marked as volatile, so we have to restore it + * ourselves. + */ + return uniwill_read_touchpad_toggle_enable(data, &data->last_touchpad_toggle_enable_state); +} + static int uniwill_suspend_battery(struct uniwill_data *data) { if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) @@ -1809,6 +1843,10 @@ static int uniwill_suspend(struct device *dev) if (ret < 0) return ret; + ret = uniwill_suspend_touchpad_toggle(data); + if (ret < 0) + return ret; + ret = uniwill_suspend_battery(data); if (ret < 0) return ret; @@ -1839,6 +1877,14 @@ static int uniwill_resume_super_key(struct uniwill_data *data) return uniwill_write_super_key_enable(data, data->last_super_key_enable_state); } +static int uniwill_resume_touchpad_toggle(struct uniwill_data *data) +{ + if (!uniwill_device_supports(data, UNIWILL_FEATURE_TOUCHPAD_TOGGLE)) + return 0; + + return uniwill_write_touchpad_toggle_enable(data, data->last_touchpad_toggle_enable_state); +} + static int uniwill_resume_battery(struct uniwill_data *data) { if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) @@ -1884,6 +1930,10 @@ static int uniwill_resume(struct device *dev) if (ret < 0) return ret; + ret = uniwill_resume_touchpad_toggle(data); + if (ret < 0) + return ret; + ret = uniwill_resume_battery(data); if (ret < 0) return ret; -- 2.39.5 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 5/6] platform/x86: uniwill-laptop: Mark EC_ADDR_OEM_4 as volatile 2026-04-06 19:36 ` [PATCH 5/6] platform/x86: uniwill-laptop: Mark EC_ADDR_OEM_4 as volatile Armin Wolf @ 2026-04-10 15:35 ` Werner Sembach 0 siblings, 0 replies; 22+ messages in thread From: Werner Sembach @ 2026-04-10 15:35 UTC (permalink / raw) To: Armin Wolf, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 06.04.26 um 21:36 schrieb Armin Wolf: > It turned out that EC_ADDR_OEM_4 also contains bits with a volatile > nature. Mark the whole register as volatile to prepare for the usage > of said bits. This also means that we now have to save/restore the > touchpad toggle state ourself. > > Signed-off-by: Armin Wolf <W_Armin@gmx.de> looks good Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> > --- > drivers/platform/x86/uniwill/uniwill-acpi.c | 70 ++++++++++++++++++--- > 1 file changed, 60 insertions(+), 10 deletions(-) > > diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c > index 4d149b39d94e..a116e2ec6453 100644 > --- a/drivers/platform/x86/uniwill/uniwill-acpi.c > +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c > @@ -343,6 +343,7 @@ struct uniwill_data { > struct mutex battery_lock; /* Protects the list of currently registered batteries */ > bool last_fn_lock_state; > bool last_super_key_enable_state; > + bool last_touchpad_toggle_enable_state; > struct mutex super_key_lock; /* Protects the toggling of the super key lock state */ > struct list_head batteries; > struct mutex led_lock; /* Protects writes to the lightbar registers */ > @@ -598,6 +599,7 @@ static bool uniwill_volatile_reg(struct device *dev, unsigned int reg) > case EC_ADDR_PWM_2: > case EC_ADDR_TRIGGER: > case EC_ADDR_SWITCH_STATUS: > + case EC_ADDR_OEM_4: > case EC_ADDR_CHARGE_CTRL: > case EC_ADDR_USB_C_POWER_PRIORITY: > return true; > @@ -747,11 +749,22 @@ static ssize_t super_key_enable_show(struct device *dev, struct device_attribute > > static DEVICE_ATTR_RW(super_key_enable); > > +static int uniwill_write_touchpad_toggle_enable(struct uniwill_data *data, bool status) > +{ > + unsigned int value; > + > + if (status) > + value = 0; > + else > + value = TOUCHPAD_TOGGLE_OFF; > + > + return regmap_update_bits(data->regmap, EC_ADDR_OEM_4, TOUCHPAD_TOGGLE_OFF, value); > +} > + > static ssize_t touchpad_toggle_enable_store(struct device *dev, struct device_attribute *attr, > const char *buf, size_t count) > { > struct uniwill_data *data = dev_get_drvdata(dev); > - unsigned int value; > bool enable; > int ret; > > @@ -759,30 +772,39 @@ static ssize_t touchpad_toggle_enable_store(struct device *dev, struct device_at > if (ret < 0) > return ret; > > - if (enable) > - value = 0; > - else > - value = TOUCHPAD_TOGGLE_OFF; > - > - ret = regmap_update_bits(data->regmap, EC_ADDR_OEM_4, TOUCHPAD_TOGGLE_OFF, value); > + ret = uniwill_write_touchpad_toggle_enable(data, enable); > if (ret < 0) > return ret; > > return count; > } > > +static int uniwill_read_touchpad_toggle_enable(struct uniwill_data *data, bool *status) > +{ > + unsigned int value; > + int ret; > + > + ret = regmap_read(data->regmap, EC_ADDR_OEM_4, &value); > + if (ret < 0) > + return ret; > + > + *status = !(value & TOUCHPAD_TOGGLE_OFF); > + > + return 0; > +} > + > static ssize_t touchpad_toggle_enable_show(struct device *dev, struct device_attribute *attr, > char *buf) > { > struct uniwill_data *data = dev_get_drvdata(dev); > - unsigned int value; > + bool status; > int ret; > > - ret = regmap_read(data->regmap, EC_ADDR_OEM_4, &value); > + ret = uniwill_read_touchpad_toggle_enable(data, &status); > if (ret < 0) > return ret; > > - return sysfs_emit(buf, "%d\n", !(value & TOUCHPAD_TOGGLE_OFF)); > + return sysfs_emit(buf, "%d\n", status); > } > > static DEVICE_ATTR_RW(touchpad_toggle_enable); > @@ -1774,6 +1796,18 @@ static int uniwill_suspend_super_key(struct uniwill_data *data) > return uniwill_read_super_key_enable(data, &data->last_super_key_enable_state); > } > > +static int uniwill_suspend_touchpad_toggle(struct uniwill_data *data) > +{ > + if (!uniwill_device_supports(data, UNIWILL_FEATURE_TOUCHPAD_TOGGLE)) > + return 0; > + > + /* > + * EC_ADDR_OEM_4 is marked as volatile, so we have to restore it > + * ourselves. > + */ > + return uniwill_read_touchpad_toggle_enable(data, &data->last_touchpad_toggle_enable_state); > +} > + > static int uniwill_suspend_battery(struct uniwill_data *data) > { > if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) > @@ -1809,6 +1843,10 @@ static int uniwill_suspend(struct device *dev) > if (ret < 0) > return ret; > > + ret = uniwill_suspend_touchpad_toggle(data); > + if (ret < 0) > + return ret; > + > ret = uniwill_suspend_battery(data); > if (ret < 0) > return ret; > @@ -1839,6 +1877,14 @@ static int uniwill_resume_super_key(struct uniwill_data *data) > return uniwill_write_super_key_enable(data, data->last_super_key_enable_state); > } > > +static int uniwill_resume_touchpad_toggle(struct uniwill_data *data) > +{ > + if (!uniwill_device_supports(data, UNIWILL_FEATURE_TOUCHPAD_TOGGLE)) > + return 0; > + > + return uniwill_write_touchpad_toggle_enable(data, data->last_touchpad_toggle_enable_state); > +} > + > static int uniwill_resume_battery(struct uniwill_data *data) > { > if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) > @@ -1884,6 +1930,10 @@ static int uniwill_resume(struct device *dev) > if (ret < 0) > return ret; > > + ret = uniwill_resume_touchpad_toggle(data); > + if (ret < 0) > + return ret; > + > ret = uniwill_resume_battery(data); > if (ret < 0) > return ret; ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 6/6] platform/x86: uniwill-laptop: Add support for battery charge modes 2026-04-06 19:36 [PATCH 0/6] platform/x86: uniwill-laptop: Charging-related improvements Armin Wolf ` (4 preceding siblings ...) 2026-04-06 19:36 ` [PATCH 5/6] platform/x86: uniwill-laptop: Mark EC_ADDR_OEM_4 as volatile Armin Wolf @ 2026-04-06 19:36 ` Armin Wolf 2026-04-10 16:53 ` Werner Sembach 5 siblings, 1 reply; 22+ messages in thread From: Armin Wolf @ 2026-04-06 19:36 UTC (permalink / raw) To: hansg, ilpo.jarvinen; +Cc: wse, platform-driver-x86, linux-kernel Many Uniwill-based devices do not supports the already existing charge limit functionality, but instead support an alternative interface for controlling the battery charge algorithm. Add support for this interface and update the documentation. Signed-off-by: Armin Wolf <W_Armin@gmx.de> --- .../admin-guide/laptops/uniwill-laptop.rst | 25 +- drivers/platform/x86/uniwill/uniwill-acpi.c | 244 ++++++++++++++---- drivers/platform/x86/uniwill/uniwill-wmi.c | 5 +- 3 files changed, 226 insertions(+), 48 deletions(-) diff --git a/Documentation/admin-guide/laptops/uniwill-laptop.rst b/Documentation/admin-guide/laptops/uniwill-laptop.rst index 561334865feb..24b41dbab886 100644 --- a/Documentation/admin-guide/laptops/uniwill-laptop.rst +++ b/Documentation/admin-guide/laptops/uniwill-laptop.rst @@ -43,9 +43,23 @@ Support for changing the platform performance mode is currently not implemented. Battery Charging Control ------------------------ -The ``uniwill-laptop`` driver supports controlling the battery charge limit. This happens over -the standard ``charge_control_end_threshold`` power supply sysfs attribute. All values -between 1 and 100 percent are supported. +.. warning:: Some devices do not properly implement the charging threshold interface. Forcing + the driver to enable access to said interface on such devices might damage the + battery [1]_. Because of this the driver will not enable said feature even when + using the ``force`` module parameter. The charging profile interface will be + available instead. + +The ``uniwill-laptop`` driver supports controlling the battery charge limit. This either happens +over the standard ``charge_control_end_threshold`` or ``charge_types`` power supply sysfs attribute, +depending on the device. When using the ``charge_control_end_threshold`` sysfs attribute, all values +between 1 and 100 percent are supported. When using the ``charge_types`` sysfs attribute, the driver +supports switching between the ``Standard``, ``Trickle`` and ``Long Life`` profiles. + +Keep in mind that when using the ``charge_types`` sysfs attribute, the EC firmware will hide the +true charging status of the battery from the operating system, potentially misleading users into +thinking that the charging profile does not work. Checking the ``current_now`` sysfs attribute +tells you the true charging status of the battery even when using the ``charge_types`` sysfs +attribute (0 means that the battery is currently not charging). Additionally the driver signals the presence of battery charging issues through the standard ``health`` power supply sysfs attribute. @@ -70,3 +84,8 @@ The ``uniwill-laptop`` driver allows to set the configurable TGP for devices wit allow it. See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details. + +References +========== + +.. [1] https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/ diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c index a116e2ec6453..fbf2e101a074 100644 --- a/drivers/platform/x86/uniwill/uniwill-acpi.c +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c @@ -254,6 +254,10 @@ #define EC_ADDR_OEM_4 0x07A6 #define OVERBOOST_DYN_TEMP_OFF BIT(1) +#define CHARGING_PROFILE_MASK GENMASK(5, 4) +#define CHARGING_PROFILE_HIGH_CAPACITY 0x00 +#define CHARGING_PROFILE_BALANCED 0x01 +#define CHARGING_PROFILE_STATIONARY 0x02 #define TOUCHPAD_TOGGLE_OFF BIT(6) #define EC_ADDR_CHARGE_CTRL 0x07B9 @@ -320,13 +324,15 @@ #define UNIWILL_FEATURE_SUPER_KEY BIT(1) #define UNIWILL_FEATURE_TOUCHPAD_TOGGLE BIT(2) #define UNIWILL_FEATURE_LIGHTBAR BIT(3) -#define UNIWILL_FEATURE_BATTERY BIT(4) -#define UNIWILL_FEATURE_CPU_TEMP BIT(5) -#define UNIWILL_FEATURE_GPU_TEMP BIT(6) -#define UNIWILL_FEATURE_PRIMARY_FAN BIT(7) -#define UNIWILL_FEATURE_SECONDARY_FAN BIT(8) -#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(9) -#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(10) +#define UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT BIT(4) +/* Mutually exclusive with the charge limit feature */ +#define UNIWILL_FEATURE_BATTERY_CHARGE_MODES BIT(5) +#define UNIWILL_FEATURE_CPU_TEMP BIT(6) +#define UNIWILL_FEATURE_GPU_TEMP BIT(7) +#define UNIWILL_FEATURE_PRIMARY_FAN BIT(8) +#define UNIWILL_FEATURE_SECONDARY_FAN BIT(9) +#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(10) +#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(11) enum usb_c_power_priority_options { USB_C_POWER_PRIORITY_CHARGING = 0, @@ -339,8 +345,15 @@ struct uniwill_data { struct regmap *regmap; unsigned int features; struct acpi_battery_hook hook; - unsigned int last_charge_ctrl; struct mutex battery_lock; /* Protects the list of currently registered batteries */ + union { + struct { + /* Protects writes to last_charge_type */ + struct mutex charge_type_lock; + enum power_supply_charge_type last_charge_type; + }; + unsigned int last_charge_ctrl; + }; bool last_fn_lock_state; bool last_super_key_enable_state; bool last_touchpad_toggle_enable_state; @@ -447,6 +460,12 @@ static inline bool uniwill_device_supports(const struct uniwill_data *data, return (data->features & features) == features; } +static inline bool uniwill_device_supports_any(const struct uniwill_data *data, + unsigned int features) +{ + return data->features & features; +} + static int uniwill_ec_reg_write(void *context, unsigned int reg, unsigned int val) { union acpi_object params[2] = { @@ -1421,6 +1440,30 @@ static int uniwill_led_init(struct uniwill_data *data) &init_data); } +static int uniwill_read_charge_type(struct uniwill_data *data, enum power_supply_charge_type *type) +{ + unsigned int value; + int ret; + + ret = regmap_read(data->regmap, EC_ADDR_OEM_4, &value); + if (ret < 0) + return ret; + + switch (FIELD_GET(CHARGING_PROFILE_MASK, value)) { + case CHARGING_PROFILE_HIGH_CAPACITY: + *type = POWER_SUPPLY_CHARGE_TYPE_STANDARD; + return 0; + case CHARGING_PROFILE_BALANCED: + *type = POWER_SUPPLY_CHARGE_TYPE_LONGLIFE; + return 0; + case CHARGING_PROFILE_STATIONARY: + *type = POWER_SUPPLY_CHARGE_TYPE_TRICKLE; + return 0; + default: + return -EPROTO; + } +} + static int uniwill_get_property(struct power_supply *psy, const struct power_supply_ext *ext, void *drvdata, enum power_supply_property psp, union power_supply_propval *val) @@ -1431,6 +1474,16 @@ static int uniwill_get_property(struct power_supply *psy, const struct power_sup int ret; switch (psp) { + case POWER_SUPPLY_PROP_CHARGE_TYPES: + /* + * We need to use the cached value here because the charging mode + * reported by the EC might temporarily change when a external power + * source has been connected. + */ + mutex_lock(&data->charge_type_lock); + val->intval = data->last_charge_type; + mutex_unlock(&data->charge_type_lock); + return 0; case POWER_SUPPLY_PROP_HEALTH: ret = power_supply_get_property_direct(psy, POWER_SUPPLY_PROP_PRESENT, &prop); if (ret < 0) @@ -1479,13 +1532,52 @@ static int uniwill_get_property(struct power_supply *psy, const struct power_sup } } +static int uniwill_write_charge_type(struct uniwill_data *data, enum power_supply_charge_type type) +{ + unsigned int value; + + switch (type) { + case POWER_SUPPLY_CHARGE_TYPE_TRICKLE: + value = FIELD_PREP(CHARGING_PROFILE_MASK, CHARGING_PROFILE_STATIONARY); + break; + case POWER_SUPPLY_CHARGE_TYPE_STANDARD: + value = FIELD_PREP(CHARGING_PROFILE_MASK, CHARGING_PROFILE_HIGH_CAPACITY); + break; + case POWER_SUPPLY_CHARGE_TYPE_LONGLIFE: + value = FIELD_PREP(CHARGING_PROFILE_MASK, CHARGING_PROFILE_BALANCED); + break; + default: + return -EINVAL; + } + + return regmap_update_bits(data->regmap, EC_ADDR_OEM_4, CHARGING_PROFILE_MASK, value); +} + +static int uniwill_restore_charge_type(struct uniwill_data *data) +{ + guard(mutex)(&data->charge_type_lock); + + return uniwill_write_charge_type(data, data->last_charge_type); +} + static int uniwill_set_property(struct power_supply *psy, const struct power_supply_ext *ext, void *drvdata, enum power_supply_property psp, const union power_supply_propval *val) { struct uniwill_data *data = drvdata; + int ret; switch (psp) { + case POWER_SUPPLY_PROP_CHARGE_TYPES: + mutex_lock(&data->charge_type_lock); + + ret = uniwill_write_charge_type(data, val->intval); + if (ret >= 0) + data->last_charge_type = val->intval; + + mutex_unlock(&data->charge_type_lock); + + return ret; case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: if (val->intval < 0 || val->intval > 100) return -EINVAL; @@ -1501,21 +1593,41 @@ static int uniwill_property_is_writeable(struct power_supply *psy, const struct power_supply_ext *ext, void *drvdata, enum power_supply_property psp) { - if (psp == POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD) + switch (psp) { + case POWER_SUPPLY_PROP_CHARGE_TYPES: + case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: return true; - - return false; + default: + return false; + } } -static const enum power_supply_property uniwill_properties[] = { +static const enum power_supply_property uniwill_charge_limit_properties[] = { POWER_SUPPLY_PROP_HEALTH, POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, }; -static const struct power_supply_ext uniwill_extension = { +static const struct power_supply_ext uniwill_charge_limit_extension = { + .name = DRIVER_NAME, + .properties = uniwill_charge_limit_properties, + .num_properties = ARRAY_SIZE(uniwill_charge_limit_properties), + .get_property = uniwill_get_property, + .set_property = uniwill_set_property, + .property_is_writeable = uniwill_property_is_writeable, +}; + +static const enum power_supply_property uniwill_charge_modes_properties[] = { + POWER_SUPPLY_PROP_CHARGE_TYPES, + POWER_SUPPLY_PROP_HEALTH, +}; + +static const struct power_supply_ext uniwill_charge_modes_extension = { .name = DRIVER_NAME, - .properties = uniwill_properties, - .num_properties = ARRAY_SIZE(uniwill_properties), + .charge_types = BIT(POWER_SUPPLY_CHARGE_TYPE_TRICKLE) | + BIT(POWER_SUPPLY_CHARGE_TYPE_STANDARD) | + BIT(POWER_SUPPLY_CHARGE_TYPE_LONGLIFE), + .properties = uniwill_charge_modes_properties, + .num_properties = ARRAY_SIZE(uniwill_charge_modes_properties), .get_property = uniwill_get_property, .set_property = uniwill_set_property, .property_is_writeable = uniwill_property_is_writeable, @@ -1531,7 +1643,13 @@ static int uniwill_add_battery(struct power_supply *battery, struct acpi_battery if (!entry) return -ENOMEM; - ret = power_supply_register_extension(battery, &uniwill_extension, data->dev, data); + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) + ret = power_supply_register_extension(battery, &uniwill_charge_limit_extension, + data->dev, data); + else + ret = power_supply_register_extension(battery, &uniwill_charge_modes_extension, + data->dev, data); + if (ret < 0) { kfree(entry); return ret; @@ -1560,7 +1678,10 @@ static int uniwill_remove_battery(struct power_supply *battery, struct acpi_batt } } - power_supply_unregister_extension(battery, &uniwill_extension); + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) + power_supply_unregister_extension(battery, &uniwill_charge_limit_extension); + else + power_supply_unregister_extension(battery, &uniwill_charge_modes_extension); return 0; } @@ -1570,25 +1691,35 @@ static int uniwill_battery_init(struct uniwill_data *data) unsigned int value, threshold; int ret; - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) - return 0; + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) { + ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); + if (ret < 0) + return ret; - ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); - if (ret < 0) - return ret; + /* + * 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); + ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); + if (ret < 0) + return ret; + } + } else { + if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) + return 0; - /* - * 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); - ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); + ret = devm_mutex_init(data->dev, &data->charge_type_lock); + if (ret < 0) + return ret; + + ret = uniwill_read_charge_type(data, &data->last_charge_type); if (ret < 0) return ret; } @@ -1609,10 +1740,13 @@ static int uniwill_notifier_call(struct notifier_block *nb, unsigned long action { struct uniwill_data *data = container_of(nb, struct uniwill_data, nb); struct uniwill_battery_entry *entry; + int ret; switch (action) { case UNIWILL_OSD_BATTERY_ALERT: - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) + if (!uniwill_device_supports_any(data, + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | + UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) return NOTIFY_DONE; mutex_lock(&data->battery_lock); @@ -1623,10 +1757,24 @@ static int uniwill_notifier_call(struct notifier_block *nb, unsigned long action return NOTIFY_OK; case UNIWILL_OSD_DC_ADAPTER_CHANGED: - if (!uniwill_device_supports(data, UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) + if (!uniwill_device_supports_any(data, + UNIWILL_FEATURE_BATTERY_CHARGE_MODES | + UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) return NOTIFY_DONE; - return notifier_from_errno(usb_c_power_priority_restore(data)); + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { + ret = uniwill_restore_charge_type(data); + if (ret < 0) + return notifier_from_errno(ret); + } + + if (uniwill_device_supports(data, UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) { + ret = usb_c_power_priority_restore(data); + if (ret < 0) + return notifier_from_errno(ret); + } + + return NOTIFY_OK; case UNIWILL_OSD_FN_LOCK: if (!uniwill_device_supports(data, UNIWILL_FEATURE_FN_LOCK)) return NOTIFY_DONE; @@ -1810,7 +1958,7 @@ static int uniwill_suspend_touchpad_toggle(struct uniwill_data *data) static int uniwill_suspend_battery(struct uniwill_data *data) { - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) + if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) return 0; /* @@ -1887,7 +2035,15 @@ static int uniwill_resume_touchpad_toggle(struct uniwill_data *data) static int uniwill_resume_battery(struct uniwill_data *data) { - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) + int ret; + + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { + ret = uniwill_restore_charge_type(data); + if (ret < 0) + return ret; + } + + if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) return 0; return regmap_update_bits(data->regmap, EC_ADDR_CHARGE_CTRL, CHARGE_CTRL_MASK, @@ -1970,7 +2126,7 @@ static struct platform_driver uniwill_driver = { static struct uniwill_device_descriptor lapqc71a_lapqc71b_descriptor __initdata = { .features = UNIWILL_FEATURE_SUPER_KEY | - UNIWILL_FEATURE_BATTERY | + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | UNIWILL_FEATURE_CPU_TEMP | UNIWILL_FEATURE_GPU_TEMP | UNIWILL_FEATURE_PRIMARY_FAN | @@ -1981,7 +2137,7 @@ static struct uniwill_device_descriptor lapac71h_descriptor __initdata = { .features = UNIWILL_FEATURE_FN_LOCK | UNIWILL_FEATURE_SUPER_KEY | UNIWILL_FEATURE_TOUCHPAD_TOGGLE | - UNIWILL_FEATURE_BATTERY | + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | UNIWILL_FEATURE_CPU_TEMP | UNIWILL_FEATURE_GPU_TEMP | UNIWILL_FEATURE_PRIMARY_FAN | @@ -1993,7 +2149,7 @@ static struct uniwill_device_descriptor lapkc71f_descriptor __initdata = { UNIWILL_FEATURE_SUPER_KEY | UNIWILL_FEATURE_TOUCHPAD_TOGGLE | UNIWILL_FEATURE_LIGHTBAR | - UNIWILL_FEATURE_BATTERY | + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | UNIWILL_FEATURE_CPU_TEMP | UNIWILL_FEATURE_GPU_TEMP | UNIWILL_FEATURE_PRIMARY_FAN | @@ -2578,8 +2734,8 @@ static int __init uniwill_init(void) } if (force) { - /* Assume that the device supports all features */ - device_descriptor.features = UINT_MAX; + /* Assume that the device supports all features except the charge limit */ + device_descriptor.features = UINT_MAX & ~UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT; pr_warn("Enabling potentially unsupported features\n"); } diff --git a/drivers/platform/x86/uniwill/uniwill-wmi.c b/drivers/platform/x86/uniwill/uniwill-wmi.c index 31d9c39f14ab..f1b89bc63df6 100644 --- a/drivers/platform/x86/uniwill/uniwill-wmi.c +++ b/drivers/platform/x86/uniwill/uniwill-wmi.c @@ -48,6 +48,7 @@ int devm_uniwill_wmi_register_notifier(struct device *dev, struct notifier_block static void uniwill_wmi_notify(struct wmi_device *wdev, union acpi_object *obj) { u32 value; + int ret; if (obj->type != ACPI_TYPE_INTEGER) return; @@ -56,7 +57,9 @@ static void uniwill_wmi_notify(struct wmi_device *wdev, union acpi_object *obj) dev_dbg(&wdev->dev, "Received WMI event %u\n", value); - blocking_notifier_call_chain(&uniwill_wmi_chain_head, value, NULL); + ret = blocking_notifier_call_chain(&uniwill_wmi_chain_head, value, NULL); + if (notifier_to_errno(ret) < 0) + dev_err(&wdev->dev, "Failed to handle event %u\n", value); } /* -- 2.39.5 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 6/6] platform/x86: uniwill-laptop: Add support for battery charge modes 2026-04-06 19:36 ` [PATCH 6/6] platform/x86: uniwill-laptop: Add support for battery charge modes Armin Wolf @ 2026-04-10 16:53 ` Werner Sembach 2026-04-10 17:53 ` Armin Wolf 0 siblings, 1 reply; 22+ messages in thread From: Werner Sembach @ 2026-04-10 16:53 UTC (permalink / raw) To: Armin Wolf, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Hi Armin, Am 06.04.26 um 21:36 schrieb Armin Wolf: > Many Uniwill-based devices do not supports the already existing > charge limit functionality, but instead support an alternative > interface for controlling the battery charge algorithm. > > Add support for this interface and update the documentation. > > Signed-off-by: Armin Wolf <W_Armin@gmx.de> > --- > .../admin-guide/laptops/uniwill-laptop.rst | 25 +- > drivers/platform/x86/uniwill/uniwill-acpi.c | 244 ++++++++++++++---- > drivers/platform/x86/uniwill/uniwill-wmi.c | 5 +- > 3 files changed, 226 insertions(+), 48 deletions(-) > > diff --git a/Documentation/admin-guide/laptops/uniwill-laptop.rst b/Documentation/admin-guide/laptops/uniwill-laptop.rst > index 561334865feb..24b41dbab886 100644 > --- a/Documentation/admin-guide/laptops/uniwill-laptop.rst > +++ b/Documentation/admin-guide/laptops/uniwill-laptop.rst > @@ -43,9 +43,23 @@ Support for changing the platform performance mode is currently not implemented. > Battery Charging Control > ------------------------ > > -The ``uniwill-laptop`` driver supports controlling the battery charge limit. This happens over > -the standard ``charge_control_end_threshold`` power supply sysfs attribute. All values > -between 1 and 100 percent are supported. > +.. warning:: Some devices do not properly implement the charging threshold interface. Forcing > + the driver to enable access to said interface on such devices might damage the > + battery [1]_. Because of this the driver will not enable said feature even when > + using the ``force`` module parameter. The charging profile interface will be > + available instead. > + > +The ``uniwill-laptop`` driver supports controlling the battery charge limit. This either happens > +over the standard ``charge_control_end_threshold`` or ``charge_types`` power supply sysfs attribute, > +depending on the device. When using the ``charge_control_end_threshold`` sysfs attribute, all values > +between 1 and 100 percent are supported. When using the ``charge_types`` sysfs attribute, the driver > +supports switching between the ``Standard``, ``Trickle`` and ``Long Life`` profiles. > + > +Keep in mind that when using the ``charge_types`` sysfs attribute, the EC firmware will hide the > +true charging status of the battery from the operating system, potentially misleading users into > +thinking that the charging profile does not work. Checking the ``current_now`` sysfs attribute > +tells you the true charging status of the battery even when using the ``charge_types`` sysfs > +attribute (0 means that the battery is currently not charging). > > Additionally the driver signals the presence of battery charging issues through the standard > ``health`` power supply sysfs attribute. > @@ -70,3 +84,8 @@ The ``uniwill-laptop`` driver allows to set the configurable TGP for devices wit > allow it. > > See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details. > + > +References > +========== > + > +.. [1] https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/ > diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c > index a116e2ec6453..fbf2e101a074 100644 > --- a/drivers/platform/x86/uniwill/uniwill-acpi.c > +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c > @@ -254,6 +254,10 @@ > > #define EC_ADDR_OEM_4 0x07A6 > #define OVERBOOST_DYN_TEMP_OFF BIT(1) > +#define CHARGING_PROFILE_MASK GENMASK(5, 4) > +#define CHARGING_PROFILE_HIGH_CAPACITY 0x00 > +#define CHARGING_PROFILE_BALANCED 0x01 > +#define CHARGING_PROFILE_STATIONARY 0x02 > #define TOUCHPAD_TOGGLE_OFF BIT(6) > > #define EC_ADDR_CHARGE_CTRL 0x07B9 > @@ -320,13 +324,15 @@ > #define UNIWILL_FEATURE_SUPER_KEY BIT(1) > #define UNIWILL_FEATURE_TOUCHPAD_TOGGLE BIT(2) > #define UNIWILL_FEATURE_LIGHTBAR BIT(3) > -#define UNIWILL_FEATURE_BATTERY BIT(4) > -#define UNIWILL_FEATURE_CPU_TEMP BIT(5) > -#define UNIWILL_FEATURE_GPU_TEMP BIT(6) > -#define UNIWILL_FEATURE_PRIMARY_FAN BIT(7) > -#define UNIWILL_FEATURE_SECONDARY_FAN BIT(8) > -#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(9) > -#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(10) > +#define UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT BIT(4) > +/* Mutually exclusive with the charge limit feature */ > +#define UNIWILL_FEATURE_BATTERY_CHARGE_MODES BIT(5) > +#define UNIWILL_FEATURE_CPU_TEMP BIT(6) > +#define UNIWILL_FEATURE_GPU_TEMP BIT(7) > +#define UNIWILL_FEATURE_PRIMARY_FAN BIT(8) > +#define UNIWILL_FEATURE_SECONDARY_FAN BIT(9) > +#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(10) > +#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(11) > > enum usb_c_power_priority_options { > USB_C_POWER_PRIORITY_CHARGING = 0, > @@ -339,8 +345,15 @@ struct uniwill_data { > struct regmap *regmap; > unsigned int features; > struct acpi_battery_hook hook; > - unsigned int last_charge_ctrl; > struct mutex battery_lock; /* Protects the list of currently registered batteries */ > + union { > + struct { > + /* Protects writes to last_charge_type */ > + struct mutex charge_type_lock; > + enum power_supply_charge_type last_charge_type; > + }; > + unsigned int last_charge_ctrl; > + }; > bool last_fn_lock_state; > bool last_super_key_enable_state; > bool last_touchpad_toggle_enable_state; > @@ -447,6 +460,12 @@ static inline bool uniwill_device_supports(const struct uniwill_data *data, > return (data->features & features) == features; > } > > +static inline bool uniwill_device_supports_any(const struct uniwill_data *data, > + unsigned int features) > +{ > + return data->features & features; > +} > + Maybe add a "!= 0" to make the return a clear 1 or 0 > static int uniwill_ec_reg_write(void *context, unsigned int reg, unsigned int val) > { > union acpi_object params[2] = { > @@ -1421,6 +1440,30 @@ static int uniwill_led_init(struct uniwill_data *data) > &init_data); > } > > +static int uniwill_read_charge_type(struct uniwill_data *data, enum power_supply_charge_type *type) > +{ > + unsigned int value; > + int ret; > + > + ret = regmap_read(data->regmap, EC_ADDR_OEM_4, &value); > + if (ret < 0) > + return ret; > + > + switch (FIELD_GET(CHARGING_PROFILE_MASK, value)) { > + case CHARGING_PROFILE_HIGH_CAPACITY: > + *type = POWER_SUPPLY_CHARGE_TYPE_STANDARD; > + return 0; > + case CHARGING_PROFILE_BALANCED: > + *type = POWER_SUPPLY_CHARGE_TYPE_LONGLIFE; > + return 0; > + case CHARGING_PROFILE_STATIONARY: > + *type = POWER_SUPPLY_CHARGE_TYPE_TRICKLE; > + return 0; > + default: > + return -EPROTO; > + } > +} Like I wrote here: https://github.com/Wer-Wolf/uniwill-laptop/issues/6#issuecomment-3987100594 I think it would be less confusing to use POWER_SUPPLY_CHARGE_TYPE_TRICKLE -> CHARGING_PROFILE_STATIONARY POWER_SUPPLY_CHARGE_TYPE_STANDARD -> CHARGING_PROFILE_BALANCED POWER_SUPPLY_CHARGE_TYPE_FAST -> CHARGING_PROFILE_HIGH_CAPACITY because then the charge speed is at least clearly communicated POWER_SUPPLY_CHARGE_TYPE_FAST would then be the default > + > static int uniwill_get_property(struct power_supply *psy, const struct power_supply_ext *ext, > void *drvdata, enum power_supply_property psp, > union power_supply_propval *val) > @@ -1431,6 +1474,16 @@ static int uniwill_get_property(struct power_supply *psy, const struct power_sup > int ret; > > switch (psp) { > + case POWER_SUPPLY_PROP_CHARGE_TYPES: > + /* > + * We need to use the cached value here because the charging mode > + * reported by the EC might temporarily change when a external power > + * source has been connected. > + */ > + mutex_lock(&data->charge_type_lock); > + val->intval = data->last_charge_type; > + mutex_unlock(&data->charge_type_lock); > + return 0; > case POWER_SUPPLY_PROP_HEALTH: > ret = power_supply_get_property_direct(psy, POWER_SUPPLY_PROP_PRESENT, &prop); > if (ret < 0) > @@ -1479,13 +1532,52 @@ static int uniwill_get_property(struct power_supply *psy, const struct power_sup > } > } > > +static int uniwill_write_charge_type(struct uniwill_data *data, enum power_supply_charge_type type) > +{ > + unsigned int value; > + > + switch (type) { > + case POWER_SUPPLY_CHARGE_TYPE_TRICKLE: > + value = FIELD_PREP(CHARGING_PROFILE_MASK, CHARGING_PROFILE_STATIONARY); > + break; > + case POWER_SUPPLY_CHARGE_TYPE_STANDARD: > + value = FIELD_PREP(CHARGING_PROFILE_MASK, CHARGING_PROFILE_HIGH_CAPACITY); > + break; > + case POWER_SUPPLY_CHARGE_TYPE_LONGLIFE: > + value = FIELD_PREP(CHARGING_PROFILE_MASK, CHARGING_PROFILE_BALANCED); > + break; > + default: > + return -EINVAL; > + } > + > + return regmap_update_bits(data->regmap, EC_ADDR_OEM_4, CHARGING_PROFILE_MASK, value); > +} > + > +static int uniwill_restore_charge_type(struct uniwill_data *data) > +{ > + guard(mutex)(&data->charge_type_lock); > + > + return uniwill_write_charge_type(data, data->last_charge_type); > +} > + > static int uniwill_set_property(struct power_supply *psy, const struct power_supply_ext *ext, > void *drvdata, enum power_supply_property psp, > const union power_supply_propval *val) > { > struct uniwill_data *data = drvdata; > + int ret; > > switch (psp) { > + case POWER_SUPPLY_PROP_CHARGE_TYPES: > + mutex_lock(&data->charge_type_lock); > + > + ret = uniwill_write_charge_type(data, val->intval); > + if (ret >= 0) > + data->last_charge_type = val->intval; > + > + mutex_unlock(&data->charge_type_lock); > + > + return ret; > case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: > if (val->intval < 0 || val->intval > 100) > return -EINVAL; > @@ -1501,21 +1593,41 @@ static int uniwill_property_is_writeable(struct power_supply *psy, > const struct power_supply_ext *ext, void *drvdata, > enum power_supply_property psp) > { > - if (psp == POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD) > + switch (psp) { > + case POWER_SUPPLY_PROP_CHARGE_TYPES: > + case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: > return true; > - > - return false; > + default: > + return false; > + } > } Could be mistaken, but does this work without producing a compiler warning or error not having a return on the top level? > > -static const enum power_supply_property uniwill_properties[] = { > +static const enum power_supply_property uniwill_charge_limit_properties[] = { > POWER_SUPPLY_PROP_HEALTH, > POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, > }; > > -static const struct power_supply_ext uniwill_extension = { > +static const struct power_supply_ext uniwill_charge_limit_extension = { > + .name = DRIVER_NAME, > + .properties = uniwill_charge_limit_properties, > + .num_properties = ARRAY_SIZE(uniwill_charge_limit_properties), > + .get_property = uniwill_get_property, > + .set_property = uniwill_set_property, > + .property_is_writeable = uniwill_property_is_writeable, > +}; > + > +static const enum power_supply_property uniwill_charge_modes_properties[] = { > + POWER_SUPPLY_PROP_CHARGE_TYPES, > + POWER_SUPPLY_PROP_HEALTH, > +}; > + > +static const struct power_supply_ext uniwill_charge_modes_extension = { > .name = DRIVER_NAME, > - .properties = uniwill_properties, > - .num_properties = ARRAY_SIZE(uniwill_properties), > + .charge_types = BIT(POWER_SUPPLY_CHARGE_TYPE_TRICKLE) | > + BIT(POWER_SUPPLY_CHARGE_TYPE_STANDARD) | > + BIT(POWER_SUPPLY_CHARGE_TYPE_LONGLIFE), > + .properties = uniwill_charge_modes_properties, > + .num_properties = ARRAY_SIZE(uniwill_charge_modes_properties), > .get_property = uniwill_get_property, > .set_property = uniwill_set_property, > .property_is_writeable = uniwill_property_is_writeable, > @@ -1531,7 +1643,13 @@ static int uniwill_add_battery(struct power_supply *battery, struct acpi_battery > if (!entry) > return -ENOMEM; > > - ret = power_supply_register_extension(battery, &uniwill_extension, data->dev, data); > + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) > + ret = power_supply_register_extension(battery, &uniwill_charge_limit_extension, > + data->dev, data); > + else > + ret = power_supply_register_extension(battery, &uniwill_charge_modes_extension, > + data->dev, data); > + Currently there is now way to specify just the health parameter, but i have to check if that is even required > if (ret < 0) { > kfree(entry); > return ret; > @@ -1560,7 +1678,10 @@ static int uniwill_remove_battery(struct power_supply *battery, struct acpi_batt > } > } > > - power_supply_unregister_extension(battery, &uniwill_extension); > + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) > + power_supply_unregister_extension(battery, &uniwill_charge_limit_extension); > + else > + power_supply_unregister_extension(battery, &uniwill_charge_modes_extension); > > return 0; > } > @@ -1570,25 +1691,35 @@ static int uniwill_battery_init(struct uniwill_data *data) > unsigned int value, threshold; > int ret; > > - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) > - return 0; > + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) { > + ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); > + if (ret < 0) > + return ret; > > - ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); > - if (ret < 0) > - return ret; > + /* > + * 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); > + ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); > + if (ret < 0) > + return ret; > + } > + } else { > + if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) > + return 0; Would use an "else if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_MODES))" and put the return 0 at the end of the function. > > - /* > - * 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); > - ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); > + ret = devm_mutex_init(data->dev, &data->charge_type_lock); > + if (ret < 0) > + return ret; > + > + ret = uniwill_read_charge_type(data, &data->last_charge_type); > if (ret < 0) > return ret; > } > @@ -1609,10 +1740,13 @@ static int uniwill_notifier_call(struct notifier_block *nb, unsigned long action > { > struct uniwill_data *data = container_of(nb, struct uniwill_data, nb); > struct uniwill_battery_entry *entry; > + int ret; > > switch (action) { > case UNIWILL_OSD_BATTERY_ALERT: > - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) > + if (!uniwill_device_supports_any(data, > + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | > + UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) > return NOTIFY_DONE; > > mutex_lock(&data->battery_lock); > @@ -1623,10 +1757,24 @@ static int uniwill_notifier_call(struct notifier_block *nb, unsigned long action > > return NOTIFY_OK; > case UNIWILL_OSD_DC_ADAPTER_CHANGED: > - if (!uniwill_device_supports(data, UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) > + if (!uniwill_device_supports_any(data, > + UNIWILL_FEATURE_BATTERY_CHARGE_MODES | > + UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) > return NOTIFY_DONE; > > - return notifier_from_errno(usb_c_power_priority_restore(data)); > + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { > + ret = uniwill_restore_charge_type(data); > + if (ret < 0) > + return notifier_from_errno(ret); > + } > + > + if (uniwill_device_supports(data, UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) { > + ret = usb_c_power_priority_restore(data); > + if (ret < 0) > + return notifier_from_errno(ret); > + } > + > + return NOTIFY_OK; > case UNIWILL_OSD_FN_LOCK: > if (!uniwill_device_supports(data, UNIWILL_FEATURE_FN_LOCK)) > return NOTIFY_DONE; > @@ -1810,7 +1958,7 @@ static int uniwill_suspend_touchpad_toggle(struct uniwill_data *data) > > static int uniwill_suspend_battery(struct uniwill_data *data) > { > - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) > + if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) > return 0; > > /* > @@ -1887,7 +2035,15 @@ static int uniwill_resume_touchpad_toggle(struct uniwill_data *data) > > static int uniwill_resume_battery(struct uniwill_data *data) > { > - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) > + int ret; > + > + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { > + ret = uniwill_restore_charge_type(data); > + if (ret < 0) > + return ret; > + } > + > + if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) > return 0; > > return regmap_update_bits(data->regmap, EC_ADDR_CHARGE_CTRL, CHARGE_CTRL_MASK, > @@ -1970,7 +2126,7 @@ static struct platform_driver uniwill_driver = { > > static struct uniwill_device_descriptor lapqc71a_lapqc71b_descriptor __initdata = { > .features = UNIWILL_FEATURE_SUPER_KEY | > - UNIWILL_FEATURE_BATTERY | > + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | > UNIWILL_FEATURE_CPU_TEMP | > UNIWILL_FEATURE_GPU_TEMP | > UNIWILL_FEATURE_PRIMARY_FAN | > @@ -1981,7 +2137,7 @@ static struct uniwill_device_descriptor lapac71h_descriptor __initdata = { > .features = UNIWILL_FEATURE_FN_LOCK | > UNIWILL_FEATURE_SUPER_KEY | > UNIWILL_FEATURE_TOUCHPAD_TOGGLE | > - UNIWILL_FEATURE_BATTERY | > + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | > UNIWILL_FEATURE_CPU_TEMP | > UNIWILL_FEATURE_GPU_TEMP | > UNIWILL_FEATURE_PRIMARY_FAN | > @@ -1993,7 +2149,7 @@ static struct uniwill_device_descriptor lapkc71f_descriptor __initdata = { > UNIWILL_FEATURE_SUPER_KEY | > UNIWILL_FEATURE_TOUCHPAD_TOGGLE | > UNIWILL_FEATURE_LIGHTBAR | > - UNIWILL_FEATURE_BATTERY | > + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | > UNIWILL_FEATURE_CPU_TEMP | > UNIWILL_FEATURE_GPU_TEMP | > UNIWILL_FEATURE_PRIMARY_FAN | Maybe we should put in some assertion to ensure that UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT and UNIWILL_FEATURE_BATTERY_CHARGE_MODES are not set at the same time, or it that being to wary? > @@ -2578,8 +2734,8 @@ static int __init uniwill_init(void) > } > > if (force) { > - /* Assume that the device supports all features */ > - device_descriptor.features = UINT_MAX; > + /* Assume that the device supports all features except the charge limit */ > + device_descriptor.features = UINT_MAX & ~UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT; > pr_warn("Enabling potentially unsupported features\n"); > } > > diff --git a/drivers/platform/x86/uniwill/uniwill-wmi.c b/drivers/platform/x86/uniwill/uniwill-wmi.c > index 31d9c39f14ab..f1b89bc63df6 100644 > --- a/drivers/platform/x86/uniwill/uniwill-wmi.c > +++ b/drivers/platform/x86/uniwill/uniwill-wmi.c > @@ -48,6 +48,7 @@ int devm_uniwill_wmi_register_notifier(struct device *dev, struct notifier_block > static void uniwill_wmi_notify(struct wmi_device *wdev, union acpi_object *obj) > { > u32 value; > + int ret; > > if (obj->type != ACPI_TYPE_INTEGER) > return; > @@ -56,7 +57,9 @@ static void uniwill_wmi_notify(struct wmi_device *wdev, union acpi_object *obj) > > dev_dbg(&wdev->dev, "Received WMI event %u\n", value); > > - blocking_notifier_call_chain(&uniwill_wmi_chain_head, value, NULL); > + ret = blocking_notifier_call_chain(&uniwill_wmi_chain_head, value, NULL); > + if (notifier_to_errno(ret) < 0) > + dev_err(&wdev->dev, "Failed to handle event %u\n", value); > } > > /* Is this something specific for this patch or just general cleanup that sneaked into here? Best regards, Werner ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 6/6] platform/x86: uniwill-laptop: Add support for battery charge modes 2026-04-10 16:53 ` Werner Sembach @ 2026-04-10 17:53 ` Armin Wolf 2026-04-10 20:24 ` Werner Sembach 0 siblings, 1 reply; 22+ messages in thread From: Armin Wolf @ 2026-04-10 17:53 UTC (permalink / raw) To: Werner Sembach, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 10.04.26 um 18:53 schrieb Werner Sembach: > Hi Armin, > > Am 06.04.26 um 21:36 schrieb Armin Wolf: >> Many Uniwill-based devices do not supports the already existing >> charge limit functionality, but instead support an alternative >> interface for controlling the battery charge algorithm. >> >> Add support for this interface and update the documentation. >> >> Signed-off-by: Armin Wolf <W_Armin@gmx.de> >> --- >> .../admin-guide/laptops/uniwill-laptop.rst | 25 +- >> drivers/platform/x86/uniwill/uniwill-acpi.c | 244 ++++++++++++++---- >> drivers/platform/x86/uniwill/uniwill-wmi.c | 5 +- >> 3 files changed, 226 insertions(+), 48 deletions(-) >> >> diff --git a/Documentation/admin-guide/laptops/uniwill-laptop.rst >> b/Documentation/admin-guide/laptops/uniwill-laptop.rst >> index 561334865feb..24b41dbab886 100644 >> --- a/Documentation/admin-guide/laptops/uniwill-laptop.rst >> +++ b/Documentation/admin-guide/laptops/uniwill-laptop.rst >> @@ -43,9 +43,23 @@ Support for changing the platform performance mode >> is currently not implemented. >> Battery Charging Control >> ------------------------ >> -The ``uniwill-laptop`` driver supports controlling the battery >> charge limit. This happens over >> -the standard ``charge_control_end_threshold`` power supply sysfs >> attribute. All values >> -between 1 and 100 percent are supported. >> +.. warning:: Some devices do not properly implement the charging >> threshold interface. Forcing >> + the driver to enable access to said interface on such >> devices might damage the >> + battery [1]_. Because of this the driver will not >> enable said feature even when >> + using the ``force`` module parameter. The charging >> profile interface will be >> + available instead. >> + >> +The ``uniwill-laptop`` driver supports controlling the battery >> charge limit. This either happens >> +over the standard ``charge_control_end_threshold`` or >> ``charge_types`` power supply sysfs attribute, >> +depending on the device. When using the >> ``charge_control_end_threshold`` sysfs attribute, all values >> +between 1 and 100 percent are supported. When using the >> ``charge_types`` sysfs attribute, the driver >> +supports switching between the ``Standard``, ``Trickle`` and ``Long >> Life`` profiles. >> + >> +Keep in mind that when using the ``charge_types`` sysfs attribute, >> the EC firmware will hide the >> +true charging status of the battery from the operating system, >> potentially misleading users into >> +thinking that the charging profile does not work. Checking the >> ``current_now`` sysfs attribute >> +tells you the true charging status of the battery even when using >> the ``charge_types`` sysfs >> +attribute (0 means that the battery is currently not charging). >> Additionally the driver signals the presence of battery charging >> issues through the standard >> ``health`` power supply sysfs attribute. >> @@ -70,3 +84,8 @@ The ``uniwill-laptop`` driver allows to set the >> configurable TGP for devices wit >> allow it. >> See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for >> details. >> + >> +References >> +========== >> + >> +.. [1] >> https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/ >> diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c >> b/drivers/platform/x86/uniwill/uniwill-acpi.c >> index a116e2ec6453..fbf2e101a074 100644 >> --- a/drivers/platform/x86/uniwill/uniwill-acpi.c >> +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c >> @@ -254,6 +254,10 @@ >> #define EC_ADDR_OEM_4 0x07A6 >> #define OVERBOOST_DYN_TEMP_OFF BIT(1) >> +#define CHARGING_PROFILE_MASK GENMASK(5, 4) >> +#define CHARGING_PROFILE_HIGH_CAPACITY 0x00 >> +#define CHARGING_PROFILE_BALANCED 0x01 >> +#define CHARGING_PROFILE_STATIONARY 0x02 >> #define TOUCHPAD_TOGGLE_OFF BIT(6) >> #define EC_ADDR_CHARGE_CTRL 0x07B9 >> @@ -320,13 +324,15 @@ >> #define UNIWILL_FEATURE_SUPER_KEY BIT(1) >> #define UNIWILL_FEATURE_TOUCHPAD_TOGGLE BIT(2) >> #define UNIWILL_FEATURE_LIGHTBAR BIT(3) >> -#define UNIWILL_FEATURE_BATTERY BIT(4) >> -#define UNIWILL_FEATURE_CPU_TEMP BIT(5) >> -#define UNIWILL_FEATURE_GPU_TEMP BIT(6) >> -#define UNIWILL_FEATURE_PRIMARY_FAN BIT(7) >> -#define UNIWILL_FEATURE_SECONDARY_FAN BIT(8) >> -#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(9) >> -#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(10) >> +#define UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT BIT(4) >> +/* Mutually exclusive with the charge limit feature */ >> +#define UNIWILL_FEATURE_BATTERY_CHARGE_MODES BIT(5) >> +#define UNIWILL_FEATURE_CPU_TEMP BIT(6) >> +#define UNIWILL_FEATURE_GPU_TEMP BIT(7) >> +#define UNIWILL_FEATURE_PRIMARY_FAN BIT(8) >> +#define UNIWILL_FEATURE_SECONDARY_FAN BIT(9) >> +#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(10) >> +#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(11) >> enum usb_c_power_priority_options { >> USB_C_POWER_PRIORITY_CHARGING = 0, >> @@ -339,8 +345,15 @@ struct uniwill_data { >> struct regmap *regmap; >> unsigned int features; >> struct acpi_battery_hook hook; >> - unsigned int last_charge_ctrl; >> struct mutex battery_lock; /* Protects the list of currently >> registered batteries */ >> + union { >> + struct { >> + /* Protects writes to last_charge_type */ >> + struct mutex charge_type_lock; >> + enum power_supply_charge_type last_charge_type; >> + }; >> + unsigned int last_charge_ctrl; >> + }; >> bool last_fn_lock_state; >> bool last_super_key_enable_state; >> bool last_touchpad_toggle_enable_state; >> @@ -447,6 +460,12 @@ static inline bool uniwill_device_supports(const >> struct uniwill_data *data, >> return (data->features & features) == features; >> } >> +static inline bool uniwill_device_supports_any(const struct >> uniwill_data *data, >> + unsigned int features) >> +{ >> + return data->features & features; >> +} >> + > Maybe add a "!= 0" to make the return a clear 1 or 0 This function already returns a boolean, so the compiler will already do this for us. >> static int uniwill_ec_reg_write(void *context, unsigned int reg, >> unsigned int val) >> { >> union acpi_object params[2] = { >> @@ -1421,6 +1440,30 @@ static int uniwill_led_init(struct >> uniwill_data *data) >> &init_data); >> } >> +static int uniwill_read_charge_type(struct uniwill_data *data, >> enum power_supply_charge_type *type) >> +{ >> + unsigned int value; >> + int ret; >> + >> + ret = regmap_read(data->regmap, EC_ADDR_OEM_4, &value); >> + if (ret < 0) >> + return ret; >> + >> + switch (FIELD_GET(CHARGING_PROFILE_MASK, value)) { >> + case CHARGING_PROFILE_HIGH_CAPACITY: >> + *type = POWER_SUPPLY_CHARGE_TYPE_STANDARD; >> + return 0; >> + case CHARGING_PROFILE_BALANCED: >> + *type = POWER_SUPPLY_CHARGE_TYPE_LONGLIFE; >> + return 0; >> + case CHARGING_PROFILE_STATIONARY: >> + *type = POWER_SUPPLY_CHARGE_TYPE_TRICKLE; >> + return 0; >> + default: >> + return -EPROTO; >> + } >> +} > Like I wrote here: > https://github.com/Wer-Wolf/uniwill-laptop/issues/6#issuecomment-3987100594 > I think it would be less confusing to use > > POWER_SUPPLY_CHARGE_TYPE_TRICKLE -> CHARGING_PROFILE_STATIONARY > > POWER_SUPPLY_CHARGE_TYPE_STANDARD -> CHARGING_PROFILE_BALANCED > > POWER_SUPPLY_CHARGE_TYPE_FAST -> CHARGING_PROFILE_HIGH_CAPACITY > > because then the charge speed is at least clearly communicated > > POWER_SUPPLY_CHARGE_TYPE_FAST would then be the default > I think that this will confuse userspace applications. POWER_SUPPLY_CHARGE_TYPE_FAST is meant to stand for above-average/non-default charging speed, while POWER_SUPPLY_CHARGE_TYPE_STANDARD is meant to stand for the default/recommended setting. In this case CHARGING_PROFILE_HIGH_CAPACITY is the default charging setting with the default charging speed, and CHARGING_PROFILE_BALANCED is the "Long Life" option with reduced charging speed. CHARGING_PROFILE_STATIONARY on the other hand could as well be called "Primary AC", so POWER_SUPPLY_CHARGE_TYPE_TRICKLE fits best for it. On a separate note, UPower prefers to select "Standard" over "Fast" when disabling the charging threshold. Mapping CHARGING_PROFILE_HIGH_CAPACITY to POWER_SUPPLY_CHARGE_TYPE_FAST would thus confuse users, because disabling the battery charging threshold thru upower will limit them CHARGING_PROFILE_BALANCED. Basically they cannot reach CHARGING_PROFILE_HIGH_CAPACITY again thru UPower when the charging threshold has been enabled. >> + >> static int uniwill_get_property(struct power_supply *psy, const >> struct power_supply_ext *ext, >> void *drvdata, enum power_supply_property psp, >> union power_supply_propval *val) >> @@ -1431,6 +1474,16 @@ static int uniwill_get_property(struct >> power_supply *psy, const struct power_sup >> int ret; >> switch (psp) { >> + case POWER_SUPPLY_PROP_CHARGE_TYPES: >> + /* >> + * We need to use the cached value here because the charging >> mode >> + * reported by the EC might temporarily change when a >> external power >> + * source has been connected. >> + */ >> + mutex_lock(&data->charge_type_lock); >> + val->intval = data->last_charge_type; >> + mutex_unlock(&data->charge_type_lock); >> + return 0; >> case POWER_SUPPLY_PROP_HEALTH: >> ret = power_supply_get_property_direct(psy, >> POWER_SUPPLY_PROP_PRESENT, &prop); >> if (ret < 0) >> @@ -1479,13 +1532,52 @@ static int uniwill_get_property(struct >> power_supply *psy, const struct power_sup >> } >> } >> +static int uniwill_write_charge_type(struct uniwill_data *data, >> enum power_supply_charge_type type) >> +{ >> + unsigned int value; >> + >> + switch (type) { >> + case POWER_SUPPLY_CHARGE_TYPE_TRICKLE: >> + value = FIELD_PREP(CHARGING_PROFILE_MASK, >> CHARGING_PROFILE_STATIONARY); >> + break; >> + case POWER_SUPPLY_CHARGE_TYPE_STANDARD: >> + value = FIELD_PREP(CHARGING_PROFILE_MASK, >> CHARGING_PROFILE_HIGH_CAPACITY); >> + break; >> + case POWER_SUPPLY_CHARGE_TYPE_LONGLIFE: >> + value = FIELD_PREP(CHARGING_PROFILE_MASK, >> CHARGING_PROFILE_BALANCED); >> + break; >> + default: >> + return -EINVAL; >> + } >> + >> + return regmap_update_bits(data->regmap, EC_ADDR_OEM_4, >> CHARGING_PROFILE_MASK, value); >> +} >> + >> +static int uniwill_restore_charge_type(struct uniwill_data *data) >> +{ >> + guard(mutex)(&data->charge_type_lock); >> + >> + return uniwill_write_charge_type(data, data->last_charge_type); >> +} >> + >> static int uniwill_set_property(struct power_supply *psy, const >> struct power_supply_ext *ext, >> void *drvdata, enum power_supply_property psp, >> const union power_supply_propval *val) >> { >> struct uniwill_data *data = drvdata; >> + int ret; >> switch (psp) { >> + case POWER_SUPPLY_PROP_CHARGE_TYPES: >> + mutex_lock(&data->charge_type_lock); >> + >> + ret = uniwill_write_charge_type(data, val->intval); >> + if (ret >= 0) >> + data->last_charge_type = val->intval; >> + >> + mutex_unlock(&data->charge_type_lock); >> + >> + return ret; >> case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: >> if (val->intval < 0 || val->intval > 100) >> return -EINVAL; >> @@ -1501,21 +1593,41 @@ static int >> uniwill_property_is_writeable(struct power_supply *psy, >> const struct power_supply_ext *ext, void >> *drvdata, >> enum power_supply_property psp) >> { >> - if (psp == POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD) >> + switch (psp) { >> + case POWER_SUPPLY_PROP_CHARGE_TYPES: >> + case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: >> return true; >> - >> - return false; >> + default: >> + return false; >> + } >> } > Could be mistaken, but does this work without producing a compiler > warning or error not having a return on the top level? All exits from the switch statement end with a return statement, so we will always leave this function once we enter the switch statement. >> -static const enum power_supply_property uniwill_properties[] = { >> +static const enum power_supply_property >> uniwill_charge_limit_properties[] = { >> POWER_SUPPLY_PROP_HEALTH, >> POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, >> }; >> -static const struct power_supply_ext uniwill_extension = { >> +static const struct power_supply_ext uniwill_charge_limit_extension = { >> + .name = DRIVER_NAME, >> + .properties = uniwill_charge_limit_properties, >> + .num_properties = ARRAY_SIZE(uniwill_charge_limit_properties), >> + .get_property = uniwill_get_property, >> + .set_property = uniwill_set_property, >> + .property_is_writeable = uniwill_property_is_writeable, >> +}; >> + >> +static const enum power_supply_property >> uniwill_charge_modes_properties[] = { >> + POWER_SUPPLY_PROP_CHARGE_TYPES, >> + POWER_SUPPLY_PROP_HEALTH, >> +}; >> + >> +static const struct power_supply_ext uniwill_charge_modes_extension = { >> .name = DRIVER_NAME, >> - .properties = uniwill_properties, >> - .num_properties = ARRAY_SIZE(uniwill_properties), >> + .charge_types = BIT(POWER_SUPPLY_CHARGE_TYPE_TRICKLE) | >> + BIT(POWER_SUPPLY_CHARGE_TYPE_STANDARD) | >> + BIT(POWER_SUPPLY_CHARGE_TYPE_LONGLIFE), >> + .properties = uniwill_charge_modes_properties, >> + .num_properties = ARRAY_SIZE(uniwill_charge_modes_properties), >> .get_property = uniwill_get_property, >> .set_property = uniwill_set_property, >> .property_is_writeable = uniwill_property_is_writeable, >> @@ -1531,7 +1643,13 @@ static int uniwill_add_battery(struct >> power_supply *battery, struct acpi_battery >> if (!entry) >> return -ENOMEM; >> - ret = power_supply_register_extension(battery, >> &uniwill_extension, data->dev, data); >> + if (uniwill_device_supports(data, >> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >> + ret = power_supply_register_extension(battery, >> &uniwill_charge_limit_extension, >> + data->dev, data); >> + else >> + ret = power_supply_register_extension(battery, >> &uniwill_charge_modes_extension, >> + data->dev, data); >> + > Currently there is now way to specify just the health parameter, but i > have to check if that is even required AFAIK the OEM software always bundles this feature with the charging limit or the charging modes. We can separate this in the future should the need arise. >> if (ret < 0) { >> kfree(entry); >> return ret; >> @@ -1560,7 +1678,10 @@ static int uniwill_remove_battery(struct >> power_supply *battery, struct acpi_batt >> } >> } >> - power_supply_unregister_extension(battery, &uniwill_extension); >> + if (uniwill_device_supports(data, >> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >> + power_supply_unregister_extension(battery, >> &uniwill_charge_limit_extension); >> + else >> + power_supply_unregister_extension(battery, >> &uniwill_charge_modes_extension); >> return 0; >> } >> @@ -1570,25 +1691,35 @@ static int uniwill_battery_init(struct >> uniwill_data *data) >> unsigned int value, threshold; >> int ret; >> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >> - return 0; >> + if (uniwill_device_supports(data, >> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) { >> + ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); >> + if (ret < 0) >> + return ret; >> - ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); >> - if (ret < 0) >> - return ret; >> + /* >> + * 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); >> + ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, >> value); >> + if (ret < 0) >> + return ret; >> + } >> + } else { >> + if (!uniwill_device_supports(data, >> UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) >> + return 0; > Would use an "else if (uniwill_device_supports(data, > UNIWILL_FEATURE_BATTERY_CHARGE_MODES))" and put the return 0 at the > end of the function. This would not work, because we must not register the battery extension when both features are not supported. >> - /* >> - * 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); >> - ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); >> + ret = devm_mutex_init(data->dev, &data->charge_type_lock); >> + if (ret < 0) >> + return ret; >> + >> + ret = uniwill_read_charge_type(data, &data->last_charge_type); >> if (ret < 0) >> return ret; >> } >> @@ -1609,10 +1740,13 @@ static int uniwill_notifier_call(struct >> notifier_block *nb, unsigned long action >> { >> struct uniwill_data *data = container_of(nb, struct >> uniwill_data, nb); >> struct uniwill_battery_entry *entry; >> + int ret; >> switch (action) { >> case UNIWILL_OSD_BATTERY_ALERT: >> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >> + if (!uniwill_device_supports_any(data, >> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >> + UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) >> return NOTIFY_DONE; >> mutex_lock(&data->battery_lock); >> @@ -1623,10 +1757,24 @@ static int uniwill_notifier_call(struct >> notifier_block *nb, unsigned long action >> return NOTIFY_OK; >> case UNIWILL_OSD_DC_ADAPTER_CHANGED: >> - if (!uniwill_device_supports(data, >> UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) >> + if (!uniwill_device_supports_any(data, >> + UNIWILL_FEATURE_BATTERY_CHARGE_MODES | >> + UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) >> return NOTIFY_DONE; >> - return >> notifier_from_errno(usb_c_power_priority_restore(data)); >> + if (uniwill_device_supports(data, >> UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { >> + ret = uniwill_restore_charge_type(data); >> + if (ret < 0) >> + return notifier_from_errno(ret); >> + } >> + >> + if (uniwill_device_supports(data, >> UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) { >> + ret = usb_c_power_priority_restore(data); >> + if (ret < 0) >> + return notifier_from_errno(ret); >> + } >> + >> + return NOTIFY_OK; >> case UNIWILL_OSD_FN_LOCK: >> if (!uniwill_device_supports(data, UNIWILL_FEATURE_FN_LOCK)) >> return NOTIFY_DONE; >> @@ -1810,7 +1958,7 @@ static int >> uniwill_suspend_touchpad_toggle(struct uniwill_data *data) >> static int uniwill_suspend_battery(struct uniwill_data *data) >> { >> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >> + if (!uniwill_device_supports(data, >> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >> return 0; >> /* >> @@ -1887,7 +2035,15 @@ static int >> uniwill_resume_touchpad_toggle(struct uniwill_data *data) >> static int uniwill_resume_battery(struct uniwill_data *data) >> { >> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >> + int ret; >> + >> + if (uniwill_device_supports(data, >> UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { >> + ret = uniwill_restore_charge_type(data); >> + if (ret < 0) >> + return ret; >> + } >> + >> + if (!uniwill_device_supports(data, >> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >> return 0; >> return regmap_update_bits(data->regmap, EC_ADDR_CHARGE_CTRL, >> CHARGE_CTRL_MASK, >> @@ -1970,7 +2126,7 @@ static struct platform_driver uniwill_driver = { >> static struct uniwill_device_descriptor >> lapqc71a_lapqc71b_descriptor __initdata = { >> .features = UNIWILL_FEATURE_SUPER_KEY | >> - UNIWILL_FEATURE_BATTERY | >> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >> UNIWILL_FEATURE_CPU_TEMP | >> UNIWILL_FEATURE_GPU_TEMP | >> UNIWILL_FEATURE_PRIMARY_FAN | >> @@ -1981,7 +2137,7 @@ static struct uniwill_device_descriptor >> lapac71h_descriptor __initdata = { >> .features = UNIWILL_FEATURE_FN_LOCK | >> UNIWILL_FEATURE_SUPER_KEY | >> UNIWILL_FEATURE_TOUCHPAD_TOGGLE | >> - UNIWILL_FEATURE_BATTERY | >> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >> UNIWILL_FEATURE_CPU_TEMP | >> UNIWILL_FEATURE_GPU_TEMP | >> UNIWILL_FEATURE_PRIMARY_FAN | >> @@ -1993,7 +2149,7 @@ static struct uniwill_device_descriptor >> lapkc71f_descriptor __initdata = { >> UNIWILL_FEATURE_SUPER_KEY | >> UNIWILL_FEATURE_TOUCHPAD_TOGGLE | >> UNIWILL_FEATURE_LIGHTBAR | >> - UNIWILL_FEATURE_BATTERY | >> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >> UNIWILL_FEATURE_CPU_TEMP | >> UNIWILL_FEATURE_GPU_TEMP | >> UNIWILL_FEATURE_PRIMARY_FAN | > Maybe we should put in some assertion to ensure that > UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT and > UNIWILL_FEATURE_BATTERY_CHARGE_MODES are not set at the same time, or > it that being to wary? I do not think that we really need that. Those device descriptors are mostly static and have a fairly trivial structure, so we should easily spot such a mistake. >> @@ -2578,8 +2734,8 @@ static int __init uniwill_init(void) >> } >> if (force) { >> - /* Assume that the device supports all features */ >> - device_descriptor.features = UINT_MAX; >> + /* Assume that the device supports all features except the >> charge limit */ >> + device_descriptor.features = UINT_MAX & >> ~UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT; >> pr_warn("Enabling potentially unsupported features\n"); >> } >> diff --git a/drivers/platform/x86/uniwill/uniwill-wmi.c >> b/drivers/platform/x86/uniwill/uniwill-wmi.c >> index 31d9c39f14ab..f1b89bc63df6 100644 >> --- a/drivers/platform/x86/uniwill/uniwill-wmi.c >> +++ b/drivers/platform/x86/uniwill/uniwill-wmi.c >> @@ -48,6 +48,7 @@ int devm_uniwill_wmi_register_notifier(struct >> device *dev, struct notifier_block >> static void uniwill_wmi_notify(struct wmi_device *wdev, union >> acpi_object *obj) >> { >> u32 value; >> + int ret; >> if (obj->type != ACPI_TYPE_INTEGER) >> return; >> @@ -56,7 +57,9 @@ static void uniwill_wmi_notify(struct wmi_device >> *wdev, union acpi_object *obj) >> dev_dbg(&wdev->dev, "Received WMI event %u\n", value); >> - blocking_notifier_call_chain(&uniwill_wmi_chain_head, value, >> NULL); >> + ret = blocking_notifier_call_chain(&uniwill_wmi_chain_head, >> value, NULL); >> + if (notifier_to_errno(ret) < 0) >> + dev_err(&wdev->dev, "Failed to handle event %u\n", value); >> } >> /* > Is this something specific for this patch or just general cleanup that > sneaked into here? > > Best regards, > > Werner It is necessary because handling of UNIWILL_OSD_DC_ADAPTER_CHANGED can now fail with an error code. I decided to place the "error handling" code inside uniwill_wmi_notify() so that the resulting error codes are not silently swallowed. Thanks, Armin Wolf ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 6/6] platform/x86: uniwill-laptop: Add support for battery charge modes 2026-04-10 17:53 ` Armin Wolf @ 2026-04-10 20:24 ` Werner Sembach 2026-04-10 21:47 ` Armin Wolf 0 siblings, 1 reply; 22+ messages in thread From: Werner Sembach @ 2026-04-10 20:24 UTC (permalink / raw) To: Armin Wolf, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 10.04.26 um 19:53 schrieb Armin Wolf: > Am 10.04.26 um 18:53 schrieb Werner Sembach: > >> Hi Armin, >> >> Am 06.04.26 um 21:36 schrieb Armin Wolf: >>> Many Uniwill-based devices do not supports the already existing >>> charge limit functionality, but instead support an alternative >>> interface for controlling the battery charge algorithm. >>> >>> Add support for this interface and update the documentation. >>> >>> Signed-off-by: Armin Wolf <W_Armin@gmx.de> >>> --- >>> .../admin-guide/laptops/uniwill-laptop.rst | 25 +- >>> drivers/platform/x86/uniwill/uniwill-acpi.c | 244 ++++++++++++++---- >>> drivers/platform/x86/uniwill/uniwill-wmi.c | 5 +- >>> 3 files changed, 226 insertions(+), 48 deletions(-) >>> >>> diff --git a/Documentation/admin-guide/laptops/uniwill-laptop.rst >>> b/Documentation/admin-guide/laptops/uniwill-laptop.rst >>> index 561334865feb..24b41dbab886 100644 >>> --- a/Documentation/admin-guide/laptops/uniwill-laptop.rst >>> +++ b/Documentation/admin-guide/laptops/uniwill-laptop.rst >>> @@ -43,9 +43,23 @@ Support for changing the platform performance mode is >>> currently not implemented. >>> Battery Charging Control >>> ------------------------ >>> -The ``uniwill-laptop`` driver supports controlling the battery charge >>> limit. This happens over >>> -the standard ``charge_control_end_threshold`` power supply sysfs attribute. >>> All values >>> -between 1 and 100 percent are supported. >>> +.. warning:: Some devices do not properly implement the charging threshold >>> interface. Forcing >>> + the driver to enable access to said interface on such devices >>> might damage the >>> + battery [1]_. Because of this the driver will not enable said >>> feature even when >>> + using the ``force`` module parameter. The charging profile >>> interface will be >>> + available instead. >>> + >>> +The ``uniwill-laptop`` driver supports controlling the battery charge >>> limit. This either happens >>> +over the standard ``charge_control_end_threshold`` or ``charge_types`` >>> power supply sysfs attribute, >>> +depending on the device. When using the ``charge_control_end_threshold`` >>> sysfs attribute, all values >>> +between 1 and 100 percent are supported. When using the ``charge_types`` >>> sysfs attribute, the driver >>> +supports switching between the ``Standard``, ``Trickle`` and ``Long Life`` >>> profiles. >>> + >>> +Keep in mind that when using the ``charge_types`` sysfs attribute, the EC >>> firmware will hide the >>> +true charging status of the battery from the operating system, potentially >>> misleading users into >>> +thinking that the charging profile does not work. Checking the >>> ``current_now`` sysfs attribute >>> +tells you the true charging status of the battery even when using the >>> ``charge_types`` sysfs >>> +attribute (0 means that the battery is currently not charging). >>> Additionally the driver signals the presence of battery charging issues >>> through the standard >>> ``health`` power supply sysfs attribute. >>> @@ -70,3 +84,8 @@ The ``uniwill-laptop`` driver allows to set the >>> configurable TGP for devices wit >>> allow it. >>> See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details. >>> + >>> +References >>> +========== >>> + >>> +.. [1] >>> https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/ >>> diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c >>> b/drivers/platform/x86/uniwill/uniwill-acpi.c >>> index a116e2ec6453..fbf2e101a074 100644 >>> --- a/drivers/platform/x86/uniwill/uniwill-acpi.c >>> +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c >>> @@ -254,6 +254,10 @@ >>> #define EC_ADDR_OEM_4 0x07A6 >>> #define OVERBOOST_DYN_TEMP_OFF BIT(1) >>> +#define CHARGING_PROFILE_MASK GENMASK(5, 4) >>> +#define CHARGING_PROFILE_HIGH_CAPACITY 0x00 >>> +#define CHARGING_PROFILE_BALANCED 0x01 >>> +#define CHARGING_PROFILE_STATIONARY 0x02 >>> #define TOUCHPAD_TOGGLE_OFF BIT(6) >>> #define EC_ADDR_CHARGE_CTRL 0x07B9 >>> @@ -320,13 +324,15 @@ >>> #define UNIWILL_FEATURE_SUPER_KEY BIT(1) >>> #define UNIWILL_FEATURE_TOUCHPAD_TOGGLE BIT(2) >>> #define UNIWILL_FEATURE_LIGHTBAR BIT(3) >>> -#define UNIWILL_FEATURE_BATTERY BIT(4) >>> -#define UNIWILL_FEATURE_CPU_TEMP BIT(5) >>> -#define UNIWILL_FEATURE_GPU_TEMP BIT(6) >>> -#define UNIWILL_FEATURE_PRIMARY_FAN BIT(7) >>> -#define UNIWILL_FEATURE_SECONDARY_FAN BIT(8) >>> -#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(9) >>> -#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(10) >>> +#define UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT BIT(4) >>> +/* Mutually exclusive with the charge limit feature */ >>> +#define UNIWILL_FEATURE_BATTERY_CHARGE_MODES BIT(5) >>> +#define UNIWILL_FEATURE_CPU_TEMP BIT(6) >>> +#define UNIWILL_FEATURE_GPU_TEMP BIT(7) >>> +#define UNIWILL_FEATURE_PRIMARY_FAN BIT(8) >>> +#define UNIWILL_FEATURE_SECONDARY_FAN BIT(9) >>> +#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(10) >>> +#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(11) >>> enum usb_c_power_priority_options { >>> USB_C_POWER_PRIORITY_CHARGING = 0, >>> @@ -339,8 +345,15 @@ struct uniwill_data { >>> struct regmap *regmap; >>> unsigned int features; >>> struct acpi_battery_hook hook; >>> - unsigned int last_charge_ctrl; >>> struct mutex battery_lock; /* Protects the list of currently >>> registered batteries */ >>> + union { >>> + struct { >>> + /* Protects writes to last_charge_type */ >>> + struct mutex charge_type_lock; >>> + enum power_supply_charge_type last_charge_type; >>> + }; >>> + unsigned int last_charge_ctrl; >>> + }; >>> bool last_fn_lock_state; >>> bool last_super_key_enable_state; >>> bool last_touchpad_toggle_enable_state; >>> @@ -447,6 +460,12 @@ static inline bool uniwill_device_supports(const struct >>> uniwill_data *data, >>> return (data->features & features) == features; >>> } >>> +static inline bool uniwill_device_supports_any(const struct uniwill_data >>> *data, >>> + unsigned int features) >>> +{ >>> + return data->features & features; >>> +} >>> + >> Maybe add a "!= 0" to make the return a clear 1 or 0 > > This function already returns a boolean, so the compiler will already do this > for us. ack > >>> static int uniwill_ec_reg_write(void *context, unsigned int reg, unsigned >>> int val) >>> { >>> union acpi_object params[2] = { >>> @@ -1421,6 +1440,30 @@ static int uniwill_led_init(struct uniwill_data *data) >>> &init_data); >>> } >>> +static int uniwill_read_charge_type(struct uniwill_data *data, enum >>> power_supply_charge_type *type) >>> +{ >>> + unsigned int value; >>> + int ret; >>> + >>> + ret = regmap_read(data->regmap, EC_ADDR_OEM_4, &value); >>> + if (ret < 0) >>> + return ret; >>> + >>> + switch (FIELD_GET(CHARGING_PROFILE_MASK, value)) { >>> + case CHARGING_PROFILE_HIGH_CAPACITY: >>> + *type = POWER_SUPPLY_CHARGE_TYPE_STANDARD; >>> + return 0; >>> + case CHARGING_PROFILE_BALANCED: >>> + *type = POWER_SUPPLY_CHARGE_TYPE_LONGLIFE; >>> + return 0; >>> + case CHARGING_PROFILE_STATIONARY: >>> + *type = POWER_SUPPLY_CHARGE_TYPE_TRICKLE; >>> + return 0; >>> + default: >>> + return -EPROTO; >>> + } >>> +} >> Like I wrote here: >> https://github.com/Wer-Wolf/uniwill-laptop/issues/6#issuecomment-3987100594 I >> think it would be less confusing to use >> >> POWER_SUPPLY_CHARGE_TYPE_TRICKLE -> CHARGING_PROFILE_STATIONARY >> >> POWER_SUPPLY_CHARGE_TYPE_STANDARD -> CHARGING_PROFILE_BALANCED >> >> POWER_SUPPLY_CHARGE_TYPE_FAST -> CHARGING_PROFILE_HIGH_CAPACITY >> >> because then the charge speed is at least clearly communicated >> >> POWER_SUPPLY_CHARGE_TYPE_FAST would then be the default >> > I think that this will confuse userspace applications. > POWER_SUPPLY_CHARGE_TYPE_FAST is meant to stand for > above-average/non-default charging speed, while > POWER_SUPPLY_CHARGE_TYPE_STANDARD is meant to stand for > the default/recommended setting. > > In this case CHARGING_PROFILE_HIGH_CAPACITY is the default charging setting > with the default charging speed, > and CHARGING_PROFILE_BALANCED is the "Long Life" option with reduced charging > speed. CHARGING_PROFILE_STATIONARY > on the other hand could as well be called "Primary AC", so > POWER_SUPPLY_CHARGE_TYPE_TRICKLE fits best for it. > > On a separate note, UPower prefers to select "Standard" over "Fast" when > disabling the charging threshold. > Mapping CHARGING_PROFILE_HIGH_CAPACITY to POWER_SUPPLY_CHARGE_TYPE_FAST would > thus confuse users, because > disabling the battery charging threshold thru upower will limit them > CHARGING_PROFILE_BALANCED. Basically > they cannot reach CHARGING_PROFILE_HIGH_CAPACITY again thru UPower when the > charging threshold has been > enabled. ok didn't know about the upower behaviour > >>> + >>> static int uniwill_get_property(struct power_supply *psy, const struct >>> power_supply_ext *ext, >>> void *drvdata, enum power_supply_property psp, >>> union power_supply_propval *val) >>> @@ -1431,6 +1474,16 @@ static int uniwill_get_property(struct power_supply >>> *psy, const struct power_sup >>> int ret; >>> switch (psp) { >>> + case POWER_SUPPLY_PROP_CHARGE_TYPES: >>> + /* >>> + * We need to use the cached value here because the charging mode >>> + * reported by the EC might temporarily change when a external power >>> + * source has been connected. >>> + */ >>> + mutex_lock(&data->charge_type_lock); >>> + val->intval = data->last_charge_type; >>> + mutex_unlock(&data->charge_type_lock); >>> + return 0; >>> case POWER_SUPPLY_PROP_HEALTH: >>> ret = power_supply_get_property_direct(psy, >>> POWER_SUPPLY_PROP_PRESENT, &prop); >>> if (ret < 0) >>> @@ -1479,13 +1532,52 @@ static int uniwill_get_property(struct power_supply >>> *psy, const struct power_sup >>> } >>> } >>> +static int uniwill_write_charge_type(struct uniwill_data *data, enum >>> power_supply_charge_type type) >>> +{ >>> + unsigned int value; >>> + >>> + switch (type) { >>> + case POWER_SUPPLY_CHARGE_TYPE_TRICKLE: >>> + value = FIELD_PREP(CHARGING_PROFILE_MASK, >>> CHARGING_PROFILE_STATIONARY); >>> + break; >>> + case POWER_SUPPLY_CHARGE_TYPE_STANDARD: >>> + value = FIELD_PREP(CHARGING_PROFILE_MASK, >>> CHARGING_PROFILE_HIGH_CAPACITY); >>> + break; >>> + case POWER_SUPPLY_CHARGE_TYPE_LONGLIFE: >>> + value = FIELD_PREP(CHARGING_PROFILE_MASK, CHARGING_PROFILE_BALANCED); >>> + break; >>> + default: >>> + return -EINVAL; >>> + } >>> + >>> + return regmap_update_bits(data->regmap, EC_ADDR_OEM_4, >>> CHARGING_PROFILE_MASK, value); >>> +} >>> + >>> +static int uniwill_restore_charge_type(struct uniwill_data *data) >>> +{ >>> + guard(mutex)(&data->charge_type_lock); >>> + >>> + return uniwill_write_charge_type(data, data->last_charge_type); >>> +} >>> + >>> static int uniwill_set_property(struct power_supply *psy, const struct >>> power_supply_ext *ext, >>> void *drvdata, enum power_supply_property psp, >>> const union power_supply_propval *val) >>> { >>> struct uniwill_data *data = drvdata; >>> + int ret; >>> switch (psp) { >>> + case POWER_SUPPLY_PROP_CHARGE_TYPES: >>> + mutex_lock(&data->charge_type_lock); >>> + >>> + ret = uniwill_write_charge_type(data, val->intval); >>> + if (ret >= 0) >>> + data->last_charge_type = val->intval; >>> + >>> + mutex_unlock(&data->charge_type_lock); >>> + >>> + return ret; >>> case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: >>> if (val->intval < 0 || val->intval > 100) >>> return -EINVAL; >>> @@ -1501,21 +1593,41 @@ static int uniwill_property_is_writeable(struct >>> power_supply *psy, >>> const struct power_supply_ext *ext, void *drvdata, >>> enum power_supply_property psp) >>> { >>> - if (psp == POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD) >>> + switch (psp) { >>> + case POWER_SUPPLY_PROP_CHARGE_TYPES: >>> + case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: >>> return true; >>> - >>> - return false; >>> + default: >>> + return false; >>> + } >>> } >> Could be mistaken, but does this work without producing a compiler warning or >> error not having a return on the top level? > > All exits from the switch statement end with a return statement, so we will > always leave this function once we > enter the switch statement. ack > >>> -static const enum power_supply_property uniwill_properties[] = { >>> +static const enum power_supply_property uniwill_charge_limit_properties[] = { >>> POWER_SUPPLY_PROP_HEALTH, >>> POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, >>> }; >>> -static const struct power_supply_ext uniwill_extension = { >>> +static const struct power_supply_ext uniwill_charge_limit_extension = { >>> + .name = DRIVER_NAME, >>> + .properties = uniwill_charge_limit_properties, >>> + .num_properties = ARRAY_SIZE(uniwill_charge_limit_properties), >>> + .get_property = uniwill_get_property, >>> + .set_property = uniwill_set_property, >>> + .property_is_writeable = uniwill_property_is_writeable, >>> +}; >>> + >>> +static const enum power_supply_property uniwill_charge_modes_properties[] = { >>> + POWER_SUPPLY_PROP_CHARGE_TYPES, >>> + POWER_SUPPLY_PROP_HEALTH, >>> +}; >>> + >>> +static const struct power_supply_ext uniwill_charge_modes_extension = { >>> .name = DRIVER_NAME, >>> - .properties = uniwill_properties, >>> - .num_properties = ARRAY_SIZE(uniwill_properties), >>> + .charge_types = BIT(POWER_SUPPLY_CHARGE_TYPE_TRICKLE) | >>> + BIT(POWER_SUPPLY_CHARGE_TYPE_STANDARD) | >>> + BIT(POWER_SUPPLY_CHARGE_TYPE_LONGLIFE), >>> + .properties = uniwill_charge_modes_properties, >>> + .num_properties = ARRAY_SIZE(uniwill_charge_modes_properties), >>> .get_property = uniwill_get_property, >>> .set_property = uniwill_set_property, >>> .property_is_writeable = uniwill_property_is_writeable, >>> @@ -1531,7 +1643,13 @@ static int uniwill_add_battery(struct power_supply >>> *battery, struct acpi_battery >>> if (!entry) >>> return -ENOMEM; >>> - ret = power_supply_register_extension(battery, &uniwill_extension, >>> data->dev, data); >>> + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >>> + ret = power_supply_register_extension(battery, >>> &uniwill_charge_limit_extension, >>> + data->dev, data); >>> + else >>> + ret = power_supply_register_extension(battery, >>> &uniwill_charge_modes_extension, >>> + data->dev, data); >>> + >> Currently there is now way to specify just the health parameter, but i have >> to check if that is even required > > AFAIK the OEM software always bundles this feature with the charging limit or > the charging modes. > We can separate this in the future should the need arise. ack > >>> if (ret < 0) { >>> kfree(entry); >>> return ret; >>> @@ -1560,7 +1678,10 @@ static int uniwill_remove_battery(struct power_supply >>> *battery, struct acpi_batt >>> } >>> } >>> - power_supply_unregister_extension(battery, &uniwill_extension); >>> + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >>> + power_supply_unregister_extension(battery, >>> &uniwill_charge_limit_extension); >>> + else >>> + power_supply_unregister_extension(battery, >>> &uniwill_charge_modes_extension); >>> return 0; >>> } >>> @@ -1570,25 +1691,35 @@ static int uniwill_battery_init(struct uniwill_data >>> *data) >>> unsigned int value, threshold; >>> int ret; >>> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >>> - return 0; >>> + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) { >>> + ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); >>> + if (ret < 0) >>> + return ret; >>> - ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); >>> - if (ret < 0) >>> - return ret; >>> + /* >>> + * 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); >>> + ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); >>> + if (ret < 0) >>> + return ret; >>> + } >>> + } else { >>> + if (!uniwill_device_supports(data, >>> UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) >>> + return 0; >> Would use an "else if (uniwill_device_supports(data, >> UNIWILL_FEATURE_BATTERY_CHARGE_MODES))" and put the return 0 at the end of >> the function. > > This would not work, because we must not register the battery extension when > both features are not supported. ah sorry overlooked that, but what about: } else if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { ret = devm_mutex_init(data->dev, &data->charge_type_lock); if (ret < 0) return ret; ret = uniwill_read_charge_type(data, &data->last_charge_type); if (ret < 0) return ret; } else { return 0; } It's the same number of lines and same indentation level but more readable imho > >>> - /* >>> - * 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); >>> - ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); >>> + ret = devm_mutex_init(data->dev, &data->charge_type_lock); >>> + if (ret < 0) >>> + return ret; >>> + >>> + ret = uniwill_read_charge_type(data, &data->last_charge_type); >>> if (ret < 0) >>> return ret; >>> } >>> @@ -1609,10 +1740,13 @@ static int uniwill_notifier_call(struct >>> notifier_block *nb, unsigned long action >>> { >>> struct uniwill_data *data = container_of(nb, struct uniwill_data, nb); >>> struct uniwill_battery_entry *entry; >>> + int ret; >>> switch (action) { >>> case UNIWILL_OSD_BATTERY_ALERT: >>> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >>> + if (!uniwill_device_supports_any(data, >>> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >>> + UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) >>> return NOTIFY_DONE; >>> mutex_lock(&data->battery_lock); >>> @@ -1623,10 +1757,24 @@ static int uniwill_notifier_call(struct >>> notifier_block *nb, unsigned long action >>> return NOTIFY_OK; >>> case UNIWILL_OSD_DC_ADAPTER_CHANGED: >>> - if (!uniwill_device_supports(data, >>> UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) >>> + if (!uniwill_device_supports_any(data, >>> + UNIWILL_FEATURE_BATTERY_CHARGE_MODES | >>> + UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) >>> return NOTIFY_DONE; >>> - return notifier_from_errno(usb_c_power_priority_restore(data)); >>> + if (uniwill_device_supports(data, >>> UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { >>> + ret = uniwill_restore_charge_type(data); >>> + if (ret < 0) >>> + return notifier_from_errno(ret); >>> + } >>> + >>> + if (uniwill_device_supports(data, >>> UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) { >>> + ret = usb_c_power_priority_restore(data); >>> + if (ret < 0) >>> + return notifier_from_errno(ret); >>> + } >>> + >>> + return NOTIFY_OK; >>> case UNIWILL_OSD_FN_LOCK: >>> if (!uniwill_device_supports(data, UNIWILL_FEATURE_FN_LOCK)) >>> return NOTIFY_DONE; >>> @@ -1810,7 +1958,7 @@ static int uniwill_suspend_touchpad_toggle(struct >>> uniwill_data *data) >>> static int uniwill_suspend_battery(struct uniwill_data *data) >>> { >>> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >>> + if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >>> return 0; >>> /* >>> @@ -1887,7 +2035,15 @@ static int uniwill_resume_touchpad_toggle(struct >>> uniwill_data *data) >>> static int uniwill_resume_battery(struct uniwill_data *data) >>> { >>> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >>> + int ret; >>> + >>> + if (uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { >>> + ret = uniwill_restore_charge_type(data); >>> + if (ret < 0) >>> + return ret; >>> + } >>> + >>> + if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >>> return 0; >>> return regmap_update_bits(data->regmap, EC_ADDR_CHARGE_CTRL, >>> CHARGE_CTRL_MASK, >>> @@ -1970,7 +2126,7 @@ static struct platform_driver uniwill_driver = { >>> static struct uniwill_device_descriptor lapqc71a_lapqc71b_descriptor >>> __initdata = { >>> .features = UNIWILL_FEATURE_SUPER_KEY | >>> - UNIWILL_FEATURE_BATTERY | >>> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >>> UNIWILL_FEATURE_CPU_TEMP | >>> UNIWILL_FEATURE_GPU_TEMP | >>> UNIWILL_FEATURE_PRIMARY_FAN | >>> @@ -1981,7 +2137,7 @@ static struct uniwill_device_descriptor >>> lapac71h_descriptor __initdata = { >>> .features = UNIWILL_FEATURE_FN_LOCK | >>> UNIWILL_FEATURE_SUPER_KEY | >>> UNIWILL_FEATURE_TOUCHPAD_TOGGLE | >>> - UNIWILL_FEATURE_BATTERY | >>> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >>> UNIWILL_FEATURE_CPU_TEMP | >>> UNIWILL_FEATURE_GPU_TEMP | >>> UNIWILL_FEATURE_PRIMARY_FAN | >>> @@ -1993,7 +2149,7 @@ static struct uniwill_device_descriptor >>> lapkc71f_descriptor __initdata = { >>> UNIWILL_FEATURE_SUPER_KEY | >>> UNIWILL_FEATURE_TOUCHPAD_TOGGLE | >>> UNIWILL_FEATURE_LIGHTBAR | >>> - UNIWILL_FEATURE_BATTERY | >>> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >>> UNIWILL_FEATURE_CPU_TEMP | >>> UNIWILL_FEATURE_GPU_TEMP | >>> UNIWILL_FEATURE_PRIMARY_FAN | >> Maybe we should put in some assertion to ensure that >> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT and UNIWILL_FEATURE_BATTERY_CHARGE_MODES >> are not set at the same time, or it that being to wary? > > I do not think that we really need that. Those device descriptors are mostly > static and have a fairly trivial structure, > so we should easily spot such a mistake. ok > >>> @@ -2578,8 +2734,8 @@ static int __init uniwill_init(void) >>> } >>> if (force) { >>> - /* Assume that the device supports all features */ >>> - device_descriptor.features = UINT_MAX; >>> + /* Assume that the device supports all features except the charge >>> limit */ >>> + device_descriptor.features = UINT_MAX & >>> ~UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT; >>> pr_warn("Enabling potentially unsupported features\n"); >>> } >>> diff --git a/drivers/platform/x86/uniwill/uniwill-wmi.c >>> b/drivers/platform/x86/uniwill/uniwill-wmi.c >>> index 31d9c39f14ab..f1b89bc63df6 100644 >>> --- a/drivers/platform/x86/uniwill/uniwill-wmi.c >>> +++ b/drivers/platform/x86/uniwill/uniwill-wmi.c >>> @@ -48,6 +48,7 @@ int devm_uniwill_wmi_register_notifier(struct device *dev, >>> struct notifier_block >>> static void uniwill_wmi_notify(struct wmi_device *wdev, union acpi_object >>> *obj) >>> { >>> u32 value; >>> + int ret; >>> if (obj->type != ACPI_TYPE_INTEGER) >>> return; >>> @@ -56,7 +57,9 @@ static void uniwill_wmi_notify(struct wmi_device *wdev, >>> union acpi_object *obj) >>> dev_dbg(&wdev->dev, "Received WMI event %u\n", value); >>> - blocking_notifier_call_chain(&uniwill_wmi_chain_head, value, NULL); >>> + ret = blocking_notifier_call_chain(&uniwill_wmi_chain_head, value, NULL); >>> + if (notifier_to_errno(ret) < 0) >>> + dev_err(&wdev->dev, "Failed to handle event %u\n", value); >>> } >>> /* >> Is this something specific for this patch or just general cleanup that >> sneaked into here? >> >> Best regards, >> >> Werner > > It is necessary because handling of UNIWILL_OSD_DC_ADAPTER_CHANGED can now > fail with an error code. > I decided to place the "error handling" code inside uniwill_wmi_notify() so > that the resulting error > codes are not silently swallowed. ok > > Thanks, > Armin Wolf > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 6/6] platform/x86: uniwill-laptop: Add support for battery charge modes 2026-04-10 20:24 ` Werner Sembach @ 2026-04-10 21:47 ` Armin Wolf 0 siblings, 0 replies; 22+ messages in thread From: Armin Wolf @ 2026-04-10 21:47 UTC (permalink / raw) To: Werner Sembach, hansg, ilpo.jarvinen; +Cc: platform-driver-x86, linux-kernel Am 10.04.26 um 22:24 schrieb Werner Sembach: > > Am 10.04.26 um 19:53 schrieb Armin Wolf: >> Am 10.04.26 um 18:53 schrieb Werner Sembach: >> >>> Hi Armin, >>> >>> Am 06.04.26 um 21:36 schrieb Armin Wolf: >>>> Many Uniwill-based devices do not supports the already existing >>>> charge limit functionality, but instead support an alternative >>>> interface for controlling the battery charge algorithm. >>>> >>>> Add support for this interface and update the documentation. >>>> >>>> Signed-off-by: Armin Wolf <W_Armin@gmx.de> >>>> --- >>>> .../admin-guide/laptops/uniwill-laptop.rst | 25 +- >>>> drivers/platform/x86/uniwill/uniwill-acpi.c | 244 >>>> ++++++++++++++---- >>>> drivers/platform/x86/uniwill/uniwill-wmi.c | 5 +- >>>> 3 files changed, 226 insertions(+), 48 deletions(-) >>>> >>>> diff --git a/Documentation/admin-guide/laptops/uniwill-laptop.rst >>>> b/Documentation/admin-guide/laptops/uniwill-laptop.rst >>>> index 561334865feb..24b41dbab886 100644 >>>> --- a/Documentation/admin-guide/laptops/uniwill-laptop.rst >>>> +++ b/Documentation/admin-guide/laptops/uniwill-laptop.rst >>>> @@ -43,9 +43,23 @@ Support for changing the platform performance >>>> mode is currently not implemented. >>>> Battery Charging Control >>>> ------------------------ >>>> -The ``uniwill-laptop`` driver supports controlling the battery >>>> charge limit. This happens over >>>> -the standard ``charge_control_end_threshold`` power supply sysfs >>>> attribute. All values >>>> -between 1 and 100 percent are supported. >>>> +.. warning:: Some devices do not properly implement the charging >>>> threshold interface. Forcing >>>> + the driver to enable access to said interface on such >>>> devices might damage the >>>> + battery [1]_. Because of this the driver will not >>>> enable said feature even when >>>> + using the ``force`` module parameter. The charging >>>> profile interface will be >>>> + available instead. >>>> + >>>> +The ``uniwill-laptop`` driver supports controlling the battery >>>> charge limit. This either happens >>>> +over the standard ``charge_control_end_threshold`` or >>>> ``charge_types`` power supply sysfs attribute, >>>> +depending on the device. When using the >>>> ``charge_control_end_threshold`` sysfs attribute, all values >>>> +between 1 and 100 percent are supported. When using the >>>> ``charge_types`` sysfs attribute, the driver >>>> +supports switching between the ``Standard``, ``Trickle`` and >>>> ``Long Life`` profiles. >>>> + >>>> +Keep in mind that when using the ``charge_types`` sysfs attribute, >>>> the EC firmware will hide the >>>> +true charging status of the battery from the operating system, >>>> potentially misleading users into >>>> +thinking that the charging profile does not work. Checking the >>>> ``current_now`` sysfs attribute >>>> +tells you the true charging status of the battery even when using >>>> the ``charge_types`` sysfs >>>> +attribute (0 means that the battery is currently not charging). >>>> Additionally the driver signals the presence of battery >>>> charging issues through the standard >>>> ``health`` power supply sysfs attribute. >>>> @@ -70,3 +84,8 @@ The ``uniwill-laptop`` driver allows to set the >>>> configurable TGP for devices wit >>>> allow it. >>>> See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for >>>> details. >>>> + >>>> +References >>>> +========== >>>> + >>>> +.. [1] >>>> https://www.reddit.com/r/XMG_gg/comments/ld9yyf/battery_limit_hidden_function_discovered_on/ >>>> diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c >>>> b/drivers/platform/x86/uniwill/uniwill-acpi.c >>>> index a116e2ec6453..fbf2e101a074 100644 >>>> --- a/drivers/platform/x86/uniwill/uniwill-acpi.c >>>> +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c >>>> @@ -254,6 +254,10 @@ >>>> #define EC_ADDR_OEM_4 0x07A6 >>>> #define OVERBOOST_DYN_TEMP_OFF BIT(1) >>>> +#define CHARGING_PROFILE_MASK GENMASK(5, 4) >>>> +#define CHARGING_PROFILE_HIGH_CAPACITY 0x00 >>>> +#define CHARGING_PROFILE_BALANCED 0x01 >>>> +#define CHARGING_PROFILE_STATIONARY 0x02 >>>> #define TOUCHPAD_TOGGLE_OFF BIT(6) >>>> #define EC_ADDR_CHARGE_CTRL 0x07B9 >>>> @@ -320,13 +324,15 @@ >>>> #define UNIWILL_FEATURE_SUPER_KEY BIT(1) >>>> #define UNIWILL_FEATURE_TOUCHPAD_TOGGLE BIT(2) >>>> #define UNIWILL_FEATURE_LIGHTBAR BIT(3) >>>> -#define UNIWILL_FEATURE_BATTERY BIT(4) >>>> -#define UNIWILL_FEATURE_CPU_TEMP BIT(5) >>>> -#define UNIWILL_FEATURE_GPU_TEMP BIT(6) >>>> -#define UNIWILL_FEATURE_PRIMARY_FAN BIT(7) >>>> -#define UNIWILL_FEATURE_SECONDARY_FAN BIT(8) >>>> -#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(9) >>>> -#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(10) >>>> +#define UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT BIT(4) >>>> +/* Mutually exclusive with the charge limit feature */ >>>> +#define UNIWILL_FEATURE_BATTERY_CHARGE_MODES BIT(5) >>>> +#define UNIWILL_FEATURE_CPU_TEMP BIT(6) >>>> +#define UNIWILL_FEATURE_GPU_TEMP BIT(7) >>>> +#define UNIWILL_FEATURE_PRIMARY_FAN BIT(8) >>>> +#define UNIWILL_FEATURE_SECONDARY_FAN BIT(9) >>>> +#define UNIWILL_FEATURE_NVIDIA_CTGP_CONTROL BIT(10) >>>> +#define UNIWILL_FEATURE_USB_C_POWER_PRIORITY BIT(11) >>>> enum usb_c_power_priority_options { >>>> USB_C_POWER_PRIORITY_CHARGING = 0, >>>> @@ -339,8 +345,15 @@ struct uniwill_data { >>>> struct regmap *regmap; >>>> unsigned int features; >>>> struct acpi_battery_hook hook; >>>> - unsigned int last_charge_ctrl; >>>> struct mutex battery_lock; /* Protects the list of >>>> currently registered batteries */ >>>> + union { >>>> + struct { >>>> + /* Protects writes to last_charge_type */ >>>> + struct mutex charge_type_lock; >>>> + enum power_supply_charge_type last_charge_type; >>>> + }; >>>> + unsigned int last_charge_ctrl; >>>> + }; >>>> bool last_fn_lock_state; >>>> bool last_super_key_enable_state; >>>> bool last_touchpad_toggle_enable_state; >>>> @@ -447,6 +460,12 @@ static inline bool >>>> uniwill_device_supports(const struct uniwill_data *data, >>>> return (data->features & features) == features; >>>> } >>>> +static inline bool uniwill_device_supports_any(const struct >>>> uniwill_data *data, >>>> + unsigned int features) >>>> +{ >>>> + return data->features & features; >>>> +} >>>> + >>> Maybe add a "!= 0" to make the return a clear 1 or 0 >> >> This function already returns a boolean, so the compiler will already >> do this for us. > ack >> >>>> static int uniwill_ec_reg_write(void *context, unsigned int reg, >>>> unsigned int val) >>>> { >>>> union acpi_object params[2] = { >>>> @@ -1421,6 +1440,30 @@ static int uniwill_led_init(struct >>>> uniwill_data *data) >>>> &init_data); >>>> } >>>> +static int uniwill_read_charge_type(struct uniwill_data *data, >>>> enum power_supply_charge_type *type) >>>> +{ >>>> + unsigned int value; >>>> + int ret; >>>> + >>>> + ret = regmap_read(data->regmap, EC_ADDR_OEM_4, &value); >>>> + if (ret < 0) >>>> + return ret; >>>> + >>>> + switch (FIELD_GET(CHARGING_PROFILE_MASK, value)) { >>>> + case CHARGING_PROFILE_HIGH_CAPACITY: >>>> + *type = POWER_SUPPLY_CHARGE_TYPE_STANDARD; >>>> + return 0; >>>> + case CHARGING_PROFILE_BALANCED: >>>> + *type = POWER_SUPPLY_CHARGE_TYPE_LONGLIFE; >>>> + return 0; >>>> + case CHARGING_PROFILE_STATIONARY: >>>> + *type = POWER_SUPPLY_CHARGE_TYPE_TRICKLE; >>>> + return 0; >>>> + default: >>>> + return -EPROTO; >>>> + } >>>> +} >>> Like I wrote here: >>> https://github.com/Wer-Wolf/uniwill-laptop/issues/6#issuecomment-3987100594 >>> I think it would be less confusing to use >>> >>> POWER_SUPPLY_CHARGE_TYPE_TRICKLE -> CHARGING_PROFILE_STATIONARY >>> >>> POWER_SUPPLY_CHARGE_TYPE_STANDARD -> CHARGING_PROFILE_BALANCED >>> >>> POWER_SUPPLY_CHARGE_TYPE_FAST -> CHARGING_PROFILE_HIGH_CAPACITY >>> >>> because then the charge speed is at least clearly communicated >>> >>> POWER_SUPPLY_CHARGE_TYPE_FAST would then be the default >>> >> I think that this will confuse userspace applications. >> POWER_SUPPLY_CHARGE_TYPE_FAST is meant to stand for >> above-average/non-default charging speed, while >> POWER_SUPPLY_CHARGE_TYPE_STANDARD is meant to stand for >> the default/recommended setting. >> >> In this case CHARGING_PROFILE_HIGH_CAPACITY is the default charging >> setting with the default charging speed, >> and CHARGING_PROFILE_BALANCED is the "Long Life" option with reduced >> charging speed. CHARGING_PROFILE_STATIONARY >> on the other hand could as well be called "Primary AC", so >> POWER_SUPPLY_CHARGE_TYPE_TRICKLE fits best for it. >> >> On a separate note, UPower prefers to select "Standard" over "Fast" >> when disabling the charging threshold. >> Mapping CHARGING_PROFILE_HIGH_CAPACITY to >> POWER_SUPPLY_CHARGE_TYPE_FAST would thus confuse users, because >> disabling the battery charging threshold thru upower will limit them >> CHARGING_PROFILE_BALANCED. Basically >> they cannot reach CHARGING_PROFILE_HIGH_CAPACITY again thru UPower >> when the charging threshold has been >> enabled. > ok didn't know about the upower behaviour >> >>>> + >>>> static int uniwill_get_property(struct power_supply *psy, const >>>> struct power_supply_ext *ext, >>>> void *drvdata, enum power_supply_property psp, >>>> union power_supply_propval *val) >>>> @@ -1431,6 +1474,16 @@ static int uniwill_get_property(struct >>>> power_supply *psy, const struct power_sup >>>> int ret; >>>> switch (psp) { >>>> + case POWER_SUPPLY_PROP_CHARGE_TYPES: >>>> + /* >>>> + * We need to use the cached value here because the >>>> charging mode >>>> + * reported by the EC might temporarily change when a >>>> external power >>>> + * source has been connected. >>>> + */ >>>> + mutex_lock(&data->charge_type_lock); >>>> + val->intval = data->last_charge_type; >>>> + mutex_unlock(&data->charge_type_lock); >>>> + return 0; >>>> case POWER_SUPPLY_PROP_HEALTH: >>>> ret = power_supply_get_property_direct(psy, >>>> POWER_SUPPLY_PROP_PRESENT, &prop); >>>> if (ret < 0) >>>> @@ -1479,13 +1532,52 @@ static int uniwill_get_property(struct >>>> power_supply *psy, const struct power_sup >>>> } >>>> } >>>> +static int uniwill_write_charge_type(struct uniwill_data *data, >>>> enum power_supply_charge_type type) >>>> +{ >>>> + unsigned int value; >>>> + >>>> + switch (type) { >>>> + case POWER_SUPPLY_CHARGE_TYPE_TRICKLE: >>>> + value = FIELD_PREP(CHARGING_PROFILE_MASK, >>>> CHARGING_PROFILE_STATIONARY); >>>> + break; >>>> + case POWER_SUPPLY_CHARGE_TYPE_STANDARD: >>>> + value = FIELD_PREP(CHARGING_PROFILE_MASK, >>>> CHARGING_PROFILE_HIGH_CAPACITY); >>>> + break; >>>> + case POWER_SUPPLY_CHARGE_TYPE_LONGLIFE: >>>> + value = FIELD_PREP(CHARGING_PROFILE_MASK, >>>> CHARGING_PROFILE_BALANCED); >>>> + break; >>>> + default: >>>> + return -EINVAL; >>>> + } >>>> + >>>> + return regmap_update_bits(data->regmap, EC_ADDR_OEM_4, >>>> CHARGING_PROFILE_MASK, value); >>>> +} >>>> + >>>> +static int uniwill_restore_charge_type(struct uniwill_data *data) >>>> +{ >>>> + guard(mutex)(&data->charge_type_lock); >>>> + >>>> + return uniwill_write_charge_type(data, data->last_charge_type); >>>> +} >>>> + >>>> static int uniwill_set_property(struct power_supply *psy, const >>>> struct power_supply_ext *ext, >>>> void *drvdata, enum power_supply_property psp, >>>> const union power_supply_propval *val) >>>> { >>>> struct uniwill_data *data = drvdata; >>>> + int ret; >>>> switch (psp) { >>>> + case POWER_SUPPLY_PROP_CHARGE_TYPES: >>>> + mutex_lock(&data->charge_type_lock); >>>> + >>>> + ret = uniwill_write_charge_type(data, val->intval); >>>> + if (ret >= 0) >>>> + data->last_charge_type = val->intval; >>>> + >>>> + mutex_unlock(&data->charge_type_lock); >>>> + >>>> + return ret; >>>> case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: >>>> if (val->intval < 0 || val->intval > 100) >>>> return -EINVAL; >>>> @@ -1501,21 +1593,41 @@ static int >>>> uniwill_property_is_writeable(struct power_supply *psy, >>>> const struct power_supply_ext *ext, void >>>> *drvdata, >>>> enum power_supply_property psp) >>>> { >>>> - if (psp == POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD) >>>> + switch (psp) { >>>> + case POWER_SUPPLY_PROP_CHARGE_TYPES: >>>> + case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD: >>>> return true; >>>> - >>>> - return false; >>>> + default: >>>> + return false; >>>> + } >>>> } >>> Could be mistaken, but does this work without producing a compiler >>> warning or error not having a return on the top level? >> >> All exits from the switch statement end with a return statement, so >> we will always leave this function once we >> enter the switch statement. > ack >> >>>> -static const enum power_supply_property uniwill_properties[] = { >>>> +static const enum power_supply_property >>>> uniwill_charge_limit_properties[] = { >>>> POWER_SUPPLY_PROP_HEALTH, >>>> POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, >>>> }; >>>> -static const struct power_supply_ext uniwill_extension = { >>>> +static const struct power_supply_ext >>>> uniwill_charge_limit_extension = { >>>> + .name = DRIVER_NAME, >>>> + .properties = uniwill_charge_limit_properties, >>>> + .num_properties = ARRAY_SIZE(uniwill_charge_limit_properties), >>>> + .get_property = uniwill_get_property, >>>> + .set_property = uniwill_set_property, >>>> + .property_is_writeable = uniwill_property_is_writeable, >>>> +}; >>>> + >>>> +static const enum power_supply_property >>>> uniwill_charge_modes_properties[] = { >>>> + POWER_SUPPLY_PROP_CHARGE_TYPES, >>>> + POWER_SUPPLY_PROP_HEALTH, >>>> +}; >>>> + >>>> +static const struct power_supply_ext >>>> uniwill_charge_modes_extension = { >>>> .name = DRIVER_NAME, >>>> - .properties = uniwill_properties, >>>> - .num_properties = ARRAY_SIZE(uniwill_properties), >>>> + .charge_types = BIT(POWER_SUPPLY_CHARGE_TYPE_TRICKLE) | >>>> + BIT(POWER_SUPPLY_CHARGE_TYPE_STANDARD) | >>>> + BIT(POWER_SUPPLY_CHARGE_TYPE_LONGLIFE), >>>> + .properties = uniwill_charge_modes_properties, >>>> + .num_properties = ARRAY_SIZE(uniwill_charge_modes_properties), >>>> .get_property = uniwill_get_property, >>>> .set_property = uniwill_set_property, >>>> .property_is_writeable = uniwill_property_is_writeable, >>>> @@ -1531,7 +1643,13 @@ static int uniwill_add_battery(struct >>>> power_supply *battery, struct acpi_battery >>>> if (!entry) >>>> return -ENOMEM; >>>> - ret = power_supply_register_extension(battery, >>>> &uniwill_extension, data->dev, data); >>>> + if (uniwill_device_supports(data, >>>> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >>>> + ret = power_supply_register_extension(battery, >>>> &uniwill_charge_limit_extension, >>>> + data->dev, data); >>>> + else >>>> + ret = power_supply_register_extension(battery, >>>> &uniwill_charge_modes_extension, >>>> + data->dev, data); >>>> + >>> Currently there is now way to specify just the health parameter, but >>> i have to check if that is even required >> >> AFAIK the OEM software always bundles this feature with the charging >> limit or the charging modes. >> We can separate this in the future should the need arise. > ack >> >>>> if (ret < 0) { >>>> kfree(entry); >>>> return ret; >>>> @@ -1560,7 +1678,10 @@ static int uniwill_remove_battery(struct >>>> power_supply *battery, struct acpi_batt >>>> } >>>> } >>>> - power_supply_unregister_extension(battery, &uniwill_extension); >>>> + if (uniwill_device_supports(data, >>>> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >>>> + power_supply_unregister_extension(battery, >>>> &uniwill_charge_limit_extension); >>>> + else >>>> + power_supply_unregister_extension(battery, >>>> &uniwill_charge_modes_extension); >>>> return 0; >>>> } >>>> @@ -1570,25 +1691,35 @@ static int uniwill_battery_init(struct >>>> uniwill_data *data) >>>> unsigned int value, threshold; >>>> int ret; >>>> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >>>> - return 0; >>>> + if (uniwill_device_supports(data, >>>> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) { >>>> + ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); >>>> + if (ret < 0) >>>> + return ret; >>>> - ret = regmap_read(data->regmap, EC_ADDR_CHARGE_CTRL, &value); >>>> - if (ret < 0) >>>> - return ret; >>>> + /* >>>> + * 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); >>>> + ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, >>>> value); >>>> + if (ret < 0) >>>> + return ret; >>>> + } >>>> + } else { >>>> + if (!uniwill_device_supports(data, >>>> UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) >>>> + return 0; >>> Would use an "else if (uniwill_device_supports(data, >>> UNIWILL_FEATURE_BATTERY_CHARGE_MODES))" and put the return 0 at the >>> end of the function. >> >> This would not work, because we must not register the battery >> extension when both features are not supported. > > ah sorry overlooked that, but what about: > > } else if (uniwill_device_supports(data, > UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { > ret = devm_mutex_init(data->dev, &data->charge_type_lock); > if (ret < 0) > return ret; > > ret = uniwill_read_charge_type(data, &data->last_charge_type); > if (ret < 0) > return ret; > } else { > return 0; > } > > It's the same number of lines and same indentation level but more > readable imho > Alright, i will check if checkpatch agrees with using "else if". If that is fine then i will restructure the code. Thanks, Armin Wolf >> >>>> - /* >>>> - * 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); >>>> - ret = regmap_write(data->regmap, EC_ADDR_CHARGE_CTRL, value); >>>> + ret = devm_mutex_init(data->dev, &data->charge_type_lock); >>>> + if (ret < 0) >>>> + return ret; >>>> + >>>> + ret = uniwill_read_charge_type(data, >>>> &data->last_charge_type); >>>> if (ret < 0) >>>> return ret; >>>> } >>>> @@ -1609,10 +1740,13 @@ static int uniwill_notifier_call(struct >>>> notifier_block *nb, unsigned long action >>>> { >>>> struct uniwill_data *data = container_of(nb, struct >>>> uniwill_data, nb); >>>> struct uniwill_battery_entry *entry; >>>> + int ret; >>>> switch (action) { >>>> case UNIWILL_OSD_BATTERY_ALERT: >>>> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >>>> + if (!uniwill_device_supports_any(data, >>>> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >>>> + UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) >>>> return NOTIFY_DONE; >>>> mutex_lock(&data->battery_lock); >>>> @@ -1623,10 +1757,24 @@ static int uniwill_notifier_call(struct >>>> notifier_block *nb, unsigned long action >>>> return NOTIFY_OK; >>>> case UNIWILL_OSD_DC_ADAPTER_CHANGED: >>>> - if (!uniwill_device_supports(data, >>>> UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) >>>> + if (!uniwill_device_supports_any(data, >>>> + UNIWILL_FEATURE_BATTERY_CHARGE_MODES | >>>> + UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) >>>> return NOTIFY_DONE; >>>> - return >>>> notifier_from_errno(usb_c_power_priority_restore(data)); >>>> + if (uniwill_device_supports(data, >>>> UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { >>>> + ret = uniwill_restore_charge_type(data); >>>> + if (ret < 0) >>>> + return notifier_from_errno(ret); >>>> + } >>>> + >>>> + if (uniwill_device_supports(data, >>>> UNIWILL_FEATURE_USB_C_POWER_PRIORITY)) { >>>> + ret = usb_c_power_priority_restore(data); >>>> + if (ret < 0) >>>> + return notifier_from_errno(ret); >>>> + } >>>> + >>>> + return NOTIFY_OK; >>>> case UNIWILL_OSD_FN_LOCK: >>>> if (!uniwill_device_supports(data, UNIWILL_FEATURE_FN_LOCK)) >>>> return NOTIFY_DONE; >>>> @@ -1810,7 +1958,7 @@ static int >>>> uniwill_suspend_touchpad_toggle(struct uniwill_data *data) >>>> static int uniwill_suspend_battery(struct uniwill_data *data) >>>> { >>>> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >>>> + if (!uniwill_device_supports(data, >>>> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >>>> return 0; >>>> /* >>>> @@ -1887,7 +2035,15 @@ static int >>>> uniwill_resume_touchpad_toggle(struct uniwill_data *data) >>>> static int uniwill_resume_battery(struct uniwill_data *data) >>>> { >>>> - if (!uniwill_device_supports(data, UNIWILL_FEATURE_BATTERY)) >>>> + int ret; >>>> + >>>> + if (uniwill_device_supports(data, >>>> UNIWILL_FEATURE_BATTERY_CHARGE_MODES)) { >>>> + ret = uniwill_restore_charge_type(data); >>>> + if (ret < 0) >>>> + return ret; >>>> + } >>>> + >>>> + if (!uniwill_device_supports(data, >>>> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT)) >>>> return 0; >>>> return regmap_update_bits(data->regmap, >>>> EC_ADDR_CHARGE_CTRL, CHARGE_CTRL_MASK, >>>> @@ -1970,7 +2126,7 @@ static struct platform_driver uniwill_driver = { >>>> static struct uniwill_device_descriptor >>>> lapqc71a_lapqc71b_descriptor __initdata = { >>>> .features = UNIWILL_FEATURE_SUPER_KEY | >>>> - UNIWILL_FEATURE_BATTERY | >>>> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >>>> UNIWILL_FEATURE_CPU_TEMP | >>>> UNIWILL_FEATURE_GPU_TEMP | >>>> UNIWILL_FEATURE_PRIMARY_FAN | >>>> @@ -1981,7 +2137,7 @@ static struct uniwill_device_descriptor >>>> lapac71h_descriptor __initdata = { >>>> .features = UNIWILL_FEATURE_FN_LOCK | >>>> UNIWILL_FEATURE_SUPER_KEY | >>>> UNIWILL_FEATURE_TOUCHPAD_TOGGLE | >>>> - UNIWILL_FEATURE_BATTERY | >>>> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >>>> UNIWILL_FEATURE_CPU_TEMP | >>>> UNIWILL_FEATURE_GPU_TEMP | >>>> UNIWILL_FEATURE_PRIMARY_FAN | >>>> @@ -1993,7 +2149,7 @@ static struct uniwill_device_descriptor >>>> lapkc71f_descriptor __initdata = { >>>> UNIWILL_FEATURE_SUPER_KEY | >>>> UNIWILL_FEATURE_TOUCHPAD_TOGGLE | >>>> UNIWILL_FEATURE_LIGHTBAR | >>>> - UNIWILL_FEATURE_BATTERY | >>>> + UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT | >>>> UNIWILL_FEATURE_CPU_TEMP | >>>> UNIWILL_FEATURE_GPU_TEMP | >>>> UNIWILL_FEATURE_PRIMARY_FAN | >>> Maybe we should put in some assertion to ensure that >>> UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT and >>> UNIWILL_FEATURE_BATTERY_CHARGE_MODES are not set at the same time, >>> or it that being to wary? >> >> I do not think that we really need that. Those device descriptors are >> mostly static and have a fairly trivial structure, >> so we should easily spot such a mistake. > ok >> >>>> @@ -2578,8 +2734,8 @@ static int __init uniwill_init(void) >>>> } >>>> if (force) { >>>> - /* Assume that the device supports all features */ >>>> - device_descriptor.features = UINT_MAX; >>>> + /* Assume that the device supports all features except the >>>> charge limit */ >>>> + device_descriptor.features = UINT_MAX & >>>> ~UNIWILL_FEATURE_BATTERY_CHARGE_LIMIT; >>>> pr_warn("Enabling potentially unsupported features\n"); >>>> } >>>> diff --git a/drivers/platform/x86/uniwill/uniwill-wmi.c >>>> b/drivers/platform/x86/uniwill/uniwill-wmi.c >>>> index 31d9c39f14ab..f1b89bc63df6 100644 >>>> --- a/drivers/platform/x86/uniwill/uniwill-wmi.c >>>> +++ b/drivers/platform/x86/uniwill/uniwill-wmi.c >>>> @@ -48,6 +48,7 @@ int devm_uniwill_wmi_register_notifier(struct >>>> device *dev, struct notifier_block >>>> static void uniwill_wmi_notify(struct wmi_device *wdev, union >>>> acpi_object *obj) >>>> { >>>> u32 value; >>>> + int ret; >>>> if (obj->type != ACPI_TYPE_INTEGER) >>>> return; >>>> @@ -56,7 +57,9 @@ static void uniwill_wmi_notify(struct wmi_device >>>> *wdev, union acpi_object *obj) >>>> dev_dbg(&wdev->dev, "Received WMI event %u\n", value); >>>> - blocking_notifier_call_chain(&uniwill_wmi_chain_head, value, >>>> NULL); >>>> + ret = blocking_notifier_call_chain(&uniwill_wmi_chain_head, >>>> value, NULL); >>>> + if (notifier_to_errno(ret) < 0) >>>> + dev_err(&wdev->dev, "Failed to handle event %u\n", value); >>>> } >>>> /* >>> Is this something specific for this patch or just general cleanup >>> that sneaked into here? >>> >>> Best regards, >>> >>> Werner >> >> It is necessary because handling of UNIWILL_OSD_DC_ADAPTER_CHANGED >> can now fail with an error code. >> I decided to place the "error handling" code inside >> uniwill_wmi_notify() so that the resulting error >> codes are not silently swallowed. > ok >> >> Thanks, >> Armin Wolf >> > ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2026-04-10 21:47 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-04-06 19:36 [PATCH 0/6] platform/x86: uniwill-laptop: Charging-related improvements Armin Wolf 2026-04-06 19:36 ` [PATCH 1/6] platform/x86: uniwill-laptop: Properly initialize charging threshold Armin Wolf 2026-04-08 22:59 ` Werner Sembach 2026-04-10 17:27 ` Armin Wolf 2026-04-10 20:26 ` Werner Sembach 2026-04-06 19:36 ` [PATCH 2/6] platform/x86: uniwill-laptop: Accept charging threshold of 0 Armin Wolf 2026-04-08 23:01 ` Werner Sembach 2026-04-06 19:36 ` [PATCH 3/6] platform/x86: uniwill-laptop: Fix behavior of "force" module param Armin Wolf 2026-04-08 23:08 ` Werner Sembach 2026-04-10 17:32 ` Armin Wolf 2026-04-10 20:30 ` Werner Sembach 2026-04-10 21:45 ` Armin Wolf 2026-04-06 19:36 ` [PATCH 4/6] platform/x86: uniwill-laptop: Rework FN lock/super key suspend handling Armin Wolf 2026-04-10 15:30 ` Werner Sembach 2026-04-10 17:33 ` Armin Wolf 2026-04-06 19:36 ` [PATCH 5/6] platform/x86: uniwill-laptop: Mark EC_ADDR_OEM_4 as volatile Armin Wolf 2026-04-10 15:35 ` Werner Sembach 2026-04-06 19:36 ` [PATCH 6/6] platform/x86: uniwill-laptop: Add support for battery charge modes Armin Wolf 2026-04-10 16:53 ` Werner Sembach 2026-04-10 17:53 ` Armin Wolf 2026-04-10 20:24 ` Werner Sembach 2026-04-10 21:47 ` Armin Wolf
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®