[PATCH 4/6] various janitorial work on the pcf50633.c

[Carsten Haitzler (The Rasterman)]

On Sat, 10 May 2008 13:55:05 +0100 Andy Green <andy at openmoko.com> babbled:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> | On Saturday 10 May 2008 14:06:18 Wolfgang Spraul wrote:
> |> We ship only with HDQ batteries, that's correct.
> |> But people may well have old GTA01 batteries, or use compatible Nokia
> |> BL-4C/5C/6C batteries, or no-name replacements for those.
> |> Our battery driver and infrastructure should be as robust as possible.
> |> Wolfgang
> |
> | The driver is robust. Currently "cat /proc/apm" is returning -1 for
> HDQ based
> | batteries, after the patch a sane number is reported (good for the
> product).
> | Regarding "acme replacement batteries". They will charge, "cat /proc/apm"
> | will return a wrong voltage number, but we don't know the battery
> curve of
> 
> Which changes with age, and if the battery happens to be getting charged
> at the time we look.  That's why we're on HDQ smart battery now.
> 
> | these batteries anyway. The best I can think of is to have a sysfs file
> | somewhere to switch between ADC and HDQ...and move this prob' to
> userspace.
> 
> Under these circumstances we should refer to the specification and its
> detailed description of power behaviours, which batteries we target and
> so on.
> 
> "moving it to userspace" is just moving the person Wolfgang will moan at
> about it not working, a valid answer to the conundrum I admit: but a
> better one is to just not support reporting a bogus battery life
> estimate with a battery we don't ship or even know what it is.

imho it was quite fine with the updated power_supply interface instead of apm.
throwing back apm emulation in is just a way of working around broken userspace
not keeping up with new kernel api's :) no manufacturer i know supports use of
batteries other than official "authorised" ones - i.e. - original design/spec
ones. i see no problem us doing the same. anything else could lead to safety,
device performance and other issues that we will only find out about when
someone's freerunner burns their house down or sets their pants on fire! :)


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>