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

[Jerome Brunet <jbrunet@baylibre.com>]

On Wed 02 Sep 2020 at 16:13, Amjad Ouled-Ameur <aouledameur@baylibre.com> wrote:

> Le sam. 29 août 2020 à 17:25, Martin Blumenstingl
> <martin.blumenstingl@googlemail.com> a écrit :
>>
>> Hi Philipp,
>>
>> On Tue, Aug 25, 2020 at 12:20 PM Philipp Zabel <p.zabel@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


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic