Patrick Welche <prlw1@newn.cam.ac.uk> writes:

> I see in the mail archives that others have had success with the
> D-Link DE-660, but I get
> 
> ne2 at pcmcia0
> ne2: D-Link DE-660 Ethernet
> ne2: where did the card go?

Same problem here, with my DE-650 (recognized as a Linksys
Ethernetcard or DE-650).

I solved this by adding an entry for it in
dev/pcmcia/pcmcia_cis_quirks.c.

Actually, the card reports that it doesn't care about its IO base
address, but only 0x300 seems to work while the generic code tried to
put it at 0x400. The quirk makes it ask explicitly for 0x300.

It looks like we are doing some kind of bus width check, but:
(from dev/isa/i82365_isasubr.c)

        /*
         * XXX some hardware doesn't seem to grok addresses in 0x400 range--
         * apparently missing a bit or more of address lines. (e.g.
         * CIRRUS_PD672X with Linksys EthernetCard ne2000 clone in TI
         * TravelMate 5000--not clear which is at fault)
         * 
         * Add a kludge to detect 10 bit wide buses and deal with them,
         * and also a config file option to override the probe.
         */

So I don't know what to do. Should I commit the quirk, or should we
try to find a more generic solution?



BTW, there is another issue: when I unconfig lpt0 (parallel port)
which uses IRQ 7, the card uses IRQ 7 and fails to receive
interrupts (timeout blah blah). This might be because the parallel
port is blocking things somehow, but it raised another question:
I tried to put an interrupt mask in the quirk above, so as to disallow
IRQ 7 (although this is certainly not desirable), and the code seems
to disregard this indication: it continues to allocate IRQ 7. Looking
through it confirms that nothing is done to take that piece of
information into account (but I may be wrong).


 Aymeric

Cross-posted to tech-kern in case someone with better knowledge of
PCMCIA can speak up about this...