[PATCH] yenta: irq-routing for TI bridges

[Pavel Roskin]

On Tue, 24 Feb 2004, Daniel Ritz wrote:

> ok, not good. what about: read the routing in MFUNC0, test if it works,
> only set to PCI if it doesn't work. the problem is we can't test if
> another device already sits on that irq. we shouldn't do anything then.

What if we just check if irqmux is 0.  Is it 0 on your card?  I believe
the only problem is the the cards that don't have irqmux initialized from
EEPROM.

I think that your fix is too intrusive.  I'm not sure it's worth it.
After all, we are not going to support every possible piece of broken
hardware, only those that are relatively widespread.  I have one, you have
one (presumably), let's see what we have.

Could you please give more information about your hardware?  My hardware
is a card based on TI PCI1410 with broken EEPROM.  It has one slot.
irqmux is 0 on startup.  Attempts to write to EEPROM damage the card
permanently.  It stops working as a valid PCI device and prevents booting
Linux with PCI support.

I'm concerned that you are reading irqmux in ti_override(), which is also
used in bridges without irqmux.  Those bridges only need changes in devctl
if any.  The fix should be in ti12xx_override() or even ti1250_override().

> yeah, not as it is now. more checks are needed, PCI fallback only if
> nothing else works. may be we should just make it a module param like in
> pcmcia-cs i82365.c?

The parameter would be the last resort.  Shifting the problem to the users
is more like a surrender than a victory.  Not to mention that such
approach won't work well with multiple card and/or solid kernel.

-- 
Regards,
Pavel Roskin