reset-cause: define new pinhole reset gpio
The pinhole reset cause will be utilized by BMC firmware to know
when it has been reset due to a user initiated pinhole reset. This
is commonly done in error scenarios where the BMC is hanging or
otherwise unresponsive.
Initially I put this under the Buttons section but as it's really more
of a reason that a pinhole reset has occurred, I went with a new
section. The BMC is not involved with the actual pinhole reset hardware
because the whole purpose of it is to trigger a BMC reset when the BMC
is unresponsive.
The design doc on this function is at:
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/47816
Change-Id: I9fb4e5909a279dc588815bb13ff1550c70f867ab
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
diff --git a/designs/device-tree-gpio-naming.md b/designs/device-tree-gpio-naming.md
index 5c78a4d..9c09058 100644
--- a/designs/device-tree-gpio-naming.md
+++ b/designs/device-tree-gpio-naming.md
@@ -96,6 +96,23 @@
#### presence-ps0, presence-ps1, ..., presence-ps\<N>
+### Reset Cause
+These are GPIOs that provide more detail on the reason for a BMC reset. BMC
+hardware generally provides some information on a BMC reboot, like a EXTRST
+(i.e. a BMC reset was reset by some external source). At times though,
+firmware needs more details on the cause of a reset. Hardware can be configured
+to latch an event into a GPIO for firmware to then utilize for different
+software logic.
+
+Pattern: `reset-cause-*`
+
+#### reset-cause-pinhole
+The pinhole reset cause will be utilized by BMC firmware to know when it
+has been reset due to a user initiated pinhole reset. This is commonly done in
+error scenarios where the BMC is hanging or otherwise unresponsive. Note that
+this GPIO is not utilized to cause the actual reset, it is a GPIO that can be
+read after the BMC reset to know the reason for the reboot was a pinhole reset.
+
### Secure Boot
#### bmc-secure-boot