Hi Philipp,
Thank you for the review.
On 22/11/2021 10:03, Philipp Zabel wrote:
Hi Amjad,
On Fri, 2021-11-12 at 17:28 +0100, Amjad Ouled-Ameur wrote:
Use reset_control_rearm() call if an error occurs in case
phy_meson_gxl_usb2_init() fails after reset() has been called ; or in case
phy_meson_gxl_usb2_exit() is called i.e the resource is no longer used
and the reset line may be triggered again by other devices.
reset_control_rearm() keeps use of triggered_count sane in the reset
framework. Therefore, use of reset_control_reset() on shared reset line
should be balanced with reset_control_rearm().
Signed-off-by: Amjad Ouled-Ameur <aouledameur@xxxxxxxxxxxx>
Reported-by: Jerome Brunet <jbrunet@xxxxxxxxxxxx>
---
drivers/phy/amlogic/phy-meson-gxl-usb2.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/amlogic/phy-meson-gxl-usb2.c b/drivers/phy/amlogic/phy-meson-gxl-usb2.c
index 2b3c0d730f20..9a9c769ecabc 100644
--- a/drivers/phy/amlogic/phy-meson-gxl-usb2.c
+++ b/drivers/phy/amlogic/phy-meson-gxl-usb2.c
@@ -110,8 +110,10 @@ static int phy_meson_gxl_usb2_init(struct phy *phy)
int ret;
ret = reset_control_reset(priv->reset);
- if (ret)
+ if (ret) {
+ reset_control_rearm(priv->reset);
I don't understand this. If reset_control_reset() returns an error for a
shared reset, it should have either
- returned before incrementing triggered_count, or
- incremented triggered_count, got a failed reset op, decremented
triggered_count again
In both cases there should be no need to rearm.
I have checked this out and I agree with you, will remove this in next
version.
Thank you for spotting this.
Regards,
Amjad
regards
Philipp
