[PATCH 0/5] Power supply and resume ordering meddling

Andy Green andy at openmoko.com
Mon Jun 2 16:55:37 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Monday 02 June 2008 14:27:37 Andy Green wrote:
|> The following series fixes some bugs around pcf50633 charging;
|> implements the red LED on the AUX key being lit when pcf50633
|> decides to charge; introduces a new method for establishing
|> resume dependency between drivers; implements this new method
|> to make jbt6k74 dependent on pcf50633 AND glamo resume before
|> it resumes, instead of using a sleepy workqueue.
|> Let the complaints begin!
| Here we go:
| Conceptual complaint:
| LED on AUX for charging is very suboptimal. Conceptually, the power
button has
| to do with power, so if at all, the power LED needs to be lit on
charging. (I
| know it wasn't your idea, Andy. For my releases, I will revert this

If you actually run it, it looks pretty OK to me to have that LED for
that purpose, intellectually consistent or not.

| Implementation complaint:
| a) This hardcoded behaviour should be configurable
| (CONFIG_HARDCODED_CHARGING_LED) for people who rather want userland to
be in
| control of the LEDs.

Yes we need something anyway to not upset production test action.  I was
thinking about something in /sys that is set by initscripts.  If we make
it inactive / 1 / 2 for off, AUX LED, POWER LED, defaulting to inactive,
you can save your reason for forking the Openmoko kernel for something
that would sound less stupid.

| b) It looks this implementation is completely ignoring the LED class
| which already implements a charging trigger. Why?

Never saw it.  Sticking the LEDs on and off is four lines of the patch
anyway, the main problem it solves is tracking charger state without
spamming I2C all the time the device is up, which you may have noticed
is not trivial.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list