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

[William Lai]

Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> 
> | From a user perspective, I still think the aux key makes more sense.
> | It is the largest and brightest led, we need an obvious indication
> | that 'something is going on'. If the aux leds are used for any other
> | indications, we should synchronize this, as in, 'aux leds are for
> | indications' whether that be charging, new message, missed calls,
> | etc. That's the idea.
> 
> OK, but presumably we want the other indications to still work if we are
> charging (and the LED is then fixed on).
> 
> I think we can make everyone happy by folding this into the /sys thing,
> so you echo a bitfield in to get the various indications, but we need to
> straighten out what "indications" are and how they behave if we are
> charging or not, or if there are more than one active (ie, missed a call
> but there is a new message also).  Can you define this for us?
> 
> I promise I won't call it a 'spec'.

We don't really have a spec for any indications other than charging.
If possible, I would do this:

RED non-flashing - battery charging
GREEN flashing - new message or missed call

So while receiving a new message while charging, the LED gives a 
continuous red, while flashing green (this is off the top of my head).
Can we do this?

Will