Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp4438189rwl; Tue, 28 Mar 2023 07:04:47 -0700 (PDT) X-Google-Smtp-Source: AKy350a3O2IL725H5pzE978rSgv8qy3Qg58ySrc4rSzg6xBpHyBPqU+j3gas2NGvKBv+ib+uM3nt X-Received: by 2002:aa7:d758:0:b0:502:233e:af49 with SMTP id a24-20020aa7d758000000b00502233eaf49mr14549128eds.4.1680012287035; Tue, 28 Mar 2023 07:04:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680012287; cv=none; d=google.com; s=arc-20160816; b=uADxa0z4UGu0Ok2plrLWaf/SNuwU9bYJ67SyPKXrG29YYrvZ1Os3am/IJKobKkRAUF CH3UeUoMWBNsPqG+J0iJYZNxGsJ9Oq+8tcHH19jAfbyHu1Z6niDXy7raIoZjDbdPDcLq zfbQrClNensePJIR5DGB+mW2r9IQurwqZScegD/BVh6QNB1POmxoUOcBQp2/TQyo8RMF 8pP5oXCxp4xmMBIqfSRrtdEb1Me4DR3DFG6N7dMmXEHIWbe0NhoMi9qGxeh2FJCwuxRC CJVBQm8fDBRsQe/J0MQ70mYxf+mNm5AWOk88H3B9mWp240bZPmS2rZ8/Ip8ICf8Urm73 Ptfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=v+3vKgAYziYUNd1/YtEm0M2tEuJj+3Sc+fTWjNKvGfM=; b=0qse2JUx/xuq1fIHXQNCamgBg20cSSXBo5yXdzXKjYvVJhvbuQxeYwhv16UBZ460lM tlCZof1AITX1n8r/+kjK9wUUpE+988eETX7HW/pYc1Zqcr5bGMGwQt2eVWRxXWGjdBQg mSZYKlMO+ft8FWvDNZcwcgAFSx42fKXalU1c2+RBVkrgWZfGr6qFJ3s8rjpI+FU3DMF5 8hKywQ7/Kd+s/LR3cbpyGwuR0l+6a+/aengAdEM7S2Hl0h0ldn/I99sgm9SSd9CS4WpK hk2S5gFKYrdtz8Kb2so5Pm+PpYDf+PHGu0zBPTR5E3RhA72T4KCZLNTBa0Y3DGqKCx8d B8Mg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=AA0Yc10U; 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=lunn.ch Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e1-20020a50fb81000000b005021f0d575esi13041312edq.677.2023.03.28.07.04.21; Tue, 28 Mar 2023 07:04:47 -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=@lunn.ch header.s=20171124 header.b=AA0Yc10U; 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=lunn.ch Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232970AbjC1OAo (ORCPT + 99 others); Tue, 28 Mar 2023 10:00:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233028AbjC1OAH (ORCPT ); Tue, 28 Mar 2023 10:00:07 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 986B2CC33; Tue, 28 Mar 2023 06:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=v+3vKgAYziYUNd1/YtEm0M2tEuJj+3Sc+fTWjNKvGfM=; b=AA0Yc10UggUYifkJN5+9WMeg/m NbiCMrPKVFf6g1DW046vTIOwTs44SSQzGVWuxI1tzR7ly2TQhW5HM+jXggnfndYrHltFlTBSEKcKL 9Xg60iIePWc/Y02BGM6fzgQXzmsW5vJcupJ3NPHBIUAQVko6k3bM+WZB5g+ETK3UtLf4=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1ph9r3-008eUK-Ek; Tue, 28 Mar 2023 15:59:17 +0200 Date: Tue, 28 Mar 2023 15:59:17 +0200 From: Andrew Lunn To: Daniel Golle Cc: netdev@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Matthias Brugger , AngeloGioacchino Del Regno , Sean Wang , Landen Chao , DENG Qingfang , Philipp Zabel , Sam Shih , Lorenzo Bianconi , John Crispin , Felix Fietkau Subject: Re: [RFC PATCH net-next 2/2] net: dsa: mt7530: introduce MMIO driver for MT7988 SoC Message-ID: <7e6915bf-f773-4644-b0a7-3cd0730dad8b@lunn.ch> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=unavailable 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 > I agree that using regmap would be better and I have evaluated that > approach as well. As regmap doesn't allow lock-skipping and mt7530.c is > much more complex than xrs700x in the way indirect access to its MDIO bus > and interrupts work, using regmap accessors for everything would not be > trivial. O.K, so lets go another way. Study the low level accesors, and put an abstraction over them. Provide an MDIO set and an MMIO set. > To illustrate what I'm talking about, let me show some examples in the > current code for which I don't see a way to use regmap: > 634) static int > 635) mt7531_ind_c45_phy_read(struct mt7530_priv *priv, int port, int devad, > 636) int regnum) > 637) { > 638) struct mii_bus *bus = priv->bus; > 639) struct mt7530_dummy_poll p; > 640) u32 reg, val; > 641) int ret; > 642) > 643) INIT_MT7530_DUMMY_POLL(&p, priv, MT7531_PHY_IAC); > 644) > 645) mutex_lock_nested(&bus->mdio_lock, MDIO_MUTEX_NESTED); So you need an abstract lock() and an unlock(). Maybe the MMIO implementation is a NOP? And the MDIO implementation does a real lock? > 646) > 647) ret = readx_poll_timeout(_mt7530_unlocked_read, &p, val, > 648) !(val & MT7531_PHY_ACS_ST), 20, 100000); _mt7530_unlocked_read and presumably _mt7530_unlocked_write()? > 649) if (ret < 0) { > 650) dev_err(priv->dev, "poll timeout\n"); > 651) goto out; > 652) } > 653) > 654) reg = MT7531_MDIO_CL45_ADDR | MT7531_MDIO_PHY_ADDR(port) | > 655) MT7531_MDIO_DEV_ADDR(devad) | regnum; > 656) mt7530_mii_write(priv, MT7531_PHY_IAC, reg | MT7531_PHY_ACS_ST); mt7530_write() and mt7530_read() Put the MDIO accessors in the _mdio.c file, and the MMIO accessors in the _mmio.c file. Pass them to the core. If you have the abstraction correct, the core should not care how the registers are accessed. Andrew