Re: [PATCH net-next v2] net: dsa: realtek: realtek-mdio: reset before setup

3 messages, 3 authors, 2022-02-13 · open the first message on its own page

Re: [PATCH net-next v2] net: dsa: realtek: realtek-mdio: reset before setup

From: Arınç ÜNAL <hidden>
Date: 2022-02-12 02:48:18


On 12 Feb 2022, at 05:27, Luiz Angelo Daros de Luca [off-list ref] wrote:

Some devices, like the switch in Banana Pi BPI R64 only starts to answer
after a HW reset. It is the same reset code from realtek-smi.

In realtek-smi, only assert the reset when the gpio is defined.
If realtek-smi also resets before setup with this patch (I don’t understand code very well) can you mention it next to mdio in the summary too?

In any case:
Acked-by: Arınç ÜNAL <redacted>
quoted hunk
Reported-by: Frank Wunderlich <redacted>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Tested-by: Frank Wunderlich <redacted>
Reviewed-by: Linus Walleij <redacted>
Reviewed-by: Alvin Šipraga <redacted>
---
drivers/net/dsa/realtek/realtek-mdio.c | 19 +++++++++++++++++++
drivers/net/dsa/realtek/realtek-smi.c  | 17 ++++++++++-------
drivers/net/dsa/realtek/realtek.h      |  3 +++
3 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/net/dsa/realtek/realtek-mdio.c b/drivers/net/dsa/realtek/realtek-mdio.c
index 0c5f2bdced9d..fa2339763c71 100644
--- a/drivers/net/dsa/realtek/realtek-mdio.c
+++ b/drivers/net/dsa/realtek/realtek-mdio.c
@@ -152,6 +152,21 @@ static int realtek_mdio_probe(struct mdio_device *mdiodev)
  /* TODO: if power is software controlled, set up any regulators here */
  priv->leds_disabled = of_property_read_bool(np, "realtek,disable-leds");

+    /* Assert then deassert RESET */
+    priv->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+    if (IS_ERR(priv->reset)) {
+        dev_err(dev, "failed to get RESET GPIO\n");
+        return PTR_ERR(priv->reset);
+    }
+
+    if (priv->reset) {
+        dev_dbg(dev, "asserted RESET\n");
+        msleep(REALTEK_HW_STOP_DELAY);
+        gpiod_set_value(priv->reset, 0);
+        msleep(REALTEK_HW_START_DELAY);
+        dev_dbg(dev, "deasserted RESET\n");
+    }
+
  ret = priv->ops->detect(priv);
  if (ret) {
      dev_err(dev, "unable to detect switch\n");
@@ -185,6 +200,10 @@ static void realtek_mdio_remove(struct mdio_device *mdiodev)

  dsa_unregister_switch(priv->ds);

+    /* leave the device reset asserted */
+    if (priv->reset)
+        gpiod_set_value(priv->reset, 1);
+
  dev_set_drvdata(&mdiodev->dev, NULL);
}
diff --git a/drivers/net/dsa/realtek/realtek-smi.c b/drivers/net/dsa/realtek/realtek-smi.c
index 946fbbd70153..a13ef07080a2 100644
--- a/drivers/net/dsa/realtek/realtek-smi.c
+++ b/drivers/net/dsa/realtek/realtek-smi.c
@@ -43,8 +43,6 @@
#include "realtek.h"

#define REALTEK_SMI_ACK_RETRY_COUNT        5
-#define REALTEK_SMI_HW_STOP_DELAY        25    /* msecs */
-#define REALTEK_SMI_HW_START_DELAY        100    /* msecs */

static inline void realtek_smi_clk_delay(struct realtek_priv *priv)
{
@@ -426,10 +424,13 @@ static int realtek_smi_probe(struct platform_device *pdev)
      dev_err(dev, "failed to get RESET GPIO\n");
      return PTR_ERR(priv->reset);
  }
-    msleep(REALTEK_SMI_HW_STOP_DELAY);
-    gpiod_set_value(priv->reset, 0);
-    msleep(REALTEK_SMI_HW_START_DELAY);
-    dev_info(dev, "deasserted RESET\n");
+    if (priv->reset) {
+        dev_dbg(dev, "asserted RESET\n");
+        msleep(REALTEK_HW_STOP_DELAY);
+        gpiod_set_value(priv->reset, 0);
+        msleep(REALTEK_HW_START_DELAY);
+        dev_dbg(dev, "deasserted RESET\n");
+    }

  /* Fetch MDIO pins */
  priv->mdc = devm_gpiod_get_optional(dev, "mdc", GPIOD_OUT_LOW);
@@ -474,7 +475,9 @@ static int realtek_smi_remove(struct platform_device *pdev)
  dsa_unregister_switch(priv->ds);
  if (priv->slave_mii_bus)
      of_node_put(priv->slave_mii_bus->dev.of_node);
-    gpiod_set_value(priv->reset, 1);
+
+    if (priv->reset)
+        gpiod_set_value(priv->reset, 1);

  platform_set_drvdata(pdev, NULL);
diff --git a/drivers/net/dsa/realtek/realtek.h b/drivers/net/dsa/realtek/realtek.h
index 3512b832b148..e7d3e1bcf8b8 100644
--- a/drivers/net/dsa/realtek/realtek.h
+++ b/drivers/net/dsa/realtek/realtek.h
@@ -13,6 +13,9 @@
#include <linux/gpio/consumer.h>
#include <net/dsa.h>

+#define REALTEK_HW_STOP_DELAY        25    /* msecs */
+#define REALTEK_HW_START_DELAY        100    /* msecs */
+
struct realtek_ops;
struct dentry;
struct inode;
-- 
2.35.1

Re: [PATCH net-next v2] net: dsa: realtek: realtek-mdio: reset before setup

From: Alvin Šipraga <hidden>
Date: 2022-02-13 12:31:45

Arınç ÜNAL [off-list ref] writes:

quoted
On 12 Feb 2022, at 05:27, Luiz Angelo Daros de Luca [off-list ref] wrote:

Some devices, like the switch in Banana Pi BPI R64 only starts to answer
after a HW reset. It is the same reset code from realtek-smi.

In realtek-smi, only assert the reset when the gpio is defined.
If realtek-smi also resets before setup with this patch (I don’t understand code very well) can you mention it next to mdio in the summary too?
realtek-smi was already asserting reset. I just asked Luiz to send a
patch to only try the reset if reset-gpio is actually specified, else it
prints "asserting RESET" without actually doing it. So this is largely
cosmetic. But it is odd to touch realtek-smi when the subject is
realtek-mdio.

Arguably this could be separated into a few patches; something to
consider if you decide to send a v3 per Florian's comment:

1. realtek-smi: add if block around reset-gpio assertion
2. realtek-smi: demote dev_info to dev_dbg in reset-gpio assertion
3. realtek-mdio: add HW reset here too, based on realtek-smi (with
   dev_dbg)

Kind regards,
Alvin

Re: [PATCH net-next v2] net: dsa: realtek: realtek-mdio: reset before setup

From: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Date: 2022-02-13 22:29:10

quoted
If realtek-smi also resets before setup with this patch (I don’t understand code very well) can you mention it next to mdio in the summary too?
realtek-smi was already asserting reset. I just asked Luiz to send a
patch to only try the reset if reset-gpio is actually specified, else it
prints "asserting RESET" without actually doing it. So this is largely
cosmetic. But it is odd to touch realtek-smi when the subject is
realtek-mdio.

Arguably this could be separated into a few patches; something to
consider if you decide to send a v3 per Florian's comment:

1. realtek-smi: add if block around reset-gpio assertion
2. realtek-smi: demote dev_info to dev_dbg in reset-gpio assertion
3. realtek-mdio: add HW reset here too, based on realtek-smi (with
   dev_dbg)
I won't be a problem.
Kind regards,
Alvin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help