From nobody Mon May 11 06:17:48 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4666CC433F5 for ; Tue, 12 Apr 2022 17:33:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358218AbiDLRfv (ORCPT ); Tue, 12 Apr 2022 13:35:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358178AbiDLRfh (ORCPT ); Tue, 12 Apr 2022 13:35:37 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33DB260CE9 for ; Tue, 12 Apr 2022 10:33:17 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id bh17so38723196ejb.8 for ; Tue, 12 Apr 2022 10:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqrs.dk; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=BOCNcCHoaIr0UXliwrJtAEwwXS/NvvZL8YTtuwi1Q8I=; b=iHELwmNmfRPmhT2mcePy8V126zUYxP288c4x/DaVpxBd+Ia45EgELwIgJJlFrCUkPv 1OCBHmkPchCgI7QYJV9s4SsJvqY0RQtXUvJL367LXF9NXdI5/b42hFMpW/iU0jxz+eNV zBx14NzL6aPnYAu9YiOxitFQVwJ3xl6wtM/jU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=BOCNcCHoaIr0UXliwrJtAEwwXS/NvvZL8YTtuwi1Q8I=; b=ckLJNvQJrZw7mfnqGW+v9c7u8oolXDvNFfm7LOFN6ih2MwpRYGRWGjc5TehNy0rwda AfFkmCMotfn7gx2MlJUSD3O9zPWDqnt0IOzorZ4hmsWMSlsv1YyKkTz3cCcju8JwYBTA Rei6zs1APFObPE85vitdL5EiY9uCEE9VpueZF9dMovhkn1iaiMOwWLAMKYaqPM3FtAZ2 +wbqu+HQx6W0w2CwOkOsBHEhHTBlZjnpo/HIr26R2PBK11yL8bvIj6klfd3O/CgpKr2a EceKeeDI+YGa5POqyDjZcoh/5l6qNdq4oSHqZef32H8L9PJLRF1DSAafujdu/24p5FjQ RmSA== X-Gm-Message-State: AOAM533ZZWwPnN+/V65caZdYQhsB12Wiz7FelhHpGrTNTwrrDsQ4MhBL HmAZtOme4UUdNLgIHvfanhC9hQ== X-Google-Smtp-Source: ABdhPJwCtPsuDTZv3XuWBYconHvJf5mN0jA4xePfXqMg/VNm92xTiBzJMxj6pVzB9PE/o9gmCPJYsw== X-Received: by 2002:a17:907:2bf4:b0:6e8:93d4:46e9 with SMTP id gv52-20020a1709072bf400b006e893d446e9mr10052342ejc.69.1649784795512; Tue, 12 Apr 2022 10:33:15 -0700 (PDT) Received: from capella.. (80.71.142.18.ipv4.parknet.dk. [80.71.142.18]) by smtp.gmail.com with ESMTPSA id o3-20020aa7dd43000000b00419db53ae65sm56142edw.7.2022.04.12.10.33.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 10:33:15 -0700 (PDT) From: =?UTF-8?q?Alvin=20=C5=A0ipraga?= To: Greg Kroah-Hartman , Sasha Levin , stable@vger.kernel.org, Linus Walleij , Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Michael Rasmussen , Luiz Angelo Daros de Luca , =?UTF-8?q?Alvin=20=C5=A0ipraga?= Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH stable 5.16+ 1/3] net: dsa: realtek: allow subdrivers to externally lock regmap Date: Tue, 12 Apr 2022 19:32:50 +0200 Message-Id: <20220412173253.2247196-2-alvin@pqrs.dk> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220412173253.2247196-1-alvin@pqrs.dk> References: <20220412173253.2247196-1-alvin@pqrs.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alvin =C5=A0ipraga [ Upstream commit 907e772f6f6debb610ea28298ab57b31019a4edb ] Currently there is no way for Realtek DSA subdrivers to serialize consecutive regmap accesses. In preparation for a bugfix relating to indirect PHY register access - which involves a series of regmap reads and writes - add a facility for subdrivers to serialize their regmap access. Specifically, a mutex is added to the driver private data structure and the standard regmap is initialized with custom lock/unlock ops which use this mutex. Then, a "nolock" variant of the regmap is added, which is functionally equivalent to the existing regmap except that regmap locking is disabled. Functions that wish to serialize a sequence of regmap accesses may then lock the newly introduced driver-owned mutex before using the nolock regmap. Doing things this way means that subdriver code that doesn't care about serialized register access - i.e. the vast majority of code - needn't worry about synchronizing register access with an external lock: it can just continue to use the original regmap. Another advantage of this design is that, while regmaps with locking disabled do not expose a debugfs interface for obvious reasons, there still exists the original regmap which does expose this interface. This interface remains safe to use even combined with driver codepaths that use the nolock regmap, because said codepaths will use the same mutex to synchronize access. With respect to disadvantages, it can be argued that having near-duplicate regmaps is confusing. However, the naming is rather explicit, and examples will abound. Finally, while we are at it, rename realtek_smi_mdio_regmap_config to realtek_smi_regmap_config. This makes it consistent with the naming realtek_mdio_regmap_config in realtek-mdio.c. Signed-off-by: Alvin =C5=A0ipraga Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller [alsi: backport to 5.16: s/priv/smi/g and remove realtek-mdio changes] Cc: stable@vger.kernel.org # v5.16+ Signed-off-by: Alvin =C5=A0ipraga --- drivers/net/dsa/realtek/realtek-smi-core.c | 48 ++++++++++++++++++++-- drivers/net/dsa/realtek/realtek-smi-core.h | 2 + 2 files changed, 47 insertions(+), 3 deletions(-) diff --git a/drivers/net/dsa/realtek/realtek-smi-core.c b/drivers/net/dsa/r= ealtek/realtek-smi-core.c index c66ebd0ee217..129ddee41928 100644 --- a/drivers/net/dsa/realtek/realtek-smi-core.c +++ b/drivers/net/dsa/realtek/realtek-smi-core.c @@ -315,7 +315,21 @@ static int realtek_smi_read(void *ctx, u32 reg, u32 *v= al) return realtek_smi_read_reg(smi, reg, val); } =20 -static const struct regmap_config realtek_smi_mdio_regmap_config =3D { +static void realtek_smi_lock(void *ctx) +{ + struct realtek_smi *smi =3D ctx; + + mutex_lock(&smi->map_lock); +} + +static void realtek_smi_unlock(void *ctx) +{ + struct realtek_smi *smi =3D ctx; + + mutex_unlock(&smi->map_lock); +} + +static const struct regmap_config realtek_smi_regmap_config =3D { .reg_bits =3D 10, /* A4..A0 R4..R0 */ .val_bits =3D 16, .reg_stride =3D 1, @@ -325,6 +339,21 @@ static const struct regmap_config realtek_smi_mdio_reg= map_config =3D { .reg_read =3D realtek_smi_read, .reg_write =3D realtek_smi_write, .cache_type =3D REGCACHE_NONE, + .lock =3D realtek_smi_lock, + .unlock =3D realtek_smi_unlock, +}; + +static const struct regmap_config realtek_smi_nolock_regmap_config =3D { + .reg_bits =3D 10, /* A4..A0 R4..R0 */ + .val_bits =3D 16, + .reg_stride =3D 1, + /* PHY regs are at 0x8000 */ + .max_register =3D 0xffff, + .reg_format_endian =3D REGMAP_ENDIAN_BIG, + .reg_read =3D realtek_smi_read, + .reg_write =3D realtek_smi_write, + .cache_type =3D REGCACHE_NONE, + .disable_locking =3D true, }; =20 static int realtek_smi_mdio_read(struct mii_bus *bus, int addr, int regnum) @@ -388,6 +417,7 @@ static int realtek_smi_probe(struct platform_device *pd= ev) const struct realtek_smi_variant *var; struct device *dev =3D &pdev->dev; struct realtek_smi *smi; + struct regmap_config rc; struct device_node *np; int ret; =20 @@ -398,14 +428,26 @@ static int realtek_smi_probe(struct platform_device *= pdev) if (!smi) return -ENOMEM; smi->chip_data =3D (void *)smi + sizeof(*smi); - smi->map =3D devm_regmap_init(dev, NULL, smi, - &realtek_smi_mdio_regmap_config); + + mutex_init(&smi->map_lock); + + rc =3D realtek_smi_regmap_config; + rc.lock_arg =3D smi; + smi->map =3D devm_regmap_init(dev, NULL, smi, &rc); if (IS_ERR(smi->map)) { ret =3D PTR_ERR(smi->map); dev_err(dev, "regmap init failed: %d\n", ret); return ret; } =20 + rc =3D realtek_smi_nolock_regmap_config; + smi->map_nolock =3D devm_regmap_init(dev, NULL, smi, &rc); + if (IS_ERR(smi->map_nolock)) { + ret =3D PTR_ERR(smi->map_nolock); + dev_err(dev, "regmap init failed: %d\n", ret); + return ret; + } + /* Link forward and backward */ smi->dev =3D dev; smi->clk_delay =3D var->clk_delay; diff --git a/drivers/net/dsa/realtek/realtek-smi-core.h b/drivers/net/dsa/r= ealtek/realtek-smi-core.h index faed387d8db3..5fcad51e1984 100644 --- a/drivers/net/dsa/realtek/realtek-smi-core.h +++ b/drivers/net/dsa/realtek/realtek-smi-core.h @@ -49,6 +49,8 @@ struct realtek_smi { struct gpio_desc *mdc; struct gpio_desc *mdio; struct regmap *map; + struct regmap *map_nolock; + struct mutex map_lock; struct mii_bus *slave_mii_bus; =20 unsigned int clk_delay; --=20 2.35.1 From nobody Mon May 11 06:17:48 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51155C433FE for ; Tue, 12 Apr 2022 17:33:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358232AbiDLRf6 (ORCPT ); Tue, 12 Apr 2022 13:35:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358225AbiDLRfl (ORCPT ); Tue, 12 Apr 2022 13:35:41 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 423F8580C5 for ; Tue, 12 Apr 2022 10:33:19 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id u15so20091842ejf.11 for ; Tue, 12 Apr 2022 10:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqrs.dk; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=sITlTL+kuRHKI1MXNipizR8/OsadxizPlkHPEYeP2BQ=; b=UDFDMaVQ3pZZ2Yyybqej3tMqSIDkzgrk/NVYkS5iuStXL6Pjaki2cSs0g26TwocwAa lL+g3XKSnAW3WvQs/KwSw8h7CP1gE7TfuaHbtiOKp2llO8AREI/M9xH1E7Bb//nV49yp 2rxkwuFvsSDzPPse2LrB8HTnNxMxgd9O/UOnM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=sITlTL+kuRHKI1MXNipizR8/OsadxizPlkHPEYeP2BQ=; b=KVxRE9crSsJtAyCAQbo6Frr/deqqwaLhL/DxoYHywbuImtAHTzRoEBILBWGPNfkN2k S9wtD/FPRVN+y1TBGe7yX1dE7vk+HbZxHvfkGjYcF9rGrFhvWCFrt3t6bd0J+dyLo34J 4cWPgV0bWSJlMkzFxFmJufhDEbXw75zgmE07mReUvsRg6IrHUd06/OmhLvKJKXYFStR3 oNk4g23fPnLTLRTJigzCV+2awhcgBkORV0u+e3egBFb1Ad82BY5BwnG9fsLgHpB6NuDi tVLg2rlzYQquv1XCqK1B+I1vOBxHCq3R315Dh9kZAc7i2EyahKOBvnKBdY+BVK2WID8Y usUw== X-Gm-Message-State: AOAM531mRNyjoS2G3jthye5A/LvNWSqGg6aODdPtYFaxxvG3vLWYxCy1 koEaE+vn9LMADdWZfqehxStKDA== X-Google-Smtp-Source: ABdhPJwFPI/ox/lPs49z9zHMgMlcR3UeYkq5NDbVc8Jdy2KbVrRJWtJ6zTVnhpWzp9nVBBwJdMEokQ== X-Received: by 2002:a17:907:1c19:b0:6e8:322f:cdd7 with SMTP id nc25-20020a1709071c1900b006e8322fcdd7mr25355296ejc.493.1649784797756; Tue, 12 Apr 2022 10:33:17 -0700 (PDT) Received: from capella.. (80.71.142.18.ipv4.parknet.dk. [80.71.142.18]) by smtp.gmail.com with ESMTPSA id o3-20020aa7dd43000000b00419db53ae65sm56142edw.7.2022.04.12.10.33.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 10:33:17 -0700 (PDT) From: =?UTF-8?q?Alvin=20=C5=A0ipraga?= To: Greg Kroah-Hartman , Sasha Levin , stable@vger.kernel.org, Linus Walleij , Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Michael Rasmussen , =?UTF-8?q?Alvin=20=C5=A0ipraga?= , Luiz Angelo Daros de Luca Cc: =?UTF-8?q?Ar=C4=B1n=C3=A7=20=C3=9CNAL?= , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH stable 5.16+ 2/3] net: dsa: realtek: rtl8365mb: serialize indirect PHY register access Date: Tue, 12 Apr 2022 19:32:51 +0200 Message-Id: <20220412173253.2247196-3-alvin@pqrs.dk> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220412173253.2247196-1-alvin@pqrs.dk> References: <20220412173253.2247196-1-alvin@pqrs.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alvin =C5=A0ipraga [ Upstream commit 2796728460b822d549841e0341752b263dc265c4 ] Realtek switches in the rtl8365mb family can access the PHY registers of the internal PHYs via the switch registers. This method is called indirect access. At a high level, the indirect PHY register access method involves reading and writing some special switch registers in a particular sequence. This works for both SMI and MDIO connected switches. Currently the rtl8365mb driver does not take any care to serialize the aforementioned access to the switch registers. In particular, it is permitted for other driver code to access other switch registers while the indirect PHY register access is ongoing. Locking is only done at the regmap level. This, however, is a bug: concurrent register access, even to unrelated switch registers, risks corrupting the PHY register value read back via the indirect access method described above. Ar=C4=B1n=C3=A7 reported that the switch sometimes returns nonsense data wh= en reading the PHY registers. In particular, a value of 0 causes the kernel's PHY subsystem to think that the link is down, but since most reads return correct data, the link then flip-flops between up and down over a period of time. The aforementioned bug can be readily observed by: 1. Enabling ftrace events for regmap and mdio 2. Polling BSMR PHY register for a connected port; it should always read the same (e.g. 0x79ed) 3. Wait for step 2 to give a different value Example command for step 2: while true; do phytool read swp2/2/0x01; done On my i.MX8MM, the above steps will yield a bogus value for the BSMR PHY register within a matter of seconds. The interleaved register access it then evident in the trace log: kworker/3:4-70 [003] ....... 1927.139849: regmap_reg_write: ethernet= -switch reg=3D1004 val=3Dbd phytool-16816 [002] ....... 1927.139979: regmap_reg_read: ethernet-= switch reg=3D1f01 val=3D0 kworker/3:4-70 [003] ....... 1927.140381: regmap_reg_read: ethernet-= switch reg=3D1005 val=3D0 phytool-16816 [002] ....... 1927.140468: regmap_reg_read: ethernet-= switch reg=3D1d15 val=3Da69 kworker/3:4-70 [003] ....... 1927.140864: regmap_reg_read: ethernet-= switch reg=3D1003 val=3D0 phytool-16816 [002] ....... 1927.140955: regmap_reg_write: ethernet= -switch reg=3D1f02 val=3D2041 kworker/3:4-70 [003] ....... 1927.141390: regmap_reg_read: ethernet-= switch reg=3D1002 val=3D0 phytool-16816 [002] ....... 1927.141479: regmap_reg_write: ethernet= -switch reg=3D1f00 val=3D1 kworker/3:4-70 [003] ....... 1927.142311: regmap_reg_write: ethernet= -switch reg=3D1004 val=3Dbe phytool-16816 [002] ....... 1927.142410: regmap_reg_read: ethernet-= switch reg=3D1f01 val=3D0 kworker/3:4-70 [003] ....... 1927.142534: regmap_reg_read: ethernet-= switch reg=3D1005 val=3D0 phytool-16816 [002] ....... 1927.142618: regmap_reg_read: ethernet-= switch reg=3D1f04 val=3D0 phytool-16816 [002] ....... 1927.142641: mdio_access: SMI-0 read p= hy:0x02 reg:0x01 val:0x0000 <- ?! kworker/3:4-70 [003] ....... 1927.143037: regmap_reg_read: ethernet-= switch reg=3D1001 val=3D0 kworker/3:4-70 [003] ....... 1927.143133: regmap_reg_read: ethernet-= switch reg=3D1000 val=3D2d89 kworker/3:4-70 [003] ....... 1927.143213: regmap_reg_write: ethernet= -switch reg=3D1004 val=3Dbe kworker/3:4-70 [003] ....... 1927.143291: regmap_reg_read: ethernet-= switch reg=3D1005 val=3D0 kworker/3:4-70 [003] ....... 1927.143368: regmap_reg_read: ethernet-= switch reg=3D1003 val=3D0 kworker/3:4-70 [003] ....... 1927.143443: regmap_reg_read: ethernet-= switch reg=3D1002 val=3D6 The kworker here is polling MIB counters for stats, as evidenced by the register 0x1004 that we are writing to (RTL8365MB_MIB_ADDRESS_REG). This polling is performed every 3 seconds, but is just one example of such unsynchronized access. In Ar=C4=B1n=C3=A7's case, the driver was not using = the switch IRQ, so the PHY subsystem was itself doing polling analogous to phytool in the above example. A test module was created [see second Link] to simulate such spurious switch register accesses while performing indirect PHY register reads and writes. Realtek was also consulted to confirm whether this is a known issue or not. The conclusion of these lines of inquiry is as follows: 1. Reading of PHY registers via indirect access will be aborted if, after executing the read operation (via a write to the INDIRECT_ACCESS_CTRL_REG), any register is accessed, other than INDIRECT_ACCESS_STATUS_REG. 2. The PHY register indirect read is only complete when INDIRECT_ACCESS_STATUS_REG reads zero. 3. The INDIRECT_ACCESS_DATA_REG, which is read to get the result of the PHY read, will contain the result of the last successful read operation. If there was spurious register access and the indirect read was aborted, then this register is not guaranteed to hold anything meaningful and the PHY read will silently fail. 4. PHY writes do not appear to be affected by this mechanism. 5. Other similar access routines, such as for MIB counters, although similar to the PHY indirect access method, are actually table access. Table access is not affected by spurious reads or writes of other registers. However, concurrent table access is not allowed. Currently this is protected via mib_lock, so there is nothing to fix. The above statements are corroborated both via the test module and through consultation with Realtek. In particular, Realtek states that this is simply a property of the hardware design and is not a hardware bug. To fix this problem, one must guard against regmap access while the PHY indirect register read is executing. Fix this by using the newly introduced "nolock" regmap in all PHY-related functions, and by aquiring the regmap mutex at the top level of the PHY register access callbacks. Although no issue has been observed with PHY register _writes_, this change also serializes the indirect access method there. This is done purely as a matter of convenience and for reasons of symmetry. Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RT= L8365MB-VC") Link: https://lore.kernel.org/netdev/CAJq09z5FCgG-+jVT7uxh1a-0CiiFsoKoHYsAW= JtiKwv7LXKofQ@mail.gmail.com/ Link: https://lore.kernel.org/netdev/871qzwjmtv.fsf@bang-olufsen.dk/ Reported-by: Ar=C4=B1n=C3=A7 =C3=9CNAL Reported-by: Luiz Angelo Daros de Luca Signed-off-by: Alvin =C5=A0ipraga Reviewed-by: Vladimir Oltean Reviewed-by: Linus Walleij Signed-off-by: David S. Miller [alsi: backport to 5.16: s/priv/smi/g] Cc: stable@vger.kernel.org # v5.16+ Signed-off-by: Alvin =C5=A0ipraga --- drivers/net/dsa/realtek/rtl8365mb.c | 54 ++++++++++++++++++----------- 1 file changed, 33 insertions(+), 21 deletions(-) diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/= rtl8365mb.c index 48c0e3e46600..3b2d5058b434 100644 --- a/drivers/net/dsa/realtek/rtl8365mb.c +++ b/drivers/net/dsa/realtek/rtl8365mb.c @@ -565,7 +565,7 @@ static int rtl8365mb_phy_poll_busy(struct realtek_smi *= smi) { u32 val; =20 - return regmap_read_poll_timeout(smi->map, + return regmap_read_poll_timeout(smi->map_nolock, RTL8365MB_INDIRECT_ACCESS_STATUS_REG, val, !val, 10, 100); } @@ -579,7 +579,7 @@ static int rtl8365mb_phy_ocp_prepare(struct realtek_smi= *smi, int phy, /* Set OCP prefix */ val =3D FIELD_GET(RTL8365MB_PHY_OCP_ADDR_PREFIX_MASK, ocp_addr); ret =3D regmap_update_bits( - smi->map, RTL8365MB_GPHY_OCP_MSB_0_REG, + smi->map_nolock, RTL8365MB_GPHY_OCP_MSB_0_REG, RTL8365MB_GPHY_OCP_MSB_0_CFG_CPU_OCPADR_MASK, FIELD_PREP(RTL8365MB_GPHY_OCP_MSB_0_CFG_CPU_OCPADR_MASK, val)); if (ret) @@ -592,8 +592,8 @@ static int rtl8365mb_phy_ocp_prepare(struct realtek_smi= *smi, int phy, ocp_addr >> 1); val |=3D FIELD_PREP(RTL8365MB_INDIRECT_ACCESS_ADDRESS_OCPADR_9_6_MASK, ocp_addr >> 6); - ret =3D regmap_write(smi->map, RTL8365MB_INDIRECT_ACCESS_ADDRESS_REG, - val); + ret =3D regmap_write(smi->map_nolock, + RTL8365MB_INDIRECT_ACCESS_ADDRESS_REG, val); if (ret) return ret; =20 @@ -606,36 +606,42 @@ static int rtl8365mb_phy_ocp_read(struct realtek_smi = *smi, int phy, u32 val; int ret; =20 + mutex_lock(&smi->map_lock); + ret =3D rtl8365mb_phy_poll_busy(smi); if (ret) - return ret; + goto out; =20 ret =3D rtl8365mb_phy_ocp_prepare(smi, phy, ocp_addr); if (ret) - return ret; + goto out; =20 /* Execute read operation */ val =3D FIELD_PREP(RTL8365MB_INDIRECT_ACCESS_CTRL_CMD_MASK, RTL8365MB_INDIRECT_ACCESS_CTRL_CMD_VALUE) | FIELD_PREP(RTL8365MB_INDIRECT_ACCESS_CTRL_RW_MASK, RTL8365MB_INDIRECT_ACCESS_CTRL_RW_READ); - ret =3D regmap_write(smi->map, RTL8365MB_INDIRECT_ACCESS_CTRL_REG, val); + ret =3D regmap_write(smi->map_nolock, RTL8365MB_INDIRECT_ACCESS_CTRL_REG, + val); if (ret) - return ret; + goto out; =20 ret =3D rtl8365mb_phy_poll_busy(smi); if (ret) - return ret; + goto out; =20 /* Get PHY register data */ - ret =3D regmap_read(smi->map, RTL8365MB_INDIRECT_ACCESS_READ_DATA_REG, - &val); + ret =3D regmap_read(smi->map_nolock, + RTL8365MB_INDIRECT_ACCESS_READ_DATA_REG, &val); if (ret) - return ret; + goto out; =20 *data =3D val & 0xFFFF; =20 - return 0; +out: + mutex_unlock(&smi->map_lock); + + return ret; } =20 static int rtl8365mb_phy_ocp_write(struct realtek_smi *smi, int phy, @@ -644,32 +650,38 @@ static int rtl8365mb_phy_ocp_write(struct realtek_smi= *smi, int phy, u32 val; int ret; =20 + mutex_lock(&smi->map_lock); + ret =3D rtl8365mb_phy_poll_busy(smi); if (ret) - return ret; + goto out; =20 ret =3D rtl8365mb_phy_ocp_prepare(smi, phy, ocp_addr); if (ret) - return ret; + goto out; =20 /* Set PHY register data */ - ret =3D regmap_write(smi->map, RTL8365MB_INDIRECT_ACCESS_WRITE_DATA_REG, - data); + ret =3D regmap_write(smi->map_nolock, + RTL8365MB_INDIRECT_ACCESS_WRITE_DATA_REG, data); if (ret) - return ret; + goto out; =20 /* Execute write operation */ val =3D FIELD_PREP(RTL8365MB_INDIRECT_ACCESS_CTRL_CMD_MASK, RTL8365MB_INDIRECT_ACCESS_CTRL_CMD_VALUE) | FIELD_PREP(RTL8365MB_INDIRECT_ACCESS_CTRL_RW_MASK, RTL8365MB_INDIRECT_ACCESS_CTRL_RW_WRITE); - ret =3D regmap_write(smi->map, RTL8365MB_INDIRECT_ACCESS_CTRL_REG, val); + ret =3D regmap_write(smi->map_nolock, RTL8365MB_INDIRECT_ACCESS_CTRL_REG, + val); if (ret) - return ret; + goto out; =20 ret =3D rtl8365mb_phy_poll_busy(smi); if (ret) - return ret; + goto out; + +out: + mutex_unlock(&smi->map_lock); =20 return 0; } --=20 2.35.1 From nobody Mon May 11 06:17:48 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85BE5C433EF for ; Tue, 12 Apr 2022 17:33:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358214AbiDLRgC (ORCPT ); Tue, 12 Apr 2022 13:36:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358191AbiDLRfm (ORCPT ); Tue, 12 Apr 2022 13:35:42 -0400 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BAFB60DBA for ; Tue, 12 Apr 2022 10:33:21 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id ks6so14099889ejb.1 for ; Tue, 12 Apr 2022 10:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqrs.dk; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=DC9ar6WVuy8H//hRbG7nMUtpZuF4AvspHn0mVs8y4F4=; b=dzanuMKUFyt8XFvAW++8zP2aQ3lZU4nsxEF4W2HXgX3INmny7m55Z4SYmUhODKnOCh 9O6Vjmvf4LIgYdK4CB0wbk5yonLYwN+vpxvy7guN1JxNSUh1E5SB55oV/pukdi7+Wv6K ZlI3TfabmMQXNgGpqT2kCmUfoFgd/iDhartcY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=DC9ar6WVuy8H//hRbG7nMUtpZuF4AvspHn0mVs8y4F4=; b=PblDNPhBcgkvHJrjfky+JaPYWQVHTZXDOe/VAz5aovynr/GQwHrKcx9WhSkdIOy2Zp BeykKl6qcBpg1qfZ5ZpLHtljd6yfq6FoVAAy2H4stVbyK+h22gE5bBfm4r9l5nN/cesE M2dsqXm2lpIzEHb43Uf/0/3FPyta4Ava9c5++PbZvnSxtAK/Z2Zg3UpXQRshcFQLAskN doWzk0Fm3WSZ66RfhZms3ylSe2x2zifpD9DtlnR6eY/oItSvCbW/nsVcqHmPziz66yfo /fHYVyU1KFJzuCmtNiXHtw6H8zXJSS97apiJV+7vxJzWso4jcnd29AfRGWqJnSP3EkDv Trdg== X-Gm-Message-State: AOAM532HF+eNAK4WAdPCJR8ouE5jRpoI1KRlEUMZK2ZjeL0NkMwvBUNc qoM3hsAHj+7nP5jHfDwDFjkbfw== X-Google-Smtp-Source: ABdhPJwhHDhcrRl1hoquPk1uVIXdYrKQmJhG0BOzDhXrDr+tJG0QcTjI1W96DDU6NAzAp9Cnx2IYBg== X-Received: by 2002:a17:907:6d0b:b0:6e8:b449:df70 with SMTP id sa11-20020a1709076d0b00b006e8b449df70mr3383233ejc.533.1649784799698; Tue, 12 Apr 2022 10:33:19 -0700 (PDT) Received: from capella.. (80.71.142.18.ipv4.parknet.dk. [80.71.142.18]) by smtp.gmail.com with ESMTPSA id o3-20020aa7dd43000000b00419db53ae65sm56142edw.7.2022.04.12.10.33.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 10:33:19 -0700 (PDT) From: =?UTF-8?q?Alvin=20=C5=A0ipraga?= To: Greg Kroah-Hartman , Sasha Levin , stable@vger.kernel.org, Linus Walleij , Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , =?UTF-8?q?Alvin=20=C5=A0ipraga?= , Luiz Angelo Daros de Luca Cc: Michael Rasmussen , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH stable 5.16+ 3/3] net: dsa: realtek: make interface drivers depend on OF Date: Tue, 12 Apr 2022 19:32:52 +0200 Message-Id: <20220412173253.2247196-4-alvin@pqrs.dk> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220412173253.2247196-1-alvin@pqrs.dk> References: <20220412173253.2247196-1-alvin@pqrs.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alvin =C5=A0ipraga [ Upstream commit 109d899452ba17996eccec7ae8249fb1f8900a16 ] The kernel test robot reported build warnings with a randconfig that built realtek-{smi,mdio} without CONFIG_OF set. Since both interface drivers are using OF and will not probe without, add the corresponding dependency to Kconfig. Link: https://lore.kernel.org/all/202203231233.Xx73Y40o-lkp@intel.com/ Link: https://lore.kernel.org/all/202203231439.ycl0jg50-lkp@intel.com/ Fixes: aac94001067d ("net: dsa: realtek: add new mdio interface for drivers= ") Fixes: 765c39a4fafe ("net: dsa: realtek: convert subdrivers into modules") Signed-off-by: Alvin =C5=A0ipraga Reviewed-by: Andrew Lunn Acked-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20220323124225.91763-1-alvin@pqrs.dk Signed-off-by: Jakub Kicinski [alsi: backport to 5.16: remove mdio part] Cc: stable@vger.kernel.org # v5.16+ Signed-off-by: Alvin =C5=A0ipraga --- drivers/net/dsa/realtek/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/dsa/realtek/Kconfig b/drivers/net/dsa/realtek/Kcon= fig index 1c62212fb0ec..1315896ed6e2 100644 --- a/drivers/net/dsa/realtek/Kconfig +++ b/drivers/net/dsa/realtek/Kconfig @@ -14,6 +14,7 @@ menuconfig NET_DSA_REALTEK config NET_DSA_REALTEK_SMI tristate "Realtek SMI connected switch driver" depends on NET_DSA_REALTEK + depends on OF default y help Select to enable support for registering switches connected --=20 2.35.1