Le sam. 29 août 2020 à 17:25, Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> a écrit : > > Hi Philipp, > > On Tue, Aug 25, 2020 at 12:20 PM Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote: > [...] > > > reset_control_clear() > > > would be the way to state that the ressource is no longer used and, that > > > from the caller perspective, the reset can fired again if necessary. > > > > > > If we take the probe / suspend / resume example: > > > * 1st device using the shared will actually trigger it (as it is now) > > > * following device just increase triggered_count > > > > > > If all devices go to suspend (calling reset_control_clear()) then > > > triggered_count will reach zero, allowing the first device resuming to > > > trigger the reset again ... this is important since it might not be the > > > one which would have got the exclusive control > > > > > > If any device don't go to suspend, meaning the ressource under reset > > > keep on being used, no reset will performed. With exlusive control, > > > there is a risk that the resuming device resets something already in use. > > > > > > Regarding the condition, on shared resets, call reset_control_reset() > > > should be balanced reset_control_clear() - no clear before reset. > > > > Martin, is this something that would be useful for the current users of > > the shared reset trigger functionality (phy-meson-gxl-usb2 and phy- > > meson8b-usb2 with reset-meson)? > for the specific use-case (system suspend) this would currently not be > useful for the two drivers you have named. This is because the > platforms on which they are used currently don't support system > suspend. > if other drivers are going to benefit from this change then please go > ahead and add the necessary API. Then I can also use it in these > drivers. however, (as far as I understand) I won't be able to verify > the new "fixed" behavior > > > Best regards, > Martin Hi Philipp, Regarding the naming of the new call, since reset_control_clear() is not really representative of the intended behaviour, I have thought of some other metaphors such as: reset_control_resettable() (sounds the most relevant to me) reset_control_standby() reset_control_unseal() reset_control_untie() reset_control_loosen()/loose() reset_control_unfetter() What do you think? Regards, Amjad -- Amjad Ouled-Ameur Embedded Linux Engineer - Villeneuve Loubet, FR Engit@BayLibre - At the Heart of Embedded Linux
