kernel/linux.git/include/linux/uio_driver.h, branch v6.19.11

treewide: Update email address

2026-01-11T16:09:11+00:00

In a vain attempt to consolidate the email zoo switch everything to the kernel.org account. Signed-off-by: Thomas Gleixner Signed-off-by: Linus Torvalds

uio: introduce UIO_MEM_DMA_COHERENT type

2024-03-07T21:52:59+00:00

Add a UIO memtype specifically for sharing dma_alloc_coherent memory with userspace, backed by dma_mmap_coherent. This is mainly for the bnx2/bnx2x/bnx2i "cnic" interface, although there are a few other uio drivers which map dma_alloc_coherent memory and will be converted to use dma_mmap_coherent as well. Signed-off-by: Nilesh Javali Signed-off-by: Chris Leech Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20240205200137.138302-1-cleech@redhat.com Signed-off-by: Greg Kroah-Hartman

uio: fix some kernel-doc markups

2020-11-09T17:39:36+00:00

The definitions for (devm_)uio_register_device should be at the header file, as the macros are there. The ones inside uio.c refer, instead, to __(devm_)uio_register_device. Update them and add new kernel-doc markups for the macros. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/82ab7b68d271aeda7396e369ff8a629491b9d628.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman

uio: add resource managed devm_uio_register_device() function

2020-03-18T11:34:10+00:00

This change adds a resource managed equivalent of uio_register_device(). Not adding devm_uio_unregister_device(), since the intent is to discourage it's usage. Having such a function may allow some bad driver designs. Most users of devm_*register*() functions rarely use the unregister equivalents. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20200306161853.25368-1-alexandru.ardelean@analog.com Signed-off-by: Greg Kroah-Hartman

UIO: fix up inapposite whiteplace in uio head file

2020-03-18T11:34:10+00:00

Whitespace is used in the inapposite place, which makes checkpatch complain. Signed-off-by: Qiang Su Link: https://lore.kernel.org/r/20200306070359.71398-1-suqiang4@huawei.com Signed-off-by: Greg Kroah-Hartman

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 305

2019-06-05T15:37:04+00:00

Based on 1 normalized pattern(s): licensed under the gplv2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 6 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Alexios Zavras Reviewed-by: Kate Stewart Reviewed-by: Allison Randal Reviewed-by: Armijn Hemel Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000433.961827334@linutronix.de Signed-off-by: Greg Kroah-Hartman

uio: introduce UIO_MEM_IOVA

2018-09-25T18:33:24+00:00

Introduce the concept of mapping physical memory locations that are normal memory. The new type UIO_MEM_IOVA are similar to existing UIO_MEM_PHYS but the backing memory is not marked as uncached. Also, indent related switch to the currently used style. Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman

uio: change to use the mutex lock instead of the spin lock

2018-07-07T14:57:35+00:00

We are hitting a regression with the following commit: commit a93e7b331568227500186a465fee3c2cb5dffd1f Author: Hamish Martin Date: Mon May 14 13:32:23 2018 +1200 uio: Prevent device destruction while fds are open The problem is the addition of spin_lock_irqsave in uio_write. This leads to hitting uio_write -> copy_from_user -> _copy_from_user -> might_fault and the logs filling up with sleeping warnings. I also noticed some uio drivers allocate memory, sleep, grab mutexes from callouts like open() and release and uio is now doing spin_lock_irqsave while calling them. Reported-by: Mike Christie CC: Hamish Martin Reviewed-by: Hamish Martin Signed-off-by: Xiubo Li Signed-off-by: Greg Kroah-Hartman

uio: Prevent device destruction while fds are open

2018-05-14T14:16:35+00:00

Prevent destruction of a uio_device while user space apps hold open file descriptors to that device. Further, access to the 'info' member of the struct uio_device is protected by spinlock. This is to ensure stale pointers to data not under control of the UIO subsystem are not dereferenced. Signed-off-by: Hamish Martin Reviewed-by: Chris Packham Signed-off-by: Greg Kroah-Hartman

uio: Allow handling of non page-aligned memory regions

2017-04-08T16:13:27+00:00

Since commit b65502879556 ("uio: we cannot mmap unaligned page contents") addresses and sizes of UIO memory regions must be page-aligned. If the address in the BAR register is not page-aligned (which is the case of the mf264 card), the mentioned commit forces the UIO driver to round the address down to the page size. Then, there is no easy way for user-space to learn the offset of the actual memory region within the page, because the offset seen in /sys/class/uio/uio?/maps/map?/offset is calculated from the rounded address and thus it is always zero. Fix that problem by including the offset in struct uio_mem. UIO drivers can set this field and userspace can read its value from /sys/class/uio/uio?/maps/map?/offset. The following commits update the uio_mf264 driver to set this new offs field. Drivers for hardware with page-aligned BARs need not to be modified provided that they initialize struct uio_info (which contains uio_mem) with zeros. Signed-off-by: Michal Sojka Signed-off-by: Greg Kroah-Hartman