Commit graph

6 commits

Author SHA1 Message Date
Uwe Kleine-König
4d80d59437 UIO: add generic UIO platform driver
This patch adds a generic UIO platform driver. It eliminates the need for a
dedicated kernel module for simple platform devices. Users only need to
implement their irq handler in platform code and fill a struct uio_info
there. This helps avoiding code duplication as UIO platform drivers often
share a lot of common code.

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Hans J. Koch <hjk@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-07-21 21:54:55 -07:00
Uwe Kleine-König
934da4766e UIO: fix UIO Kconfig dependencies
ae210f1886 introduced a big "if UIO"/"endif"
where all uio drivers are defined.  So know there is no need for them to
depend explicitly on UIO.

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Hans J. Koch <hjk@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-07-21 21:54:53 -07:00
Ben Nizette
b54f2863a2 UIO: Implement a UIO interface for the SMX Cryptengine
This patch implements a UIO interface for the SMX Cryptengine.

The Cryptengine found on the Nias Digital SMX board is best suited
for a UIO interface.  It is not wired in to the cryptographic API
as the engine handles it's own keys, algorithms, everything.  All
that we know about is that if there's room in the buffer, you can
write data to it and when there's data ready, you read it out again.

There isn't necessarily even any direct correlation between data
going in and data coming out again, the engine may consume or
generate data all on its own.

This driver is for proprietary hardware but we're always told to
submit the drivers anyway; here you are.  :-)

This is version 4 of this patch and addresses all issues raised by
Hans-Jürgen Koch and Paul Mundt in their reviews.  Slightly altered
is Paul's suggestion to use DRV_NAME and DRV_VERSION as the UIO
version and name.  While at the moment they are the same, there
is no reason for them to stay that way.  Nevertheless we now at
least provide a MODULE_VERSION macro to keep modinfo happy.

Signed-off-by: Ben Nizette <bn@niasdigital.com>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Hans J Koch <hjk@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-19 19:10:18 -07:00
Denis Cheng
ae210f1886 uio: Kconfig improvements
Signed-off-by: Denis Cheng <crquan@gmail.com>
Signed-off-by: Hans J. Koch <hjk@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-04-19 19:10:17 -07:00
Hans-Jürgen Koch
bc4c4f45ac UIO: Hilscher CIF card driver
this is a patch that adds support for Hilscher CIF DeviceNet and
Profibus cards. I tested it on a Kontron CPX board, and Thomas reviewed
it.

You can find the user space part here:

http://www.osadl.org/projects/downloads/UIO/user/cif-0.1.0.tar.gz

Notes: cif_api.c is the main file you want to look at. It contains the
functions to open, close, mmap and so on. cif_dps.c adds functions
specific to Profibus cards, and cif_dn.c contains functions for
DeviceNet cards.  cif.c is a universal playground, it's just a small
test program.  The user space part of this UIO driver is still work in
progress, and not everything is tested yet. At the moment, the thread in
cif_api.c contains some code that artificially makes the card generate
interrupts, this was added for testing and will be removed later. But
the driver already contains all the functions needed for useful
operation, so it gives a good idea of how such a thing looks like.

For comparison, here's what you get from the manufacturer
(www.hilscher.com) when you ask for a Linux 2.6 driver:

http://www.tglx.de/private/hjk/cif-orig-2.6.tar.bz2

WARNING: Don't look at the code for too long, you might become sick :-)


Signed-off-by: Hans-Jürgen Koch <hjk@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-07-18 15:57:16 -07:00
Hans J. Koch
beafc54c4e UIO: Add the User IO core code
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>
2007-07-18 15:57:15 -07:00