Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp2866185pxb; Mon, 18 Apr 2022 09:52:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVC8B2oB08FSRPqbbiCj6Wn1IcbCtdH/ANDxm2FTKGkzwAhcWyyRq4+SP47SMIYVGUvx1X X-Received: by 2002:a17:906:1cd1:b0:6ec:c59:6a1d with SMTP id i17-20020a1709061cd100b006ec0c596a1dmr9143524ejh.77.1650300777740; Mon, 18 Apr 2022 09:52:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650300777; cv=none; d=google.com; s=arc-20160816; b=Kic51L6QZXPpg0m0G0dP2bfK6PFzPKUrV1po1u5AB43HOOagW9xiHdPGyl5EOooefg VHDKj9Mb3CfOrbWS/LSBRPFW7aTSV8CbECBHrNEXrmxniHLHtyCyPZRTP+YJ2xXddX2s ltV6Sn6XfLF+vXaoRGMbRISPu9N1mvKse+rIjr6Q9UzbHFfjQ/a6OQE8Rrru3yxJu/tq HY9AgMy3V5zqP4cpbOb4Put784DIz72BOqI1b4uJMG1TquSpfSGAuIEPiL4XaiJCBeZG Bh/ihW3E70JPtjSh8E6IZ5bLatXOZHC7kiwNiw3uLvEDn1JmNmxydVYT6dYep1Vl1f/E oZPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=VBT4bik3SfLWIVtsfa+3vz0VoVlWoSFEqTCBlQA5IO4=; b=wXtmCIhzbLNOmkIcpH7AMuV9+hKcM6+tCwYU0u5AVGqTgbEVSewhN5WGWtfmb9CGp7 Tp7+0FpEtOXAuNqAaJ4RyER8xJmAat6i8T9RWmma9JmjOXHAeLsRAsShTCVylkT42VCE MrfQBNBI6rjjgBpU6+EpidZ7n3S/+9RDduqNKt+iIiJmE4c4g0zoGDG0C1Zeo/haT6kk YMZf+LPTqF3EVnEM5a1KU/usYYmc2HQwBo4NQAxItJrc4/RRxTgzO9l5wJtQMBEO2or0 k9i+fzayotC/gVwZ1Ja3iYkARAQ7V2x2ZcUuiwp8/4aPWHgO+qL6Buyh6NuJZTQC0f1K QrLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=U9xERDq3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t19-20020a056402525300b00418c2b5bdf2si7437471edd.212.2022.04.18.09.52.33; Mon, 18 Apr 2022 09:52:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=U9xERDq3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238120AbiDRMSP (ORCPT + 99 others); Mon, 18 Apr 2022 08:18:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238123AbiDRMSA (ORCPT ); Mon, 18 Apr 2022 08:18:00 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEA16E0F4; Mon, 18 Apr 2022 05:15:20 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 79A7860F09; Mon, 18 Apr 2022 12:15:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AD09C385A1; Mon, 18 Apr 2022 12:15:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650284119; bh=2dPRE+Zv1VmQOig1vPhXOzPvKQh29twZf5djrYUW3kE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U9xERDq3C+VjCBsfECAwLp0DAPfb+G15wPuxApsxFA9CBu+OiYhJYpRglttWCvWoT oRv8eqZldCvBxpHAOeJTkpdBwtxOO0hT4OwSsV2pLvwn82IdLikXBMXctF/C7o9GLV iSrgOKtVzsujmqVHB/s5cEznv1Y5EaCb/BZxicc0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Alvin=20=C5=A0ipraga?= , Vladimir Oltean , "David S. Miller" Subject: [PATCH 5.17 005/219] net: dsa: realtek: allow subdrivers to externally lock regmap Date: Mon, 18 Apr 2022 14:09:34 +0200 Message-Id: <20220418121203.623778576@linuxfoundation.org> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220418121203.462784814@linuxfoundation.org> References: <20220418121203.462784814@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alvin Šipraga commit 907e772f6f6debb610ea28298ab57b31019a4edb upstream. 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 Šipraga Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller [alsi: backport to 5.16: s/priv/smi/g and remove realtek-mdio changes] Signed-off-by: Alvin Šipraga Signed-off-by: Greg Kroah-Hartman --- 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(-) --- 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, u return realtek_smi_read_reg(smi, reg, val); } -static const struct regmap_config realtek_smi_mdio_regmap_config = { +static void realtek_smi_lock(void *ctx) +{ + struct realtek_smi *smi = ctx; + + mutex_lock(&smi->map_lock); +} + +static void realtek_smi_unlock(void *ctx) +{ + struct realtek_smi *smi = ctx; + + mutex_unlock(&smi->map_lock); +} + +static const struct regmap_config realtek_smi_regmap_config = { .reg_bits = 10, /* A4..A0 R4..R0 */ .val_bits = 16, .reg_stride = 1, @@ -325,6 +339,21 @@ static const struct regmap_config realte .reg_read = realtek_smi_read, .reg_write = realtek_smi_write, .cache_type = REGCACHE_NONE, + .lock = realtek_smi_lock, + .unlock = realtek_smi_unlock, +}; + +static const struct regmap_config realtek_smi_nolock_regmap_config = { + .reg_bits = 10, /* A4..A0 R4..R0 */ + .val_bits = 16, + .reg_stride = 1, + /* PHY regs are at 0x8000 */ + .max_register = 0xffff, + .reg_format_endian = REGMAP_ENDIAN_BIG, + .reg_read = realtek_smi_read, + .reg_write = realtek_smi_write, + .cache_type = REGCACHE_NONE, + .disable_locking = true, }; static int realtek_smi_mdio_read(struct mii_bus *bus, int addr, int regnum) @@ -388,6 +417,7 @@ static int realtek_smi_probe(struct plat const struct realtek_smi_variant *var; struct device *dev = &pdev->dev; struct realtek_smi *smi; + struct regmap_config rc; struct device_node *np; int ret; @@ -398,13 +428,25 @@ static int realtek_smi_probe(struct plat if (!smi) return -ENOMEM; smi->chip_data = (void *)smi + sizeof(*smi); - smi->map = devm_regmap_init(dev, NULL, smi, - &realtek_smi_mdio_regmap_config); + + mutex_init(&smi->map_lock); + + rc = realtek_smi_regmap_config; + rc.lock_arg = smi; + smi->map = devm_regmap_init(dev, NULL, smi, &rc); if (IS_ERR(smi->map)) { ret = PTR_ERR(smi->map); dev_err(dev, "regmap init failed: %d\n", ret); return ret; } + + rc = realtek_smi_nolock_regmap_config; + smi->map_nolock = devm_regmap_init(dev, NULL, smi, &rc); + if (IS_ERR(smi->map_nolock)) { + ret = PTR_ERR(smi->map_nolock); + dev_err(dev, "regmap init failed: %d\n", ret); + return ret; + } /* Link forward and backward */ smi->dev = dev; --- 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; unsigned int clk_delay;