[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