Patch to 2.3.99-pre5 kernel to get Linksys card working...

[Christopher Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 12, 2000 at 06:59:53PM -0400, Jeff Garzik wrote:
> Christopher Smith wrote:
> > Ok. I've read over the LC82C115 docs enough that I actually have a
> > clue what's going on inside that chips (I don't pretend to understand
> > the 139 odd other tulip cards out there ;-). Consequently, I've been
> > able to trim down my patch a fair bit. Rather than post a patch to
> > 2.2.14 which would be of limited interest, I've managed to get the
> > patch to work with the 2.3.99-pre5 kernel. The change is basically to
> > the bitfield sent to the CSR6 register. I haven't read any of the
> > other tulip docs yet, but looking at the LC82C115 docs what the
> > original driver was doing seems insane.
> > 
> > Anyway, the patch I've applied is not really applied in the right
> > place, but it does make it clear where the problem is. I can think of
> > about 10 different ways to do it better (there might be something said
> > for making a #define or a data field called CSR6_MASK), but I'll leave
> > that to the experts. ;-)
> Take a look at 2.3.99-pre6-pre1 (found in /pub/linux/kernel/testing/). 
> If you look at "pre6-1.bz2", the patch against 2.3.99-pre5 release, it
> should contain the various bits of CSR6 spelled out, for the 21143 chip.

Thanks. I did take a peak. It appears VERY clear that CSR6's
behavior/meaning varies SIGNIFICANTLY with each chipset. Additionally,
naming conventions are not consistent (why should they be? ;-). I have
come to believe the tulip chipset is a modern day tower of babel. It
seems to me that it would make sense to, along with the timer
routines, use function pointers for setting up CSR6 (and possibly the
whole area). Indeed, it seems like the code would be more maintainable
if function pointers were used more often (I know how crazy that
sounds).
 
> I am all for getting rid of magic numbers in the code.  Doing so has
> helped me spot bugs in existing drivers on more than one occasion. 
> (including a specific 21041 case where I was told "getting rid of magic
> numbers doesn't help" ;-);-))

Well, my solution still takes advantage of some magic numbers,
although their "magic" may be just from either poor documentation or
my own misunderstandings. I tried setting the flags the documentation
suggested one needed to set, and it didn't work. So, I grabbed the
values that the working driver was using, tweaked it to be a bit more
optimal (uses 100mbps istead of 10mbps), and went with it.

BTW, to make decoding the "magic numbers" much easier I wrote a little
Java application which lets me type in 32-bit numbers (any radix) and
shows which binary fields are checked off (and I can then toggle the
fields and see what the new numbers are). I'm sure there are lots of
tools that do this. If you want it, let me know. I was going to touch
it up a bit so the layout was a bit nicer.

> > Please find the patch attached below.
> 
> Cool, thanks.


I'm still not sure that the patch is 100% correct for the
PNIC2. Tulip-diag shows me using a transmit threshold instead of
store-and-forward, which I suspect is more efficient. However, this
WORKS, which is much faster than the previous non-working
implementation. ;-)
 
> > enlightening. :-) I actually added module options to my local version
> > of the kernel driver which let me toggle the settings for the card's
> > LED's (actually necessary to get them to do what they're LABELLED as
> > doing... sigh. ;-).
> 
> Patches to fix this are welcome too.  Generally this involves reading
> value(s) from EEPROM and then communicating them to the chip.  Since the
> method to do this often varies across chips, chip revisions, and boards,
> it is not uncommon for the LEDs to be setup incorrectly.

Yeah. I figured out that my LEDs were actually behaving correctly
according to chip specifications. The problem was the way the LEDs
were labelled on the card required an alternate configuration. Anyway,
I figured the same chip would likely have different LED displays so it
made sense to just let the user specify any alterations in the LED
policy. Of course, LED options map differently for each tulip chip
(the PNIC2 has 4 LED's for starters, and a lot of the others
don't).It's a cop out, but I just can't imagine us tracking all the
millions of cards and somehow trying to detect them all at
startup. So, I basically added options led0 to led3. Setting any of
the options caused the system to override the default LED settings. If
this sounds like something you want I'll port it to the 2.3.x series.

- --Chris


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE49Wh6frrCpthD+UYRAgqWAJwN4UKd/b2wcTbdSNwmumn6dscbagCeKB8O
S6ACaDbtfEsyvCYPCZMnieA=
=gMKK
-----END PGP SIGNATURE-----
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org