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