Re: [patch] ACPI battery driver emits POWER_SUPPLY_STATUS_FULL when power lead plugged in

[Alexey Starikovskiy <astarikovskiy@suse.de>]

Looks good to me.

Richard Hughes wrote:
> On Sat, 2009-01-24 at 19:37 +0300, Alexey Starikovskiy wrote:
>>> I don't understand, why this guesswork over fully charged?  If you cannot
>>> detect fully charged, then *don't*.
>>>
>>> But if you must sinthesize it, and you can get an up-to-date "last full
>>> capacity" from the battery when comparing, I suggest:
>>>
>>> full = (current capacity == last full capacity) && !charging &&
>>>        !discharging
>> certainly, 90% is wrong, but 100% makes a day...
> 
> I think we need some sort of logic like this.
>  
>>> That would *still* be wrong in a few corner cases, but at least they're rare
>>> corner cases that happens only when the pack recalibrates its fuel gauge.
>> full in this case is not exact term. As any other term beside current_now and voltage_now.
>> Capacity of the battery is estimated, so any number that was depending on it, is estimated too.
> 
> Right, never underestimate the brokenness of some people's batteries out
> there. Coupled with broken BIOS's, some of the fix-up code in HAL is
> 'interesting'. I think all the fix-up code in HAL belongs in in the
> kernel.
> 
>>> If there isn't a reliable way to detect the "full" state, just drop the
>>> fully charged detection altogether.
>> People are used to see "full" state of the battery. I think we could tolerate not-full-enough 
>> for sub-second interval instead of dropping full state altogether.
> 
> We shouldn't drop the full state, we should just add some metric like
> above. What about something like the attached (untested) patch? Would
> something this be accepted?
> 
> Richard.
> 
>