The `insn_read` handler for the EEPROM subdevice
(`apci3501_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.)
Following 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 <abbotti@xxxxxxxxx>
---
drivers/staging/comedi/drivers/addi_apci_3501.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/addi_apci_3501.c b/drivers/staging/comedi/drivers/addi_apci_3501.c
index a38267928e5e..b4aa588975df 100644
--- a/drivers/staging/comedi/drivers/addi_apci_3501.c
+++ b/drivers/staging/comedi/drivers/addi_apci_3501.c
@@ -258,8 +258,15 @@ static int apci3501_eeprom_insn_read(struct comedi_device *dev,
{
struct apci3501_private *devpriv = dev->private;
unsigned short addr = CR_CHAN(insn->chanspec);
+ unsigned int val;
+ unsigned int i;
- data[0] = apci3501_eeprom_readw(devpriv->amcc, 2 * addr);
+ if (insn->n) {
+ /* No point reading the same EEPROM location more than once. */
+ val = apci3501_eeprom_readw(devpriv->amcc, 2 * addr);
+ for (i = 0; i < insn->n; i++)
+ data[i] = val;
+ }
return insn->n;
}
--
2.19.1
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
