linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jbe@pengutronix.de (Juergen Borleis)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/5] RTC/i.MX/DryIce: add some background info about the states the machine can be in
Date: Tue, 14 Apr 2015 11:11:52 +0200	[thread overview]
Message-ID: <1429002716-19821-2-git-send-email-jbe@pengutronix.de> (raw)
In-Reply-To: <1429002716-19821-1-git-send-email-jbe@pengutronix.de>

Signed-off-by: Juergen Borleis <jbe@pengutronix.de>
Signed-off-by: Robert Schwebel <rsc@pengutronix.de>
[rsc: got NDA clearance from Freescale]
---
 drivers/rtc/rtc-imxdi.c | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index c666eab..8750477 100644
--- a/drivers/rtc/rtc-imxdi.c
+++ b/drivers/rtc/rtc-imxdi.c
@@ -129,6 +129,49 @@ struct imxdi_dev {
 	struct work_struct work;
 };
 
+/* Some background:
+ *
+ * The DryIce unit is a complex security/tamper monitor device. To be able do
+ * its job in a useful manner it runs a bigger statemachine to bring it into
+ * security/tamper failure state and once again to bring it out of this state.
+ *
+ * This unit can be in one of three states:
+ *
+ * - "NON-VALID STATE"
+ *   always after the battery power was removed
+ * - "FAILURE STATE"
+ *   if one of the enabled security events have happend
+ * - "VALID STATE"
+ *   if the unit works as expected
+ *
+ * Everything stops when the unit enters the failure state including the RTC
+ * counter (to be able to detect the time the security event happend).
+ *
+ * The following events (when enabled) let the DryIce unit enter the failure
+ * state:
+ *
+ * - wire-mesh-tamper detect
+ * - external tamper B detect
+ * - external tamper A detect
+ * - temperature tamper detect
+ * - clock tamper detect
+ * - voltage tamper detect
+ * - RTC counter overflow
+ * - monotonic counter overflow
+ * - external boot
+ *
+ * If we find the DryIce unit in "FAILURE STATE" and the TDCHL cleared, we
+ * can only detect this state. In this case the unit is completely locked and
+ * must force a second "SYSTEM POR" to bring the DryIce into the
+ * "NON-VALID STATE" + "FAILURE STATE" where a recovery is possible.
+ * If the TDCHL is set in the "FAILURE STATE" we are out of luck. In this case
+ * a battery power cycle is required.
+ *
+ * In the "NON-VALID STATE" + "FAILURE STATE" we can clear the "FAILURE STATE"
+ * and recover the DryIce unit. By clearing the "NON-VALID STATE" as the last
+ * task, we bring back this unit into life.
+ */
+
 /*
  * enable a dryice interrupt
  */
-- 
2.1.4

  reply	other threads:[~2015-04-14  9:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14  9:11 [PATCH 2nd try] RTC/i.MX/DryICE: add recovery routines to the driver Juergen Borleis
2015-04-14  9:11 ` Juergen Borleis [this message]
2015-04-21 22:09   ` [rtc-linux] [PATCH 1/5] RTC/i.MX/DryIce: add some background info about the states the machine can be in Alexandre Belloni
2015-04-24 10:10     ` Juergen Borleis
2015-04-14  9:11 ` [PATCH 2/5] RTC/i.MX/DryIce: add the unit recovery code Juergen Borleis
2015-04-21 23:14   ` [rtc-linux] " Alexandre Belloni
2015-04-21 23:46     ` Alexandre Belloni
2015-04-24 10:24     ` Juergen Borleis
2015-04-14  9:11 ` [PATCH 3/5] RTC/i.MX/DryIce: monitor a security violation at runtime Juergen Borleis
2015-04-14  9:11 ` [PATCH 4/5] RTC/i.MX/DryIce: when locked, do not fail silently Juergen Borleis
2015-04-21 23:30   ` [rtc-linux] " Alexandre Belloni
2015-04-14  9:11 ` [PATCH 5/5] RTC/i.MX/DryIce: prepare to force a security violation Juergen Borleis
2015-04-21 23:26 ` [rtc-linux] [PATCH 2nd try] RTC/i.MX/DryICE: add recovery routines to the driver Alexandre Belloni
2015-04-24 10:32   ` Juergen Borleis
  -- strict thread matches above, loose matches on Subject: below --
2015-04-14  9:08 [PATCH 1/5] RTC/i.MX/DryIce: add some background info about the states the machine can be in Juergen Borleis
2015-04-14  9:38 ` Juergen Borleis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1429002716-19821-2-git-send-email-jbe@pengutronix.de \
    --to=jbe@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).