Maxim Levitsky wrote:
On Sat, 2009-10-31 at 10:48 +0000, Alan Jenkins wrote:
Maxim Levitsky wrote:
On Mon, 2009-09-07 at 13:29 +0100, Alan Jenkins wrote:
Maxim Levitsky wrote:
On Tue, 2009-05-12 at 15:51 +0100, Alan Jenkins wrote:
Keeping this device around lets userspace know that we have a battery
bay, even if there is nothing in it at the moment. This is what every
other battery driver does, so ACPI should do it as well.
There is no reason to preserve the old behaviour. We now correctly
provide the "present" attribute, which will return "0" when the battery
is removed. HAL was already trying to check this attribute, so
it should be fine.
Signed-off-by: Alan Jenkins <alan-jenkins@xxxxxxxxxxxxxx>
What happened to this patch?
I still get the issue this patch attempts to fix:
maxim@maxim-laptop:~/software/kernel/linux-2.6$
ls /sys/class/power_supply/
AC
maxim@maxim-laptop:~/software/kernel/linux-2.6$
ls /sys/class/power_supply/
AC BAT0
maxim@maxim-laptop:~/software/kernel/linux-2.6$
ls /sys/class/power_supply/
AC
maxim@maxim-laptop:~/software/kernel/linux-2.6$ uname -r
2.6.31-rc8-next-20090904-next
maxim@maxim-laptop:~/software/kernel/linux-2.6$
When I unplug the battery, its sysfs entry disappears.
Thus if system was booted without battery, there will be no way to know
system has one.
This patch doesn't apply.
I rebased these patches a while back
http://patchwork.kernel.org/patch/33118/
http://patchwork.kernel.org/patch/33119/
http://patchwork.kernel.org/patch/33120/
you should find these will still apply.
Regards
Alan
Any progress on adding special battery bay device?
Best regards,
Maxim Levitsky
No, sorry.
I did think of one complication - suspend/resume. (That's not blocking
me though, it's just a matter of time). Assume the obvious device tree:
ACPI BAT0 -> battery bay device -> [ battery device ]
The user might suspend with the battery removed, and then add the
battery and resume. But
1) Parent devices are resumed before their children.
2) The device core won't let you add a child device to a device
which is currently suspended.
So when BAT0 resumes, the battery bay device is still suspended.
Therefore the resume handler for BAT0 cannot directly create the battery
device.
So we either need to
a) provide some sort of resume mechanism attached to the battery bay
device, or
b) use a different device tree and use symlinks to represent the
relationship i.e.
ACPI BAT0 -> battery bay device (with "battery" symlink)
-> battery device (with "bay" symlink)
I favour b).
Regards
Alan
Me too.
In fact, I don't think there is need for relationship between bay and
battery.
All I need is some way for kernel to notify that batteries might became
present, so it would be enough to create a dummy child of the BAT0
exactly like you said.
Probably even it is possible not to use symlinks.
Best regards,
Maxim Levitsky
I believe there are systems with more than one battery. I think we
should be able to tell userspace "there is one battery present, called
BAT0, and one empty battery bay, called BAT1". The symlinks would
provide a reasonably clean way to indicate which battery bay is empty.
Regards
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
