From: Jonathan Nieder <jrnieder@gmail.com>
To: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Martin Michlmayr <tbm@cyrius.com>,
linux-scsi@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RFC v2] [SCSI] atp870u: Fix bad use of udelay
Date: Tue, 24 Apr 2012 02:49:16 -0500 [thread overview]
Message-ID: <20120424074916.GA25261@burratino> (raw)
In-Reply-To: <1231536107.3235.50.camel@localhost.localdomain>
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
This is because udelay is defined on ARM, roughly speaking, as
#define udelay(n) ((n) > 2000 ? __bad_udelay() : \
__const_udelay((n) * ((2199023U*HZ)>>11)))
The argument to __const_udelay is the number of jiffies to wait
divided by 4, but this does not work unless the multiplication does
not overflow, and that is what the build error is designed to prevent.
The intended behavior can be achieved by using mdelay to call udelay
multiple times in a loop.
[jn: adding context]
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Cc: <stable@vger.kernel.org>
---
Hi James,
Three years ago, you wrote[1]:
>>> * akpm@linux-foundation.org <akpm@linux-foundation.org> [2009-01-09 12:28]:
>>>> 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.
[...]
> It's wrong to silence a warning or build break while keeping the effect
> it was complaining about it's hiding a bug. Now if the warning is
> wrong, we can take it out of the ARM build ... but I've got to say it
> looks right: the udelay in this driver will lock a UP system solid for
> 2ms.
Sorry for the very slow response. I think the patch was inadequately
explained and that it is actually a good patch.
Here's the patch again with a description that helped me convince
myself it is ok. Could you look it over and let me know what you
think?
Thanks,
Jonathan
[1] http://thread.gmane.org/gmane.linux.scsi/47523/focus=47533
drivers/scsi/atp870u.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/atp870u.c b/drivers/scsi/atp870u.c
index 68ce08552f69..a540162ac59c 100644
--- a/drivers/scsi/atp870u.c
+++ b/drivers/scsi/atp870u.c
@@ -1173,7 +1173,16 @@ wait_io1:
outw(val, tmport);
outb(2, 0x80);
TCM_SYNC:
- udelay(0x800);
+ /*
+ * The funny division into multiple delays is to accomodate
+ * arches like ARM where udelay() multiplies its argument by
+ * a large number to initialize a loop counter. To avoid
+ * overflow, the maximum supported udelay is 2000 microseconds.
+ *
+ * XXX it would be more polite to find a way to use msleep()
+ */
+ mdelay(2);
+ udelay(48);
if ((inb(tmport) & 0x80) == 0x00) { /* bsy ? */
outw(0, tmport--);
outb(0, tmport);
--
1.7.10
next prev parent reply other threads:[~2012-04-24 7:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-09 20:28 [patch 10/11] scsi: fix bad use of udelay in atp870u.c akpm
2009-01-09 20:58 ` Martin Michlmayr
2009-01-09 21:03 ` Andrew Morton
2009-01-09 21:21 ` James Bottomley
2009-01-10 15:50 ` Christoph Hellwig
2012-04-24 7:49 ` Jonathan Nieder [this message]
2012-04-24 21:18 ` [PATCH/RFC v2] [SCSI] atp870u: Fix bad use of udelay Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120424074916.GA25261@burratino \
--to=jrnieder@gmail.com \
--cc=JBottomley@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=tbm@cyrius.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox