[PATCH 1/1] usb: dwc3: meson-g12a: fix shared reset control use

[Amjad Ouled-Ameur]

reset_control_put() is already used in the reset framework.


Le lun. 7 sept. 2020 à 10:31, Jerome Brunet <jbrunet at baylibre.com> a écrit :
>
>
> On Wed 02 Sep 2020 at 16:13, Amjad Ouled-Ameur <aouledameur at baylibre.com> wrote:
>
> > Le sam. 29 août 2020 à 17:25, Martin Blumenstingl
> > <martin.blumenstingl at googlemail.com> a écrit :
> >>
> >> Hi Philipp,
> >>
> >> On Tue, Aug 25, 2020 at 12:20 PM Philipp Zabel <p.zabel at pengutronix.de> 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 at BayLibre - At the Heart of Embedded Linux