On Wed 02 Sep 2020 at 16:13, Amjad Ouled-Ameur <aouledameur@xxxxxxxxxxxx> wrote: > 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? my suggestion would be reset_control_put() > > Regards, > Amjad
