Subject: Re: Kingmax KEN0100-AF
To: <>
From: David Laight <david@l8s.co.uk>
List: tech-kern
Date: 01/22/2002 14:41:55
> 
>  > Removing
>  >
>  >    965          if ((last_liobase == psc->sc_pcioh.addr)
>  >    966              || (last_liobase != new_liobase))
>  >
>  > from if_ne_pcmcia.c,v 1.85 allows a Kingmax KEN0100-AF ethernet card to
>  > work:
> 
> If all the AX88190-based cards decode only 10-bit i/o
> address lines, how about applying 10-bit mask such as
> 
> -       if ((last_liobase == psc->sc_pcioh.addr)
> +       if (((last_liobase & 0x3ff) == (psc->sc_pcioh.addr & 0x3ff))
>             || (last_liobase != new_liobase))

I've been reading some source code for you....
The 'last_liobase' code was added when fixing bug 11285, but you seem to
be suffering from something else...
FWIW the code has just tried to write the iobase address to the base
address register in config space, and is (attempting) to check that it
has updated the value. I think the writes were done only moments earlier
in pcmcia_iomap (in dev/pcmcia/pcmcia.c).  Bug 11285 seems to imply that
certain cards don't like these registers being written!

Now clearly your card only support 10bit decode - at least reading the
base address register is returning the written value masked to 10bits. 
Changing the test to read (say):
	if ((last_iobase & 0x3ff) == (psc->sc_pcioh.addr & 0x3ff))
		rv = 0;
would probably verify that the card was using the correct address.

But this still doesn't tell us where this 'unlikely to be correct'
address 0x 0x4300 came from.  As far I can tell, the address is
allocated by the code (about line 610 od if_ne_pcmcia.c):

                if (pcmcia_io_alloc(pa->pf, cfe->iospace[0].start,
                    NE2000_NPORTS, NE2000_NPORTS, &psc->sc_pcioh)) {
#ifdef DIAGNOSTIC
                        printf(": can't allocate i/o space %lx;
ignored\n%s",
                            cfe->iospace[0].start,
dsc->sc_dev.dv_xname);
#endif
                        continue;
                }

Now I think cfe->iospace[0].start is zero on entry.  But this disappears
off via a jump table - so it is somewhat difficult to statically
determine what happens next.  Maybe a printf might verify that 'start'
is zero and sc_pcioh.addr is 0x4300 after the call.  The kernel startup
messages will probably indicate which pcmcia driver is being used.  Some
printfs it its io_alloc routine might help.

	David