reset_control_put() is already used in the reset framework. Le lun. 7 sept. 2020 à 10:31, Jerome Brunet <jbrunet@xxxxxxxxxxxx> a écrit : > > > 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 > -- Amjad Ouled-Ameur Embedded Linux Engineer - Villeneuve Loubet, FR Engit@BayLibre - At the Heart of Embedded Linux
