Hi Anand,

On Fri, Jun 18, 2021 at 5:33 PM Anand Moon [off-list ref] wrote:
[...]

quoted

For shared resets (like the one we have here) reset_control_reset will
only trigger the reset line once until all drivers using that reset
line are unloaded.
So effectively this new phy_ops.reset callback will be a no-op.

I know his register is shared between two USB IPs,
but I have not observed any issues.

have you checked at which point we're then actually triggering the reset?
I assume that you will find that the reset is only triggered for the
very first power_on/init call - which makes this patch effectively a
no-op (yes, we're calling reset_control_reset then, but that doesn't
mean that a reset is triggered on hardware level - see
drivers/reset/core.c at around line 346).

[...]

quoted

quoted

-       priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, NULL);
+       priv->reset = devm_reset_control_get_optional_shared(&pdev->dev, "phy");

I think this breaks compatibility with existing .dtbs and our
dt-bindings (as we're not documenting a "reset-names" property).
What is the goal of this one?

OK, If we pass NULL over here there is the possibility
USB phy will not get registered.

I don't understand why - with NULL everything is working fine for me.
Also no matter which name you give to the reset line (in reset-names),
it will be the same reset line in all cases. If it's the same reset
line before and after: why is this needed?


Best regards,
Martin

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy