reset_control_put() is already used in the reset framework.


Le lun. 7 sept. 2020 à 10:31, Jerome Brunet [off-list ref] a écrit :

On Wed 02 Sep 2020 at 16:13, Amjad Ouled-Ameur [off-list ref] wrote:

quoted

Le sam. 29 août 2020 à 17:25, Martin Blumenstingl
[off-list ref] a écrit :

quoted

Hi Philipp,

On Tue, Aug 25, 2020 at 12:20 PM Philipp Zabel [off-list ref] wrote:
[...]

quoted

quoted

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()

quoted

Regards,
Amjad

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

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