Re: powerpc with gigabit card hanging

[Matt Porter <mporter@kernel.crashing.org>]

On Tue, Sep 28, 2004 at 01:23:53AM -0500, Segher Boessenkool wrote:
> > It is a
> > non-full-featured firmware thing.  If you take a look at MIPS, ARM,
> > SH, PPC embedded platforms you'll see a similar thing. But wait,
> > you'll even see interrupt routing tables in the decidedly not embedded
> > Alpha architecture. :) Linux does do it, and there is a very clear
> > infrastructure for managing routing tables and standard/non-standard
> > PCI swizzle mechanisms.
> 
> Sure.  But the interrupt _assignment_ should be done by firmware.

I can't argue with ideaology.
 
> > Again, on some platforms, not this one. Let's just agree that
> > not everything is a x86/BIOS or ppc64/pmac/OF machine that
> > has this done in some blackbox firmware.
> 
> Oh, I believe that.  But the firmware should be fixed, not a
> terrible hack added to Linux.
> 
> Segher
> 
> p.s.  And I know this isn't always practically possible; but why
> then support a product like that at all, in the Open Source
> community?

By this reasoning, we should also not support the many BIOS/OF
platforms that report incorrect data and have to have their
reported data fixed up by the kernel. That's gross too by the
same measure.

To answer your question, we support the products because other
than this one minor detail, the platforms generally have merits
that far outweigh the "horrors" of having a very concise interrupt
routing table in the kernel. The same reasoning is true in the case
of BIOS/OF bugs that are worked around. it's not practical to
fix that firmware, but we don't throw away those platforms in
defiance. Frankly, there wouldn't be much of anything in the
kernel (anything with a PCI quirk must go).

More importantly, the maintainers of the kernel, from Linus down
through each architecture have made this practice acceptable
policy for many many years.

-Matt