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

[Amjad Ouled-Ameur]

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?

Regards,
Amjad


-- 
Amjad Ouled-Ameur
Embedded Linux Engineer - Villeneuve Loubet, FR
Engit at BayLibre - At the Heart of Embedded Linux