target/linux/generic/backport-6.1/781-v6.6-02-net-dsa-qca8k-fix-potential-MDIO-bus-conflict-when-a.patch

   1 From 526c8ee04bdbd4d8d19a583b1f3b06700229a815 Mon Sep 17 00:00:00 2001
   2 From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <kabel@kernel.org>
   3 Date: Wed, 4 Oct 2023 11:19:04 +0200
   4 Subject: [PATCH 2/2] net: dsa: qca8k: fix potential MDIO bus conflict when
   5  accessing internal PHYs via management frames
   6 MIME-Version: 1.0
   7 Content-Type: text/plain; charset=UTF-8
   8 Content-Transfer-Encoding: 8bit
   9
  10 Besides the QCA8337 switch the Turris 1.x device has on it's MDIO bus
  11 also Micron ethernet PHY (dedicated to the WAN port).
  12
  13 We've been experiencing a strange behavior of the WAN ethernet
  14 interface, wherein the WAN PHY started timing out the MDIO accesses, for
  15 example when the interface was brought down and then back up.
  16
  17 Bisecting led to commit 2cd548566384 ("net: dsa: qca8k: add support for
  18 phy read/write with mgmt Ethernet"), which added support to access the
  19 QCA8337 switch's internal PHYs via management ethernet frames.
  20
  21 Connecting the MDIO bus pins onto an oscilloscope, I was able to see
  22 that the MDIO bus was active whenever a request to read/write an
  23 internal PHY register was done via an management ethernet frame.
  24
  25 My theory is that when the switch core always communicates with the
  26 internal PHYs via the MDIO bus, even when externally we request the
  27 access via ethernet. This MDIO bus is the same one via which the switch
  28 and internal PHYs are accessible to the board, and the board may have
  29 other devices connected on this bus. An ASCII illustration may give more
  30 insight:
  31
  32            +---------+
  33       +----|         |
  34       |    | WAN PHY |
  35       | +--|         |
  36       | |  +---------+
  37       | |
  38       | |  +----------------------------------+
  39       | |  | QCA8337                          |
  40 MDC   | |  |                        +-------+ |
  41 ------o-+--|--------o------------o--|       | |
  42 MDIO    |  |        |            |  | PHY 1 |-|--to RJ45
  43 --------o--|---o----+---------o--+--|       | |
  44            |   |    |         |  |  +-------+ |
  45            | +-------------+  |  o--|       | |
  46            | | MDIO MDC    |  |  |  | PHY 2 |-|--to RJ45
  47 eth1       | |             |  o--+--|       | |
  48 -----------|-|port0        |  |  |  +-------+ |
  49            | |             |  |  o--|       | |
  50            | | switch core |  |  |  | PHY 3 |-|--to RJ45
  51            | +-------------+  o--+--|       | |
  52            |                  |  |  +-------+ |
  53            |                  |  o--|  ...  | |
  54            +----------------------------------+
  55
  56 When we send a request to read an internal PHY register via an ethernet
  57 management frame via eth1, the switch core receives the ethernet frame
  58 on port 0 and then communicates with the internal PHY via MDIO. At this
  59 time, other potential devices, such as the WAN PHY on Turris 1.x, cannot
  60 use the MDIO bus, since it may cause a bus conflict.
  61
  62 Fix this issue by locking the MDIO bus even when we are accessing the
  63 PHY registers via ethernet management frames.
  64
  65 Fixes: 2cd548566384 ("net: dsa: qca8k: add support for phy read/write with mgmt Ethernet")
  66 Signed-off-by: Marek Behún <kabel@kernel.org>
  67 Reviewed-by: Christian Marangi <ansuelsmth@gmail.com>
  68 Signed-off-by: David S. Miller <davem@davemloft.net>
  69 ---
  70  drivers/net/dsa/qca/qca8k-8xxx.c | 11 +++++++++++
  71  1 file changed, 11 insertions(+)
  72
  73 --- a/drivers/net/dsa/qca/qca8k-8xxx.c
  74 +++ b/drivers/net/dsa/qca/qca8k-8xxx.c
  75 @@ -665,6 +665,15 @@ qca8k_phy_eth_command(struct qca8k_priv
  76                 goto err_read_skb;
  77         }
  78
  79 +       /* It seems that accessing the switch's internal PHYs via management
  80 +        * packets still uses the MDIO bus within the switch internally, and
  81 +        * these accesses can conflict with external MDIO accesses to other
  82 +        * devices on the MDIO bus.
  83 +        * We therefore need to lock the MDIO bus onto which the switch is
  84 +        * connected.
  85 +        */
  86 +       mutex_lock(&priv->bus->mdio_lock);
  87 +
  88         /* Actually start the request:
  89          * 1. Send mdio master packet
  90          * 2. Busy Wait for mdio master command
  91 @@ -677,6 +686,7 @@ qca8k_phy_eth_command(struct qca8k_priv
  92         mgmt_master = priv->mgmt_master;
  93         if (!mgmt_master) {
  94                 mutex_unlock(&mgmt_eth_data->mutex);
  95 +               mutex_unlock(&priv->bus->mdio_lock);
  96                 ret = -EINVAL;
  97                 goto err_mgmt_master;
  98         }
  99 @@ -764,6 +774,7 @@ exit:
 100                                     QCA8K_ETHERNET_TIMEOUT);
 101
 102         mutex_unlock(&mgmt_eth_data->mutex);
 103 +       mutex_unlock(&priv->bus->mdio_lock);
 104
 105         return ret;
 106