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
next prev parent 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).