[PATCH net-next 0/2] net: dsa: microchip: let the board state its reset timing

[PATCH net-next 0/2] net: dsa: microchip: let the board state its reset timing

[Rodolfo Giometti]

ksz_switch_register() waits a fixed 100ms after releasing the reset
line before it reads the chip ID. That figure comes from commit
1c45ba93d34c ("net: dsa: microchip: Adjust reset release timing to match
reference reset circuit"), which derives it from the reset circuit the
datasheet recommends: about 95ms for a 10k pull-up and a 10uF
capacitor. It is the timing of a reference board, and on one of our
boards it turns out to be too short.

The board is an i.MX93 with a KSZ9897 on LPSPI6 at 500kHz. Every boot
ended with

  ksz-switch spi0.0: unsupported switch detected ffffff00)

and no user ports, while a second board of the same family running the
very same image came up fine.

The bus is not at fault. With the switch already out of reset, reading
the chip ID through spidev on the failing board returns the expected
0x00989700, at the same speed and mode the driver uses. What differs is
how soon the part is ready. Driving the reset line by hand and polling
the chip ID every 11ms gives, on the failing board:

  reset asserted for 10ms  ->  answers 95-120ms after the rising edge
  reset asserted for  1s   ->  answers    ~160ms after the rising edge

So a probe that reads at 100ms is at best a coin flip there, and never
succeeds when the part comes out of a long reset. The board that works
is simply on the right side of the same margin, which is why one image
behaves differently on two boards.

Since this is a property of the board rather than of the driver, take
the delays from the device tree instead of hardcoding them, reusing
reset-assert-us and reset-deassert-us, which already carry exactly this
meaning for MDIO devices. The defaults keep the current behaviour, so
boards that do not set them are unaffected.

Tested on both boards with a 6.18-based NXP kernel, powered up from
cold, with the failing one given reset-deassert-us = <250000>. It now
detects the switch at every boot, and the one that already worked is
unchanged: same detection, no SPI errors or timeouts. On both, the
probe lands ~150ms later than before, which is the added wait showing
up where it should. On net-next the series was built, not run on
hardware.

Rodolfo Giometti (2):
  dt-bindings: net: dsa: microchip: add reset timing properties
  net: dsa: microchip: take the reset timings from the device tree

 .../bindings/net/dsa/microchip,ksz.yaml       | 12 +++++++++++
 drivers/net/dsa/microchip/ksz_common.c        | 20 +++++++++++++++++--
 2 files changed, 30 insertions(+), 2 deletions(-)


base-commit: 071876fd50482a68603a9460d80dd6dd58827ee1
-- 
2.43.0

[PATCH net-next 1/2] dt-bindings: net: dsa: microchip: add reset timing properties

[Rodolfo Giometti]

How long a KSZ switch needs before it answers on its management bus
after the reset line is released depends on the board it sits on, and a
board that needs longer than the driver waits has no way to say so.

Document reset-assert-us and reset-deassert-us with the meaning they
already have for MDIO devices, and record the timings the driver has
been using so far as their defaults.

Assisted-by: LLM
Signed-off-by: Rodolfo Giometti <giometti@enneenne.com>
---
 .../devicetree/bindings/net/dsa/microchip,ksz.yaml   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
index 4ed13870ed3a..5a99d79ea982 100644
--- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
@@ -48,6 +48,18 @@ properties:
       Should be a gpio specifier for a reset line.
     maxItems: 1
 
+  reset-assert-us:
+    description:
+      How long the reset line is held asserted, in microseconds.
+    default: 10000
+
+  reset-deassert-us:
+    description:
+      How long to wait after the reset line is released before the switch is
+      accessed, in microseconds. Boards whose switch needs longer than the
+      default to answer on the management bus state their own value here.
+    default: 100000
+
   wakeup-source: true
 
   microchip,synclko-125:
-- 
2.43.0

[PATCH net-next 2/2] net: dsa: microchip: take the reset timings from the device tree

[Rodolfo Giometti]

ksz_switch_register() holds the reset line asserted for 10ms and then
waits a fixed 100ms before reading the chip ID. On an i.MX93 board
fitted with a KSZ9897 the switch starts answering 95-120ms after a
10ms reset pulse, and about 160ms after a 1s one, so the read can
return all ones, and the probe then gives up:

  ksz-switch spi0.0: unsupported switch detected ffffff00)

The same part on another board of the same family answers well within
the 100ms, which makes the wait a property of the board rather than of
the driver.

Take reset-assert-us and reset-deassert-us from the device tree, keeping
the current timings as the defaults so nothing changes for the boards
that do not set them. The delays are now free to span the ranges of the
different sleep helpers, so let fsleep() pick.

Assisted-by: LLM
Signed-off-by: Rodolfo Giometti <giometti@enneenne.com>
---
 drivers/net/dsa/microchip/ksz_common.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 767c8fe8e819..365a804eee31 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -23,6 +23,7 @@
 #include <linux/of_net.h>
 #include <linux/micrel_phy.h>
 #include <linux/pinctrl/consumer.h>
+#include <linux/property.h>
 #include <net/dsa.h>
 #include <net/ieee8021q.h>
 #include <net/pkt_cls.h>
@@ -3990,6 +3991,8 @@ int ksz_switch_register(struct ksz_device *dev)
 	const struct ksz_chip_data *info;
 	struct device_node *ports;
 	phy_interface_t interface;
+	u32 deassert_us = 100000;
+	u32 assert_us = 10000;
 	unsigned int port_num;
 	u32 lookup_chip_id;
 	int ret;
@@ -4001,6 +4004,19 @@ int ksz_switch_register(struct ksz_device *dev)
 		return PTR_ERR(dev->reset_gpio);
 
 	if (dev->reset_gpio) {
+		/*
+		 * How long the switch takes to answer on the management bus
+		 * after the reset is released is a property of the board, not
+		 * of the driver: about 160ms has been measured on one of
+		 * them. The values above are only the historical default,
+		 * so a board that needs more states its own timing with the
+		 * properties MDIO devices already use for the same purpose.
+		 */
+		device_property_read_u32(dev->dev, "reset-assert-us",
+					 &assert_us);
+		device_property_read_u32(dev->dev, "reset-deassert-us",
+					 &deassert_us);
+
 		if (of_device_is_compatible(dev->dev->of_node, "microchip,ksz8463")) {
 			ret = ksz8463_configure_straps_spi(dev);
 			if (ret)
@@ -4008,9 +4024,9 @@ int ksz_switch_register(struct ksz_device *dev)
 		}
 
 		gpiod_set_value_cansleep(dev->reset_gpio, 1);
-		usleep_range(10000, 12000);
+		fsleep(assert_us);
 		gpiod_set_value_cansleep(dev->reset_gpio, 0);
-		msleep(100);
+		fsleep(deassert_us);
 
 		if (of_device_is_compatible(dev->dev->of_node, "microchip,ksz8463")) {
 			ret = ksz8463_release_straps_spi(dev);
-- 
2.43.0