3.14-rc: /proc/acpi/battery gone?

3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

Hi!

It seems /proc/acpi/battery interface is gone, and I don't see any
option to reintroduce it... what is going on?

(I got into habit of archiving content of /proc/acpi/battery to
monitor, how battery ages..)

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

Hi!

> It seems /proc/acpi/battery interface is gone, and I don't see any
> option to reintroduce it... what is going on?
> 
> (I got into habit of archiving content of /proc/acpi/battery to
> monitor, how battery ages..)

And this is ungood:

pavel@duo:~/denx/active$ cat /sys/class/power_supply/BAT0/alarm 
2403000

What is it? Not exactly easy to guess, and not documented. 

pavel@duo:~$ grep alarm /data/l/linux-good/Documentation/ABI/*/*
/data/l/linux-good/Documentation/ABI/testing/sysfs-ptp:What:
/sys/class/ptp/ptpN/n_alarms
/data/l/linux-good/Documentation/ABI/testing/sysfs-ptp:		alarms
offer by the PTP hardware clock.
pavel@duo:~$ 

I wish files with physical values included units. alarm is probably in
uA, but it might be uW as well, and ... :-(.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.14-rc: /proc/acpi/battery gone?

[Ilia Mirkin]

On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> It seems /proc/acpi/battery interface is gone, and I don't see any
> option to reintroduce it... what is going on?

The interface went away in a semi-recent kernel release (3.13 or
3.12), breaking pretty much every battery app. (Admittedly the
interface was marked as deprecated for quite some time, but that
didn't stop everyone from using it and not caring about the new
thing.) I've yet to find a windowmaker dock app that works with the
current sysfs API :(

  -ilia

Re: 3.14-rc: /proc/acpi/battery gone?

[Richard Weinberger]

On Fri, Mar 14, 2014 at 10:29 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> Hi!
>>
>> It seems /proc/acpi/battery interface is gone, and I don't see any
>> option to reintroduce it... what is going on?
>
> The interface went away in a semi-recent kernel release (3.13 or
> 3.12), breaking pretty much every battery app. (Admittedly the
> interface was marked as deprecated for quite some time, but that
> didn't stop everyone from using it and not caring about the new
> thing.) I've yet to find a windowmaker dock app that works with the
> current sysfs API :(
>

commit 1e2d9cdfb4494fce682b4ae010d86a2766816d36
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Fri Oct 11 09:54:08 2013 +0800

    ACPI / Battery: Remove battery's proc directory

    The battery's proc directory isn't useded and remove it.

    Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Looks like this one is the said commit.
If it breaks userspace we have to revert it IMHO.

-- 
Thanks,
//richard

Re: 3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> > It seems /proc/acpi/battery interface is gone, and I don't see any
> > option to reintroduce it... what is going on?
> 
> The interface went away in a semi-recent kernel release (3.13 or
> 3.12), breaking pretty much every battery app. (Admittedly the
> interface was marked as deprecated for quite some time, but that
> didn't stop everyone from using it and not caring about the new
> thing.) I've yet to find a windowmaker dock app that works with the
> current sysfs API :(

Name one application it broke, and we'll get it reverted. It broke my
by-hand journalling, at the very least.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.14-rc: /proc/acpi/battery gone?

[Ilia Mirkin]

On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
>> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> > Hi!
>> >
>> > It seems /proc/acpi/battery interface is gone, and I don't see any
>> > option to reintroduce it... what is going on?
>>
>> The interface went away in a semi-recent kernel release (3.13 or
>> 3.12), breaking pretty much every battery app. (Admittedly the
>> interface was marked as deprecated for quite some time, but that
>> didn't stop everyone from using it and not caring about the new
>> thing.) I've yet to find a windowmaker dock app that works with the
>> current sysfs API :(
>
> Name one application it broke, and we'll get it reverted. It broke my
> by-hand journalling, at the very least.

wmbattery

They have attempted to use the sysfs api, but apparently that
integration was done with an older version of that API. There's also
some attempt to get it to work with upower, but I couldn't figure out
how to make that work either on my (up-to-date gentoo) box. (TBH I
didn't spend more than an hour or two on it, so it may not be
impossible.)

  -ilia

Re: 3.14-rc: /proc/acpi/battery gone?

[Rafael J. Wysocki]

On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:
> On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
> >> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >> > Hi!
> >> >
> >> > It seems /proc/acpi/battery interface is gone, and I don't see any
> >> > option to reintroduce it... what is going on?
> >>
> >> The interface went away in a semi-recent kernel release (3.13 or
> >> 3.12), breaking pretty much every battery app. (Admittedly the
> >> interface was marked as deprecated for quite some time, but that
> >> didn't stop everyone from using it and not caring about the new
> >> thing.) I've yet to find a windowmaker dock app that works with the
> >> current sysfs API :(
> >
> > Name one application it broke, and we'll get it reverted. It broke my
> > by-hand journalling, at the very least.
> 
> wmbattery
> 
> They have attempted to use the sysfs api, but apparently that
> integration was done with an older version of that API. There's also
> some attempt to get it to work with upower, but I couldn't figure out
> how to make that work either on my (up-to-date gentoo) box. (TBH I
> didn't spend more than an hour or two on it, so it may not be
> impossible.)

Tianyu, can you please have a look at this?

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: 3.14-rc: /proc/acpi/battery gone?

[Stefan Lippers-Hollmann]

Hi

On Saturday 15 March 2014, Rafael J. Wysocki wrote:
> On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:
> > On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > > On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
> > >> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
[...]
> > wmbattery
> > 
> > They have attempted to use the sysfs api, but apparently that
> > integration was done with an older version of that API. There's also
> > some attempt to get it to work with upower, but I couldn't figure out
> > how to make that work either on my (up-to-date gentoo) box. (TBH I
> > didn't spend more than an hour or two on it, so it may not be
> > impossible.)
> 
> Tianyu, can you please have a look at this?

Disclaimer, I've never used wmbattery so far.

The current upstream version (2.42, released in early december 2013) 
of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
it changed to using upower by default, with non-default fall-backs for
reading from sysfs. 

The only change required for building upower with wmbattery 2.42 
appears to be a new build-dependency on libupower-glib-dev (at least 
on Debian, built from the upower source package). Given that this 
version is present in Debian testing and unstable, I'd assume that it's
supposed to work using upower, although I haven't confirmed that myself.

Judging from the Gentoo ebuild, you probably just have to add 
"sys-power/upower" to the RDEPEND variable and make sure to build
wmbattery 2.42; this is untested.

Regards
	Stefan Lippers-Hollmann

[1]	Homepage: http://kitenet.net/~joey/code/wmbattery/
	Vcs-Git: git://git.kitenet.net/wmbattery

Re: 3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

On Sat 2014-03-15 02:46:19, Rafael J. Wysocki wrote:
> On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:
> > On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > > On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
> > >> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > >> > Hi!
> > >> >
> > >> > It seems /proc/acpi/battery interface is gone, and I don't see any
> > >> > option to reintroduce it... what is going on?
> > >>
> > >> The interface went away in a semi-recent kernel release (3.13 or
> > >> 3.12), breaking pretty much every battery app. (Admittedly the
> > >> interface was marked as deprecated for quite some time, but that
> > >> didn't stop everyone from using it and not caring about the new
> > >> thing.) I've yet to find a windowmaker dock app that works with the
> > >> current sysfs API :(
> > >
> > > Name one application it broke, and we'll get it reverted. It broke my
> > > by-hand journalling, at the very least.
> > 
> > wmbattery
> > 
> > They have attempted to use the sysfs api, but apparently that
> > integration was done with an older version of that API. There's also
> > some attempt to get it to work with upower, but I couldn't figure out
> > how to make that work either on my (up-to-date gentoo) box. (TBH I
> > didn't spend more than an hour or two on it, so it may not be
> > impossible.)
> 
> Tianyu, can you please have a look at this?

So far I tried patch below, but it says:

ACPI: Deprecated procfs I/F for battery is loaded, please retry with
CONFIG_ACPI_PROCFS_POWER cleared
ACPI: Battery Slot [BAT0] (battery present)
Error: Driver 'battery' is already registered, aborting...
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

and /proc/acpi does not appear.

										Pavel

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 4770de5..561bf25 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -56,6 +56,23 @@ config ACPI_PROCFS
 
 	  Say N to delete /proc/acpi/ files that have moved to /sys/
 
+config ACPI_PROCFS_POWER
+	bool "Deprecated power /proc/acpi directories"
+	depends on PROC_FS
+	help
+	  For backwards compatibility, this option allows
+          deprecated power /proc/acpi/ directories to exist, even when
+          they have been replaced by functions in /sys.
+          The deprecated directories (and their replacements) include:
+	  /proc/acpi/battery/* (/sys/class/power_supply/*)
+	  /proc/acpi/ac_adapter/* (sys/class/power_supply/*)
+	  This option has no effect on /proc/acpi/ directories
+	  and functions, which do not yet exist in /sys
+	  This option, together with the proc directories, will be
+	  deleted in 2.6.39.
+
+	  Say N to delete power /proc/acpi/ directories that have moved to /sys/
+
 config ACPI_EC_DEBUGFS
 	tristate "EC read/write access through /sys/kernel/debug/ec"
 	default n
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..bce34af 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -47,6 +47,7 @@ acpi-y				+= sysfs.o
 acpi-$(CONFIG_X86)		+= acpi_cmos_rtc.o
 acpi-$(CONFIG_DEBUG_FS)		+= debugfs.o
 acpi-$(CONFIG_ACPI_NUMA)	+= numa.o
+acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 ifdef CONFIG_ACPI_VIDEO
 acpi-y				+= video_detect.o
 endif
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 797a693..dfe31f6 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -37,6 +37,16 @@
 #include <asm/unaligned.h>
 
 #include <linux/acpi.h>
+
+#ifdef CONFIG_ACPI_PROCFS_POWER
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+#include <asm/uaccess.h>
+#endif
+
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+
 #include <linux/power_supply.h>
 
 #define PREFIX "ACPI: "
@@ -66,6 +76,19 @@ static unsigned int cache_time = 1000;
 module_param(cache_time, uint, 0644);
 MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
 
+#ifdef CONFIG_ACPI_PROCFS_POWER
+extern struct proc_dir_entry *acpi_lock_battery_dir(void);
+extern void *acpi_unlock_battery_dir(struct proc_dir_entry *acpi_battery_dir);
+
+enum acpi_battery_files {
+	info_tag = 0,
+	state_tag,
+	alarm_tag,
+	ACPI_BATTERY_NUMFILES,
+};
+
+#endif
+
 static const struct acpi_device_id battery_device_ids[] = {
 	{"PNP0C0A", 0},
 	{"", 0},
@@ -301,6 +324,14 @@ static enum power_supply_property energy_battery_props[] = {
 	POWER_SUPPLY_PROP_SERIAL_NUMBER,
 };
 
+#ifdef CONFIG_ACPI_PROCFS_POWER
+inline char *acpi_battery_units(struct acpi_battery *battery)
+{
+	return (battery->power_unit == ACPI_BATTERY_POWER_UNIT_MA) ?
+		"mA" : "mW";
+}
+#endif
+
 /* --------------------------------------------------------------------------
                                Battery Management
    -------------------------------------------------------------------------- */
@@ -719,6 +750,279 @@ static void acpi_battery_refresh(struct acpi_battery *battery)
 }
 
 /* --------------------------------------------------------------------------
+                              FS Interface (/proc)
+   -------------------------------------------------------------------------- */
+
+#ifdef CONFIG_ACPI_PROCFS_POWER
+static struct proc_dir_entry *acpi_battery_dir;
+
+static int acpi_battery_print_info(struct seq_file *seq, int result)
+{
+	struct acpi_battery *battery = seq->private;
+
+	if (result)
+		goto end;
+
+	seq_printf(seq, "present:                 %s\n",
+		   acpi_battery_present(battery) ? "yes" : "no");
+	if (!acpi_battery_present(battery))
+		goto end;
+	if (battery->design_capacity == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "design capacity:         unknown\n");
+	else
+		seq_printf(seq, "design capacity:         %d %sh\n",
+			   battery->design_capacity,
+			   acpi_battery_units(battery));
+
+	if (battery->full_charge_capacity == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "last full capacity:      unknown\n");
+	else
+		seq_printf(seq, "last full capacity:      %d %sh\n",
+			   battery->full_charge_capacity,
+			   acpi_battery_units(battery));
+
+	seq_printf(seq, "battery technology:      %srechargeable\n",
+		   (!battery->technology)?"non-":"");
+
+	if (battery->design_voltage == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "design voltage:          unknown\n");
+	else
+		seq_printf(seq, "design voltage:          %d mV\n",
+			   battery->design_voltage);
+	seq_printf(seq, "design capacity warning: %d %sh\n",
+		   battery->design_capacity_warning,
+		   acpi_battery_units(battery));
+	seq_printf(seq, "design capacity low:     %d %sh\n",
+		   battery->design_capacity_low,
+		   acpi_battery_units(battery));
+	seq_printf(seq, "cycle count:		  %i\n", battery->cycle_count);
+	seq_printf(seq, "capacity granularity 1:  %d %sh\n",
+		   battery->capacity_granularity_1,
+		   acpi_battery_units(battery));
+	seq_printf(seq, "capacity granularity 2:  %d %sh\n",
+		   battery->capacity_granularity_2,
+		   acpi_battery_units(battery));
+	seq_printf(seq, "model number:            %s\n", battery->model_number);
+	seq_printf(seq, "serial number:           %s\n", battery->serial_number);
+	seq_printf(seq, "battery type:            %s\n", battery->type);
+	seq_printf(seq, "OEM info:                %s\n", battery->oem_info);
+      end:
+	if (result)
+		seq_printf(seq, "ERROR: Unable to read battery info\n");
+	return result;
+}
+
+static int acpi_battery_print_state(struct seq_file *seq, int result)
+{
+	struct acpi_battery *battery = seq->private;
+
+	if (result)
+		goto end;
+
+	seq_printf(seq, "present:                 %s\n",
+		   acpi_battery_present(battery) ? "yes" : "no");
+	if (!acpi_battery_present(battery))
+		goto end;
+
+	seq_printf(seq, "capacity state:          %s\n",
+			(battery->state & 0x04) ? "critical" : "ok");
+	if ((battery->state & 0x01) && (battery->state & 0x02))
+		seq_printf(seq,
+			   "charging state:          charging/discharging\n");
+	else if (battery->state & 0x01)
+		seq_printf(seq, "charging state:          discharging\n");
+	else if (battery->state & 0x02)
+		seq_printf(seq, "charging state:          charging\n");
+	else
+		seq_printf(seq, "charging state:          charged\n");
+
+	if (battery->rate_now == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "present rate:            unknown\n");
+	else
+		seq_printf(seq, "present rate:            %d %s\n",
+			   battery->rate_now, acpi_battery_units(battery));
+
+	if (battery->capacity_now == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "remaining capacity:      unknown\n");
+	else
+		seq_printf(seq, "remaining capacity:      %d %sh\n",
+			   battery->capacity_now, acpi_battery_units(battery));
+	if (battery->voltage_now == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "present voltage:         unknown\n");
+	else
+		seq_printf(seq, "present voltage:         %d mV\n",
+			   battery->voltage_now);
+      end:
+	if (result)
+		seq_printf(seq, "ERROR: Unable to read battery state\n");
+
+	return result;
+}
+
+static int acpi_battery_print_alarm(struct seq_file *seq, int result)
+{
+	struct acpi_battery *battery = seq->private;
+
+	if (result)
+		goto end;
+
+	if (!acpi_battery_present(battery)) {
+		seq_printf(seq, "present:                 no\n");
+		goto end;
+	}
+	seq_printf(seq, "alarm:                   ");
+	if (!battery->alarm)
+		seq_printf(seq, "unsupported\n");
+	else
+		seq_printf(seq, "%u %sh\n", battery->alarm,
+				acpi_battery_units(battery));
+      end:
+	if (result)
+		seq_printf(seq, "ERROR: Unable to read battery alarm\n");
+	return result;
+}
+
+static ssize_t acpi_battery_write_alarm(struct file *file,
+					const char __user * buffer,
+					size_t count, loff_t * ppos)
+{
+	int result = 0;
+	char alarm_string[12] = { '\0' };
+	struct seq_file *m = file->private_data;
+	struct acpi_battery *battery = m->private;
+
+	if (!battery || (count > sizeof(alarm_string) - 1))
+		return -EINVAL;
+	if (!acpi_battery_present(battery)) {
+		result = -ENODEV;
+		goto end;
+	}
+	if (copy_from_user(alarm_string, buffer, count)) {
+		result = -EFAULT;
+		goto end;
+	}
+	alarm_string[count] = '\0';
+	battery->alarm = simple_strtol(alarm_string, NULL, 0);
+	result = acpi_battery_set_alarm(battery);
+      end:
+	if (!result)
+		return count;
+	return result;
+}
+
+typedef int(*print_func)(struct seq_file *seq, int result);
+
+static print_func acpi_print_funcs[ACPI_BATTERY_NUMFILES] = {
+	acpi_battery_print_info,
+	acpi_battery_print_state,
+	acpi_battery_print_alarm,
+};
+
+static int acpi_battery_read(int fid, struct seq_file *seq)
+{
+	struct acpi_battery *battery = seq->private;
+	int result = acpi_battery_update(battery);
+	return acpi_print_funcs[fid](seq, result);
+}
+
+#define DECLARE_FILE_FUNCTIONS(_name) \
+static int acpi_battery_read_##_name(struct seq_file *seq, void *offset) \
+{ \
+	return acpi_battery_read(_name##_tag, seq); \
+} \
+static int acpi_battery_##_name##_open_fs(struct inode *inode, struct file *file) \
+{ \
+	return single_open(file, acpi_battery_read_##_name, PDE_DATA(inode)); \
+}
+
+DECLARE_FILE_FUNCTIONS(info);
+DECLARE_FILE_FUNCTIONS(state);
+DECLARE_FILE_FUNCTIONS(alarm);
+
+#undef DECLARE_FILE_FUNCTIONS
+
+#define FILE_DESCRIPTION_RO(_name) \
+	{ \
+	.name = __stringify(_name), \
+	.mode = S_IRUGO, \
+	.ops = { \
+		.open = acpi_battery_##_name##_open_fs, \
+		.read = seq_read, \
+		.llseek = seq_lseek, \
+		.release = single_release, \
+		.owner = THIS_MODULE, \
+		}, \
+	}
+
+#define FILE_DESCRIPTION_RW(_name) \
+	{ \
+	.name = __stringify(_name), \
+	.mode = S_IFREG | S_IRUGO | S_IWUSR, \
+	.ops = { \
+		.open = acpi_battery_##_name##_open_fs, \
+		.read = seq_read, \
+		.llseek = seq_lseek, \
+		.write = acpi_battery_write_##_name, \
+		.release = single_release, \
+		.owner = THIS_MODULE, \
+		}, \
+	}
+
+static const struct battery_file {
+	struct file_operations ops;
+	umode_t mode;
+	const char *name;
+} acpi_battery_file[] = {
+	FILE_DESCRIPTION_RO(info),
+	FILE_DESCRIPTION_RO(state),
+	FILE_DESCRIPTION_RW(alarm),
+};
+
+#undef FILE_DESCRIPTION_RO
+#undef FILE_DESCRIPTION_RW
+
+static int acpi_battery_add_fs(struct acpi_device *device)
+{
+	struct proc_dir_entry *entry = NULL;
+	int i;
+
+	printk(KERN_WARNING PREFIX "Deprecated procfs I/F for battery is loaded,"
+			" please retry with CONFIG_ACPI_PROCFS_POWER cleared\n");
+	if (!acpi_device_dir(device)) {
+		acpi_device_dir(device) = proc_mkdir(acpi_device_bid(device),
+						     acpi_battery_dir);
+		if (!acpi_device_dir(device))
+			return -ENODEV;
+	}
+
+	for (i = 0; i < ACPI_BATTERY_NUMFILES; ++i) {
+		entry = proc_create_data(acpi_battery_file[i].name,
+					 acpi_battery_file[i].mode,
+					 acpi_device_dir(device),
+					 &acpi_battery_file[i].ops,
+					 acpi_driver_data(device));
+		if (!entry)
+			return -ENODEV;
+	}
+	return 0;
+}
+
+static void acpi_battery_remove_fs(struct acpi_device *device)
+{
+	int i;
+	if (!acpi_device_dir(device))
+		return;
+	for (i = 0; i < ACPI_BATTERY_NUMFILES; ++i)
+		remove_proc_entry(acpi_battery_file[i].name,
+				  acpi_device_dir(device));
+
+	remove_proc_entry(acpi_device_bid(device), acpi_battery_dir);
+	acpi_device_dir(device) = NULL;
+}
+
+#endif
+
+/* --------------------------------------------------------------------------
                                  Driver Interface
    -------------------------------------------------------------------------- */
 
@@ -791,6 +1095,15 @@ static int acpi_battery_add(struct acpi_device *device)
 	result = acpi_battery_update(battery);
 	if (result)
 		goto fail;
+#ifdef CONFIG_ACPI_PROCFS_POWER
+	result = acpi_battery_add_fs(device);
+#endif
+	if (result) {
+#ifdef CONFIG_ACPI_PROCFS_POWER
+		acpi_battery_remove_fs(device);
+#endif
+		goto fail;
+	}
 
 	printk(KERN_INFO PREFIX "%s Slot [%s] (battery %s)\n",
 		ACPI_BATTERY_DEVICE_NAME, acpi_device_bid(device),
@@ -817,6 +1130,9 @@ static int acpi_battery_remove(struct acpi_device *device)
 		return -EINVAL;
 	battery = acpi_driver_data(device);
 	unregister_pm_notifier(&battery->pm_nb);
+#ifdef CONFIG_ACPI_PROCFS_POWER
+	acpi_battery_remove_fs(device);
+#endif
 	sysfs_remove_battery(battery);
 	mutex_destroy(&battery->lock);
 	mutex_destroy(&battery->sysfs_lock);
@@ -865,9 +1181,23 @@ static void __init acpi_battery_init_async(void *unused, async_cookie_t cookie)
 	if (acpi_disabled)
 		return;
 
+
 	if (dmi_check_system(bat_dmi_table))
 		battery_bix_broken_package = 1;
 	acpi_bus_register_driver(&acpi_battery_driver);
+
+#ifdef CONFIG_ACPI_PROCFS_POWER
+	acpi_battery_dir = acpi_lock_battery_dir();
+	if (!acpi_battery_dir)
+		return;
+#endif
+	if (acpi_bus_register_driver(&acpi_battery_driver) < 0) {
+#ifdef CONFIG_ACPI_PROCFS_POWER
+		acpi_unlock_battery_dir(acpi_battery_dir);
+#endif
+		return;
+	}
+	return;
 }
 
 static int __init acpi_battery_init(void)
@@ -879,6 +1209,9 @@ static int __init acpi_battery_init(void)
 static void __exit acpi_battery_exit(void)
 {
 	acpi_bus_unregister_driver(&acpi_battery_driver);
+#ifdef CONFIG_ACPI_PROCFS_POWER
+	acpi_unlock_battery_dir(acpi_battery_dir);
+#endif
 }
 
 module_init(acpi_battery_init);
diff --git a/drivers/acpi/cm_sbs.c b/drivers/acpi/cm_sbs.c
new file mode 100644
index 0000000..6c9ee68
--- /dev/null
+++ b/drivers/acpi/cm_sbs.c
@@ -0,0 +1,105 @@
+/*
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/acpi.h>
+#include <linux/types.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+
+#define PREFIX "ACPI: "
+
+ACPI_MODULE_NAME("cm_sbs");
+#define ACPI_AC_CLASS		"ac_adapter"
+#define ACPI_BATTERY_CLASS	"battery"
+#define _COMPONENT		ACPI_SBS_COMPONENT
+static struct proc_dir_entry *acpi_ac_dir;
+static struct proc_dir_entry *acpi_battery_dir;
+
+static DEFINE_MUTEX(cm_sbs_mutex);
+
+static int lock_ac_dir_cnt;
+static int lock_battery_dir_cnt;
+
+struct proc_dir_entry *acpi_lock_ac_dir(void)
+{
+	mutex_lock(&cm_sbs_mutex);
+	if (!acpi_ac_dir)
+		acpi_ac_dir = proc_mkdir(ACPI_AC_CLASS, acpi_root_dir);
+	if (acpi_ac_dir) {
+		lock_ac_dir_cnt++;
+	} else {
+		printk(KERN_ERR PREFIX
+				  "Cannot create %s\n", ACPI_AC_CLASS);
+	}
+	mutex_unlock(&cm_sbs_mutex);
+	return acpi_ac_dir;
+}
+EXPORT_SYMBOL(acpi_lock_ac_dir);
+
+void acpi_unlock_ac_dir(struct proc_dir_entry *acpi_ac_dir_param)
+{
+	mutex_lock(&cm_sbs_mutex);
+	if (acpi_ac_dir_param)
+		lock_ac_dir_cnt--;
+	if (lock_ac_dir_cnt == 0 && acpi_ac_dir_param && acpi_ac_dir) {
+		remove_proc_entry(ACPI_AC_CLASS, acpi_root_dir);
+		acpi_ac_dir = NULL;
+	}
+	mutex_unlock(&cm_sbs_mutex);
+}
+EXPORT_SYMBOL(acpi_unlock_ac_dir);
+
+struct proc_dir_entry *acpi_lock_battery_dir(void)
+{
+	mutex_lock(&cm_sbs_mutex);
+	if (!acpi_battery_dir) {
+		acpi_battery_dir =
+		    proc_mkdir(ACPI_BATTERY_CLASS, acpi_root_dir);
+	}
+	if (acpi_battery_dir) {
+		lock_battery_dir_cnt++;
+	} else {
+		printk(KERN_ERR PREFIX
+				  "Cannot create %s\n", ACPI_BATTERY_CLASS);
+	}
+	mutex_unlock(&cm_sbs_mutex);
+	return acpi_battery_dir;
+}
+EXPORT_SYMBOL(acpi_lock_battery_dir);
+
+void acpi_unlock_battery_dir(struct proc_dir_entry *acpi_battery_dir_param)
+{
+	mutex_lock(&cm_sbs_mutex);
+	if (acpi_battery_dir_param)
+		lock_battery_dir_cnt--;
+	if (lock_battery_dir_cnt == 0 && acpi_battery_dir_param
+	    && acpi_battery_dir) {
+		remove_proc_entry(ACPI_BATTERY_CLASS, acpi_root_dir);
+		acpi_battery_dir = NULL;
+	}
+	mutex_unlock(&cm_sbs_mutex);
+	return;
+}
+EXPORT_SYMBOL(acpi_unlock_battery_dir);


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 03/14/2014 05:45 PM, Richard Weinberger wrote:
> On Fri, Mar 14, 2014 at 10:29 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
>>> Hi!
>>>
>>> It seems /proc/acpi/battery interface is gone, and I don't see any
>>> option to reintroduce it... what is going on?
>>
>> The interface went away in a semi-recent kernel release (3.13 or
>> 3.12), breaking pretty much every battery app. (Admittedly the
>> interface was marked as deprecated for quite some time, but that
>> didn't stop everyone from using it and not caring about the new
>> thing.) I've yet to find a windowmaker dock app that works with the
>> current sysfs API :(
>>
>
> commit 1e2d9cdfb4494fce682b4ae010d86a2766816d36
> Author: Lan Tianyu <tianyu.lan@intel.com>
> Date:   Fri Oct 11 09:54:08 2013 +0800
>
>      ACPI / Battery: Remove battery's proc directory
>
>      The battery's proc directory isn't useded and remove it.
>
>      Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Looks like this one is the said commit.
> If it breaks userspace we have to revert it IMHO.
>

Yes, we will revert the commit if it really breaks some APPs.

Re: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 03/14/2014 10:17 PM, Stefan Lippers-Hollmann wrote:
> Hi
>
> On Saturday 15 March 2014, Rafael J. Wysocki wrote:
>> On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:
>>> On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek <pavel@ucw.cz> wrote:
>>>> On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
>>>>> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> [...]
>>> wmbattery
>>>
>>> They have attempted to use the sysfs api, but apparently that
>>> integration was done with an older version of that API. There's also
>>> some attempt to get it to work with upower, but I couldn't figure out
>>> how to make that work either on my (up-to-date gentoo) box. (TBH I
>>> didn't spend more than an hour or two on it, so it may not be
>>> impossible.)
>>
>> Tianyu, can you please have a look at this?
>
> Disclaimer, I've never used wmbattery so far.
>
> The current upstream version (2.42, released in early december 2013)
> of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
> it changed to using upower by default, with non-default fall-backs for
> reading from sysfs.
>
> The only change required for building upower with wmbattery 2.42
> appears to be a new build-dependency on libupower-glib-dev (at least
> on Debian, built from the upower source package). Given that this
> version is present in Debian testing and unstable, I'd assume that it's
> supposed to work using upower, although I haven't confirmed that myself.
>
> Judging from the Gentoo ebuild, you probably just have to add
> "sys-power/upower" to the RDEPEND variable and make sure to build
> wmbattery 2.42; this is untested.
>

Hi Stefan:
	I just glance wmbattery code. I find the code in the acpi.c is already 
using the new sysfs battery interfaces, right?

...

#define SYSFS_PATH "/sys/class/power_supply"

...
char *acpi_labels[] = {
	"uevent",
	"status",
	"BAT",
	"AC",
	"POWER_SUPPLY_CAPACITY=",
	"POWER_SUPPLY_??????_FULL_DESIGN=", /* CHARGE or ENERGY */
	"POWER_SUPPLY_PRESENT=",
	"POWER_SUPPLY_??????_NOW=",
	"POWER_SUPPLY_CURRENT_NOW=",
	"POWER_SUPPLY_STATUS=",
#if ACPI_THERMAL
	"thermal_zone",
#endif
	"POWER_SUPPLY_ONLINE=",
	"POWER_SUPPLY_??????_FULL=",
	NULL
};


> Regards
> 	Stefan Lippers-Hollmann
>
> [1]	Homepage: http://kitenet.net/~joey/code/wmbattery/
> 	Vcs-Git: git://git.kitenet.net/wmbattery
>

Re: 3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

Hi!

> >>>They have attempted to use the sysfs api, but apparently that
> >>>integration was done with an older version of that API. There's also
> >>>some attempt to get it to work with upower, but I couldn't figure out
> >>>how to make that work either on my (up-to-date gentoo) box. (TBH I
> >>>didn't spend more than an hour or two on it, so it may not be
> >>>impossible.)
> >>
> >>Tianyu, can you please have a look at this?
> >
> >Disclaimer, I've never used wmbattery so far.
> >
> >The current upstream version (2.42, released in early december 2013)
> >of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
> >it changed to using upower by default, with non-default fall-backs for
> >reading from sysfs.
> >
> >The only change required for building upower with wmbattery 2.42
> >appears to be a new build-dependency on libupower-glib-dev (at least
> >on Debian, built from the upower source package). Given that this
> >version is present in Debian testing and unstable, I'd assume that it's
> >supposed to work using upower, although I haven't confirmed that myself.
> >
> >Judging from the Gentoo ebuild, you probably just have to add
> >"sys-power/upower" to the RDEPEND variable and make sure to build
> >wmbattery 2.42; this is untested.
> >
> 
> Hi Stefan:
> 	I just glance wmbattery code. I find the code in the acpi.c is
> already using the new sysfs battery interfaces, right?
> 
> ...
> 
> #define SYSFS_PATH "/sys/class/power_supply"
> 
> ...
> char *acpi_labels[] = {
> 	"uevent",
> 	"status",
> 	"BAT",
> 	"AC",
> 	"POWER_SUPPLY_CAPACITY=",
> 	"POWER_SUPPLY_??????_FULL_DESIGN=", /* CHARGE or ENERGY */
> 	"POWER_SUPPLY_PRESENT=",
> 	"POWER_SUPPLY_??????_NOW=",
> 	"POWER_SUPPLY_CURRENT_NOW=",
> 	"POWER_SUPPLY_STATUS=",
> #if ACPI_THERMAL
> 	"thermal_zone",
> #endif
> 	"POWER_SUPPLY_ONLINE=",
> 	"POWER_SUPPLY_??????_FULL=",
> 	NULL
> };

New kernel should work with old userspace... and clearly it does not.

Do you have test patch for a revert?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 03/15/2014 12:05 PM, Pavel Machek wrote:
> Hi!
>
>>>>> They have attempted to use the sysfs api, but apparently that
>>>>> integration was done with an older version of that API. There's also
>>>>> some attempt to get it to work with upower, but I couldn't figure out
>>>>> how to make that work either on my (up-to-date gentoo) box. (TBH I
>>>>> didn't spend more than an hour or two on it, so it may not be
>>>>> impossible.)
>>>>
>>>> Tianyu, can you please have a look at this?
>>>
>>> Disclaimer, I've never used wmbattery so far.
>>>
>>> The current upstream version (2.42, released in early december 2013)
>>> of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
>>> it changed to using upower by default, with non-default fall-backs for
>>> reading from sysfs.
>>>
>>> The only change required for building upower with wmbattery 2.42
>>> appears to be a new build-dependency on libupower-glib-dev (at least
>>> on Debian, built from the upower source package). Given that this
>>> version is present in Debian testing and unstable, I'd assume that it's
>>> supposed to work using upower, although I haven't confirmed that myself.
>>>
>>> Judging from the Gentoo ebuild, you probably just have to add
>>> "sys-power/upower" to the RDEPEND variable and make sure to build
>>> wmbattery 2.42; this is untested.
>>>
>>
>> Hi Stefan:
>> 	I just glance wmbattery code. I find the code in the acpi.c is
>> already using the new sysfs battery interfaces, right?
>>
>> ...
>>
>> #define SYSFS_PATH "/sys/class/power_supply"
>>
>> ...
>> char *acpi_labels[] = {
>> 	"uevent",
>> 	"status",
>> 	"BAT",
>> 	"AC",
>> 	"POWER_SUPPLY_CAPACITY=",
>> 	"POWER_SUPPLY_??????_FULL_DESIGN=", /* CHARGE or ENERGY */
>> 	"POWER_SUPPLY_PRESENT=",
>> 	"POWER_SUPPLY_??????_NOW=",
>> 	"POWER_SUPPLY_CURRENT_NOW=",
>> 	"POWER_SUPPLY_STATUS=",
>> #if ACPI_THERMAL
>> 	"thermal_zone",
>> #endif
>> 	"POWER_SUPPLY_ONLINE=",
>> 	"POWER_SUPPLY_??????_FULL=",
>> 	NULL
>> };
>
> New kernel should work with old userspace... and clearly it does not.
>
> Do you have test patch for a revert?
>
> 									Pavel

Please try this patch.

commit 6cb7ea8975bf8ffafd893204f55eddd1aebd8ff6
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Sat Mar 15 12:20:15 2014 -0400

     Revert "ACPI / Battery: Remove battery's proc directory" and "ACPI: 
Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c"

     The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery
     directory and breaks some old userspace tools. This patch
     is to revert them.

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index f60f11d..c9231b1 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -43,6 +43,23 @@ config ACPI_SLEEP
  	depends on SUSPEND || HIBERNATION
  	default y

+config ACPI_PROCFS_POWER
+	bool "Deprecated power /proc/acpi directories"
+	depends on PROC_FS
+	help
+	  For backwards compatibility, this option allows
+          deprecated power /proc/acpi/ directories to exist, even when
+          they have been replaced by functions in /sys.
+          The deprecated directories (and their replacements) include:
+	  /proc/acpi/battery/* (/sys/class/power_supply/*)
+	  /proc/acpi/ac_adapter/* (sys/class/power_supply/*)
+	  This option has no effect on /proc/acpi/ directories
+	  and functions, which do not yet exist in /sys
+	  This option, together with the proc directories, will be
+	  deleted in 2.6.39.
+
+	  Say N to delete power /proc/acpi/ directories that have moved to /sys/
+
  config ACPI_EC_DEBUGFS
  	tristate "EC read/write access through /sys/kernel/debug/ec"
  	default n
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..bce34af 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -47,6 +47,7 @@ acpi-y				+= sysfs.o
  acpi-$(CONFIG_X86)		+= acpi_cmos_rtc.o
  acpi-$(CONFIG_DEBUG_FS)		+= debugfs.o
  acpi-$(CONFIG_ACPI_NUMA)	+= numa.o
+acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
  ifdef CONFIG_ACPI_VIDEO
  acpi-y				+= video_detect.o
  endif
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 797a693..22c8696 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -36,6 +36,12 @@
  #include <linux/suspend.h>
  #include <asm/unaligned.h>

+#ifdef CONFIG_ACPI_PROCFS_POWER
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+#include <asm/uaccess.h>
+#endif
+
  #include <linux/acpi.h>
  #include <linux/power_supply.h>

@@ -66,6 +72,19 @@ static unsigned int cache_time = 1000;
  module_param(cache_time, uint, 0644);
  MODULE_PARM_DESC(cache_time, "cache time in milliseconds");

+#ifdef CONFIG_ACPI_PROCFS_POWER
+extern struct proc_dir_entry *acpi_lock_battery_dir(void);
+extern void *acpi_unlock_battery_dir(struct proc_dir_entry 
*acpi_battery_dir);
+
+enum acpi_battery_files {
+	info_tag = 0,
+	state_tag,
+	alarm_tag,
+	ACPI_BATTERY_NUMFILES,
+};
+
+#endif
+
  static const struct acpi_device_id battery_device_ids[] = {
  	{"PNP0C0A", 0},
  	{"", 0},
@@ -301,6 +320,14 @@ static enum power_supply_property 
energy_battery_props[] = {
  	POWER_SUPPLY_PROP_SERIAL_NUMBER,
  };

+#ifdef CONFIG_ACPI_PROCFS_POWER
+inline char *acpi_battery_units(struct acpi_battery *battery)
+{
+	return (battery->power_unit == ACPI_BATTERY_POWER_UNIT_MA) ?
+		"mA" : "mW";
+}
+#endif
+
  /* 
--------------------------------------------------------------------------
                                 Battery Management
 
-------------------------------------------------------------------------- 
*/
@@ -719,6 +746,279 @@ static void acpi_battery_refresh(struct 
acpi_battery *battery)
  }

  /* 
--------------------------------------------------------------------------
+                              FS Interface (/proc)
+ 
-------------------------------------------------------------------------- 
*/
+
+#ifdef CONFIG_ACPI_PROCFS_POWER
+static struct proc_dir_entry *acpi_battery_dir;
+
+static int acpi_battery_print_info(struct seq_file *seq, int result)
+{
+	struct acpi_battery *battery = seq->private;
+
+	if (result)
+		goto end;
+
+	seq_printf(seq, "present:                 %s\n",
+		   acpi_battery_present(battery) ? "yes" : "no");
+	if (!acpi_battery_present(battery))
+		goto end;
+	if (battery->design_capacity == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "design capacity:         unknown\n");
+	else
+		seq_printf(seq, "design capacity:         %d %sh\n",
+			   battery->design_capacity,
+			   acpi_battery_units(battery));
+
+	if (battery->full_charge_capacity == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "last full capacity:      unknown\n");
+	else
+		seq_printf(seq, "last full capacity:      %d %sh\n",
+			   battery->full_charge_capacity,
+			   acpi_battery_units(battery));
+
+	seq_printf(seq, "battery technology:      %srechargeable\n",
+		   (!battery->technology)?"non-":"");
+
+	if (battery->design_voltage == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "design voltage:          unknown\n");
+	else
+		seq_printf(seq, "design voltage:          %d mV\n",
+			   battery->design_voltage);
+	seq_printf(seq, "design capacity warning: %d %sh\n",
+		   battery->design_capacity_warning,
+		   acpi_battery_units(battery));
+	seq_printf(seq, "design capacity low:     %d %sh\n",
+		   battery->design_capacity_low,
+		   acpi_battery_units(battery));
+	seq_printf(seq, "cycle count:		  %i\n", battery->cycle_count);
+	seq_printf(seq, "capacity granularity 1:  %d %sh\n",
+		   battery->capacity_granularity_1,
+		   acpi_battery_units(battery));
+	seq_printf(seq, "capacity granularity 2:  %d %sh\n",
+		   battery->capacity_granularity_2,
+		   acpi_battery_units(battery));
+	seq_printf(seq, "model number:            %s\n", battery->model_number);
+	seq_printf(seq, "serial number:           %s\n", battery->serial_number);
+	seq_printf(seq, "battery type:            %s\n", battery->type);
+	seq_printf(seq, "OEM info:                %s\n", battery->oem_info);
+      end:
+	if (result)
+		seq_printf(seq, "ERROR: Unable to read battery info\n");
+	return result;
+}
+
+static int acpi_battery_print_state(struct seq_file *seq, int result)
+{
+	struct acpi_battery *battery = seq->private;
+
+	if (result)
+		goto end;
+
+	seq_printf(seq, "present:                 %s\n",
+		   acpi_battery_present(battery) ? "yes" : "no");
+	if (!acpi_battery_present(battery))
+		goto end;
+
+	seq_printf(seq, "capacity state:          %s\n",
+			(battery->state & 0x04) ? "critical" : "ok");
+	if ((battery->state & 0x01) && (battery->state & 0x02))
+		seq_printf(seq,
+			   "charging state:          charging/discharging\n");
+	else if (battery->state & 0x01)
+		seq_printf(seq, "charging state:          discharging\n");
+	else if (battery->state & 0x02)
+		seq_printf(seq, "charging state:          charging\n");
+	else
+		seq_printf(seq, "charging state:          charged\n");
+
+	if (battery->rate_now == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "present rate:            unknown\n");
+	else
+		seq_printf(seq, "present rate:            %d %s\n",
+			   battery->rate_now, acpi_battery_units(battery));
+
+	if (battery->capacity_now == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "remaining capacity:      unknown\n");
+	else
+		seq_printf(seq, "remaining capacity:      %d %sh\n",
+			   battery->capacity_now, acpi_battery_units(battery));
+	if (battery->voltage_now == ACPI_BATTERY_VALUE_UNKNOWN)
+		seq_printf(seq, "present voltage:         unknown\n");
+	else
+		seq_printf(seq, "present voltage:         %d mV\n",
+			   battery->voltage_now);
+      end:
+	if (result)
+		seq_printf(seq, "ERROR: Unable to read battery state\n");
+
+	return result;
+}
+
+static int acpi_battery_print_alarm(struct seq_file *seq, int result)
+{
+	struct acpi_battery *battery = seq->private;
+
+	if (result)
+		goto end;
+
+	if (!acpi_battery_present(battery)) {
+		seq_printf(seq, "present:                 no\n");
+		goto end;
+	}
+	seq_printf(seq, "alarm:                   ");
+	if (!battery->alarm)
+		seq_printf(seq, "unsupported\n");
+	else
+		seq_printf(seq, "%u %sh\n", battery->alarm,
+				acpi_battery_units(battery));
+      end:
+	if (result)
+		seq_printf(seq, "ERROR: Unable to read battery alarm\n");
+	return result;
+}
+
+static ssize_t acpi_battery_write_alarm(struct file *file,
+					const char __user * buffer,
+					size_t count, loff_t * ppos)
+{
+	int result = 0;
+	char alarm_string[12] = { '\0' };
+	struct seq_file *m = file->private_data;
+	struct acpi_battery *battery = m->private;
+
+	if (!battery || (count > sizeof(alarm_string) - 1))
+		return -EINVAL;
+	if (!acpi_battery_present(battery)) {
+		result = -ENODEV;
+		goto end;
+	}
+	if (copy_from_user(alarm_string, buffer, count)) {
+		result = -EFAULT;
+		goto end;
+	}
+	alarm_string[count] = '\0';
+	battery->alarm = simple_strtol(alarm_string, NULL, 0);
+	result = acpi_battery_set_alarm(battery);
+      end:
+	if (!result)
+		return count;
+	return result;
+}
+
+typedef int(*print_func)(struct seq_file *seq, int result);
+
+static print_func acpi_print_funcs[ACPI_BATTERY_NUMFILES] = {
+	acpi_battery_print_info,
+	acpi_battery_print_state,
+	acpi_battery_print_alarm,
+};
+
+static int acpi_battery_read(int fid, struct seq_file *seq)
+{
+	struct acpi_battery *battery = seq->private;
+	int result = acpi_battery_update(battery);
+	return acpi_print_funcs[fid](seq, result);
+}
+
+#define DECLARE_FILE_FUNCTIONS(_name) \
+static int acpi_battery_read_##_name(struct seq_file *seq, void *offset) \
+{ \
+	return acpi_battery_read(_name##_tag, seq); \
+} \
+static int acpi_battery_##_name##_open_fs(struct inode *inode, struct 
file *file) \
+{ \
+	return single_open(file, acpi_battery_read_##_name, PDE_DATA(inode)); \
+}
+
+DECLARE_FILE_FUNCTIONS(info);
+DECLARE_FILE_FUNCTIONS(state);
+DECLARE_FILE_FUNCTIONS(alarm);
+
+#undef DECLARE_FILE_FUNCTIONS
+
+#define FILE_DESCRIPTION_RO(_name) \
+	{ \
+	.name = __stringify(_name), \
+	.mode = S_IRUGO, \
+	.ops = { \
+		.open = acpi_battery_##_name##_open_fs, \
+		.read = seq_read, \
+		.llseek = seq_lseek, \
+		.release = single_release, \
+		.owner = THIS_MODULE, \
+		}, \
+	}
+
+#define FILE_DESCRIPTION_RW(_name) \
+	{ \
+	.name = __stringify(_name), \
+	.mode = S_IFREG | S_IRUGO | S_IWUSR, \
+	.ops = { \
+		.open = acpi_battery_##_name##_open_fs, \
+		.read = seq_read, \
+		.llseek = seq_lseek, \
+		.write = acpi_battery_write_##_name, \
+		.release = single_release, \
+		.owner = THIS_MODULE, \
+		}, \
+	}
+
+static const struct battery_file {
+	struct file_operations ops;
+	umode_t mode;
+	const char *name;
+} acpi_battery_file[] = {
+	FILE_DESCRIPTION_RO(info),
+	FILE_DESCRIPTION_RO(state),
+	FILE_DESCRIPTION_RW(alarm),
+};
+
+#undef FILE_DESCRIPTION_RO
+#undef FILE_DESCRIPTION_RW
+
+static int acpi_battery_add_fs(struct acpi_device *device)
+{
+	struct proc_dir_entry *entry = NULL;
+	int i;
+
+	printk(KERN_WARNING PREFIX "Deprecated procfs I/F for battery is loaded,"
+			" please retry with CONFIG_ACPI_PROCFS_POWER cleared\n");
+	if (!acpi_device_dir(device)) {
+		acpi_device_dir(device) = proc_mkdir(acpi_device_bid(device),
+						     acpi_battery_dir);
+		if (!acpi_device_dir(device))
+			return -ENODEV;
+	}
+
+	for (i = 0; i < ACPI_BATTERY_NUMFILES; ++i) {
+		entry = proc_create_data(acpi_battery_file[i].name,
+					 acpi_battery_file[i].mode,
+					 acpi_device_dir(device),
+					 &acpi_battery_file[i].ops,
+					 acpi_driver_data(device));
+		if (!entry)
+			return -ENODEV;
+	}
+	return 0;
+}
+
+static void acpi_battery_remove_fs(struct acpi_device *device)
+{
+	int i;
+	if (!acpi_device_dir(device))
+		return;
+	for (i = 0; i < ACPI_BATTERY_NUMFILES; ++i)
+		remove_proc_entry(acpi_battery_file[i].name,
+				  acpi_device_dir(device));
+
+	remove_proc_entry(acpi_device_bid(device), acpi_battery_dir);
+	acpi_device_dir(device) = NULL;
+}
+
+#endif
+
+/* 
--------------------------------------------------------------------------
                                   Driver Interface
 
-------------------------------------------------------------------------- 
*/

@@ -791,6 +1091,15 @@ static int acpi_battery_add(struct acpi_device 
*device)
  	result = acpi_battery_update(battery);
  	if (result)
  		goto fail;
+#ifdef CONFIG_ACPI_PROCFS_POWER
+	result = acpi_battery_add_fs(device);
+#endif
+	if (result) {
+#ifdef CONFIG_ACPI_PROCFS_POWER
+		acpi_battery_remove_fs(device);
+#endif
+		goto fail;
+	}

  	printk(KERN_INFO PREFIX "%s Slot [%s] (battery %s)\n",
  		ACPI_BATTERY_DEVICE_NAME, acpi_device_bid(device),
@@ -817,6 +1126,9 @@ static int acpi_battery_remove(struct acpi_device 
*device)
  		return -EINVAL;
  	battery = acpi_driver_data(device);
  	unregister_pm_notifier(&battery->pm_nb);
+#ifdef CONFIG_ACPI_PROCFS_POWER
+	acpi_battery_remove_fs(device);
+#endif
  	sysfs_remove_battery(battery);
  	mutex_destroy(&battery->lock);
  	mutex_destroy(&battery->sysfs_lock);
@@ -864,10 +1176,21 @@ static void __init acpi_battery_init_async(void 
*unused, async_cookie_t cookie)
  {
  	if (acpi_disabled)
  		return;
-
  	if (dmi_check_system(bat_dmi_table))
  		battery_bix_broken_package = 1;
-	acpi_bus_register_driver(&acpi_battery_driver);
+
+#ifdef CONFIG_ACPI_PROCFS_POWER
+	acpi_battery_dir = acpi_lock_battery_dir();
+	if (!acpi_battery_dir)
+		return;
+#endif
+	if (acpi_bus_register_driver(&acpi_battery_driver) < 0) {
+#ifdef CONFIG_ACPI_PROCFS_POWER
+		acpi_unlock_battery_dir(acpi_battery_dir);
+#endif
+		return;
+	}
+	return;
  }

  static int __init acpi_battery_init(void)
@@ -879,6 +1202,9 @@ static int __init acpi_battery_init(void)
  static void __exit acpi_battery_exit(void)
  {
  	acpi_bus_unregister_driver(&acpi_battery_driver);
+#ifdef CONFIG_ACPI_PROCFS_POWER
+	acpi_unlock_battery_dir(acpi_battery_dir);
+#endif
  }

  module_init(acpi_battery_init);
diff --git a/drivers/acpi/cm_sbs.c b/drivers/acpi/cm_sbs.c
new file mode 100644
index 0000000..6c9ee68
--- /dev/null
+++ b/drivers/acpi/cm_sbs.c
@@ -0,0 +1,105 @@
+/*
+ * 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/acpi.h>
+#include <linux/types.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+
+#define PREFIX "ACPI: "
+
+ACPI_MODULE_NAME("cm_sbs");
+#define ACPI_AC_CLASS		"ac_adapter"
+#define ACPI_BATTERY_CLASS	"battery"
+#define _COMPONENT		ACPI_SBS_COMPONENT
+static struct proc_dir_entry *acpi_ac_dir;
+static struct proc_dir_entry *acpi_battery_dir;
+
+static DEFINE_MUTEX(cm_sbs_mutex);
+
+static int lock_ac_dir_cnt;
+static int lock_battery_dir_cnt;
+
+struct proc_dir_entry *acpi_lock_ac_dir(void)
+{
+	mutex_lock(&cm_sbs_mutex);
+	if (!acpi_ac_dir)
+		acpi_ac_dir = proc_mkdir(ACPI_AC_CLASS, acpi_root_dir);
+	if (acpi_ac_dir) {
+		lock_ac_dir_cnt++;
+	} else {
+		printk(KERN_ERR PREFIX
+				  "Cannot create %s\n", ACPI_AC_CLASS);
+	}
+	mutex_unlock(&cm_sbs_mutex);
+	return acpi_ac_dir;
+}
+EXPORT_SYMBOL(acpi_lock_ac_dir);
+
+void acpi_unlock_ac_dir(struct proc_dir_entry *acpi_ac_dir_param)
+{
+	mutex_lock(&cm_sbs_mutex);
+	if (acpi_ac_dir_param)
+		lock_ac_dir_cnt--;
+	if (lock_ac_dir_cnt == 0 && acpi_ac_dir_param && acpi_ac_dir) {
+		remove_proc_entry(ACPI_AC_CLASS, acpi_root_dir);
+		acpi_ac_dir = NULL;
+	}
+	mutex_unlock(&cm_sbs_mutex);
+}
+EXPORT_SYMBOL(acpi_unlock_ac_dir);
+
+struct proc_dir_entry *acpi_lock_battery_dir(void)
+{
+	mutex_lock(&cm_sbs_mutex);
+	if (!acpi_battery_dir) {
+		acpi_battery_dir =
+		    proc_mkdir(ACPI_BATTERY_CLASS, acpi_root_dir);
+	}
+	if (acpi_battery_dir) {
+		lock_battery_dir_cnt++;
+	} else {
+		printk(KERN_ERR PREFIX
+				  "Cannot create %s\n", ACPI_BATTERY_CLASS);
+	}
+	mutex_unlock(&cm_sbs_mutex);
+	return acpi_battery_dir;
+}
+EXPORT_SYMBOL(acpi_lock_battery_dir);
+
+void acpi_unlock_battery_dir(struct proc_dir_entry *acpi_battery_dir_param)
+{
+	mutex_lock(&cm_sbs_mutex);
+	if (acpi_battery_dir_param)
+		lock_battery_dir_cnt--;
+	if (lock_battery_dir_cnt == 0 && acpi_battery_dir_param
+	    && acpi_battery_dir) {
+		remove_proc_entry(ACPI_BATTERY_CLASS, acpi_root_dir);
+		acpi_battery_dir = NULL;
+	}
+	mutex_unlock(&cm_sbs_mutex);
+	return;
+}
+EXPORT_SYMBOL(acpi_unlock_battery_dir);

>

Re: 3.14-rc: /proc/acpi/battery gone?

[Stefan Lippers-Hollmann]

Hi

On Saturday 15 March 2014, Lan Tianyu wrote:
> On 03/14/2014 10:17 PM, Stefan Lippers-Hollmann wrote:
> > Hi
> >
> > On Saturday 15 March 2014, Rafael J. Wysocki wrote:
> >> On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:
> >>> On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >>>> On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
> >>>>> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
[...]
> Hi Stefan:
> 	I just glance wmbattery code. I find the code in the acpi.c is already 
> using the new sysfs battery interfaces, right?

By default, wmbattery appears to default to using upower as abstraction
level, instead of querying sysfs itself directly.

http://git.kitenet.net/?p=wmbattery.git;a=blob;f=autoconf/makeinfo.in;hb=HEAD

which sets USE_UPOWER=1 by default.

If USE_UPOWER=0 is set explicitly for the build, it reverts back to 
direct sysfs parsing - and yes, it does appear to adhere to the current
sysfs API properly.

The last remains, and the ability to parse procfs (which hasn't been 
default for quite some time already, in favour of using hal as 
abstraction layer) has finally been removed in

http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=833eb63a5ce4f2fb712a201b1db4f2db1700fddb

The switch from procfs parsing to hal (by default at least) in turn 
happened with

http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=63c3d1a0b11e8ade1a5612bb5baa3d92e153bbbe

in 2008 (before Debian squeeze/ oldstable). I have not investigated if 
hal then read from procfs or sysfs, but wmbattery at least didn't read
from procfs itself, unless explicitly told to do so (USE_HAL=0) during 
the build since mid 2008.

The current version of wmbattery however will never try to access 
/proc/acpi, the current version no longer knows of its existence.

[Again, I'm not familiar with wmbattery myself and have never run it]

Regards
	Stefan Lippers-Hollmann

Re: 3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

Hi!

> >New kernel should work with old userspace... and clearly it does not.
> >
> >Do you have test patch for a revert?
> 
> Please try this patch.

I tried to apply it, but it is a bit too wordwrapped :-(.

Thanks,
									Pavel

> @@ -301,6 +320,14 @@ static enum power_supply_property
> energy_battery_props[] = {
>  	POWER_SUPPLY_PROP_SERIAL_NUMBER,
>  };
> 
> +#ifdef CONFIG_ACPI_PROCFS_POWER
> +inline char *acpi_battery_units(struct acpi_battery *battery)
> +{
> +	return (battery->power_unit == ACPI_BATTERY_POWER_UNIT_MA) ?
> +		"mA" : "mW";
> +}
> +#endif
> +
>  /* --------------------------------------------------------------------------
>                                 Battery Management
> 
> --------------------------------------------------------------------------
> */

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.14-rc: /proc/acpi/battery gone?

[Ilia Mirkin]

On Sat, Mar 15, 2014 at 11:57 PM, Stefan Lippers-Hollmann <s.L-H@gmx.de> wrote:
> Hi
>
> On Saturday 15 March 2014, Lan Tianyu wrote:
>> On 03/14/2014 10:17 PM, Stefan Lippers-Hollmann wrote:
>> > Hi
>> >
>> > On Saturday 15 March 2014, Rafael J. Wysocki wrote:
>> >> On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:
>> >>> On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> >>>> On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
>> >>>>> On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> [...]
>> Hi Stefan:
>>       I just glance wmbattery code. I find the code in the acpi.c is already
>> using the new sysfs battery interfaces, right?
>
> By default, wmbattery appears to default to using upower as abstraction
> level, instead of querying sysfs itself directly.
>
> http://git.kitenet.net/?p=wmbattery.git;a=blob;f=autoconf/makeinfo.in;hb=HEAD
>
> which sets USE_UPOWER=1 by default.
>
> If USE_UPOWER=0 is set explicitly for the build, it reverts back to
> direct sysfs parsing - and yes, it does appear to adhere to the current
> sysfs API properly.
>
> The last remains, and the ability to parse procfs (which hasn't been
> default for quite some time already, in favour of using hal as
> abstraction layer) has finally been removed in
>
> http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=833eb63a5ce4f2fb712a201b1db4f2db1700fddb
>
> The switch from procfs parsing to hal (by default at least) in turn
> happened with
>
> http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=63c3d1a0b11e8ade1a5612bb5baa3d92e153bbbe
>
> in 2008 (before Debian squeeze/ oldstable). I have not investigated if
> hal then read from procfs or sysfs, but wmbattery at least didn't read
> from procfs itself, unless explicitly told to do so (USE_HAL=0) during
> the build since mid 2008.
>
> The current version of wmbattery however will never try to access
> /proc/acpi, the current version no longer knows of its existence.
>
> [Again, I'm not familiar with wmbattery myself and have never run it]

Stefan,

Thanks for looking into this. The newest wmbattery version indeed
supports upower. However, I haven't figured out how to get it to work.
That's obviously not the kernel's fault, but an unfortunate reality.
It seems to really want dbus to be running, but when I start dbus
(which nothing else on my system needs, apparently), it just hangs. My
knowledge of these things is, (un)fortunately non-existent, so I just
gave up on the upower approach. Running something as heavy as dbus
just for a silly dock app seems... silly as well.

Doing a build with USE_UPOWER=0 does indeed seem to work a little bit,
in that it notices AC plug/unplug events, but the actual battery info
isn't updated properly. Could be a wmbattery bug for all I know (quite
likely, in fact). Older versions used to work just fine. I never had
HAL enabled, so I think it used procfs. I'm guessing that they removed
the proc code in response to it being removed from the kernel... and I
guess the sysfs-handling code atrophied over time, or perhaps never
worked? With the version that's marked as 'stable' in gentoo, 2.40, it
still very much tries to access /proc/acpi:

open("/dev/apm_bios", O_WRONLY)         = -1 ENOENT (No such file or directory)
access("/proc/apm", R_OK)               = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/acpi", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
open("/sys/module/acpi/parameters/acpica_version", O_RDONLY) = 4
openat(AT_FDCWD, "/proc/acpi/battery",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "/proc/acpi/ac_adapter",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open("/dev/sonypi", O_RDWR)             = -1 ENOENT (No such file or directory)
Error: No APM, ACPI, HAL or SPIC support detected.

Other programs I've tried:

wmacpi-2.2-rc1:
open("/sys/module/acpi/parameters/acpica_version", O_RDONLY) = 3
openat(AT_FDCWD, "/proc/acpi/battery",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
No batteries or ACPI not supported

wmpower-0.4.3:
Welcome to wmpower version 0.4.3...
open("/proc/version", O_RDONLY)         = 3
open("/proc/omnibook/dmi", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/proc/i8k", O_RDONLY)             = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/acpi/toshiba",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open("/dev/toshiba", O_RDWR)            = -1 ENOENT (No such file or directory)
CPU frequency scaling NOT available
access("/proc/acpi/info", R_OK)         = -1 ENOENT (No such file or directory)
access("/proc/apm", R_OK)               = -1 ENOENT (No such file or directory)
No power management subsystem detected
No power management support...

Now, I'm in no position to say whether it's reasonable to keep the
/proc/acpi interface around, but the current situation is that what's
out there doesn't quite seem to know how to deal with /sys/.

Cheers,

  -ilia

Re: 3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

Hi!

> >>       I just glance wmbattery code. I find the code in the acpi.c is already
> >> using the new sysfs battery interfaces, right?
> >
> > By default, wmbattery appears to default to using upower as abstraction
> > level, instead of querying sysfs itself directly.
> >
> > http://git.kitenet.net/?p=wmbattery.git;a=blob;f=autoconf/makeinfo.in;hb=HEAD
> >
> > which sets USE_UPOWER=1 by default.
> >
> > If USE_UPOWER=0 is set explicitly for the build, it reverts back to
> > direct sysfs parsing - and yes, it does appear to adhere to the current
> > sysfs API properly.
> >
> > The last remains, and the ability to parse procfs (which hasn't been
> > default for quite some time already, in favour of using hal as
> > abstraction layer) has finally been removed in
> >
> > http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=833eb63a5ce4f2fb712a201b1db4f2db1700fddb
> >
> > The switch from procfs parsing to hal (by default at least) in turn
> > happened with
> >
> > http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=63c3d1a0b11e8ade1a5612bb5baa3d92e153bbbe
> >
> > in 2008 (before Debian squeeze/ oldstable). I have not investigated if
> > hal then read from procfs or sysfs, but wmbattery at least didn't read
> > from procfs itself, unless explicitly told to do so (USE_HAL=0) during
> > the build since mid 2008.
> >
> > The current version of wmbattery however will never try to access
> > /proc/acpi, the current version no longer knows of its existence.
> >
> > [Again, I'm not familiar with wmbattery myself and have never run it]
> 
> Stefan,
> 
> Thanks for looking into this. The newest wmbattery version indeed
> supports upower. However, I haven't figured out how to get it to work.
> That's obviously not the kernel's fault, but an unfortunate reality.
> It seems to really want dbus to be running, but when I start dbus
> (which nothing else on my system needs, apparently), it just hangs. My
> knowledge of these things is, (un)fortunately non-existent, so I just
> gave up on the upower approach. Running something as heavy as dbus
> just for a silly dock app seems... silly as well.

Any news on this one?

It seems that delaying fsck on battery power also relies on
/proc/acpi/battery...

https://bbs.archlinux.org/viewtopic.php?id=12168

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 04/20/2014 09:09 PM, Pavel Machek wrote:
> Hi!
>
>>>>        I just glance wmbattery code. I find the code in the acpi.c is already
>>>> using the new sysfs battery interfaces, right?
>>>
>>> By default, wmbattery appears to default to using upower as abstraction
>>> level, instead of querying sysfs itself directly.
>>>
>>> http://git.kitenet.net/?p=wmbattery.git;a=blob;f=autoconf/makeinfo.in;hb=HEAD
>>>
>>> which sets USE_UPOWER=1 by default.
>>>
>>> If USE_UPOWER=0 is set explicitly for the build, it reverts back to
>>> direct sysfs parsing - and yes, it does appear to adhere to the current
>>> sysfs API properly.
>>>
>>> The last remains, and the ability to parse procfs (which hasn't been
>>> default for quite some time already, in favour of using hal as
>>> abstraction layer) has finally been removed in
>>>
>>> http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=833eb63a5ce4f2fb712a201b1db4f2db1700fddb
>>>
>>> The switch from procfs parsing to hal (by default at least) in turn
>>> happened with
>>>
>>> http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=63c3d1a0b11e8ade1a5612bb5baa3d92e153bbbe
>>>
>>> in 2008 (before Debian squeeze/ oldstable). I have not investigated if
>>> hal then read from procfs or sysfs, but wmbattery at least didn't read
>>> from procfs itself, unless explicitly told to do so (USE_HAL=0) during
>>> the build since mid 2008.
>>>
>>> The current version of wmbattery however will never try to access
>>> /proc/acpi, the current version no longer knows of its existence.
>>>
>>> [Again, I'm not familiar with wmbattery myself and have never run it]
>>
>> Stefan,
>>
>> Thanks for looking into this. The newest wmbattery version indeed
>> supports upower. However, I haven't figured out how to get it to work.
>> That's obviously not the kernel's fault, but an unfortunate reality.
>> It seems to really want dbus to be running, but when I start dbus
>> (which nothing else on my system needs, apparently), it just hangs. My
>> knowledge of these things is, (un)fortunately non-existent, so I just
>> gave up on the upower approach. Running something as heavy as dbus
>> just for a silly dock app seems... silly as well.
>
> Any news on this one?
>
> It seems that delaying fsck on battery power also relies on
> /proc/acpi/battery...

Ok. I will prepare a patch to recover /proc/acpi/battery.

>
> https://bbs.archlinux.org/viewtopic.php?id=12168
>
> 									Pavel
>