[PATCH net 1/3] net: dsa: realtek-smi: don't log an error on EPROBE_DEFER

From: Alvin Šipraga <redacted>

Probe deferral is not an error, so don't log this as an error:

[0.590156] realtek-smi ethernet-switch: unable to register switch ret = -517

Signed-off-by: Alvin Šipraga <redacted>
---
 drivers/net/dsa/realtek-smi-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/realtek-smi-core.c b/drivers/net/dsa/realtek-smi-core.c
index c66ebd0ee217..9415dd81ce5a 100644
--- a/drivers/net/dsa/realtek-smi-core.c
+++ b/drivers/net/dsa/realtek-smi-core.c

@@ -456,7 +456,9 @@ static int realtek_smi_probe(struct platform_device *pdev)
 	smi->ds->ops = var->ds_ops;
 	ret = dsa_register_switch(smi->ds);
 	if (ret) {
-		dev_err(dev, "unable to register switch ret = %d\n", ret);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "unable to register switch ret = %d\n",
+				ret);
 		return ret;
 	}
 	return 0;

-- 
2.34.0

Hi Arınç,
On 11/26/21 13:57, Arınç ÜNAL wrote:

quoted

On 26 Nov 2021, at 15:50, Alvin Šipraga [off-list ref] wrote:

From: Alvin Šipraga [off-list ref]

A contact at Realtek has clarified what exactly the units of RGMII RX
delay are. The answer is that the unit of RX delay is "about 0.3 ns".
Take this into account when parsing rx-internal-delay-ps by
approximating the closest step value. Delays of more than 2.1 ns are
rejected.

This obviously contradicts the previous assumption in the driver that a
step value of 4 was "about 2 ns", but Realtek also points out that it is
easy to find more than one RX delay step value which makes RGMII work.

Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC")
Cc: Arınç ÜNAL <redacted>
Signed-off-by: Alvin Šipraga <redacted>

Acked-by: Arınç ÜNAL <redacted>

I know you submitted a device tree using this driver with 
rx-internal-delay-ps = <2000>. Would you care to test your device tree 
with this patch and see if it needs updating? Before this patch, the 
driver would configure a step value of 4. After this patch it will 
configure a step value of 7.

If you experience problems then we will have to update the device tree 
again, assuming this patch is accepted.

Thanks!

	Alvin

On 26 Nov 2021, at 15:50, Alvin Šipraga [off-list ref] wrote:

From: Alvin Šipraga [off-list ref]

A contact at Realtek has clarified what exactly the units of RGMII RX
delay are. The answer is that the unit of RX delay is "about 0.3 ns".
Take this into account when parsing rx-internal-delay-ps by
approximating the closest step value. Delays of more than 2.1 ns are
rejected.

This obviously contradicts the previous assumption in the driver that a
step value of 4 was "about 2 ns", but Realtek also points out that it is
easy to find more than one RX delay step value which makes RGMII work.

Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC")
Cc: Arınç ÜNAL <redacted>
Signed-off-by: Alvin Šipraga <redacted>

Acked-by: Arınç ÜNAL <redacted>

From: Alvin Šipraga <redacted>

Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC")
Signed-off-by: Alvin Šipraga <redacted>
---
 drivers/net/dsa/rtl8365mb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/rtl8365mb.c b/drivers/net/dsa/rtl8365mb.c
index baaae97283c5..c52225d115d4 100644
--- a/drivers/net/dsa/rtl8365mb.c
+++ b/drivers/net/dsa/rtl8365mb.c

@@ -276,7 +276,7 @@
 		(RTL8365MB_PORT_ISOLATION_REG_BASE + (_physport))
 #define   RTL8365MB_PORT_ISOLATION_MASK			0x07FF
 
-/* MSTP port state registers - indexed by tree instancrSTI (tree ine */
+/* MSTP port state registers - indexed by tree instance */
 #define RTL8365MB_MSTI_CTRL_BASE			0x0A00
 #define RTL8365MB_MSTI_CTRL_REG(_msti, _physport) \
 		(RTL8365MB_MSTI_CTRL_BASE + ((_msti) << 1) + ((_physport) >> 3))

-- 
2.34.0

From: Alvin Šipraga <redacted>

A contact at Realtek has clarified what exactly the units of RGMII RX
delay are. The answer is that the unit of RX delay is "about 0.3 ns".
Take this into account when parsing rx-internal-delay-ps by
approximating the closest step value. Delays of more than 2.1 ns are
rejected.

This obviously contradicts the previous assumption in the driver that a
step value of 4 was "about 2 ns", but Realtek also points out that it is
easy to find more than one RX delay step value which makes RGMII work.

Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC")
Cc: Arınç ÜNAL <redacted>
Signed-off-by: Alvin Šipraga <redacted>
---
 drivers/net/dsa/rtl8365mb.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/net/dsa/rtl8365mb.c b/drivers/net/dsa/rtl8365mb.c
index c52225d115d4..bb65576ebf3c 100644
--- a/drivers/net/dsa/rtl8365mb.c
+++ b/drivers/net/dsa/rtl8365mb.c

@@ -760,7 +760,8 @@ static int rtl8365mb_ext_config_rgmii(struct realtek_smi *smi, int port,
 	 *     0 = no delay, 1 = 2 ns delay
 	 *   RX delay:
 	 *     0 = no delay, 7 = maximum delay
-	 *     No units are specified, but there are a total of 8 steps.
+	 *     Each step is approximately 0.3 ns, so the maximum delay is about
+	 *     2.1 ns.
 	 *
 	 * The vendor driver also states that this must be configured *before*
 	 * forcing the external interface into a particular mode, which is done

@@ -771,10 +772,6 @@ static int rtl8365mb_ext_config_rgmii(struct realtek_smi *smi, int port,
 	 * specified. We ignore the detail of the RGMII interface mode
 	 * (RGMII_{RXID, TXID, etc.}), as this is considered to be a PHY-only
 	 * property.
-	 *
-	 * For the RX delay, we assume that a register value of 4 corresponds to
-	 * 2 ns. But this is just an educated guess, so ignore all other values
-	 * to avoid too much confusion.
 	 */
 	if (!of_property_read_u32(dn, "tx-internal-delay-ps", &val)) {
 		val = val / 1000; /* convert to ns */

@@ -787,13 +784,13 @@ static int rtl8365mb_ext_config_rgmii(struct realtek_smi *smi, int port,
 	}
 
 	if (!of_property_read_u32(dn, "rx-internal-delay-ps", &val)) {
-		val = val / 1000; /* convert to ns */
+		val = DIV_ROUND_CLOSEST(val, 300); /* convert to 0.3 ns step */
 
-		if (val == 0 || val == 2)
-			rx_delay = val * 2;
+		if (val <= 7)
+			rx_delay = val;
 		else
 			dev_warn(smi->dev,
-				 "EXT port RX delay must be 0 to 2 ns\n");
+				 "EXT port RX delay must be 0 to 2.1 ns\n");
 	}
 
 	ret = regmap_update_bits(

-- 
2.34.0

On 26.11.2021 13:50, Alvin Šipraga wrote:

Better use dev_err_probe().

+			dev_err(dev, "unable to register switch ret = %d\n",
+				ret);
 		return ret;
 	}
 	return 0;

On 11/29/21 08:13, Heiner Kallweit wrote:

On 26.11.2021 13:50, Alvin Šipraga wrote:

quoted

From: Alvin Šipraga <redacted>

Probe deferral is not an error, so don't log this as an error:

[0.590156] realtek-smi ethernet-switch: unable to register switch ret = -517

Signed-off-by: Alvin Šipraga <redacted>
---
  drivers/net/dsa/realtek-smi-core.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/realtek-smi-core.c b/drivers/net/dsa/realtek-smi-core.c
index c66ebd0ee217..9415dd81ce5a 100644
--- a/drivers/net/dsa/realtek-smi-core.c
+++ b/drivers/net/dsa/realtek-smi-core.c

@@ -456,7 +456,9 @@ static int realtek_smi_probe(struct platform_device *pdev)
  	smi->ds->ops = var->ds_ops;
  	ret = dsa_register_switch(smi->ds);
  	if (ret) {
-		dev_err(dev, "unable to register switch ret = %d\n", ret);
+		if (ret != -EPROBE_DEFER)

Better use dev_err_probe().

Didn't know about that - thanks. I'll send a v2.

quoted

+			dev_err(dev, "unable to register switch ret = %d\n",
+				ret);
  		return ret;
  	}
  	return 0;

Hey Alvin.

On 26/11/2021 16:01, Alvin Šipraga wrote:

Hi Arınç,
On 11/26/21 13:57, Arınç ÜNAL wrote:

quoted

quoted

On 26 Nov 2021, at 15:50, Alvin Šipraga [off-list ref] wrote:

From: Alvin Šipraga [off-list ref]

A contact at Realtek has clarified what exactly the units of RGMII RX
delay are. The answer is that the unit of RX delay is "about 0.3 ns".
Take this into account when parsing rx-internal-delay-ps by
approximating the closest step value. Delays of more than 2.1 ns are
rejected.

This obviously contradicts the previous assumption in the driver that a
step value of 4 was "about 2 ns", but Realtek also points out that it is
easy to find more than one RX delay step value which makes RGMII work.

Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC")
Cc: Arınç ÜNAL <redacted>
Signed-off-by: Alvin Šipraga <redacted>

Acked-by: Arınç ÜNAL <redacted>

I know you submitted a device tree using this driver with
rx-internal-delay-ps = <2000>. Would you care to test your device tree
with this patch and see if it needs updating? Before this patch, the
driver would configure a step value of 4. After this patch it will
configure a step value of 7.

If you experience problems then we will have to update the device tree
again, assuming this patch is accepted.

I just tested the driver with this patch on 5.15. The switch seems to 
receive/transmit frames through the cpu port with rx-internal-delay-ps = 
<2000> fine.

Should we update the device tree to use 2100 ps for rx-internal-delay-ps 
anyway?

Arınç

Hi Arınç,

On 11/29/21 13:27, Arınç ÜNAL wrote:

Hey Alvin.

On 26/11/2021 16:01, Alvin Šipraga wrote:

quoted

Hi Arınç,
On 11/26/21 13:57, Arınç ÜNAL wrote:

quoted

quoted

On 26 Nov 2021, at 15:50, Alvin Šipraga [off-list ref] wrote:

From: Alvin Šipraga [off-list ref]

A contact at Realtek has clarified what exactly the units of RGMII RX
delay are. The answer is that the unit of RX delay is "about 0.3 ns".
Take this into account when parsing rx-internal-delay-ps by
approximating the closest step value. Delays of more than 2.1 ns are
rejected.

This obviously contradicts the previous assumption in the driver that a
step value of 4 was "about 2 ns", but Realtek also points out that 
it is
easy to find more than one RX delay step value which makes RGMII work.

Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver 
for RTL8365MB-VC")
Cc: Arınç ÜNAL <redacted>
Signed-off-by: Alvin Šipraga <redacted>

Acked-by: Arınç ÜNAL <redacted>

I know you submitted a device tree using this driver with
rx-internal-delay-ps = <2000>. Would you care to test your device tree
with this patch and see if it needs updating? Before this patch, the
driver would configure a step value of 4. After this patch it will
configure a step value of 7.

If you experience problems then we will have to update the device tree
again, assuming this patch is accepted.

I just tested the driver with this patch on 5.15. The switch seems to 
receive/transmit frames through the cpu port with rx-internal-delay-ps = 
<2000> fine.

Great, thanks a lot for testing!

Should we update the device tree to use 2100 ps for rx-internal-delay-ps 
anyway?

Under the hood the driver will do the same thing, so it's not necessary.

Arınç