linux-kernel - Re: Generic battery interface

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20060727145944.GB3131@elf.ucw.cz>
Date:	Thu, 27 Jul 2006 16:59:44 +0200
From:	Pavel Machek <pavel@...e.cz>
To:	Shem Multinymous <multinymous@...il.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>, vojtech@...e.cz,
	Len Brown <len.brown@...el.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-thinkpad@...ux-thinkpad.org
Subject: Re: Generic battery interface

Hi!

> >This would also be useful for the OLPC project - it's unlikely that
> >it'll use ACPI, but a more feature-rich interface than /proc/apm would
> >be massively helpful. This is just a matter of speccing out what
> >information is needed and what format it should be presented in, and
> >then adding a new device class, right?
> 
> Can we really assume there's one driver providing all battery-related
> attributes?

Anything else would be crazy, I'd say.

> For example, on a ThinkPad you want the ACPI battery module loaded so
> that handles hande battery-related ACPI events, but on ACPI can't
> doesn't provide all available attributes. For example, ACPI reports
> the equvialent of
>  /sys/devices/platform/smapi/BAT0/power_avg (last minute average)
> but not
>  /sys/devices/platform/smapi/BAT0/power_now (instantaneous average)
> or
>  /sys/devices/platform/smapi/BAT0/cycle_count
> or control functions like
>  /sys/devices/platform/smapi/BAT0/force_discharge
> (see http://thinkwiki.org/wiki/tp_smapi for detials).

Well, in that case probably smapi driver should "hook into" acpi
driver.

> In this particular case we could split the ACPI module into two, one
> module for events and one module for the sysfs interface, and load
> only the first one on ThinkPads. But that's only because tp_smapi
> happens to reproduce all of ACPI's attributes; there are probably
> other cases whether neither method dominates the other.

I hope such hardware will not be too common. Thinkpad is covered by
accident, and I do not know about any other problematic machine.

Worst case, we would get equivalent of

/sys/class/battery/system_battery_acpi/...
/sys/class/battery/system_battery_some_clever_vendor_hack/...

with some values common between both of them. I'd say it is still
better than having vendor_hack in /sys in one format while having acpi
battery in /proc/acpi in completely different format.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/