Subject: Re: Please review design of Security Engine driver for Au1550
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Shigeyuki Fukushima <shige@netbsd.org>
List: port-evbmips
Date: 03/10/2006 18:51:10
Thank you for your reply.

Garrett D'Amore wrote:
> You're jumping ahead of me now -- I was planning on implementing this
> myself.   :-)  A few considerations:
> 
> 1) This is a SafeNet core.  It might be a good idea to see if we can use
> a common safenet driver and au1550 specific attachment code. 
> (safenet_aubus.c and safenet_pci.c?)

There is already a device entry 'aucrypto' in
sys/arch/mips/alchemy/au1550.c.
Is 'safenet' preferred rather that 'aucrypto'?

> 2) OpenCrypto is definitely the right way to go.

Ok. I think so.

> 3) The RNG code should be a part.  I was going to write the RNG code
> last weekend but got caught up.  The "rnd" framework really needs some
> enhancements so that we can register a callback routine where the rnd
> framework can poll for entropy.  This was the topic of a long discussion
> off-list last week. :-)  I've promised to do this, I just haven't got to
> it yet.

Humm..
A memory map for RNG is in the middle area of Security Engine
memory map.
In my Attachment code, allocating memory map from 0x0000 to 0x07ff.

A plan of implementation an OpenCrypto device and an RNG device of
Au1550 is either plan1 or plan2 (following):

plan 1: split implementation
   opencrypto device:
       allocate two bus_space_map 0x0000-0x00ff and 0x0200-0x07ff
   rng device:
       allocate one bus_space_map 0x0100-0x01ff

plan2: one implementation
   opencrypto & rng device:
       allocate one bus_space_map 0x0000-0x07ff

Which do you like for it?
IMHO, I like plan2-implementation.
-- 
Kind Regards,
--- shige
Shigeyuki Fukushima <shige@{FreeBSD,jp.FreeBSD,NetBSD}.org>