kernel/linux.git/drivers/comedi, branch v6.19.11

comedi: dmm32at: serialize use of paged registers

2026-01-16T15:43:51+00:00

Some of the hardware registers of the DMM-32-AT board are multiplexed, using the least significant two bits of the Miscellaneous Control register to select the function of registers at offsets 12 to 15: 00 => 8254 timer/counter registers are accessible 01 => 8255 digital I/O registers are accessible 10 => Reserved 11 => Calibration registers are accessible The interrupt service routine (`dmm32at_isr()`) clobbers the bottom two bits of the register with value 00, which would interfere with access to the 8255 registers by the `dm32at_8255_io()` function (used for Comedi instruction handling on the digital I/O subdevice). Make use of the generic Comedi device spin-lock `dev->spinlock` (which is otherwise unused by this driver) to serialize access to the miscellaneous control register and paged registers. Fixes: 3c501880ac44 ("Staging: comedi: add dmm32at driver") Cc: stable@vger.kernel.org Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260112162835.91688-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman

comedi: Fix getting range information for subdevices 16 to 255

2026-01-16T15:42:15+00:00

The `COMEDI_RANGEINFO` ioctl does not work properly for subdevice indices above 15. Currently, the only in-tree COMEDI drivers that support more than 16 subdevices are the "8255" driver and the "comedi_bond" driver. Making the ioctl work for subdevice indices up to 255 is achievable. It needs minor changes to the handling of the `COMEDI_RANGEINFO` and `COMEDI_CHANINFO` ioctls that should be mostly harmless to user-space, apart from making them less broken. Details follow... The `COMEDI_RANGEINFO` ioctl command gets the list of supported ranges (usually with units of volts or milliamps) for a COMEDI subdevice or channel. (Only some subdevices have per-channel range tables, indicated by the `SDF_RANGETYPE` flag in the subdevice information.) It uses a `range_type` value and a user-space pointer, both supplied by user-space, but the `range_type` value should match what was obtained using the `COMEDI_CHANINFO` ioctl (if the subdevice has per-channel range tables) or `COMEDI_SUBDINFO` ioctl (if the subdevice uses a single range table for all channels). Bits 15 to 0 of the `range_type` value contain the length of the range table, which is the only part that user-space should care about (so it can use a suitably sized buffer to fetch the range table). Bits 23 to 16 store the channel index, which is assumed to be no more than 255 if the subdevice has per-channel range tables, and is set to 0 if the subdevice has a single range table. For `range_type` values produced by the `COMEDI_SUBDINFO` ioctl, bits 31 to 24 contain the subdevice index, which is assumed to be no more than 255. But for `range_type` values produced by the `COMEDI_CHANINFO` ioctl, bits 27 to 24 contain the subdevice index, which is assumed to be no more than 15, and bits 31 to 28 contain the COMEDI device's minor device number for some unknown reason lost in the mists of time. The `COMEDI_RANGEINFO` ioctl extract the length from bits 15 to 0 of the user-supplied `range_type` value, extracts the channel index from bits 23 to 16 (only used if the subdevice has per-channel range tables), extracts the subdevice index from bits 27 to 24, and ignores bits 31 to 28. So for subdevice indices 16 to 255, the `COMEDI_SUBDINFO` or `COMEDI_CHANINFO` ioctl will report a `range_type` value that doesn't work with the `COMEDI_RANGEINFO` ioctl. It will either get the range table for the subdevice index modulo 16, or will fail with `-EINVAL`. To fix this, always use bits 31 to 24 of the `range_type` value to hold the subdevice index (assumed to be no more than 255). This affects the `COMEDI_CHANINFO` and `COMEDI_RANGEINFO` ioctls. There should not be anything in user-space that depends on the old, broken usage, although it may now see different values in bits 31 to 28 of the `range_type` values reported by the `COMEDI_CHANINFO` ioctl for subdevices that have per-channel subdevices. User-space should not be trying to decode bits 31 to 16 of the `range_type` values anyway. Fixes: ed9eccbe8970 ("Staging: add comedi core") Cc: stable@vger.kernel.org #5.17+ Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20251203162438.176841-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman

Merge tag 'char-misc-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2025-12-07T02:34:24+00:00

Pull char/misc/IIO driver updates from Greg KH: "Here is the big set of char/misc/iio driver updates for 6.19-rc1. Lots of stuff in here including: - lots of IIO driver updates, cleanups, and additions - large interconnect driver changes as they get converted over to a dynamic system of ids - coresight driver updates - mwave driver updates - binder driver updates and changes - comedi driver fixes now that the fuzzers are being set loose on them - nvmem driver updates - new uio driver addition - lots of other small char/misc driver updates, full details in the shortlog All of these have been in linux-next for a while now" * tag 'char-misc-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (304 commits) char: applicom: fix NULL pointer dereference in ac_ioctl hangcheck-timer: fix coding style spacing hangcheck-timer: Replace %Ld with %lld hangcheck-timer: replace printk(KERN_CRIT) with pr_crit uio: Add SVA support for PCI devices via uio_pci_generic_sva.c dt-bindings: slimbus: fix warning from example intel_th: Fix error handling in intel_th_output_open misc: rp1: Fix an error handling path in rp1_probe() char: xillybus: add WQ_UNBOUND to alloc_workqueue users misc: bh1770glc: use pm_runtime_resume_and_get() in power_state_store misc: cb710: Fix a NULL vs IS_ERR() check in probe() mux: mmio: Add suspend and resume support virt: acrn: split acrn_mmio_dev_res out of acrn_mmiodev greybus: gb-beagleplay: Fix timeout handling in bootloader functions greybus: add WQ_PERCPU to alloc_workqueue users char/mwave: drop typedefs char/mwave: drop printk wrapper char/mwave: remove printk tracing char/mwave: remove unneeded fops char/mwave: remove MWAVE_FUTZ_WITH_OTHER_DEVICES ifdeffery ...

Merge tag 'hardening-v6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2025-12-05T17:11:02+00:00

Pull hardening updates from Kees Cook: - string: Add missing kernel-doc return descriptions (Kriish Sharma) - Update some mis-typed allocations These correct some accidentally wrong types used in allocations (that didn't affect the resulting size) that never got picked up from the batch I sent a few months ago. - Enable GCC diagnostic context for value-tracking warnings This results in better GCC diagnostics for the value range tracking, so we can get better visibility into where those values are coming from when we get out-of-bounds warnings at compile time. * tag 'hardening-v6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: kbuild: Enable GCC diagnostic context for value-tracking warnings string: Add missing kernel-doc return descriptions media: iris: Cast iris_hfi_gen2_get_instance() allocation type drm/plane: Remove const qualifier from plane->modifiers allocation type comedi: Adjust range_table_list allocation type

comedi: 8255: Fail to attach if fail to request I/O port region

2025-11-26T13:20:20+00:00

The COMEDI standalone 8255 driver can be used to configure a COMEDI device consisting of one of more subdevices, each using an 8255 digital I/O chip mapped to a range of port I/O addresses. The base port I/O address of each chip is specified in an array of integer option values by the `COMEDI_DEVCONFIG` ioctl. When support for multiple 8255 subdevices per device was added in the out-of-tree comedi 0.7.27 back in 1999, if any port I/O region could not be requested, then the corresponding subdevice was set to be an "unused" subdevice, and the COMEDI device would still be set-up OK as long as those were the only types of errors. That has persisted until the present day, but seems a bit odd in retrospect. All the other COMEDI drivers that use port I/O or memory regions will fail to set up the device if any region cannot be requested. It seems unlikely that the sys admin would deliberately choose a port that cannot be requested just to leave a gap in the device's usable subdevice numbers, and failing to set-up the device will provide a more noticeable indication that something hasn't been set-up correctly, so change the driver to fail to set up the device if any of the port I/O regions cannot be requested. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20251028112833.15033-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman

comedi: comedi_bond: Check for loops when bonding devices

2025-11-26T13:20:10+00:00

The "comedi_bond" driver allows a composite COMEDI device to be built up from the subdevices of other COMEDI devices, although it currently only supports digital I/O subdevices. Although it checks that it is not trying to bind to itself, it is possible to end up with a cycle of "comedi_bond" devices bound to each other. For example: 1. Configure /dev/comedi0 to use some COMEDI hardware device with digital I/O subdevices, but not a "comedi_bond" device. 2. Configure /dev/comedi1 as a "comedi_bond" device bound to /dev/comedi0. 3. Unconfigure /dev/comedi0 and reconfigure it as a "comedi_bond" device bound to /dev/comedi1. Now we have /dev/comedi0 and /dev/comedi1 bound in a cycle. When an operation is performed on the digital I/O subdevice of /dev/comedi0 for example, it will try and perform the operation on /dev/comedi1, which will try and perform the operation on /dev/comedi0. The task will end up deadlocked trying to lock /dev/comedi0's mutex which it has already locked. I discovered that possibility while investigating fix sysbot crash https://syzkaller.appspot.com/bug?extid=4a6138c17a47937dcea1 ("possible deadlock in comedi_do_insn"), but I think that report may be a false positive. To avoid that, replace the calls to `comedi_open()` and `comedi_close()` in "kcomedilib" with calls to `comedi_open_from()` and `comedi_close_from()`. These take an extra parameter that indicates the COMEDI minor device number from which the open or close is being performed. `comedi_open_from()` will refuse to open the device if doing so would result in a cycle. The cycle detection depends on the extra parameter having the correct value for this device and also for existing devices in the chain. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20251027153748.4569-3-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman

comedi: kcomedilib: Add loop checking variants of open and close

2025-11-26T13:20:10+00:00

Add `comedi_open_from(path, from)` and `comedi_close_from(dev, from)` as variants of the existing `comedi_from(path)` and `comedi_close(dev)`. The additional `from` parameter is a minor device number that tells the function that the COMEDI device is being opened or closed from another COMEDI device if the value is in the range [0, `COMEDI_NUM_BOARD_MINORS`-1]. In that case the function will refuse to open the device if it would lead to a chain of devices opening each other. (It will also impose a limit on the number of simultaneous opens from one device to another because we need to count those.) The new functions are intended to be used by the "comedi_bond" driver, which is the only driver that uses the existing `comedi_open()` and `comedi_close()` functions. The new functions will be used to avoid some possible deadlock situations. Replace the existing, exported `comedi_open()` and `comedi_close()` functions with inline wrapper functions that call the newly exported `comedi_open_from()` and `comedi_close_from()` functions. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20251027153748.4569-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman

comedi: Use reference count for asynchronous command functions

2025-11-26T13:19:41+00:00

comedi: Add reference counting for Comedi command handling

2025-11-26T13:19:41+00:00

For interrupts from badly behaved hardware (as emulated by Syzbot), it is possible for the Comedi core functions that manage the progress of asynchronous data acquisition to be called from driver ISRs while no asynchronous command has been set up, which can cause problems such as invalid pointer dereferencing or dividing by zero. To help protect against that, introduce new functions to maintain a reference counter for asynchronous commands that are being set up. `comedi_get_is_subdevice_running(s)` will check if a command has been set up on a subdevice and is still marked as running, and if so will increment the reference counter and return `true`, otherwise it will return `false` without modifying the reference counter. `comedi_put_is_subdevice_running(s)` will decrement the reference counter and set a completion event when decremented to 0. Change the `do_cmd_ioctl()` function (responsible for setting up the asynchronous command) to reinitialize the completion event and set the reference counter to 1 before it marks the subdevice as running. Change the `do_become_nonbusy()` function (responsible for destroying a completed command) to call `comedi_put_is_subdevice_running(s)` and wait for the completion event after marking the subdevice as not running. Because the subdevice normally gets marked as not running before the call to `do_become_nonbusy()` (and may also be called when the Comedi device is being detached from the low-level driver), add a new flag `COMEDI_SRF_BUSY` to the set of subdevice run-flags that indicates that an asynchronous command was set up and will need to be destroyed. This flag is set by `do_cmd_ioctl()` and cleared and checked by `do_become_nonbusy()`. Subsequent patches will change the Comedi core functions that are called from low-level drivers for asynchrous command handling to make use of the `comedi_get_is_subdevice_running()` and `comedi_put_is_subdevice_running()` functions, and will modify the ISRs of some of these low-level drivers if they dereference the subdevice's `async` pointer directly. Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20251023133001.8439-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman

comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()

2025-11-26T13:19:15+00:00

Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems from the fact that in case of early device detach via pcl818_detach(), subdevice dev->read_subdev may not have initialized its pointer to &struct comedi_async as intended. Thus, any such dereferencing of &s->async->cmd will lead to general protection fault and kernel crash. Mitigate this problem by removing a call to pcl818_ai_cancel() from pcl818_detach() altogether. This way, if the subdevice setups its support for async commands, everything async-related will be handled via subdevice's own ->cancel() function in comedi_device_detach_locked() even before pcl818_detach(). If no support for asynchronous commands is provided, there is no need to cancel anything either. [1] Syzbot crash: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762 ... Call Trace: pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115 comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207 do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline] comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] ... Reported-by: syzbot+fce5d9d5bd067d6fbe9b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fce5d9d5bd067d6fbe9b Fixes: 00aba6e7b565 ("staging: comedi: pcl818: remove 'neverending_ai' from private data") Cc: stable Signed-off-by: Nikita Zhandarovich Reviewed-by: Ian Abbott Link: https://patch.msgid.link/20251023141457.398685-1-n.zhandarovich@fintech.ru Signed-off-by: Greg Kroah-Hartman