powerpc with gigabit card hanging

[Segher Boessenkool]

>>> This assumes a world where everything is managed by magic BIOS/OF
>>> initialization. That's not the case for this user's board port.
>>
>> The OS (Linux, specifically) won't do it for you.  It has to be set up
>> beforehand.  Unless "embedded Linux" gets this the wrong way around
>> as well.
>
> This isn't an "embedded Linux" (whatever that is) thing.

That;s why I put quotes around it :-)

> 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.

>> and b) it is wrong.  On the
>> majority of platforms, you can route any PCI IRQ to any number you 
>> want.
>> The firmware will tell you where it ends up (over PCI config space).

> On commodity platforms that's true. But on just about every single
> dedicated purpose platform (embedded systems), interrupt routing is
> a static board layout/design decision.

And the firmware should still program the final interrupt number
into the PCI device's config space.

> No, it also tells you which pin it is routed to (A-D). That's
> an important piece of information when routing interrupts.

Sure.  The firmware is still *required* by the PCI spec to fill
the IRQ # config space field, though.

> 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?