I have a political question, if I have a user space driver, is my kernel

tainted or not? Does this open another multi-month flame war around GPL,

BSD, NDA, source available but not GPL, and all the other things we

talked to death about inserting non-GPL modules?
--

Bill Davidsen <davidsen@tmr.com>

   "We have more to fear from the bungling of the incompetent than from

the machinations of the wicked."  - from Slashdot

-

Surely not. By using the kernel's userspace interface, you create no

"derived work" of the kernel. See COPYING in the root directory of the 
Hopefully not. BTW, all existing UIO userspace drivers I know about

are GPL or LGPL.
Hans
-

That only covers normal system calls - but I don't think thats what is

relevant, taints are for debug assistance not politics.
I think we should have a taint flag for UIO type drivers. Not for any

licensing or political reason but for the simple fact it means that there

may be other complexities to debugging - and not the same one as a binary

module. Probably we want the same marker for mmap /dev/mem too.
Alan

-

I agree, if we make it entirely clear that the flag is nonpolitical. 
	tglx
-

Hm, I don't know, what makes this different from the fact that we can

mmap PCI device space today through the proc and sysfs entries?  That's

how X gets direct access to the hardware for a number of different

cards, and that's pretty much the same thing as the UIO interface is

doing.
Unless you think we should also use the same "taint" flag on those

accesses too, and if so, I have no objection.
thanks,
greg k-h

-

Right, this is just a hint, that something in user space is accessing

the hardware directly. Not a too bad idea, but pretty much useless when

we add X to the picture as it will be set always :)
	tglx
-

Some people -- like me -- use X68_fbcon over vesafb, in order not to

be tainted this way.
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Index: linux-2.6.21-mm_20040728/drivers/char/mem.c

===================================================================

--- linux-2.6.21-mm_20040728.orig/drivers/char/mem.c

+++ linux-2.6.21-mm_20040728/drivers/char/mem.c

@@ -274,6 +274,9 @@ static int mmap_mem(struct file * file,

 	if (!private_mapping_ok(vma))

 		return -ENOSYS;
+	if (strcmp(current->comm, "Xorg") != 0)

+		tainted |= TAINT_USER;

+

 	vma->vm_page_prot = phys_mem_access_prot(file, vma->vm_pgoff,

 						 size,

 						 vma->vm_page_prot);

#<EOF>
Jan

--

-

The X server has many names.  Xorg isn't the name of the server here for

example (its "X"). 
Alan

-

The kernel driver has to be GPL, the user space part can be as any user

space code closed source. Of course we recommend to make it open as

those user space drivers which we did so far are all licensed under

LPGL.
There is nothing to flame, the user space boundary is entirely clear.
	tglx
-

On Fri, 27 Apr 2007 15:49:57 -0700
I'm a bit uncertain about the whole UIO idea, really.  I have this vague

feeling that we'd prefer to encourage people to move device drivers into

GPL'ed kernel rather than encouraging them to do closed-source userspace

implementations which will probably end up being slower, less reliable and

unavailable on various architectures, distros, etc.
But I don't think I have the capacity to actually think about this further
eh?  How come a particular device requires 156 lines of kernel code to

support a userspace driver?  Doesn't that kind of defeat the point?
-

Thanks for tossing it out ;-) I understand your uncertainty and I share your

opinion about encouraging industry developers to GPL their drivers. It really

took me some time until I understood that sometimes there are _good_ reasons

for a closed driver. UIO is not intended for mass products like graphic cards.

We're talking about companies who developed special hardware for use in

special applications like machine control. They sometimes need to keep a

part of their driver closed, at least for some time. Sometimes it's because

they want to protect themselves, sometimes because their customer demands it.

Usually, they know about the disadvantages you mentioned (if they're our

customers, be sure we tell them!).
Anyway, UIO is not just a system to allow closed drivers. There are enough

other reasons why these industry developers want userspace drivers. The most

important one is that they're usually no experienced kernel developers. They

can let somebody write the kernel part for them, and then write their driver

using the tools and libraries they know, with floating point and all that

stuff. It's just convenient. If I had to write a driver for a fieldbus card

today, I'd use UIO. And I'd make it free software. UIO doesn't force anybody 
This is quite a large kernel module for an UIO device due to quite

stupid hardware design. It needs two memory mappings, and the interrupt

handler is not the simplest thing possible. BTW, I don't think that

156 lines is so much. It allows to handle quite a complex PCI card. And

it's so simple that it can be even explained to industry programmers

who are no kernel gurus.
Thanks,

Hans
-

UIO is suprisingly close to chunks of the drm driver so the basic design

seems to have some sanity to it. 
Alan

-

It's not a closed vs. open issue, it just turns out that a lot of people

keep trying to write PCI drivers in userspace (how many different papers

were published on this topic alone in the past year...).  This framework

is to allow this to happen in a sane and correct way.
Lots of different types of odd devices do not fit into the "kernelspace

driver" framework very well for a variety of reasons:

	- zillions of different controls in the card

	- floating point is needed to compute the next step of an

	  operation in moving a physical object
With this framework, we provide a solid and simple way to provide for

these kinds of devices.  The Linutronix guys have had a lot of

experience in supporting this kind of hardware in the past and can

provide better examples if you need.
But yes, it does allow you to write a PCI driver in userspace, being

closed source, if you really want to.  But if you do that, then you get

_no_ advantages of being in the kernel (caching, common userspace

interface, resource management, etc.) and need to handle that all

yourself.  Heck, that's pretty much what X does today for lots of old
No, you still need kernel code to handle the interrupt properly, we do

not want userspace to do this as it would slow the system down and do

all sorts of other bad things.  That's the main problem with all of

those other proposals that people have for trying to do this kind of

work in the past (can't share irqs, can't block on userspace in an

interrupt handler, etc.)
thanks,
greg k-h

-

Right, we don't need another dozen of attempts to get it wrong.
Interestingly enough some talks at ELC were using UIO already for

testing and prototyping and the feedback from these guys was positive on

the technical side and not at all focussed on the ability to do closed
It's not necessarily slower. We were able to optimize an application by

using UIO and we got >20% performance gain, due to the fact that we can

operate on the device directly instead of copying data back and forth

between kernel and userspace for no good reason.
Removing the insane amount of 68 ioctls of the original in kernel

driver, which are just there to flip some bit in the chip registers is

definitely a win.
Having a sane user space driver instead of an eye-cancer causing kernel

driver and a user space library, which needs to hide the ioctl madness

away from the application programmer reduced the overall code size from
5264 lines of kernel code + 3275 lines of user space code
to 
UIO is not targeted on devices which are part of a kernel subsystem, it

is targeted for self contained special devices, which have currently

tons of out of tree drivers with an average quality of 0. Those devices

do not fit in the in kernel driver landscape at all and we really should
Right, you can do closed source drivers and I prefer when people use

this interface instead of fiddling with faked licenses and creating

legal bordercases. 
All drivers we did so far have LGPL user space counterparts and that's

the preferred way to go.
Also we have the user space driver support for USB already and I have
Ack.
	tglx
-

From: Hans J. Koch <hjk@linutronix.de>
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>

---

 drivers/Kconfig            |    1 +

 drivers/Makefile           |    1 +

 drivers/uio/Kconfig        |   14 +

 drivers/uio/Makefile       |    1 +

 drivers/uio/uio.c          |  702 ++++++++++++++++++++++++++++++++++++++++++++

 include/linux/uio_driver.h |   91 ++++++

 6 files changed, 810 insertions(+), 0 deletions(-)

 create mode 100644 drivers/uio/Kconfig

 create mode 100644 drivers/uio/Makefile

 create mode 100644 drivers/uio/uio.c

 create mode 100644 include/linux/uio_driver.h
diff --git a/drivers/Kconfig b/drivers/Kconfig

index 050323f..325a108 100644

--- a/drivers/Kconfig

+++ b/drivers/Kconfig

@@ -84,4 +84,5 @@ source "drivers/auxdisplay/Kconfig"
 source "drivers/kvm/Kconfig"
+source "drivers/uio/Kconfig"

 endmenu

diff --git a/drivers/Makefile b/drivers/Makefile

index 920c975..5cf267f 100644

--- a/drivers/Makefile

+++ b/drivers/Makefile

@@ -37,6 +37,7 @@ obj-$(CONFIG_SCSI)		+= scsi/

 obj-$(CONFIG_ATA)		+= ata/

 obj-$(CONFIG_FUSION)		+= message/

 obj-$(CONFIG_IEEE1394)		+= ieee1394/

+obj-$(CONFIG_UIO)		+= uio/

 obj-y				+= cdrom/

 obj-y				+= auxdisplay/

 obj-$(CONFIG_MTD)		+= mtd/

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig

new file mode 100644

index 0000000..8fcef21

--- /dev/null

+++ b/drivers/uio/Kconfig

@@ -0,0 +1,14 @@

+menu "Userspace I/O"

+config UIO

+	tristate "Userspace I/O drivers"

+	default n

+	help

+	  Enable this to allow the userspa...
[ message continues ]

AFAIK we don't currently have any platform that runs binaries with

different sizes of "int" but this is a) an unsigned value anyway, and b)

should be a fixed type (eg u32)
Otherwise it looks ok at the momenmt, although there is a real nasty

waiting for anyone who tries to use it. At the point open is possible or

IRQs can be enabled you are safe in the core merged as idev->info is

always valid, but any driver module trying to go back via info->uio_dev

has a NULL pointer for an early IRQ or open event.
This means that the fasync support in the current code is basically

unusable until this is fixed
Alan

-

I reviewed the code once more and find it OK. There is only one legal

value for the parameter "count" of uio_read(), and that's sizeof(int).

The data that is actually read is the element "event" of struct uio_device,

which is of type atomic_t. The latter has the size of an int.
Unfortunately, the fact that the read count _must_ be sizeof(int) is not
This patch should fix it:
Index: linux-2.6.22-rc/drivers/uio/uio.c

===================================================================

--- linux-2.6.22-rc.orig/drivers/uio/uio.c	2007-04-28 20:01:02.000000000 +0200

+++ linux-2.6.22-rc/drivers/uio/uio.c	2007-04-28 20:15:00.000000000 +0200

@@ -633,6 +633,8 @@

 	if (ret)

 		goto err_uio_dev_add_attributes;
+	info->uio_dev = idev;

+

 	if (idev->info->irq >= 0) {

 		ret = request_irq(idev->info->irq, uio_interrupt,

 				  idev->info->irq_flags, idev->info->name, idev);

@@ -640,7 +642,6 @@

 			goto err_request_irq;

 	}
-	info->uio_dev = idev;

 	return 0;
 err_request_irq:
Thanks for your review,

Hans
-

If you are a box with multiple supported binary types how big is an

"int". We use explicit sizes to ensure that uio_read() will work when/if

we get platforms which support binaries with differing ideas of the size
The latter is the size of a kernel "int".
Other patch looks fine.

-

Here's a fix to that effect:
Index: linux-2.6.22-rc/drivers/uio/uio.c

===================================================================

--- linux-2.6.22-rc.orig/drivers/uio/uio.c	2007-04-28 22:46:34.000000000 +0200

+++ linux-2.6.22-rc/drivers/uio/uio.c	2007-04-28 22:59:40.000000000 +0200

@@ -264,7 +264,7 @@
 struct uio_listener {

 	struct uio_device *dev;

-	int event_count;

+	s32 event_count;

 };
 static int uio_open(struct inode *inode, struct file *filep)

@@ -345,12 +345,12 @@

 	struct uio_device *idev = listener->dev;

 	DECLARE_WAITQUEUE(wait, current);

 	ssize_t retval;

-	int event_count;

+	s32 event_count;
 	if (idev->info->irq == UIO_IRQ_NONE)

 		return -EIO;
-	if (count != sizeof(int))

+	if (count != sizeof(s32))

 		return -EINVAL;
 	add_wait_queue(&idev->wait, &wait);
Thanks,

Hans

-

Can you please add a matching paragraph to the documentation ?
	tglx
-

Yes, I'll add a "How to write userspace code" section tomorrow. I'll send a

patch as soon as it's ready.
Hans
-

Here's the promised update for the documentation:
Hans
Index: linux-2.6.22-rc/Documentation/DocBook/uio-howto.tmpl

===================================================================

--- linux-2.6.22-rc.orig/Documentation/DocBook/uio-howto.tmpl	2007-04-29 22:17:45.000000000 +0200

+++ linux-2.6.22-rc/Documentation/DocBook/uio-howto.tmpl	2007-04-30 00:15:38.000000000 +0200

@@ -30,6 +30,12 @@
 <revhistory>

 	<revision>

+	<revnumber>0.3</revnumber>

+	<date>2007-04-29</date>

+	<authorinitials>hjk</authorinitials>

+	<revremark>Added section about userspace drivers.</revremark>

+	</revision>

+	<revision>

 	<revnumber>0.2</revnumber>

 	<date>2007-02-13</date>

 	<authorinitials>hjk</authorinitials>

@@ -484,14 +490,121 @@
 </sect1>
+<sect1 id="userspace_driver" xreflabel="Writing a driver in user space">

+<?dbhtml filename="userspace_driver.html"?>

+<title>Writing a driver in userspace</title>

+	<para>

+	Once you have a working kernel module for your hardware, you can

+	write the userspace part of your driver. You don't need any special

+	libraries, your driver can be written in any reasonable language,

+	you can use floating point numbers and so on. In short, you can

+	use all the tools and libraries you'd normally use for writing a

+	userspace application.

+	</para>

+

+<sect2 id="getting_uio_information">

+<title>Getting information about your UIO device</title>

+	<para>

+	Information about all UIO devices is available in sysfs. The

+	first thing you should do in your driver is check

+	<varname>name</varname> and <varname>version</varname> to

+	make sure your talking to the right device and that its kernel

+	driver has the version you expect.

+	</para>

+	<para>

+	You should also make sure that the memory mapping you need

+	exists and has the size you expec...
[ message continues ]

Well, it is kind of academic, as probably half of the user space

interfaces will explode, but in theory you are right.
Hans, let's change it to u32 to get this out of the way.
	tglx
-

We'll fix that ASAP.
	tglx
-

From: Hans J. Koch <hjk@linutronix.de>
Documentation for the UIO interface
From: Hans J. Koch <hjk@linutronix.de>

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---

 Documentation/DocBook/kernel-api.tmpl |    4 +

 Documentation/DocBook/uio-howto.tmpl  |  498 +++++++++++++++++++++++++++++++++

 2 files changed, 502 insertions(+), 0 deletions(-)

 create mode 100644 Documentation/DocBook/uio-howto.tmpl
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl

index 0bb9023..40e968d 100644

--- a/Documentation/DocBook/kernel-api.tmpl

+++ b/Documentation/DocBook/kernel-api.tmpl

@@ -396,6 +396,10 @@ X!Edrivers/pnp/system.c

 !Edrivers/pnp/manager.c

 !Edrivers/pnp/support.c

      </sect1>

+     <sect1><title>Userspace IO devices</title>

+!Edrivers/uio/uio.c

+!Iinclude/linux/uio_driver.h

+     </sect1>

   </chapter>
   <chapter id="blkdev">

diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl

new file mode 100644

index 0000000..bd2209f

--- /dev/null

+++ b/Documentation/DocBook/uio-howto.tmpl

@@ -0,0 +1,498 @@

+<?xml version="1.0" encoding="UTF-8"?>

+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"

+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">

+

+<article id="index">

+<articleinfo>

+<title>The Userspace I/O HOWTO</title>

+

+<author>

+      <firstname>Hans-J

Most of this reads well.  Thanks.

A few typo corrections are below...
But it doesn't build for me with 'make htmldocs'.

Did you test it?
Warning(/tester/linsrc/linux-2.6.21-rc7-mm2//drivers/uio/uio.c:240): No description found for parameter 'info'

Warning(/tester/linsrc/linux-2.6.21-rc7-mm2//drivers/uio/uio.c:594): No description found for parameter 'owner'

Warning(/tester/linsrc/linux-2.6.21-rc7-mm2//drivers/uio/uio.c:594): No description found for parameter 'info'

Warning(/tester/linsrc/linux-2.6.21-rc7-mm2//drivers/uio/uio.c:667): No description found for parameter 'info'

Error(/tester/linsrc/linux-2.6.21-rc7-mm2//include/linux/uio_driver.h:29): cannot understand prototype: 'struct uio_mem '

Error(/tester/linsrc/linux-2.6.21-rc7-mm2//include/linux/uio_driver.h:55): cannot understand prototype: 'struct uio_info '

Warning(/tester/linsrc/linux-2.6.21-rc7-mm2//include/linux/uio_driver.h): no structured comments found
Patch below for all of is these (including typos).
However, it still fails 'make htmldocs' for me.

What am I missing?  How did it work for you?

My DTD doesn't like to see <varname> inside a <listitem>:
linux-2.6.21-rc7-mm2/Documentation/DocBook/uio-howto.xml:333: element listitem: validity error : Element listitem content does not follow the DTD, expecting (calloutlist | glosslist | itemizedlist | orderedlist | segmentedlist | simplelist | variablelist | caution | important | note | tip | warning | literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | para | simpara | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | equation | example | figure | table | msgset | procedure | sidebar | qandaset | anchor | bridgehead | remark | highlights | abstract | authorblurb | epigraph | indexterm | beginpa...
[ message continues ]

Thank you for your work. I generated a new patch that includes all your

suggestions and also fixes the build problems.
Yes, this only occurs when the <listitem> content is not surrounded by

<para></para>. I fixed that. I also changed the whole thing from

"article" to "book" as all the other *.tmpl files are books. 
Here I also replaced ioremap_nocache() by ioremap(). I just fixed that in

uio_cif.c and don't want to encourage other people to write the same nonsense.
Here's my patch, as I said, it should include your fixes as well:
Index: linux-2.6.22-rc/drivers/uio/uio.c

===================================================================

--- linux-2.6.22-rc.orig/drivers/uio/uio.c	2007-05-02 08:32:19.000000000 +0200

+++ linux-2.6.22-rc/drivers/uio/uio.c	2007-05-02 09:10:40.000000000 +0200

@@ -234,7 +234,7 @@
 /**

  * uio_event_notify - trigger an interrupt event

- * @idev: UIO device where the event occured

+ * @info: UIO device capabilities

  */

 void uio_event_notify(struct uio_info *info)

 {

@@ -583,8 +583,9 @@

 /**

  * uio_register_device - register a new userspace IO device

  *

+ * @owner:	module that creates the new device

  * @parent:	parent device

- * @idev:	device capabilities

+ * @info:	UIO device capabilities

  *

  * returns zero on success or a negative error code.

  */

@@ -660,9 +661,8 @@
 /**

  * uio_unregister_device - unregister a industrial IO device

- * @uiodev:	UIO device driver identifier

+ * @info:	UIO device capabilities

  *

- * returns 0 on success

  */

 void uio_unregister_device(struct uio_info *info)

 {

Index: linux-2.6.22-rc/include/linux/uio_driver.h

===================================================================

--- linux-2.6.22-rc.orig/include/linux/uio_driver.h	2007-05-02 08:24:38.000000000 +0200

+++ linux-2.6.22-rc/include/linux/uio_driver.h	2007-05-02 08:42:42.000000000 +0200

@@ -19,7 +19,7 @@

 #include <linux/interrupt.h>
 /**

- * uio_mem - description of a UIO memory region

+ * ...
[ message continues ]

Hi,
---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

The patch goes on top of Greg's original patch plus the one I recently

sent (adding the chapter about the userspace driver part).

If you haven't got it handy, I mean this one:
http://marc.info/?l=linux-kernel&m=117788526325956&w=2
Thanks,

Hans
-

OK, your fixes all look good, but still needs one minor fix (below).
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
---
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix last UIO kernel-doc problem.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>

---

 drivers/uio/uio.c |    1 -

 1 file changed, 1 deletion(-)
--- linux-2.6.21-git4.orig/drivers/uio/uio.c

+++ linux-2.6.21-git4/drivers/uio/uio.c

@@ -582,7 +582,6 @@ static void uio_class_destroy(void)
 /**

  * uio_register_device - register a new userspace IO device

- *

  * @owner:	module that creates the new device

  * @parent:	parent device

  * @info:	UIO device capabilities

-

Hm, I have about 3 different patches here now, all dependant on each

other, yet I can't tell which goes first :(
Can someone just send me 1, or 3 with the correct order in which to

apply them?
thanks,
greg k-h

-

Hi Greg,

I attached all the UIO patches I collected so far. This is my series file:
uio.patch

fix-early-irq-problem-in-uio.patch

uio-documentation.patch

fix-uio_read-type-problem.patch

uio-dummy.patch

uio-hilscher-cif-card-driver.patch

ioremap-in-uio-hilscher-cif.patch

add-userspace-howto-to-uio-doc.patch

fix-uio-doc-build-problems.patch
It should also work without uio-dummy.patch.

I added Randy's last one-line patch to fix-uio-doc-build-problems.patch.
All patches are

Signed-off-by: Hans J. Koch <hjk@linutronix.de>
fix-uio-doc-build-problems.patch is also

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks,

Hans

I also updated the original patch set with all these changes. They can be

found here:
http://www.osadl.org/projects/downloads/UIO/kernel/
Thanks,

Hans

-

Can one of you make sure that Andrew has a version in -mm that

will build without bombing?  Current 2.6.21-mm1 does this on UIO docs,

but all of these have been fixed via email AFAIK:
Warning(/tester/linsrc/linux-2621-mm1//drivers/uio/uio.c:240): No description found for parameter 'info'

Warning(/tester/linsrc/linux-2621-mm1//drivers/uio/uio.c:594): No description found for parameter 'owner'

Warning(/tester/linsrc/linux-2621-mm1//drivers/uio/uio.c:594): No description found for parameter 'info'

Warning(/tester/linsrc/linux-2621-mm1//drivers/uio/uio.c:667): No description found for parameter 'info'

Error(/tester/linsrc/linux-2621-mm1//include/linux/uio_driver.h:29): cannot understand prototype: 'struct uio_mem '

Error(/tester/linsrc/linux-2621-mm1//include/linux/uio_driver.h:55): cannot understand prototype: 'struct uio_info '

Warning(/tester/linsrc/linux-2621-mm1//include/linux/uio_driver.h): no structured comments found

make[1]: *** [Documentation/DocBook/kernel-api.xml] Error 2

make: *** [mandocs] Error 2
---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

Andrew usually takes Greg's patches AFAIK. The patches in

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/...
Yes, all of these are fixed in the patches I sent.
Thanks,

Hans
-

From: Hans-J

Alan Cox pointed out (offlist) that ioremap_nocache() is unneccessary here.

This patch replaces it with ioremap():
Thanks, Alan!
hjk
Index: linux-2.6.22-rc/drivers/uio/uio_cif.c

===================================================================

--- linux-2.6.22-rc.orig/drivers/uio/uio_cif.c	2007-04-29 21:34:45.000000000 +0200

+++ linux-2.6.22-rc/drivers/uio/uio_cif.c	2007-04-29 21:36:31.000000000 +0200

@@ -64,9 +64,8 @@

 	info->mem[0].addr = pci_resource_start(dev, 0);

 	if (!info->mem[0].addr)

 		goto out_release;

-	info->mem[0].internal_addr = ioremap_nocache(

-						pci_resource_start(dev, 0),

-						pci_resource_len(dev, 0) );

+	info->mem[0].internal_addr = ioremap(pci_resource_start(dev, 0),

+					     pci_resource_len(dev, 0) );

 	if (!info->mem[0].internal_addr)

 		goto out_release;
-