From: Thomas Koch <linrunner@gmx.net>
To: "Hans de Goede" <hdegoede@redhat.com>,
"Nicolò Piazzalunga" <nicolopiazzalunga@gmail.com>,
"Mark Pearson" <markpearson@lenovo.com>,
platform-driver-x86@vger.kernel.org,
"Nitin Joshi1" <njoshi1@lenovo.com>,
"Sebastian Reichel" <sre@kernel.org>
Cc: jwrdegoede@fedoraproject.org, smclt30p@gmail.com
Subject: Re: [PATCH 1/3] thinkpad_acpi: add support for force_discharge
Date: Wed, 29 Sep 2021 07:47:08 +0200 [thread overview]
Message-ID: <943fa4fb-273a-0a36-4919-26c05ae4a534@gmx.net> (raw)
In-Reply-To: <ba6698de-1700-fce9-6bca-12ee577ac09b@redhat.com>
Hi Hans,
On 27.09.21 17:12, Hans de Goede wrote:
> Hi Nicolò,
>
> On 9/27/21 5:00 PM, Nicolò Piazzalunga wrote:
>> Hi,
>>
>> On 9/27/21 3:59 PM, Mark Pearson wrote:
>>> Do let me know if there are some important use cases for these so I can go back to the FW team and discuss supporting them properly.
>>
>> The important use cases are force discharge and inhibit charge.
>> These at present are dealt with using tpacpi-bat, which relies on (out of tree) acpi_call.
>> See also your previous reply.
>
> I can see how those can be useful in certain circumstances.
>
> I can also understand how Lenovo does not want these to be
> available by default everywhere.
>
> I think a good compromise would be to add a bool module option
> which defaults to false to enable these.
From the user perspective, I don't agree that this is a good
compromise. Users simply want to recalibrate their battery. Having to
set the module option beforehand is an unnecessary hurdle imho.
Of course a module option again leads to support overhead in "user
space". Then tlp-stat -b would have to inform the user that
force_discharge is unfortunately not available, but he should try to set
the module option. What would that be good for?
While I respect Mark's official opinion, I would like to counter with my
experience from 10 years of TLP development and support:
The calls for force_discharge work unmodified since the 2012 ThinkPads
(T420/X220) on all models that also support charge thresholds.
They also work reliably, otherwise the issue tracker at tpacpi-bat and
TLP would be full of user issues.
inhibit_charge is probably used rather rarely, at least no TLP user has
asked for it.
@Mark: what is Lenovo's position on the calls for charge thresholds
already included in thinkpad_acpi? Are they also internal?
>
> Assuming Mark is ok with that, this is still blocked on agreeing
> on standard power_supply class property names for these 2 features.
>
> Can you perhaps write a (RFC) patch adding proposed standardized
> attributes for this to:
>
> Documentation/ABI/testing/sysfs-class-power
>
> As well as to the enum power_supply_property {}
> enum in: include/linux/power_supply.h
>
> And to the power_supply_attrs[] array in
> drivers/power/supply/power_supply_sysfs.c
>
> ?
>
> And then send that the Sebastian Reichel with the linux-pm
> and platform-driver-x86 lists in the Cc?
>
> Regards,
>
> Hans
>
--
Freundliche Grüße / Kind regards,
Thomas Koch
Mail : linrunner@gmx.net
Web : https://linrunner.de/tlp
next prev parent reply other threads:[~2021-09-29 5:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 14:01 [PATCH 1/3] thinkpad_acpi: add support for force_discharge Nicolo' Piazzalunga
2021-04-07 10:24 ` Hans de Goede
2021-04-07 10:33 ` Barnabás Pőcze
2021-04-08 13:51 ` Sebastian Reichel
2021-04-08 18:18 ` Thomas Koch
2021-04-09 18:33 ` Thomas Koch
2021-04-13 8:05 ` Hans de Goede
2021-04-17 11:49 ` Thomas Koch
2021-04-17 17:03 ` Hans de Goede
2021-05-19 14:45 ` Nicolo' Piazzalunga
2021-04-07 12:19 ` Thomas Koch
2021-04-07 17:48 ` [External] " Mark Pearson
[not found] ` <VI1PR09MB2302B7C3AD8014CC98D36AA595759@VI1PR09MB2302.eurprd09.prod.outlook.com>
2021-04-12 17:10 ` Mark Pearson
2021-09-27 13:59 ` Mark Pearson
2021-09-27 15:00 ` Nicolò Piazzalunga
2021-09-27 15:12 ` Hans de Goede
2021-09-27 16:50 ` [External] " Mark Pearson
2021-09-29 5:47 ` Thomas Koch [this message]
2021-09-29 9:55 ` Hans de Goede
2021-09-29 10:45 ` Thomas Koch
2021-09-29 10:56 ` Hans de Goede
2021-09-29 13:45 ` [External] " Mark Pearson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=943fa4fb-273a-0a36-4919-26c05ae4a534@gmx.net \
--to=linrunner@gmx.net \
--cc=hdegoede@redhat.com \
--cc=jwrdegoede@fedoraproject.org \
--cc=markpearson@lenovo.com \
--cc=nicolopiazzalunga@gmail.com \
--cc=njoshi1@lenovo.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=smclt30p@gmail.com \
--cc=sre@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).