[PATCH] misc: atmel-secumod: Driver for Atmel "security module".

[alexandre.belloni@free-electrons.com (Alexandre Belloni)]

On 29/01/2016 at 11:13:05 +1100, Finn Thain wrote :
> 
> On Mon, 25 Jan 2016, David Mosberger wrote:
> 
> > On Mon, Jan 25, 2016 at 4:09 AM, Alexandre Belloni 
> > <alexandre.belloni@free-electrons.com> wrote:
> > 
> > > I know this does more than that but I think those thre sections should 
> > > be registered using the nvmem framework. The sysfs file creation and 
> > > accesses then comes for free.
> > 
> > I think Finn's patches would have to go in for that first, since the 
> > existing nvram code is a mess. Even with Finn's patches in, I think it 
> > could go either way.
> 
> I think Alexandre is speaking of the nvmem subsystem (not nvram).
> Documentation/devicetree/bindings/nvmem
> Documentation/nvmem
> drivers/nvmem
> 

absolutely.

> > I'm not exactly sure how some of the features of the security module 
> > would be used: key management, auto erasing, there is a strange "backup 
> > mode" vs "normal mode" which is not well documented, etc.  So I think it 
> > may well end up being sufficiently different to warrant a separate 
> > driver.
> 
> nvmem is not a subsystem I am familiar with, so it's not immediately clear 
> to me what your driver would look like if re-written that way.
> 
> Maybe it would become simpler. But if you did end up needing a separate 
> misc driver as well, maybe use of the nvmem framework would actually 
> increase complexity.
> 
> It would depend on your requirements. But I would focus on the actual 
> requirement rather than uncertain future possibilities.
> 
> > 
> > > Another idea is also to expose it using a genpool so it can be 
> > > accessed as sram from inside the kernel.
> > 
> > That may be a fine idea, but as far as our application is concerned, we 
> > need user-level access to the battery-backed RAM.
> 
> Right. I don't see how adding a memory allocator would help either.
> 

While the immediate need is to use that sram from userspace, I think
this is valuable to already think that at some point we will need to be
able to partition and access that sram from the kernel.



-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com