Donald Becker wrote:

On Thu, 11 Jul 2002, Jeff Garzik wrote:

quoted

Donald Becker wrote:

quoted

The mdelay(300) is completely bogus.

...

quoted

Ouch.  You are absolutely right, and I take the blame for not reviewing 
more closely.  That's what I get for trusting vendors too much ;-)
[D-Link has been the one patching sundance and dl2k for a while now]

Very, very few vendor patchs are worth applying.  They sometimes know of
otherwise undocumented chip bugs, but a lot of the actual code is bad.

It's not "maintaining" a driver when you just take a vendor modification
of a driver and assume it's OK.  You have to understand the changes and
evaluate if they make sense.

I never claimed to maintain sundance ;-)  Not having docs and test 
hardware tends to narrow the field a bit.

quoted

I've been meaning to go through several drivers and fix up the stupid 
assumptions they make about autonegotiation completion time.

Putting broken changes into the kernel with a plan to go back later and
clean them is a bad development methodology.

That depends on the change.  mdelay(300) is a case of "stupid but 
usually works" not completely broken.  As long as it's forward progress 
that gets something working, I would rather apply now and fix up later. 
  That reduces the overall brokenness time a user must deal with.

I'm accepting patches to clean up sundance, if someone with test 
hardware is willing to compare your driver and the kernel's.

	Jeff