lkml.org 
[lkml]   [2005]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/5] Centralise NO_IRQ definition


On Tue, 22 Nov 2005, Benjamin Herrenschmidt wrote:
>
> The ppc irq handling is more complex than that due to the wide range of
> different hardware. We parse the irq tree from OF and assign them to
> ranges of numbers allocated per controller. Adding some remapping of
> some numbers would add complexity and possible bugs.

Let me rephrase that as: "On ppc we already _do_ irq mapping, but we made
a mistake to map to 0, so to cover up that mistake we now want everybody
else to change how they have done things since day 1".

See? You argue that there might be "possible bugs". Yet you totally ignore
the fact that I can absolutely point to code that we _know_ depends on
"zero means no irq". So when you argue for changing away from that, I
GUARANTEE you that it has a higher likelihood of bugs AND that it affects
a hell of a lot more code than the alternative I propose.

Anyway, let's just stop this discussion. Let's just leave PCI_NO_IRQ as 0
on x86, and let PPC has it as -1. Problem solved. That way we are
guaranteed to not introduce any new bugs. It works today, and we can just
ignore this whole patch-series, since centralizing NO_IRQ is clearly the
wrong thing to do.

By centralizing NO_IRQ, you either have to break a lot of existing PC
setups, or you have to potentially break (far fewer) PowerPC setups. So
let's not do it at all.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.052 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site