From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Julian Andres Klode <jak@jak-linux.org>,
Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>,
Matthew Garrett <matthew.garrett@nebula.com>,
"open list:THINKPAD ACPI EXT..."
<ibm-acpi-devel@lists.sourceforge.net>,
"open list:THINKPAD ACPI EXT..."
<platform-driver-x86@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] thinkpad_acpi: Add support for controlling charge thresholds
Date: Mon, 30 Dec 2013 18:06:58 -0200 [thread overview]
Message-ID: <20131230200658.GA1808@khazad-dum.debian.net> (raw)
In-Reply-To: <20131230132619.GA24241@jak-x230>
On Mon, 30 Dec 2013, Julian Andres Klode wrote:
> I think that a more generic approach is a good idea, but
> I don't think creating a new power supply device would be the right
...
> We could extend the existing battery devices and then get paths like
> /sys/class/power_supply/BAT0/start_charge_thresh
> which looks `natural'. There is one problem with that approach, though:
I'm fine with extending battery devices, in fact I agree that it would be a
better place to add these attributes to.
> A ThinkPad supports multiple batteries: In my case, I could add a slice
> battery. But the ACPI driver only exposes a BAT0 device without a slice
> being attached (I assume a BAT1 will pop-up if you add a slice battery,
Thinkpad batteries are static, BAT1 is always BAT1 for the firmware,
regardless of whether BAT0 is present or not. Their parameters can always
be set as well, since they're stored in the EC and not in the battery pack
uC. And the EC doesn't care whether the battery is present or not.
> but can't test it, as I don't own one). This means that you can only
> configure the slice battery when it's plugged in. I don't know if its
> a good idea to work like this.
We could change the ACPI battery driver to optionally allow a platform
driver (or a dmi table) to order it to register batteries that are not
present at boot, and set that flag for thinkpads.
> Another problem is that I don't know any other systems supporting charge
> thresholds, and I don't want to dictate interfaces built for ThinkPads
> as a generic way.
All SBS batteries support it, which means most notebooks do. Whether they
expose it or not, and whether their platform drivers know about it or not in
order to expose these parameters to the kernel and to userspace, is a
separate issue.
Refer to: http://www.sbs-forum.org/
So yes, we can and should add these as generic *optional* parameters for
generic batteries. How to best add it to the ACPI battery driver is
something to think about.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2013-12-30 20:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 13:56 [PATCH 0/4] thinkpad_acpi: Add support for controlling charge thresholds Julian Andres Klode
2013-11-11 13:56 ` [PATCH 1/4] " Julian Andres Klode
2013-11-13 13:50 ` Julian Andres Klode
2013-12-30 13:29 ` Julian Andres Klode
2013-12-30 21:58 ` Henrique de Moraes Holschuh
2013-12-30 22:40 ` Henrique de Moraes Holschuh
2013-12-31 0:01 ` Julian Andres Klode
2013-12-31 12:12 ` [ibm-acpi-devel] " Henrique de Moraes Holschuh
2013-12-31 22:46 ` Julian Andres Klode
2014-04-06 12:14 ` Julian Andres Klode
2014-04-09 18:00 ` Henrique de Moraes Holschuh
2013-11-11 13:56 ` [PATCH 2/4] thinkpad_acpi: battery: Add force_discharge attribute Julian Andres Klode
2013-11-11 13:56 ` [PATCH 3/4] thinkpad_acpi: battery: Add force_discharge_ac_break attribute Julian Andres Klode
2013-11-11 13:56 ` [PATCH 4/4] thinkpad_acpi: battery: Add inhibit_charge_minutes attribute Julian Andres Klode
2013-11-25 14:59 ` [PATCH 0/4] thinkpad_acpi: Add support for controlling charge thresholds Julian Andres Klode
2013-12-28 21:10 ` Julian Andres Klode
2013-12-28 22:10 ` Henrique de Moraes Holschuh
2013-12-30 13:26 ` Julian Andres Klode
2013-12-30 20:06 ` Henrique de Moraes Holschuh [this message]
2014-01-20 21:22 ` Pavel Machek
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=20131230200658.GA1808@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=ibm-acpi@hmh.eng.br \
--cc=jak@jak-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.garrett@nebula.com \
--cc=platform-driver-x86@vger.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