linux-toradex.git/include/linux/uio_driver.h, branch v4.11-rc3

uio: support memory sizes larger than 32 bits

2014-11-07T18:09:07+00:00

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 
Signed-off-by: Greg Kroah-Hartman

uio: Export definition of struct uio_device

2014-10-03T04:35:54+00:00

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 
Signed-off-by: Nicholas Bellinger

include: replace linux/module.h with "struct module" wherever possible

2011-10-31T23:32:32+00:00

The  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 
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

include: convert various register fcns to macros to avoid include chaining

2011-10-31T23:32:32+00:00

The original implementations reference THIS_MODULE in an inline.
We could include , but it is better to avoid chaining.

Fortunately someone else already thought of this, and made a similar
inline into a #define in  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

uio: Support physical addresses >32 bits on 32-bit systems

2011-10-18T18:18:57+00:00

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 
Signed-off-by: Minghuan Lian 
Signed-off-by: Kumar Gala 
Signed-off-by: Hans J. Koch 
Signed-off-by: Greg Kroah-Hartman

uio: Change mail address of Hans J. Koch

2010-11-11T00:57:11+00:00

My old mail address doesn't exist anymore. This changes all occurrences
to my new address.

Signed-off-by: Hans J. Koch 
Signed-off-by: Greg Kroah-Hartman

uio: Cleanup irq handling.

2010-10-22T17:16:43+00:00

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 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Hans J. Koch 
Signed-off-by: Greg Kroah-Hartman

UIO: Add name attributes for mappings and port regions

2009-03-24T23:38:24+00:00

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 
Signed-off-by: Greg Kroah-Hartman

uio: make uio_info's name and version const

2009-01-06T18:44:44+00:00

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 
Signed-off-by: Hans J. Koch 
Signed-off-by: Greg Kroah-Hartman

UIO: Pass information about ioports to userspace (V2)

2009-01-06T18:44:44+00:00

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 
Signed-off-by: Greg Kroah-Hartman