Re: [PATCH 3/3] ACPI: battery: register power_supply subdevice even when battery not present

[Maxim Levitsky <maximlevitsky@gmail.com>]

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@tuffmail.co.uk>
> >>>>     
> >>>>         
> >>> 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