+/* Minimum space we guarantee in the state FDT when calling read/write*/
+#define SANDBOX_STATE_MIN_SPACE 0x1000
+
+/**
+ * struct sandbox_state_io - methods to saved/restore sandbox state
+ * @name: Name of of the device tree node, also the name of the variable
+ * holding this data so it should be an identifier (use underscore
+ * instead of minus)
+ * @compat: Compatible string for the node containing this state
+ *
+ * @read: Function to read state from FDT
+ * If data is available, then blob and node will provide access to it. If
+ * not (blob == NULL and node == -1) this function should set up an empty
+ * data set for start-of-day.
+ * @param blob: Pointer to device tree blob, or NULL if no data to read
+ * @param node: Node offset to read from
+ * @return 0 if OK, -ve on error
+ *
+ * @write: Function to write state to FDT
+ * The caller will ensure that there is a node ready for the state. The
+ * node may already contain the old state, in which case it should be
+ * overridden. There is guaranteed to be SANDBOX_STATE_MIN_SPACE bytes
+ * of free space, so error checking is not required for fdt_setprop...()
+ * calls which add up to less than this much space.
+ *
+ * For adding larger properties, use state_setprop().
+ *
+ * @param blob: Device tree blob holding state
+ * @param node: Node to write our state into
+ *
+ * Note that it is possible to save data as large blobs or as individual
+ * hierarchical properties. However, unless you intend to keep state files
+ * around for a long time and be able to run an old state file on a new
+ * sandbox, it might not be worth using individual properties for everything.
+ * This is certainly supported, it is just a matter of the effort you wish
+ * to put into the state read/write feature.
+ */
+struct sandbox_state_io {
+ const char *name;
+ const char *compat;
+ int (*write)(void *blob, int node);
+ int (*read)(const void *blob, int node);
+};
+
+/**
+ * SANDBOX_STATE_IO - Declare sandbox state to read/write
+ *
+ * Sandbox permits saving state from one run and restoring it in another. This
+ * allows the test system to retain state between runs and thus better
+ * emulate a real system. Examples of state that might be useful to save are
+ * the emulated GPIOs pin settings, flash memory contents and TPM private
+ * data. U-Boot memory contents is dealth with separately since it is large
+ * and it is not normally useful to save it (since a normal system does not
+ * preserve DRAM between runs). See the '-m' option for this.
+ *
+ * See struct sandbox_state_io above for member documentation.
+ */
+#define SANDBOX_STATE_IO(_name, _compat, _read, _write) \
+ ll_entry_declare(struct sandbox_state_io, _name, state_io) = { \
+ .name = __stringify(_name), \
+ .read = _read, \
+ .write = _write, \
+ .compat = _compat, \
+ }
+