The `insn_read` handler for the EEPROM subdevice (`eeprom_insn_read()`)
currently ignores `insn->n` (the number of samples to be read) and
assumes a single sample is to be read. But `insn->n` could be 0,
meaning no samples should be read, in which case `data[0]` ought not to
be written. (The comedi core at least ensures that `data[0]` exists,
but we should not rely on that.)
Follow the usual Comedi guidelines and interpret `insn->n` as the number
of samples to be read, but only read the EEPROM location once and make
`insn->n` copies, as we don't expect the contents of the EEPROM location
to change between readings.
Signed-off-by: Ian Abbott <abbo...@mev.co.uk>
---
drivers/staging/comedi/drivers/cb_pcidas64.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
b/drivers/staging/comedi/drivers/cb_pcidas64.c
index 44e5aaf8bae5..e1774e09a320 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
@@ -3768,9 +3768,17 @@ static int eeprom_read_insn(struct comedi_device *dev,
struct comedi_subdevice *s,
struct comedi_insn *insn, unsigned int *data)
{
- data[0] = read_eeprom(dev, CR_CHAN(insn->chanspec));
+ unsigned int val;
+ unsigned int i;
- return 1;
+ if (insn->n) {
+ /* No point reading the same EEPROM location more than once. */
+ val = read_eeprom(dev, CR_CHAN(insn->chanspec));
+ for (i = 0; i < insn->n; i++)
+ data[i] = val;
+ }
+
+ return insn->n;
}
/* Allocate and initialize the subdevice structures. */
--
2.19.1
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
