On Fri, 22 Jan 2021 at 10:36, Damien Hedde <[email protected]> wrote: > > Move the reset count decrement from "just after" to "just before" > calling the exit phase handler. The goal is to make > resettable_is_in_reset() returning false during the handler execution. > > This simplifies reset handling in resettable devices. > > Typically, a function that updates the device state will just need > to read the current reset state and not anymore treat the "in > a reset-exit transition" special case. > > As a side note, this patch also fixes the fact that the reset count was > not decremented in case of recursive reset.
This seems like a reasonable change and looking through the sources it shouldn't break anything. > diff --git a/docs/devel/reset.rst b/docs/devel/reset.rst > index abea1102dc..021a7277a2 100644 > --- a/docs/devel/reset.rst > +++ b/docs/devel/reset.rst > @@ -210,9 +210,9 @@ Polling the reset state > Resettable interface provides the ``resettable_is_in_reset()`` function. > This function returns true if the object parameter is currently under reset. > > -An object is under reset from the beginning of the *init* phase to the end of > -the *exit* phase. During all three phases, the function will return that the > -object is in reset. > +An object is under reset from the beginning of the *init* phase to the *exit* > +phase. During *init* and *hold* phase only, the function will return that the > +object is in reset. The state is changed just before calling the *exit* > method. There is no "init" phase -- the documentation and the data structures name the phases "enter", "hold" and "exit". Agreed with Philippe about saying "beginning of the *enter* phase to the beginning of the *exit* phase" (but an ascii art diagram is probably overkill). thanks -- PMM
