summaryrefslogtreecommitdiff
path: root/include/linux/uio_driver.h
diff options
context:
space:
mode:
authorHans J. Koch <hjk@linutronix.de>2008-12-06 02:23:13 +0100
committerGreg Kroah-Hartman <gregkh@suse.de>2009-01-06 10:44:44 -0800
commite70c412ee45332db2636a8f5a35a0685efb0e4aa (patch)
tree98340f89baa09af04f67f4be5184363c54f2ef2f /include/linux/uio_driver.h
parente543ae896626a54c0c05e3c434312d6d033d450c (diff)
downloadlinux-3.10-e70c412ee45332db2636a8f5a35a0685efb0e4aa.tar.gz
linux-3.10-e70c412ee45332db2636a8f5a35a0685efb0e4aa.tar.bz2
linux-3.10-e70c412ee45332db2636a8f5a35a0685efb0e4aa.zip
UIO: Pass information about ioports to userspace (V2)
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>
Diffstat (limited to 'include/linux/uio_driver.h')
-rw-r--r--include/linux/uio_driver.h26
1 files changed, 26 insertions, 0 deletions
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index cdf338d94b7..20be327bfbb 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -38,6 +38,24 @@ struct uio_mem {
#define MAX_UIO_MAPS 5
+struct uio_portio;
+
+/**
+ * struct uio_port - description of a UIO port region
+ * @start: start of port region
+ * @size: size of port region
+ * @porttype: type of port (see UIO_PORT_* below)
+ * @portio: for use by the UIO core only.
+ */
+struct uio_port {
+ unsigned long start;
+ unsigned long size;
+ int porttype;
+ struct uio_portio *portio;
+};
+
+#define MAX_UIO_PORT_REGIONS 5
+
struct uio_device;
/**
@@ -46,6 +64,7 @@ struct uio_device;
* @name: device name
* @version: device driver version
* @mem: list of mappable memory regions, size==0 for end of list
+ * @port: list of port regions, size==0 for end of list
* @irq: interrupt number or UIO_IRQ_CUSTOM
* @irq_flags: flags for request_irq()
* @priv: optional private data
@@ -60,6 +79,7 @@ struct uio_info {
char *name;
char *version;
struct uio_mem mem[MAX_UIO_MAPS];
+ struct uio_port port[MAX_UIO_PORT_REGIONS];
long irq;
unsigned long irq_flags;
void *priv;
@@ -92,4 +112,10 @@ extern void uio_event_notify(struct uio_info *info);
#define UIO_MEM_LOGICAL 2
#define UIO_MEM_VIRTUAL 3
+/* defines for uio_port->porttype */
+#define UIO_PORT_NONE 0
+#define UIO_PORT_X86 1
+#define UIO_PORT_GPIO 2
+#define UIO_PORT_OTHER 3
+
#endif /* _LINUX_UIO_DRIVER_H_ */