[patch 14/17] scsi: fix bad use of udelay in atp870u.c

[patch 14/17] scsi: fix bad use of udelay in atp870u.c

[akpm]

From: Martin Michlmayr <tbm@cyrius.com>

The ACARD driver calls udelay() with a value > 2000, which leads to
to the following compilation error on ARM:
  ERROR: "__bad_udelay" [drivers/scsi/atp870u.ko] undefined!
  make[1]: *** [__modpost] Error 1
Fix this by using a combination of mdelay and udelay.

Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/scsi/atp870u.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff -puN drivers/scsi/atp870u.c~scsi-fix-bad-use-of-udelay-in-atp870uc drivers/scsi/atp870u.c
--- a/drivers/scsi/atp870u.c~scsi-fix-bad-use-of-udelay-in-atp870uc
+++ a/drivers/scsi/atp870u.c
@@ -1171,7 +1171,8 @@ wait_io1:
 	outw(val, tmport);
 	outb(2, 0x80);
 TCM_SYNC:
-	udelay(0x800);
+	mdelay(2);
+	udelay(48);
 	if ((inb(tmport) & 0x80) == 0x00) {	/* bsy ? */
 		outw(0, tmport--);
 		outb(0, tmport);
_

Re: [patch 14/17] scsi: fix bad use of udelay in atp870u.c

[James Bottomley]

On Wed, 2008-10-29 at 14:24 -0700, akpm@linux-foundation.org wrote:
> -       udelay(0x800);
> +       mdelay(2);
> +       udelay(48);

OK, this fix is obviously wrong ... the code holds off interrupts for
two ticks that's clearly completely bogus.  In this case silencing the
warning is hiding the bogosity ... now if only someone could actually
fix it ...

James

Re: [patch 14/17] scsi: fix bad use of udelay in atp870u.c

[Andrew Morton]

On Wed, 29 Oct 2008 16:42:15 -0500
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Wed, 2008-10-29 at 14:24 -0700, akpm@linux-foundation.org wrote:
> > -       udelay(0x800);
> > +       mdelay(2);
> > +       udelay(48);
> 
> OK, this fix is obviously wrong ... the code holds off interrupts for
> two ticks that's clearly completely bogus.  In this case silencing the
> warning is hiding the bogosity ... now if only someone could actually
> fix it ...
> 

That'll take some heavy lifting.  There's an mdelay(128) a few lines up!

I'd suggest that you merge this to fix the ARM build then hurriedly
find something else to look at :(