public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 1/4] thinkpad_acpi: Add support for controlling charge thresholds
Date: Mon, 30 Dec 2013 20:40:45 -0200	[thread overview]
Message-ID: <20131230224045.GC4938@khazad-dum.debian.net> (raw)
In-Reply-To: <20131230215843.GB4938@khazad-dum.debian.net>

On Mon, 30 Dec 2013, Henrique de Moraes Holschuh wrote:
> On Mon, 30 Dec 2013, Julian Andres Klode wrote:
> > On Mon, Nov 11, 2013 at 02:56:30PM +0100, Julian Andres Klode wrote:
> > > Add support for battery charge thresholds in new Sandy Bridge and Ivy Bridge
> > > ThinkPads. Based on the unofficial documentation in tpacpi-bat.
> > > 
> > > The threshold files support the values '0' for the controller's default,
> > > and 1-99 as percentages. Values outside of that range are rejected. The
> > > behaviour of '0' might be confusing, especially for the stop case where
> > > it basically seems to mean '100'.
> > 
> > Thinking more about this, it might make more sense to simply accept a 100
> > value and not accept a 0 value in the stop case (I tried multiple times to
> > write 100 to a stop_charge_thresh file, because that feels more natural).
> > 
> > Having a 0 mean 100% is just odd. So stop_charge_thresh should simply
> > accepts integer values in the range [1, 100] (and start_charge_thresh
> > should continue accept [0, 99], as 0 really means 0 there).
> 
> Indeed.  Just return EINVAL for a stop threshold of 0.

Actually, a stop threshold below the current start threshold is also invalid
and what happens when you try that is implementation-specific.  And the
kernel is not the only party who can change the thresholds, so you have to
read them if you really need to know the current value.

To correct myself, stop threshold being zero is also implementation-
specific. on thinkpads it is not valid.

For thinkpads, I believe the EC firmware changes the other threshold so that
the boundary condition stop > start is always valid.  But I never tried it
with a direct EC write to validate this.  If it becomes important, I can
check -- but I'd still prefer to enforce sanity at the driver level just in
case.  Don't tempt the gremilins, for they live at boundary conditions and
their sleep is light indeed.

-- 
  "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

  reply	other threads:[~2013-12-30 22:40 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 [this message]
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
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=20131230224045.GC4938@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