|author||Pantelis Antoniou <email@example.com>||2014-07-04 19:58:49 +0300|
|committer||Mark Brown <firstname.lastname@example.org>||2015-02-16 14:57:31 +0900|
of: Transactional DT support.
Introducing DT transactional support. A DT transaction is a method which allows one to apply changes in the live tree, in such a way that either the full set of changes take effect, or the state of the tree can be rolled-back to the state it was before it was attempted. An applied transaction can be rolled-back at any time. Documentation is in Documentation/devicetree/changesets.txt Signed-off-by: Pantelis Antoniou <email@example.com> [glikely: Removed device notifiers and reworked to be more consistent] Signed-off-by: Grant Likely <firstname.lastname@example.org> (cherry picked from commit 201c910bd6898d81d4ac6685d0f421b7e10f3c5d) Signed-off-by: Mark Brown <email@example.com> Conflicts: drivers/of/selftest.c drivers/of/testcase-data/testcases.dtsi include/linux/of.h
Diffstat (limited to 'Documentation')
1 files changed, 40 insertions, 0 deletions
diff --git a/Documentation/devicetree/changesets.txt b/Documentation/devicetree/changesets.txt
new file mode 100644
@@ -0,0 +1,40 @@
+A DT changeset is a method which allows one to apply changes
+in the live tree in such a way that either the full set of changes
+will be applied, or none of them will be. If an error occurs partway
+through applying the changeset, then the tree will be rolled back to the
+previous state. A changeset can also be removed after it has been
+When a changeset is applied, all of the changes get applied to the tree
+at once before emitting OF_RECONFIG notifiers. This is so that the
+receiver sees a complete and consistent state of the tree when it
+receives the notifier.
+The sequence of a changeset is as follows.
+1. of_changeset_init() - initializes a changeset
+2. A number of DT tree change calls, of_changeset_attach_node(),
+of_changeset_remove_property, of_changeset_update_property() to prepare
+a set of changes. No changes to the active tree are made at this point.
+All the change operations are recorded in the of_changeset 'entries'
+3. mutex_lock(of_mutex) - starts a changeset; The global of_mutex
+ensures there can only be one editor at a time.
+4. of_changeset_apply() - Apply the changes to the tree. Either the
+entire changeset will get applied, or if there is an error the tree will
+be restored to the previous state
+5. mutex_unlock(of_mutex) - All operations complete, release the mutex
+If a successfully applied changeset needs to be removed, it can be done
+with the following sequence.