From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753539AbbDXKaF (ORCPT ); Fri, 24 Apr 2015 06:30:05 -0400 Received: from metis.ext.pengutronix.de ([92.198.50.35]:39731 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752840AbbDXKaC convert rfc822-to-8bit (ORCPT ); Fri, 24 Apr 2015 06:30:02 -0400 From: Juergen Borleis Organization: Pengutronix e.K. To: linux-arm-kernel@lists.infradead.org Subject: Re: [rtc-linux] [PATCH 2nd try] RTC/i.MX/DryICE: add recovery routines to the driver Date: Fri, 24 Apr 2015 12:32:30 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) Cc: Alexandre Belloni , kernel@pengutronix.de, Alessandro Zummo , linux-kernel@vger.kernel.org, rtc-linux@googlegroups.com References: <1429002716-19821-1-git-send-email-jbe@pengutronix.de> <20150421232615.GD8539@piout.net> In-Reply-To: <20150421232615.GD8539@piout.net> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <201504241232.30104.jbe@pengutronix.de> X-SA-Exim-Connect-IP: 2001:6f8:1178:4:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: jbe@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alexandre, On Wednesday 22 April 2015 01:26:15 Alexandre Belloni wrote: > On 14/04/2015 at 11:11:51 +0200, Juergen Borleis wrote : > > 2nd try, this time with a cover letter... m( > > > > The built-in RTC unit on some i.MX SoCs isn't an RTC only. It is also a > > tamper monitor unit which can keep some keys. When it does its tamper > > detection job > > Does it have more functions? I would say that it also holds some keys > but I don't have a handy Freescale representative to contact ;) Yes it can hold some keys and will delete them if it detects a security violation via its tamper detection feature. > I'm fine getting that unlocking done in the RTC driver but maybe in the > future, it will be necessary to handle that in an MFD driver when adding > support for the other functions. This change set just makes the RTC work again. Observation was, *sometimes* and *somehow* this unit tends to lock even if no of these tamper detection features were enabled nor the externals signals (to detect these security violations) were used. Regards, Juergen -- Pengutronix e.K.                              | Juergen Borleis             | Industrial Linux Solutions      | http://www.pengutronix.de/ | From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de. [2001:6f8:1178:4:290:27ff:fe1d:cc33]) by gmr-mx.google.com with ESMTPS id bc3si106994wib.2.2015.04.24.03.30.03 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 24 Apr 2015 03:30:04 -0700 (PDT) From: Juergen Borleis To: linux-arm-kernel@lists.infradead.org Subject: Re: [rtc-linux] [PATCH 2nd try] RTC/i.MX/DryICE: add recovery routines to the driver Date: Fri, 24 Apr 2015 12:32:30 +0200 Cc: Alexandre Belloni , kernel@pengutronix.de, Alessandro Zummo , linux-kernel@vger.kernel.org, rtc-linux@googlegroups.com References: <1429002716-19821-1-git-send-email-jbe@pengutronix.de> <20150421232615.GD8539@piout.net> In-Reply-To: <20150421232615.GD8539@piout.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <201504241232.30104.jbe@pengutronix.de> Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Hi Alexandre, On Wednesday 22 April 2015 01:26:15 Alexandre Belloni wrote: > On 14/04/2015 at 11:11:51 +0200, Juergen Borleis wrote : > > 2nd try, this time with a cover letter... m( > > > > The built-in RTC unit on some i.MX SoCs isn't an RTC only. It is also a > > tamper monitor unit which can keep some keys. When it does its tamper > > detection job > > Does it have more functions? I would say that it also holds some keys > but I don't have a handy Freescale representative to contact ;) Yes it can hold some keys and will delete them if it detects a security=20 violation via its tamper detection feature. > I'm fine getting that unlocking done in the RTC driver but maybe in the > future, it will be necessary to handle that in an MFD driver when adding > support for the other functions. This change set just makes the RTC work again. Observation was, *sometimes*= and=20 *somehow* this unit tends to lock even if no of these tamper detection=20 features were enabled nor the externals signals (to detect these security=20 violations) were used. Regards, Juergen =2D-=20 Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| Juergen Borleis =A0 =A0 =A0 =A0 =A0 =A0 | Industrial Linux Solutions =A0 =A0 =A0| http://www.pengutroni= x.de/ | From mboxrd@z Thu Jan 1 00:00:00 1970 From: jbe@pengutronix.de (Juergen Borleis) Date: Fri, 24 Apr 2015 12:32:30 +0200 Subject: [rtc-linux] [PATCH 2nd try] RTC/i.MX/DryICE: add recovery routines to the driver In-Reply-To: <20150421232615.GD8539@piout.net> References: <1429002716-19821-1-git-send-email-jbe@pengutronix.de> <20150421232615.GD8539@piout.net> Message-ID: <201504241232.30104.jbe@pengutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Alexandre, On Wednesday 22 April 2015 01:26:15 Alexandre Belloni wrote: > On 14/04/2015 at 11:11:51 +0200, Juergen Borleis wrote : > > 2nd try, this time with a cover letter... m( > > > > The built-in RTC unit on some i.MX SoCs isn't an RTC only. It is also a > > tamper monitor unit which can keep some keys. When it does its tamper > > detection job > > Does it have more functions? I would say that it also holds some keys > but I don't have a handy Freescale representative to contact ;) Yes it can hold some keys and will delete them if it detects a security violation via its tamper detection feature. > I'm fine getting that unlocking done in the RTC driver but maybe in the > future, it will be necessary to handle that in an MFD driver when adding > support for the other functions. This change set just makes the RTC work again. Observation was, *sometimes* and *somehow* this unit tends to lock even if no of these tamper detection features were enabled nor the externals signals (to detect these security violations) were used. Regards, Juergen -- Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Juergen Borleis ? ? ? ? ? ? | Industrial Linux Solutions ? ? ?| http://www.pengutronix.de/ |