<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/staging/comedi, branch v3.12.44</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>staging: comedi: comedi_compat32.c: fix COMEDI_CMD copy back</title>
<updated>2015-03-16T13:58:16+00:00</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2015-01-27T18:16:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b848046a02bc2a35da3f6a0fbae8db6ff1691cc4'/>
<id>b848046a02bc2a35da3f6a0fbae8db6ff1691cc4</id>
<content type='text'>
commit 42b8ce6f55facfa101462e694d33fc6bca471138 upstream.

`do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl.
This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd`
back to user-space.  (This occurs when the low-level Comedi driver's
`do_cmdtest()` handler returns non-zero to indicate a problem with the
contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has
the `CMDF_BOGUS` flag set.)

`compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible
version of the `COMEDI_CMD` ioctl.  Currently, it never copies a 32-bit
compatible version of `struct comedi_cmd` back to user-space, which is
at odds with the way the regular `COMEDI_CMD` ioctl is handled.  To fix
it, change `compat_cmd()` to copy a 32-bit compatible version of the
`struct comedi_cmd` back to user-space when the main ioctl handler
returns `-EAGAIN`.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Reviewed-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 42b8ce6f55facfa101462e694d33fc6bca471138 upstream.

`do_cmd_ioctl()` in "comedi_fops.c" handles the `COMEDI_CMD` ioctl.
This returns `-EAGAIN` if it has copied a modified `struct comedi_cmd`
back to user-space.  (This occurs when the low-level Comedi driver's
`do_cmdtest()` handler returns non-zero to indicate a problem with the
contents of the `struct comedi_cmd`, or when the `struct comedi_cmd` has
the `CMDF_BOGUS` flag set.)

`compat_cmd()` in "comedi_compat32.c" handles the 32-bit compatible
version of the `COMEDI_CMD` ioctl.  Currently, it never copies a 32-bit
compatible version of `struct comedi_cmd` back to user-space, which is
at odds with the way the regular `COMEDI_CMD` ioctl is handled.  To fix
it, change `compat_cmd()` to copy a 32-bit compatible version of the
`struct comedi_cmd` back to user-space when the main ioctl handler
returns `-EAGAIN`.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Reviewed-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: comedi: cb_pcidas64: fix incorrect AI range code handling</title>
<updated>2015-03-05T14:37:14+00:00</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2015-02-27T18:10:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5bebf22856156a533aa6a107385e17b1422dba2e'/>
<id>5bebf22856156a533aa6a107385e17b1422dba2e</id>
<content type='text'>
commit be8e89087ec2d2c8a1ad1e3db64bf4efdfc3c298 upstream.

The hardware range code values and list of valid ranges for the AI
subdevice is incorrect for several supported boards.  The hardware range
code values for all boards except PCI-DAS4020/12 is determined by
calling `ai_range_bits_6xxx()` based on the maximum voltage of the range
and whether it is bipolar or unipolar, however it only returns the
correct hardware range code for the PCI-DAS60xx boards.  For
PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar
ranges.  For PCI-DAS64/Mx/16 it returns the wrong code for all the
ranges and the comedi range table is incorrect.

Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new
member `ai_range_codes` of `struct pcidas64_board` to map the comedi
range table indices to the hardware range codes.  Use a new comedi range
table for the PCI-DAS64/Mx/16 boards (and the commented out variants).

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit be8e89087ec2d2c8a1ad1e3db64bf4efdfc3c298 upstream.

The hardware range code values and list of valid ranges for the AI
subdevice is incorrect for several supported boards.  The hardware range
code values for all boards except PCI-DAS4020/12 is determined by
calling `ai_range_bits_6xxx()` based on the maximum voltage of the range
and whether it is bipolar or unipolar, however it only returns the
correct hardware range code for the PCI-DAS60xx boards.  For
PCI-DAS6402/16 (and /12) it returns the wrong code for the unipolar
ranges.  For PCI-DAS64/Mx/16 it returns the wrong code for all the
ranges and the comedi range table is incorrect.

Change `ai_range_bits_6xxx()` to use a look-up table pointed to by new
member `ai_range_codes` of `struct pcidas64_board` to map the comedi
range table indices to the hardware range codes.  Use a new comedi range
table for the PCI-DAS64/Mx/16 boards (and the commented out variants).

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: comedi: ni_daq_700: add mux settling delay</title>
<updated>2014-06-20T15:34:05+00:00</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2014-05-19T10:29:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=089768acf22bb5a9d5a255413e5fdac0ad15c6ea'/>
<id>089768acf22bb5a9d5a255413e5fdac0ad15c6ea</id>
<content type='text'>
commit ffed54dced86723f352323f15789d9ad6bee25e1 upstream.

I got a patch from the original author, Fred Brooks, to add a small
settling delay after setting the AI channel multiplexor.  The lack of
delay resulted in unstable or scrambled data on faster processors.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Reported-by: Fred Brooks &lt;nsaspook@nsaspook.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ffed54dced86723f352323f15789d9ad6bee25e1 upstream.

I got a patch from the original author, Fred Brooks, to add a small
settling delay after setting the AI channel multiplexor.  The lack of
delay resulted in unstable or scrambled data on faster processors.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Reported-by: Fred Brooks &lt;nsaspook@nsaspook.com&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: comedi: usbdux: bug fix for accessing 'ao_chanlist' in private data</title>
<updated>2014-05-15T07:55:00+00:00</updated>
<author>
<name>H Hartley Sweeten</name>
<email>hsweeten@visionengravers.com</email>
</author>
<published>2014-03-28T16:20:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8ed38426cc92fa6b7af07a9b0498ccba9a51b9ec'/>
<id>8ed38426cc92fa6b7af07a9b0498ccba9a51b9ec</id>
<content type='text'>
commit 2704f807f9498054b8153002bafa3e818079e9a5 upstream.

In usbdux_ao_cmd(), the channels for the command are transfered from the
cmd-&gt;chanlist and stored in the private data 'ao_chanlist'. The channel
numbers are bit-shifted when stored so that they become the "command"
that is transfered to the device. The channel to command conversion
results in the 'ao_chanlist' having these values for the channels:

  channel 0 -&gt; ao_chanlist = 0x00
  channel 1 -&gt; ao_chanlist = 0x40
  channel 2 -&gt; ao_chanlist = 0x80
  channel 3 -&gt; ao_chanlist = 0xc0

The problem is, the usbduxsub_ao_isoc_irq() function uses the 'chan' value
from 'ao_chanlist' to access the 'ao_readback' array in the private data.
So instead of accessing the array as 0, 1, 2, 3, it accesses it as 0x00,
0x40, 0x80, 0xc0.

Fix this by storing the raw channel number in 'ao_chanlist' and doing the
bit-shift when creating the command.

Fixes: a998a3db530bff80 "staging: comedi: usbdux: cleanup the private data 'outBuffer'"
Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Reviewed-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Acked-by: Bernd Porr &lt;mail@berndporr.me.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2704f807f9498054b8153002bafa3e818079e9a5 upstream.

In usbdux_ao_cmd(), the channels for the command are transfered from the
cmd-&gt;chanlist and stored in the private data 'ao_chanlist'. The channel
numbers are bit-shifted when stored so that they become the "command"
that is transfered to the device. The channel to command conversion
results in the 'ao_chanlist' having these values for the channels:

  channel 0 -&gt; ao_chanlist = 0x00
  channel 1 -&gt; ao_chanlist = 0x40
  channel 2 -&gt; ao_chanlist = 0x80
  channel 3 -&gt; ao_chanlist = 0xc0

The problem is, the usbduxsub_ao_isoc_irq() function uses the 'chan' value
from 'ao_chanlist' to access the 'ao_readback' array in the private data.
So instead of accessing the array as 0, 1, 2, 3, it accesses it as 0x00,
0x40, 0x80, 0xc0.

Fix this by storing the raw channel number in 'ao_chanlist' and doing the
bit-shift when creating the command.

Fixes: a998a3db530bff80 "staging: comedi: usbdux: cleanup the private data 'outBuffer'"
Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Reviewed-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Acked-by: Bernd Porr &lt;mail@berndporr.me.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: comedi: 8255_pci: initialize MITE data window</title>
<updated>2014-05-05T12:24:37+00:00</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2014-03-13T15:30:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c78609380c224adcbdf21f138505c63d93d4ce7c'/>
<id>c78609380c224adcbdf21f138505c63d93d4ce7c</id>
<content type='text'>
commit 268d1e799663b795cba15c64f5d29407786a9dd4 upstream.

According to National Instruments' PCI-DIO-96/PXI-6508/PCI-6503 User
Manual, the physical address in PCI BAR1 needs to be OR'ed with 0x80 and
written to register offset 0xC0 in the "MITE" registers (BAR0).  Do so
during initialization of the National Instruments boards handled by the
"8255_pci" driver.  The boards were previously handled by the
"ni_pcidio" driver, where the initialization was done by `mite_setup()`
in the "mite" module.  The "mite" module comes with too much extra
baggage for the "8255_pci" driver to deal with so use a local, simpler
initialization function.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 268d1e799663b795cba15c64f5d29407786a9dd4 upstream.

According to National Instruments' PCI-DIO-96/PXI-6508/PCI-6503 User
Manual, the physical address in PCI BAR1 needs to be OR'ed with 0x80 and
written to register offset 0xC0 in the "MITE" registers (BAR0).  Do so
during initialization of the National Instruments boards handled by the
"8255_pci" driver.  The boards were previously handled by the
"ni_pcidio" driver, where the initialization was done by `mite_setup()`
in the "mite" module.  The "mite" module comes with too much extra
baggage for the "8255_pci" driver to deal with so use a local, simpler
initialization function.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>staging: comedi: adv_pci1710: fix analog output readback value</title>
<updated>2014-02-22T21:32:27+00:00</updated>
<author>
<name>H Hartley Sweeten</name>
<email>hsweeten@visionengravers.com</email>
</author>
<published>2014-02-05T21:59:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=efab4626e2c8867ab669caec1b1be2458ea3a052'/>
<id>efab4626e2c8867ab669caec1b1be2458ea3a052</id>
<content type='text'>
commit 1e85c1ea1ff2a60659e790ef8ec76c7339445841 upstream.

The last value written to a analog output channel is cached in the
private data of this driver for readback.

Currently, the wrong value is cached in the (*insn_write) functions.
The current code stores the data[n] value for readback afer the loop
has written all the values. At this time 'n' points past the end of
the data array.

Fix the functions by using a local variable to hold the data being
written to the analog output channel. This variable is then used
after the loop is complete to store the readback value. The current
value is retrieved before the loop in case no values are actually
written..

Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Reviewed-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1e85c1ea1ff2a60659e790ef8ec76c7339445841 upstream.

The last value written to a analog output channel is cached in the
private data of this driver for readback.

Currently, the wrong value is cached in the (*insn_write) functions.
The current code stores the data[n] value for readback afer the loop
has written all the values. At this time 'n' points past the end of
the data array.

Fix the functions by using a local variable to hold the data being
written to the analog output channel. This variable is then used
after the loop is complete to store the readback value. The current
value is retrieved before the loop in case no values are actually
written..

Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Reviewed-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>staging: comedi: adl_pci9111: fix incorrect irq passed to request_irq()</title>
<updated>2014-01-25T16:49:28+00:00</updated>
<author>
<name>H Hartley Sweeten</name>
<email>hsweeten@visionengravers.com</email>
</author>
<published>2013-12-05T20:43:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e2fcb249ce690eca7002d3f748ecefb9113ac2b1'/>
<id>e2fcb249ce690eca7002d3f748ecefb9113ac2b1</id>
<content type='text'>
commit 48108fe3daa0d142f9b97178fdb23704ea3a407b upstream.

The dev-&gt;irq passed to request_irq() will always be 0 when the auto_attach
function is called. The pcidev-&gt;irq should be used instead to get the correct
irq number.

Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Reviewed-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 48108fe3daa0d142f9b97178fdb23704ea3a407b upstream.

The dev-&gt;irq passed to request_irq() will always be 0 when the auto_attach
function is called. The pcidev-&gt;irq should be used instead to get the correct
irq number.

Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Reviewed-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>staging: comedi: addi_apci_1032: fix subdevice type/flags bug</title>
<updated>2014-01-25T16:49:28+00:00</updated>
<author>
<name>H Hartley Sweeten</name>
<email>hsweeten@visionengravers.com</email>
</author>
<published>2013-12-09T23:06:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=10d00b05a364d9cb56b5ed7b2e52a3fc7a72462a'/>
<id>10d00b05a364d9cb56b5ed7b2e52a3fc7a72462a</id>
<content type='text'>
commit 90daf69a7a3f1d1a41018c799968a0bb896d65e0 upstream.

The SDF_CMD_READ should be one of the s-&gt;subdev_flags not part of
the s-&gt;type.

Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Reviewed-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 90daf69a7a3f1d1a41018c799968a0bb896d65e0 upstream.

The SDF_CMD_READ should be one of the s-&gt;subdev_flags not part of
the s-&gt;type.

Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Reviewed-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>staging: comedi: drivers: fix return value of comedi_load_firmware()</title>
<updated>2014-01-09T20:25:07+00:00</updated>
<author>
<name>H Hartley Sweeten</name>
<email>hsweeten@visionengravers.com</email>
</author>
<published>2013-12-10T23:31:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bec1a4f8696c44ce96398dceab8aba4785ec8ea9'/>
<id>bec1a4f8696c44ce96398dceab8aba4785ec8ea9</id>
<content type='text'>
commit c6236c0ce39c809c336ca929f68cf8ad02cf94e0 upstream.

Some of the callback functions that upload the firmware in the comedi
drivers return a positive value indicating the number of bytes sent
to the device. Detect this condition and just return '0' to indicate
a successful upload.

Reported-by: Bernd Porr &lt;mail@berndporr.me.uk&gt;
Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Acked-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Acked-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c6236c0ce39c809c336ca929f68cf8ad02cf94e0 upstream.

Some of the callback functions that upload the firmware in the comedi
drivers return a positive value indicating the number of bytes sent
to the device. Detect this condition and just return '0' to indicate
a successful upload.

Reported-by: Bernd Porr &lt;mail@berndporr.me.uk&gt;
Signed-off-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Acked-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Acked-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>staging: comedi: 8255_pci: fix for newer PCI-DIO48H</title>
<updated>2014-01-09T20:25:07+00:00</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2013-12-13T12:00:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4f66e9d70edf73e796486199f847ad5402bf0eac'/>
<id>4f66e9d70edf73e796486199f847ad5402bf0eac</id>
<content type='text'>
commit 0283f7a100882684ad32b768f9f1ad81658a0b92 upstream.

At some point, Measurement Computing / ComputerBoards redesigned the
PCI-DIO48H to use a PLX PCI interface chip instead of an AMCC chip.
This meant they had to put their hardware registers in the PCI BAR 2
region instead of PCI BAR 1.  Unfortunately, they kept the same PCI
device ID for the new design.  This means the driver recognizes the
newer cards, but doesn't work (and is likely to screw up the local
configuration registers of the PLX chip) because it's using the wrong
region.

Since  the PCI subvendor and subdevice IDs were both zero on the old
design, but are the same as the vendor and device on the new design, we
can tell the old design and new design apart easily enough.  Split the
existing entry for the PCI-DIO48H in `pci_8255_boards[]` into two new
entries, referenced by different entries in the PCI device ID table
`pci_8255_pci_table[]`.  Use the same board name for both entries.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Acked-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0283f7a100882684ad32b768f9f1ad81658a0b92 upstream.

At some point, Measurement Computing / ComputerBoards redesigned the
PCI-DIO48H to use a PLX PCI interface chip instead of an AMCC chip.
This meant they had to put their hardware registers in the PCI BAR 2
region instead of PCI BAR 1.  Unfortunately, they kept the same PCI
device ID for the new design.  This means the driver recognizes the
newer cards, but doesn't work (and is likely to screw up the local
configuration registers of the PLX chip) because it's using the wrong
region.

Since  the PCI subvendor and subdevice IDs were both zero on the old
design, but are the same as the vendor and device on the new design, we
can tell the old design and new design apart easily enough.  Split the
existing entry for the PCI-DIO48H in `pci_8255_boards[]` into two new
entries, referenced by different entries in the PCI device ID table
`pci_8255_pci_table[]`.  Use the same board name for both entries.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Acked-by: H Hartley Sweeten &lt;hsweeten@visionengravers.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
