linux-kernel - Re: [PATCH 0/4] thinkpad_acpi: Add support for controlling charge thresholds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131230200658.GA1808@khazad-dum.debian.net>
Date:	Mon, 30 Dec 2013 18:06:58 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Julian Andres Klode <jak@...-linux.org>,
	Henrique de Moraes Holschuh <ibm-acpi@....eng.br>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	"open list:THINKPAD ACPI EXT..." 
	<ibm-acpi-devel@...ts.sourceforge.net>,
	"open list:THINKPAD ACPI EXT..." 
	<platform-driver-x86@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] thinkpad_acpi: Add support for controlling charge
 thresholds

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/