2.3.51 tulip broken

[Donald Becker]

On Tue, 14 Mar 2000, Jeff Garzik wrote:

> >  /* 21041 transceiver register settings: 10-T, 10-2, AUI, 10-T, 10T-FD*/
> > -u16 t21041_csr13[] = { 0xEF01, 0xEF09, 0xEF09, 0xEF01, 0xEF09, };
> > -u16 t21041_csr14[] = { 0xFFFF, 0xF7FD, 0xF7FD, 0x7F3F, 0x7F3D, };
> > +u16 t21041_csr13[] = { 0xEF05, 0xEF09, 0xEF09, 0xEF01, 0xEF09, };
> > +u16 t21041_csr14[] = { 0x7F3F, 0xF7FD, 0xF7FD, 0x7F3F, 0x7F3D, };
> >  u16 t21041_csr15[] = { 0x0008, 0x0006, 0x000E, 0x0008, 0x0008, };
> 
> This sort of code (not your patch, but the code itself) pisses me off --
> these are magic numbers and I cannot evaluate their correctness at all
> without having the spec in one hand.

The meaning of the bits in CSR13 depends on each other.
The databook lists the suggested values in Hex.
Having symbolic values wouldn't help at all.

> I would __REALLY__ like to see someone grab a spec and define symbolic
> constants for the various bits being set here.

No.  It wouldn't help.  It would just make you *think* that you could hack the
code without knowing what is going on.

> The code above, IMNSHO, the THE REASON why there is so much randomness
> and brokenness in all the tulip drivers right now.

My view is that the Tulip driver complexity is because it supports 150
different chip and transceiver designs, all around a common core.

Splitting the 

I'm not opposed to having multiple drivers, after all I designed the 8390
set, but it doesn't make sense in this case.  (In fact I oppose the Xircom
driver additions.  The Xircom design is similar, but doesn't share the
common semantics.  It should never have been integrated.)

> > I was trying to debug the problem (but I have no time to do it now) and
> > found that tulip problems are probably related to media autodetection 
> > code. Unfortunately, Donald Becker's drivers generally do not allow
> > setting media manually and disabling autodetection totally :(((

My Tulip driver does allow forcing the media type.  You just have to know
the transceiver details to do this.

> Yes, this is another problem.  The plan is to port the Sparc64 'ethtool'
> and interface to be generally available.  This will allow users a
> generic way to set/correct ther media settings.

No, it won't.  The problem isn't that easy.

> > Jeff, what do you think of putting two tulip drivers into 2.3/2.4 ?
> > Or do you believe that problems with 21041 will be fixed before 2.4 ?
> 
> I strongly dislike having two drivers, and want to get everything
> working with the new driver.  The biggest obstacle to this task is the
> above -- someone needs to go through the Tulip spec(s), and replace
> magic numbers with constants.

No, that's not the problem.  You might blame it on the constants, but you
didn't understand the task you were taking on when you decided to take over
maintaining the Ethernet drivers.  It took years to write the driver set --
it's something you can just pick up in a few months.  And expecting me to
now fix or maintain your hacked up code branch is just completely
unreasonable.

Donald Becker
Scyld Computing Corporation, becker@scyld.com




-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org