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 2 of this patch and addresses all issues raised by
Hans-Jürgen Koch and Paul Mundt in their reviews.

Signed-off-by: Ben Nizette <bn@niasdigital.com>
---
Apologies for the confusion around this patch, I didn't mean to give the
impression that I'd ignored Paul; I am of course grateful for his review
and bug catch.  I received the review just a minute after sending out
the last version, made the change locally but didn't immediately resend.
I'll know better next time.

diff --git a/MAINTAINERS b/MAINTAINERS
index 2cdb591..480fd44 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3554,6 +3554,11 @@ M:	mhoffman@lightlink.com
 L:	lm-sensors@lm-sensors.org
 S:	Maintained
 
+SMX UIO Interface
+P:	Ben Nizette
+M:	bn@niasdigital.com
+S:	Maintained
+
 SOFTMAC LAYER (IEEE 802.11)
 P:	Daniel Drake
 M:	dsd@gentoo.org
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index b778ed7..f57b347 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -26,4 +26,16 @@ config UIO_CIF
 	  To compile this driver as a module, choose M here: the module
 	  will be called uio_cif.
 
+config UIO_SMX
+	tristate "SMX cryptengine UIO interface"
+	depends on UIO
+	default n
+	help
+	  Userspace IO interface to the Cryptography engine found on the
+	  Nias Digital SMX boards.  These will be available from Q4 ...
[ message continues ]

You may as well use DRV_NAME and DRV_VERSION, then you can toss that over
to MODULE_VERSION() if you're so inclined. It's generally nice to keep
platform_get_irq() can fail, which you don't presently handle (though I
guess uio_register_device() will error out if you hand off -ENXIO as your
IRQ anyways, so it's not technically an issue). That's a pretty minor
issue, though, but might be something you wish to fix up if you are
Your error paths are also pretty quiet. A dev_err() or so in the few
failure cases you do have might not be a terrible idea.

uio_register_device() also has quite a few different error cases, so it's
at least worth preserving the error value and returning that back,
rather than always returning -ENODEV.
--

[ message continues ]

Am Thu, 13 Mar 2008 19:06:55 +0900

UIO name and version are intentionally independent of module name and
version. It's meant to be an information for the userspace part of the driver

uio_register_device() will silently not register an interrupt if the number
is negative. This allows us to register a driver without interrupts. Hmm.
Maybe we should explicitly check for UIO_IRQ_NONE there and fail if a
different negative irq is passed in. Thanks for pointing this out.



Right. Maybe we should make uio_register_device a bit more verbose, too.

Thanks for your detailed review!

Hans
--

[ message continues ]

Am Thu, 13 Mar 2008 20:35:40 +1100
schrieb Ben Nizette <bn@niasdigital.com>:

Ben,
sorry, but your code doesn't compile. See below.

Thanks,

--

[ message continues ]