PATCH: __bad_udelay fixes(?) for linux-2.4.0-prerelease

From: Adam J. Richter (adam@yggdrasil.com)
Date: Mon Jan 01 2001 - 00:34:59 EST


        linux-2.4.0-prerelease changes the udelay() macro defined
in linux/include/asm-i386/delay.h to reference the undefined symbol
__bad_udelay if udelay is called with a constant exceeding 20000
(that is, 20 milliseconds). I guess the purpose of this change is
to tell driver maintainers to either take a harder look at whether they
really need to do a busy sleep for that long (you can still do it with
a loop) or have them give up the CPU during the sleep (although I do not see
a simple helper routine in the kernel to do this). This change prevents
four modules in 2.4.0-prerelease from linking. I have attached a patch
allowing them to link, but I would appreciate feedback on whether my
patches are the best approach. Here is a summary:

drivers/net/tokenring/smctr.c - I think this is the only file that had
                                  a real bug. The comments say it is
                                  delaying for 2ms in two places, but the
                                  code actually asks for a delay of 200ms
                                  in each place. I have changed it to
                                  really only delay 2ms in each place.
                                  I would like to know if it still drives
                                  the hardware correctly. PLEASE TEST.

drivers/net/irda/tohoboe.c - The code already has a FIXME and it
                                  currently does 10 iterations of 100ms
                                  delays, checking a register at each loop.
                                  I have changed it to do 1000 iterations of
                                  1ms. It is the same maximum delay, but
                                  it will exit faster once the event that
                                  it is looking for occurs. Is there a
                                  better fix?

drivers/video/atyfb.c - An intentional 50ms delay.
drivers/video/clgenfb.c - An intentional 100ms delay.
                                  I've changed both files to keep the
                                  delays by using mdelay instead of udelay.
                                  Perhaps somebody could check the
                                  approaprirate documentation and test
                                  on real hardware to determine if the
                                  delays really need to be this long.

        Anyhow, I think we should try to resolve the __bad_udelay
problems somehow by, say, linux-2.4.0-prerelease79. :-)

-- 
Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."


- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jan 07 2001 - 21:00:11 EST