[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200810210101.19741.david-b@pacbell.net>
Date: Tue, 21 Oct 2008 01:01:19 -0700
From: David Brownell <david-b@...bell.net>
To: benh@...nel.crashing.org
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"linuxppc-dev list" <linuxppc-dev@...abs.org>
Subject: Re: Bug in "genirq: record trigger type"
On Monday 20 October 2008, Benjamin Herrenschmidt wrote:
> This one is obviously broken and breaks booting on a whole bunch of
> machines (including powermac's and thus my G5, it's never good when my
> own machine breaks !).
>
> Nice to see 3 SOB's and one Ack and nobody caught the obvious bug :-)
As you saw, that one's fixed. Chris' patch unfortunately didn't
get integrated right away.
I'm a bit more curious about another potential issue though ... as
described in the patch comment:
- Make set_irq_type() usage match request_irq() usage:
* IRQ_TYPE_NONE should be a NOP; succeed, so irq_chip methods
won't have to handle that case any more (many do it wrong).
It might be a bit more accurate to say irq_chip.set_type() methods
are *inconsistent* in handling IRQ_TYPE_NONE. Previously the
set_irq_type() method would pass that down to irq_chip code.
I had observed two behaviors, but I thought I observed a third one
in some of the PowerPC code:
(1) ignore it ... matching request_irq() usage
(2) return an error ... nasty
(3) assign some irq_chip-specific trigger mode
That third behavior might cause a bit of trouble, but I think
it was only used during platform init. Someone more attuned
to PowerPC might want to check ...
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists