cc1352_bootloader_rx() appends each serdev chunk into the fixed
rx_buffer before parsing bootloader packets. The helper can keep
leftover bytes between callbacks and may receive multiple packets in one
callback, so a single count value is not constrained by one packet
length.
Check that the incoming chunk fits in the remaining receive buffer space
before memcpy(). If it does not, drop the staged data and consume the
bytes instead of overflowing rx_buffer.
Fixes: 0cf7befa3e ("greybus: gb-beagleplay: Add firmware upload API")
Cc: stable <stable@kernel.org>
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260402054016.38587-1-pengpeng@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that hdlc_tx_frames() can drop frames when the circular buffer is
full, make the failure visible to callers:
- Change hdlc_tx_frames() return type from void to int (-EAGAIN on
buffer full).
- Change gb_beagleplay_start_svc() / gb_beagleplay_stop_svc() to
return int so probe and firmware-upload paths can detect failures.
- gb_message_send(): propagate the error so the greybus core can
handle the transport failure.
- hdlc_tx_s_frame_ack(): log with dev_warn_ratelimited on failure
(ACK loss is recoverable by HDLC retransmission).
- Probe path: propagate start_svc failure via new free_greybus label.
- Firmware upload paths: return FW_UPLOAD_ERR_RW_ERROR when SVC
restart fails instead of silently continuing.
- Remove path: best-effort stop_svc, ignore failure.
Cc: Ayush Singh <ayushdevel1325@gmail.com>
Cc: Johan Hovold <johan@kernel.org>
Cc: Alex Elder <elder@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
Link: https://patch.msgid.link/20260330120801.981506-2-geoffreyhe2@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hdlc_append() calls usleep_range() to wait for circular buffer space,
but it is called with tx_producer_lock (a spinlock) held via
hdlc_tx_frames() -> hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc.
Sleeping while holding a spinlock is illegal and can trigger
"BUG: scheduling while atomic".
Fix this by moving the buffer-space wait out of hdlc_append() and into
hdlc_tx_frames(), before the spinlock is acquired. The new flow:
1. Pre-calculate the worst-case encoded frame length.
2. Wait (with sleep) outside the lock until enough space is available,
kicking the TX consumer work to drain the buffer.
3. Acquire the spinlock, re-verify space, and write the entire frame
atomically.
This ensures that sleeping only happens without any lock held, and
that frames are either fully enqueued or not written at all.
This bug is found by CodeQL static analysis tool (interprocedural
sleep-in-atomic query) and my code review.
Fixes: ec558bbfea ("greybus: Add BeaglePlay Linux Driver")
Cc: stable <stable@kernel.org>
Cc: Ayush Singh <ayushdevel1325@gmail.com>
Cc: Johan Hovold <johan@kernel.org>
Cc: Alex Elder <elder@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
Link: https://patch.msgid.link/20260330120801.981506-1-geoffreyhe2@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260311082226.14865-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When `flashing_mode` is set, `gb_tty_receive()` routes incoming bytes to
`cc1352_bootloader_rx()`. That helper appends the new bytes to the shared
`rx_buffer` with `memcpy()` but does not check that the chunk fits in the
remaining space first. The normal HDLC receive path already enforces
`MAX_RX_HDLC`, so do the same here before appending bootloader data.
If a packet would overflow the receive buffer, drop it and reset the
bootloader receive state instead of copying past the end of `rx_buffer`.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260322031923.58013-1-pengpeng@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 6cd5a9a35c ("staging/trivial: fix typos concerning "access"")
accidentally changed "Acces I/O Products" to "Access I/O Products",
although "Acces" should actually be a capitalized acronym "ACCES"
(standing for "Acquisition, Control, and Communication: Engineering &
Systems"). Change it in the "aio_aio12_8" and "aio_iiro_16" drivers and
change the Kconfig file to match.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260129114402.11033-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "s526" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a Sensoray
526 board. It currently allows any base address to be configured but
the hardware only supports base addresses (configured by on-board DIP
switches) in the range 0 to 0xFFC0 on 64-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-47-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "rti800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a RTI-802
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board DIP
switches) in the range 0 to 0x3FC on 4-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-46-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "rti800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a RTI-800
or RTI-815 board. It currently allows any base address to be configured
but the hardware only supports base addresses (configured by on-board
DIP switches) in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-45-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcmmio" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
PCM-UIO48A or PCM-UIO96A board. It will probably work with the later
PCM-UIO48C and PCM-UIO96C boards. It currently allows any base address
to be configured but the hardware only supports base addresses
(configured by on-board jumpers) in the range 0 to 0xFFF0 on 16-byte
boundaries (for PCM-UIO48C) or 0 to 0xFFE0 on 32-byte boundaries (for
PCM-UIO96C). (The PCM-UIO48A supports base addresses up to 0xFF0 and
the PCI-UIO96A supports base addresses up to 0x7E0.)
Add a sanity check to ensure the device is not configured at an
unsupported base address (allowing for the extended range of the "C"
models).
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-44-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcmmio" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a PCM-MIO
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0 to 0xFFE0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-43-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcmda12" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
PCM-D/A-12 or PCM-A/D-16 board. It currently allows any base address to
be configured. I cannot find a full manual, but the short datasheet
says it uses 15 consecutive I/O addresses on "any even sixteen port
boundary", so assume it supports base addresses (configured by on-board
jumpers) in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-42-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcmad" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
PCM-A/D-12 or PCM-A/D-16 board. It currently allows any base address to
be configured but the hardware only supports base addresses (configured
by on-board jumpers) in the range 0 to 0x3FC on 4-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-41-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcm3724" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a PCM-3724
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board DIP
switches) in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-40-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcl818" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a board in
the PCL-818 series. It currently allows any base address to be
configured but the hardware devices only support base addresses
(configured by on-board DIP switches) from 0 to 0x3F0 on 16-byte
boundaries. If the board has a FIFO and jumper JP6 is in the "Enabled"
(default) position, then the base address needs to be on a 32-byte
boundary and the length of the I/O port region will be 32 (to allow
access to the FIFO registers) instead of 16. The state of jumper JP6 is
unknown, so if the board has a FIFO device and is being configured on an
odd 16-byte boundary, assume that jumper JP6 is in the "Disabled"
position (to disallow access to the FIFO registers).
Add a sanity check to ensure the device is not configured at an
unsupported base address.
If the board has a FIFO and is configured on an odd 16-byte boundary,
log a reminder that JP6 needs to be in the "Disabled" position for
correct operation. If the board has a FIFO and is configured on an even
16-byte boundary and the configuration option has been set to use the
FIFO (`it->options[2] == -1`), log a reminder that JP6 needs to be in
the "Enabled" position.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-39-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcl816" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a PCL-816
or PCL-814B ISA board. It currently allows any base address to be
configured but the hardware devices only support base addresses
(configured by on-board DIP switches) from 0 to 0x3F0 on 16-byte
boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-38-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcl812" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of various
analog/digital I/O ISA boards from Advantech, ADLINK, and ICP DAS. It
currently allows any base address to be configured but the hardware
devices only support base addresses (configured by on-board DIP
switches) from 0 or 0x200 (depending on the model) to 0x3F0 on 16-byte
boundaries.
Store the minimum supported I/O base addresses in the static board
information array elements and add a sanity check to ensure the device
is not configured at an unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-37-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcl730" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of various
relay output and digital input ISA board from Advantech, ADLINK, ICP
DAS, and Diamond Systems. It currently allows any base address to be
configured but the hardware devices have restrictions on the base
addresses (configured by on-board DIP switches or jumpers), including
the alignment, which can be larger than the board's I/O register address
span. The Diamond Systems IR104-PBF board is particularly restricted to
4 different base addresses with different sized gaps between the
possible addresses.
Store the minimum supported I/O base addresses and alignment in the
static board information array elements and add a sanity check to ensure
the device is not configured at an unsupported base address. For the
IR104-PBF board, add a special check that the base address is one of the
4 supported base addresses for that board.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-36-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcl726" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of various
analog output ISA boards from Advantech (PCL-726/727/728) and ADLINK
(ACL-6126/6128). (Most of them also have digital I/O.) It currently
allows any base address to be configured but the hardware only supports
base addresses (configured by on-board DIP switches) from 0 or 0x200 up
to nearly 0x3FF, depending on the model.
Store the minimum and maximum supported I/O address ranges in the static
board information array elements (the required alignment is already
stored in the `io_len` member), and add a sanity check to ensure the
device is not configured at an unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-35-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcl724" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of various
8255 chip-based digital I/O ISA boards from Advantech, ADLINK,
WinSystems, and Diamond Systems. It currently allows any base address
to be configured but the hardware only supports base addresses
(configured by on-board DIP switches or jumpers) in various ranges, and
on various alignment boundaries, depending on the model.
Store the minimum and maximum supported I/O address ranges in the static
board information array elements (the required alignment is already
stored in the `io_range` member), and add a sanity check to ensure the
device is not configured at an unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-34-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "pcl711" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an
Advantech PCL-711 series board or an Adlink ACL-8112 series board. It
currently allows any base address to be configured but the hardware only
supports base addresses (configured by on-board DIP switches) in the
range 0 to 0x3F0 (for PCL-711) or 0x200 to 0x3F0 (for ACL-8112) on
16-byte boundaries.
Store the minimum supported I/O base address in the static board
information array elements, and add a sanity check to ensure the device
is not configured at an unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-33-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "ni_labpc" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
Lab-PC-1200 series or Lab-PC+ board. It currently allows any base
address to be configured but the hardware only supports base addresses
(configured by a configuration utility and stored in nonvolatile memory)
in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-32-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "ni_atmio16d" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an
AT-MIO-16 o AT-MIO-16D board. It currently allows any base address to
be configured but the hardware only supports base addresses (configured
by on-board DIP switches) in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-31-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "ni_atmio" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an AT E
Series board. Or, if the option value is zero, it can search ISA PNP
devices to look for a compatible board. If the base address is
configured manually, it currently allows any base address to be
configured but the hardware only supports base addresses (configured by
a configuration utility and stored in nonvolatile memory) in the range
0x20 to 0xFFE0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-30-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "ni_at_ao" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an AT-AO-6
or AT-AO-10 board. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
on-board jumpers) in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-29-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "ni_at_a2150" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an AT-A2150
series board. It currently allows any base address to be configured but
the hardware only supports base addresses (configured by on-board
jumpers) in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-28-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "multiq3" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a Multiq-3
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-27-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "mpc624" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a MPC624
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-26-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "fl512" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an FL512
board. It currently allows any base address to be configured and uses a
16-byte register region.
I cannot find any information about this board, but assume it needs to
be aligned to a 16-byte boundary. I have no idea about the allowed
range, so allow anything in a 32-bit range and add a "FIXME" comment
(although most ancient ISA cards only support 10-bit address decoding).
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-25-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2817" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DT2817
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0x200 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-24-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2815" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DT2815
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0x200 to 0x3fe on 2-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-23-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2814" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DT2814
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0x200 to 0x3fe on 2-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-22-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2811" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DT2811 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
on-board jumpers) in the range 0x200 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-21-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dt2801" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DT2801 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0x200 to 0x3fe on 2-byte
boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-20-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dmm32at" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
Diamond-MM-32-AT board. It currently allows any base address to be
configured but the hardware only supports 8 possible base addresses
(selected by 3 on-board jumpers). These are 0x100, 0x140, 0x180, 0x200,
0x280, 0x300, 0x340, and 0x380.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-19-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DAS800 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-18-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das6402" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DAS6402 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-17-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das1800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a board
compatible with the DAS1800 series. It currently allows any base
address to be configured but the hardware only supports base addresses
(configured by an on-board DIP switch) in the range 0 to 0x3f0 on
16-byte boundaries. Some boards have an additional span of up to 0x10
registers at offset 0x400 from the main 0x10 byte region.
Add a sanity check to ensure the device is not configured at an
unsupported base address. If the main base address is correctly aligned
and within range, then the additional region at offset 0x400 from the
configured base address will naturally be within range and correctly
aligned.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-16-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das16m1" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DAS16/M1
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0 to 0x3f0 on 16-byte boundaries. It has an
additional span of 0x8 registers at offset 0x400 from the main 0x10 byte
region.
Add a sanity check to ensure the device is not configured at an
unsupported base address. If the main base address is correctly aligned
and within range, then the additional region at offset 0x400 from the
configured base address will naturally be within range and correctly
aligned.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-15-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das16" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a various
DAS16 compatible boards. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f0 on 16- or 32-byte
boundaries. Some of the boards have an 8255 chip at offset 0x10 and
require the board to be configured on a 32-byte boundary unless some
on-board jumpers are set to limit the board to decoding only the first
0x10 registers, disabling access to the 8255. Some other boards place
the 8255 chip (and some other registers) at offset 0x400 from the base
address, decoding 0x10 registers at the base address and 0x8 registers
at the base address plus 0x400.
Add a sanity check to ensure the device is not configured at an
unsupported base address. If the device has the 8255 chip at offset
0x10, and is being configured with the base address at an odd 16-byte
boundary, limit the size of the region to 0x10 and disable the 8255
subdevice.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-14-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "das08_isa" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DAS08 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f0 on 16-byte boundaries.
(Technically, the DIP switches allow 8-byte boundaries, but I do not
think that is advisable given that the boards decode an 16-byte address
range.)
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-13-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "dac02" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
DAC-02 board. It currently allows any base address to be configured but
the hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0x200 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-12-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The "comedi_parport" driver treats a standard printer parallel port as a
COMEDI digital I/O device, driving the port's I/O registers directly.
It uses an admin-supplied configuration option (`it->options[0]`) to
configure the I/O port base address of the device. Currently, the
driver allows any I/O base address to be specified as long as the I/O
region can be reserved, and it converts the specified `int` option value
holding the base address to `unsigned long`.
It doesn't make sense to allow base addresses that are not aligned to
4-byte boundaries (for SPP printer ports, although printer ports with
EPP/ECP support actually need to be aligned on 8-byte boundaries), so
add a check for 4-byte alignment.
Convert the option value that specifies the base address from `int` to
`unsigned int` instead of `unsigned long` so it ends up the same on
32-bit and 64-bit systems.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://patch.msgid.link/20260130170416.49994-11-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
