All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Koch <linrunner@gmx.net>
To: Hans de Goede <hdegoede@redhat.com>, Sebastian Reichel <sre@kernel.org>
Cc: "Nicolo' Piazzalunga" <nicolopiazzalunga@gmail.com>,
	"platform-driver-x86@vger.kernel.org"
	<platform-driver-x86@vger.kernel.org>,
	"Mark Pearson" <markpearson@lenovo.com>,
	"Nitin Joshi1" <njoshi1@lenovo.com>,
	"jwrdegoede@fedoraproject.org" <jwrdegoede@fedoraproject.org>,
	"smclt30p@gmail.com" <smclt30p@gmail.com>,
	"Barnabás Pőcze" <pobrn@protonmail.com>
Subject: Re: [PATCH 1/3] thinkpad_acpi: add support for force_discharge
Date: Sat, 17 Apr 2021 13:49:46 +0200	[thread overview]
Message-ID: <a2d850e9-789d-54e8-e098-1a0829504031@gmx.net> (raw)
In-Reply-To: <6f58903f-5219-9aff-78ca-33687e2e4147@redhat.com>

Hi Hans,

from a userspace perspective, I don't think it's optimal to combine the
two features and the status. For example, how do I find out which one is
available?

I have to test the writability of status and then still don't know which
one is available. Seeing if force_discharge or inhibit_charge are there
is much simpler.

And then enabling that: triggering force_discharge by writing
"Discharging" is ok. But for inhibit_charge we would need a new status,
something like "Charging inhibited". This then causes problems for the
existing userspace, says: upowerd could not handle it. You remember the
"Not charging" patch from Ognen?


--

Freundliche Grüße / Kind regards,

Thomas Koch



Mail : linrunner@gmx.net

Web  : https://linrunner.de/tlp


On 13.04.21 10:05, Hans de Goede wrote:
> Hi,
>
> On 4/9/21 8:33 PM, Thomas Koch wrote:
>> Hi,
>>
>> On 08.04.21 15:51, Sebastian Reichel wrote:
>>
>>> IIUIC you have 'force_discharge', which basically means the system
>>> is running from battery power despite an AC adapter being connected
>>> and 'inhibit_discharge', which inhibits charging, so system does not
>>> charge battery when AC is connected, but uses AC to supply itself
>>> (so battery is idle)?
>>>
>>> We already have this kind of features on embedded systems (which
>>> often provide all kind of charger details). Those drivers solve
>>> this by having a writable 'status' property in the charger device:
>>>
>>> What:           /sys/class/power_supply/<supply_name>/status
>>> Date:           May 2007
>>> Contact:        linux-pm@vger.kernel.org
>>> Description:
>>>                   Represents the charging status of the battery. Normally this
>>>                   is read-only reporting although for some supplies this can be
>>>                   used to enable/disable charging to the battery.
>>>
>>>                   Access: Read, Write
>>>
>>>                   Valid values:
>>>                                 "Unknown", "Charging", "Discharging",
>>>                                 "Not charging", "Full"
>>>
>>> If I do not miss anything writing "Discharging" is the same as forced
>>> discharge and "Not Charging" (AKA Idle) is the same as your inhibit feature.
>>
>> There are ThinkPads with two batteries (BAT0, BAT1) and the hardware
>> allows to select which one to discharge. An approach through
>> /sys/class/power_supply/AC/status won't cover this.
>
> The mentioned status strings come from /sys/class/power_supply/VAT#/status,
> rather then from /sys/class/power_supply/AC/status.
>
> There is one problem though, which is that the status attribute is being
> managed by drivers/acpi/battery.c. There is infra for a driver like
> the thinkpad_apci driver to add new attributes to a power_supply but
> AFAIK there is no infra to say intercept writes to an attribute where
> the reading is handled by another driver.
>
> I guess we could add some special hook to allow another driver to
> intercept status writes.
>
> Sebastian, what is your take on this ?
>
> Regards,
>
> Hans
>

  reply	other threads:[~2021-04-17 11:50 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 [this message]
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
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=a2d850e9-789d-54e8-e098-1a0829504031@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=pobrn@protonmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.