From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S965327AbcHaRFB (ORCPT <rfc822;w@1wt.eu>);
        Wed, 31 Aug 2016 13:05:01 -0400
Received: from down.free-electrons.com ([37.187.137.238]:42835 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org
        with ESMTP id S965120AbcHaRFA (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 31 Aug 2016 13:05:00 -0400
Date: Wed, 31 Aug 2016 19:04:56 +0200
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        Boris Brezillon <boris.brezillon@free-electrons.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Subject: Re: [PATCH 5/5] misc: sram: add Atmel securam support
Message-ID: <20160831170456.c7rm3h7kpqor5evg@piout.net>
References: <20160831161108.8780-1-alexandre.belloni@free-electrons.com>
 <20160831161108.8780-6-alexandre.belloni@free-electrons.com>
 <1472661937.9330.8.camel@pengutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1472661937.9330.8.camel@pengutronix.de>
User-Agent: Mutt/1.6.2-neo (2016-07-23)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 31/08/2016 at 18:45:37 +0200, Philipp Zabel wrote :
> Hi Alexandre,
> 
> Am Mittwoch, den 31.08.2016, 18:11 +0200 schrieb Alexandre Belloni:
> > The Atmel secure SRAM is connected to a security module and may be erased
> > automatically under certain conditions. For that reason, it is necessary to
> > wait for the security module to flag that SRAM accesses are allowed before
> > accessing it.
> > 
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > ---
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Philipp Zabel <p.zabel@pengutronix.de>
> > Cc: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> >  drivers/misc/sram.c | 52 +++++++++++++++++++++++++++++++++++++++++++++-------
> >  1 file changed, 45 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> > index f84b53d6ce50..8d411c64d07f 100644
> > --- a/drivers/misc/sram.c
> > +++ b/drivers/misc/sram.c
> > @@ -19,12 +19,16 @@
> >   */
> >  
> >  #include <linux/clk.h>
> > +#include <linux/delay.h>
> >  #include <linux/genalloc.h>
> >  #include <linux/io.h>
> >  #include <linux/list_sort.h>
> >  #include <linux/of_address.h>
> >  #include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> >  #include <linux/slab.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <soc/at91/atmel-secumod.h>
> >  
> >  #define SRAM_GRANULARITY	32
> >  
> > @@ -334,12 +338,43 @@ static int sram_reserve_regions(struct sram_dev *sram, struct resource *res)
> >  	return ret;
> >  }
> >  
> > +static int atmel_securam_wait(void)
> > +{
> > +	struct regmap *regmap;
> > +	unsigned long timeout = jiffies + HZ;
> 
> Can this really take up to a second?
> 

Well, probably not but it can take some time. My understanding is that
it can take up to almost half a second (4096 bytes at 8kHz). But quite
frankly, by the time linux is starting, the delay has probably already
expired so the while loop is unlikely to run.

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