[PATCH] Filter key bouncing for more keys

Michael Buesch mb at bu3sch.de
Wed Dec 31 12:41:33 CET 2008


On Wednesday 31 December 2008 08:56:57 Andy Green wrote:
> Somebody in the thread at some point said:
> | On Tuesday 30 December 2008 23:38:35 Nelson Castillo wrote:
> |>> +               if (irq == keys[n].irq) {
> |>> +                       if (machine_is_neo1973_gta01() &&
> global_inside_suspend
> |>> +                           && NEO1973_KEY_AUX == n) {
> |>> +                               /* if you stall inside resume then
> AUX will
> |>> +                                * force a panic, which in turn
> forces a dump
> |>> +                                * of the pending syslog */
> |>> +                               int *p = NULL;
> |>> +                               printk(KERN_ERR "death %d\n", *p);
> |
> | Why not like this?
> | I think this has a better chance of getting accepted upstream.
> |
> | 	dump_stack();
> | 	panic("AUX stall inside resume\n");
> 
> You're right; but we'll pull it out before this goes upstream.
> 
> This depends on three other ugly local patches into kernel guts as well,
> 
> ~ - one makes printk spew any pending syslog buffer if it sees it is
> printing a panic or OOPS,
> 
> ~ - another makes a global to say if we are in suspend - resume, and
> 
> ~ - the last makes a s3c-only parallel forced printascii and "emergency
> dump configure" for UART that can dump independent of UART or clock or
> anything else state (without using LL debug for anything otherwise).

Ok, nice.

> All of those are needed to be sure to get context when the situation can
> be that the UARTs and other stuff like consoles are suspended, but
> they're all quite dirty.  But trying to understand why suspend is broken
> has been a desperate business.

Yeah, suspend is quite hard to debug :)


-- 
Greetings, Michael.



More information about the openmoko-kernel mailing list