On 09/02/17 15:36, Saber Rezvani wrote:
Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay
Signed-off-by: Saber Rezvani <irsaber@xxxxxxxxx>
---
drivers/staging/comedi/drivers/dyna_pci10xx.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/comedi/drivers/dyna_pci10xx.c b/drivers/staging/comedi/drivers/dyna_pci10xx.c
index c9eb26f..febdc88 100644
--- a/drivers/staging/comedi/drivers/dyna_pci10xx.c
+++ b/drivers/staging/comedi/drivers/dyna_pci10xx.c
@@ -89,7 +89,7 @@ static int dyna_pci10xx_insn_read_ai(struct comedi_device *dev,
/* trigger conversion */
smp_mb();
outw_p(0x0000 + range + chan, dev->iobase + 2);
- udelay(10);
+ usleep_range(10, 100);
ret = comedi_timeout(dev, s, insn, dyna_pci10xx_ai_eoc, 0);
if (ret)
@@ -125,7 +125,7 @@ static int dyna_pci10xx_insn_write_ao(struct comedi_device *dev,
smp_mb();
/* trigger conversion and write data */
outw_p(data[n], dev->iobase);
- udelay(10);
+ usleep_range(10, 100);
}
mutex_unlock(&devpriv->mutex);
return n;
I think those two (in ..._read_ai() and ..._write_ao()) are borderline
cases, since they are in a data reading or writing loops. However,
setting the number of iterations greater than 1 isn't very common,
especially for analog output. Perhaps a compromise is in order, say by
using a much tighter range, such as 'usleep_range(10, 20);'.
@@ -143,7 +143,7 @@ static int dyna_pci10xx_di_insn_bits(struct comedi_device *dev,
mutex_lock(&devpriv->mutex);
smp_mb();
d = inw_p(devpriv->BADR3);
- udelay(10);
+ usleep_range(10, 100);
/* on return the data[0] contains output and data[1] contains input */
data[1] = d;
@@ -163,7 +163,7 @@ static int dyna_pci10xx_do_insn_bits(struct comedi_device *dev,
if (comedi_dio_update_state(s, data)) {
smp_mb();
outw_p(s->state, devpriv->BADR3);
- udelay(10);
+ usleep_range(10, 100);
}
data[1] = s->state;
Those ones are okay.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@xxxxxxxxx> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
