Re: [PATCH][2.5] 3c509 increase udelay in *read_eeprom

[Jeff Garzik <jgarzik@pobox.com>]

Zwane Mwaikambo wrote:

>Hi Jeff,
>This is David's patch, find his reasoning and patch below.
>
>"... I had to set the udelay() call parameters to 2000 in  read_eeprom() 
>and 4000 in id_read_eeprom() to get the system to boot reliably with 2 
>3c509's in it. If I didn't set these values high enough, I got an oops 
>about 1/3 of the time when I booted....somehow (I'm guessing) it just 
>took the cards longer to initialize/respond when there were two of them 
>on the bus.
>
>I know the possibility of this (and the fix, setting the values higher) is 
>mentioned in Becker's 3c509 instructions, but I wanted to relay my 
>experience to you as well. Since AFAIK these subroutines are only called 
>at initialization time (we don't need to read the EEPROM after init), what 
>would be the harm of setting these values higher - at least 1000 for both, 
>say - in the standard driver? Certainly a millisecond or two means nothing 
>at boot time, and if it prevents even a few machines from mysteriously 
>oopsing when they're started, it's a win overall ..."
>  
>


lol... big udelays are almost always wrong.

First, long delays lock out everybody, thus you should do operations 
that require long waits via a timer or schedule_timeout() in process 
context.
Second, udelay of 1000 or greater is a bug, use mdelay() instead.