summaryrefslogtreecommitdiff
path: root/include/linux/uio_driver.h
AgeCommit message (Collapse)AuthorFilesLines
2020-11-09uio: fix some kernel-doc markupsMauro Carvalho Chehab1-0/+16
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 <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/82ab7b68d271aeda7396e369ff8a629491b9d628.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18uio: add resource managed devm_uio_register_device() functionAlexandru Ardelean1-0/+9
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 <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200306161853.25368-1-alexandru.ardelean@analog.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18UIO: fix up inapposite whiteplace in uio head fileQiang Su1-12/+12
Whitespace is used in the inapposite place, which makes checkpatch complain. Signed-off-by: Qiang Su <suqiang4@huawei.com> Link: https://lore.kernel.org/r/20200306070359.71398-1-suqiang4@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 305Thomas Gleixner1-2/+1
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 <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Armijn Hemel <armijn@tjaldur.nl> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000433.961827334@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-25uio: introduce UIO_MEM_IOVAStephen Hemminger1-0/+1
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 <sthemmin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-07uio: change to use the mutex lock instead of the spin lockXiubo Li1-1/+1
We are hitting a regression with the following commit: commit a93e7b331568227500186a465fee3c2cb5dffd1f Author: Hamish Martin <hamish.martin@alliedtelesis.co.nz> 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 <mchristi@redhat.com> CC: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Reviewed-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-14uio: Prevent device destruction while fds are openHamish Martin1-1/+3
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 <hamish.martin@alliedtelesis.co.nz> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-08uio: Allow handling of non page-aligned memory regionsMichal Sojka1-5/+8
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 <sojkam1@fel.cvut.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-07uio: support memory sizes larger than 32 bitsCristian Stoica1-1/+1
This is a completion to 27a90700a4275c5178b883b65927affdafa5185c The size field is also increased to allow values larger than 32 bits on platforms that have more than 32 bit physical addresses. Signed-off-by: Cristian Stoica <cristian.stoica@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-03uio: Export definition of struct uio_deviceAndy Grover1-1/+11
In order to prevent a O(n) search of the filesystem to link up its uio node with its target configuration, TCMU needs to know the minor number that UIO assigned. Expose the definition of this struct so TCMU can access this field. Signed-off-by: Andy Grover <agrover@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2011-11-01include: replace linux/module.h with "struct module" wherever possiblePaul Gortmaker1-1/+1
The <linux/module.h> pretty much brings in the kitchen sink along with it, so it should be avoided wherever reasonably possible in terms of being included from other commonly used <linux/something.h> files, as it results in a measureable increase on compile times. The worst culprit was probably device.h since it is used everywhere. This file also had an implicit dependency/usage of mutex.h which was masked by module.h, and is also fixed here at the same time. There are over a dozen other headers that simply declare the struct instead of pulling in the whole file, so follow their lead and simply make it a few more. Most of the implicit dependencies on module.h being present by these headers pulling it in have been now weeded out, so we can finally make this change with hopefully minimal breakage. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-11-01include: convert various register fcns to macros to avoid include chainingPaul Gortmaker1-5/+5
The original implementations reference THIS_MODULE in an inline. We could include <linux/export.h>, but it is better to avoid chaining. Fortunately someone else already thought of this, and made a similar inline into a #define in <linux/device.h> for device_schedule_callback(), [see commit 523ded71de0] so follow that precedent here. Also bubble up any __must_check that were used on the prev. wrapper inline functions up one to the real __register functions, to preserve any prev. sanity checks that were used in those instances. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-18uio: Support physical addresses >32 bits on 32-bit systemsKai Jiang1-2/+5
To support >32-bit physical addresses for UIO_MEM_PHYS type we need to extend the width of 'addr' in struct uio_mem. Numerous platforms like embedded PPC, ARM, and X86 have support for systems with larger physical address than logical. Since 'addr' may contain a physical, logical, or virtual address the easiest solution is to just change the type to 'phys_addr_t' which should always be greater than or equal to the sizeof(void *) such that it can properly hold any of the address types. For physical address we can support up to a 44-bit physical address on a typical 32-bit system as we utilize remap_pfn_range() for the mapping of the memory region and pfn's are represnted by shifting the address by the page size (typically 4k). Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Hans J. Koch <hjk@hansjkoch.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-11-11uio: Change mail address of Hans J. KochHans J. Koch1-1/+1
My old mail address doesn't exist anymore. This changes all occurrences to my new address. Signed-off-by: Hans J. Koch <hjk@hansjkoch.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-10-22uio: Cleanup irq handling.Eric W. Biederman1-1/+1
Change the value of UIO_IRQ_NONE -2 to 0. 0 is well defined in the rest of the kernel as the value to indicate an irq has not been assigned. Update the calls to request_irq and free_irq to only ignore UIO_IRQ_NONE and UIO_IRQ_CUSTOM allowing the rest of the kernel's possible irq numbers to be used. Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Hans J. Koch <hjk@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-03-25UIO: Add name attributes for mappings and port regionsHans J. Koch1-0/+4
If a UIO device has several memory mappings, it can be difficult for userspace to find the right one. The situation becomes even worse if the UIO driver can handle different versions of a card that have different numbers of mappings. Benedikt Spranger has such cards and pointed this out to me. Thanks, Bene! To address this problem, this patch adds "name" sysfs attributes for each mapping. Userspace can use these to clearly identify each mapping. The name string is optional. If a driver doesn't set it, an empty string will be returned, so this patch won't break existing drivers. The same problem exists for port region information, so a "name" attribute is added there, too. Signed-off-by: Hans J. Koch <hjk@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-06uio: make uio_info's name and version constStephen Rothwell1-2/+2
These are only ever assigned constant strings and never modified. This was noticed because Wolfram Sang needed to cast the result of of_get_property() in order to assign it to the name field of a struct uio_info. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Hans J. Koch <hjk@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-06UIO: Pass information about ioports to userspace (V2)Hans J. Koch1-0/+26
Devices sometimes have memory where all or parts of it can not be mapped to userspace. But it might still be possible to access this memory from userspace by other means. An example are PCI cards that advertise not only mappable memory but also ioport ranges. On x86 architectures, these can be accessed with ioperm, iopl, inb, outb, and friends. Mike Frysinger (CCed) reported a similar problem on Blackfin arch where it doesn't seem to be easy to mmap non-cached memory but it can still be accessed from userspace. This patch allows kernel drivers to pass information about such ports to userspace. Similar to the existing mem[] array, it adds a port[] array to struct uio_info. Each port range is described by start, size, and porttype. If a driver fills in at least one such port range, the UIO core will simply pass this information to userspace by creating a new directory "portio" underneath /sys/class/uio/uioN/. Similar to the "mem" directory, it will contain a subdirectory (portX) for each port range given. Note that UIO simply passes this information to userspace, it performs no action whatsoever with this data. It's userspace's responsibility to obtain access to these ports and to solve arch dependent issues. The "porttype" attribute tells userspace what kind of port it is dealing with. This mechanism could also be used to give userspace information about GPIOs related to a device. You frequently find such hardware in embedded devices, so I added a UIO_PORT_GPIO definition. I'm not really sure if this is a good idea since there are other solutions to this problem, but it won't hurt much anyway. Signed-off-by: Hans J. Koch <hjk@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-07-22UIO: minor style and comment fixesUwe Kleine-König1-3/+3
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Signed-off-by: Hans J. Koch <hjk@linutronix.de>
2008-07-22UIO: Add write function to allow irq maskingHans J. Koch1-0/+2
Sometimes it is necessary to enable/disable the interrupt of a UIO device from the userspace part of the driver. With this patch, the UIO kernel driver can implement an "irqcontrol()" function that does this. Userspace can write an s32 value to /dev/uioX (usually 0 or 1 to turn the irq off or on). The UIO core will then call the driver's irqcontrol function. Signed-off-by: Hans J. Koch <hjk@linutronix.de> Acked-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Acked-by: Magnus Damm <damm@igel.co.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-01-25UIO: fix kobject usageGreg Kroah-Hartman1-2/+4
The uio kobject code is "wierd". This patch should hopefully fix it up to be sane and not leak memory anymore. Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Benedikt Spranger <b.spranger@linutronix.de> Signed-off-by: Hans J. Koch <hjk@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-19UIO: Add the User IO core codeHans J. Koch1-0/+91
This interface allows the ability to write the majority of a driver in userspace with only a very small shell of a driver in the kernel itself. It uses a char device and sysfs to interact with a userspace process to process interrupts and control memory accesses. See the docbook documentation for more details on how to use this interface. From: Hans J. Koch <hjk@linutronix.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Benedikt Spranger <b.spranger@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>