Documentation: devicetree: changesets do locking on their own meanwhile
Since commit183223770a
("drivers/of: Export OF changeset functions"), the mentioned functions do all necessary locking. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Fixes:183223770a
("drivers/of: Export OF changeset functions") Signed-off-by: Rob Herring <robh@kernel.org>
This commit is contained in:
parent
fa8410b355
commit
63b77d6d5a
|
@ -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'
|
All the change operations are recorded in the of_changeset 'entries'
|
||||||
list.
|
list.
|
||||||
|
|
||||||
3. mutex_lock(of_mutex) - starts a changeset; The global of_mutex
|
3. of_changeset_apply() - Apply the changes to the tree. Either the
|
||||||
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
|
entire changeset will get applied, or if there is an error the tree will
|
||||||
be restored to the previous state
|
be restored to the previous state. The core ensures proper serialization
|
||||||
|
through locking. An unlocked version __of_changeset_apply is available,
|
||||||
5. mutex_unlock(of_mutex) - All operations complete, release the mutex
|
if needed.
|
||||||
|
|
||||||
If a successfully applied changeset needs to be removed, it can be done
|
If a successfully applied changeset needs to be removed, it can be done
|
||||||
with the following sequence.
|
with of_changeset_revert().
|
||||||
|
|
||||||
1. mutex_lock(of_mutex)
|
|
||||||
|
|
||||||
2. of_changeset_revert()
|
|
||||||
|
|
||||||
3. mutex_unlock(of_mutex)
|
|
||||||
|
|
Loading…
Reference in New Issue