Documentation: devicetree: changesets do locking on their own meanwhile
authorWolfram Sang <wsa+renesas@sang-engineering.com>
Wed, 24 Aug 2016 13:38:56 +0000 (15:38 +0200)
committerRob Herring <robh@kernel.org>
Tue, 30 Aug 2016 22:07:44 +0000 (17:07 -0500)
Since commit 183223770ae862 ("drivers/of: Export OF changeset functions"),
the mentioned functions do all necessary locking.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Fixes: 183223770ae862 ("drivers/of: Export OF changeset functions")
Signed-off-by: Rob Herring <robh@kernel.org>
Documentation/devicetree/changesets.txt

index 935ba5a..cb488ee 100644 (file)
@@ -21,20 +21,11 @@ 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'
 list.
 
-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
+3. 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
+be restored to the previous state. The core ensures proper serialization
+through locking. An unlocked version __of_changeset_apply is available,
+if needed.
 
 If a successfully applied changeset needs to be removed, it can be done
-with the following sequence.
-
-1. mutex_lock(of_mutex)
-
-2. of_changeset_revert()
-
-3. mutex_unlock(of_mutex)
+with of_changeset_revert().