Le Tue, Jun 21, 2022 at 02:37:35PM +0100, John Keeping a écrit :

On Tue, Jun 21, 2022 at 10:05:54AM +0200, LABBE Corentin wrote:

quoted

Le Mon, Jun 20, 2022 at 12:04:24PM +0100, John Keeping a écrit :

quoted

On Sun, May 08, 2022 at 06:59:38PM +0000, Corentin Labbe wrote:

quoted

reset could be handled by PM functions.

Is there any further rationale for this?

After this change there is no longer a guaranteed reset pulse on probe
since the reset control may already be de-asserted.  This is normally
the most important case for a reset as it's the only time when the state
of the hardware is unknown.

The original use of devm_add_action_or_reset() seems a bit weird already
since there doesn't seem to be any need to assert reset when the driver
is unloaded.

I am not an hw engineer, so my knowledge on reset is low.
So why not having a reset pulse on probe is a problem ?

The point of the reset is to bring the hardware back to a known state.
Since we don't know what state the hardware will be in following the
bootloader or previous OS, I think the reset in probe is the only place
that it is important.

If this patch isn't fixing anything, I suggest just dropping it.

Thanks for the explanation, I will re-add the reset at probe.