Hi, On 11/17/20 2:33 AM, Philipp Zabel wrote: > Add initial reset controller API documentation. This is mostly intended > to describe the concepts to users of the consumer API, and to tie the > kerneldoc comments we already have into the driver API documentation. > > Signed-off-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> > --- > Changes since the RFC [1]: > - Replaced all :c:func:`function` with function() (Jonathan Corbet) > - Typo fixes and wording improvements (Randy Dunlap) > - Mention new reset_control_rearm() API as a counterpart to > reset_control_reset() for shared resets in the Triggering section > - Grammar fix in the Querying section > - Add reset.rst to MAINTAINERS > > [1] https://lore.kernel.org/lkml/20191022164547.22632-1-p.zabel@xxxxxxxxxxxxxx/ > --- > Documentation/driver-api/index.rst | 1 + > Documentation/driver-api/reset.rst | 219 +++++++++++++++++++++++++++++ > MAINTAINERS | 1 + > 3 files changed, 221 insertions(+) > create mode 100644 Documentation/driver-api/reset.rst > diff --git a/Documentation/driver-api/reset.rst b/Documentation/driver-api/reset.rst > new file mode 100644 > index 000000000000..00a6ad79dd6c > --- /dev/null > +++ b/Documentation/driver-api/reset.rst > @@ -0,0 +1,219 @@ > +Querying > +-------- > + > +Only some reset controllers support querying the current status of a reset > +line, via reset_control_status(). > +This function returns a positive non-zero value if the given reset line is > +asserted. Maybe note that reset_control_status() does not accept a reset control array as its input parameter. > + > +Reset control arrays > +-------------------- > + > +Some drivers need to assert a bunch of reset lines in no particular order. > +devm_reset_control_array_get() returns an opaque reset control handle that can > +be used to assert, deassert, or trigger all specified reset controls at once. > +The reset control API does not guarantee the order in which the individual > +controls therein are handled. Reviewed-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> thanks. -- ~Randy
