Message ID | 20230515195922.617243-1-afd@ti.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp7159151vqo; Mon, 15 May 2023 13:01:41 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5ldaOu9YIwJeSHfmJiS6mk1wYGu2lMagXLKs9I49k04qaLhshDphah2L8DuhBBTY+KSLSX X-Received: by 2002:a17:902:eccd:b0:1a6:4127:857 with SMTP id a13-20020a170902eccd00b001a641270857mr48870501plh.5.1684180901560; Mon, 15 May 2023 13:01:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684180901; cv=none; d=google.com; s=arc-20160816; b=vwqNwE2PzqusbDi2B4oJO+kKeNRjDIIn1n6PSul/3YH9RP7SHZS0aOYy2RtMi3cegm Aw7MqdcplgXaHXPp1CtgFs+9Ch/xcQE4Cl7O70xqDtTbSk7rFoV01sk3DDLy788zJ7Vm 08egu379SC9W46I3ZKSNguCrCEA5nyDg618IViA9VpM/wBvydEIQV8CBDqQVS+Hs6Gq8 uSnHWNjU8ru16Xm3aOaJ6qK18Bfs21UohXEyqc2tlsBmp5kjDhPInsbc3OuUANOd3n4D gw7ag0xcp9FO+PR8R5hGbIsitT4F7E1IiwXmMf4nNyVEFLQ+jFPW9gG7utm/bgAZDnrL JFOQ== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=ZMmu+Jtm+xCqgH0l6TlKmPYujrA59t9EtYDFwsokG04=; b=L/TsQA5VV19VVFMe9MOwlUGfmeEFTS2ULDafjKPcYzOqSlJz8vl6urWWIp0JtMxloH zg5GMY//LAE5DHPbyoWc2eBDXjCHzgu2W4pV1beE0fveKAkb1mtQqSeO+Uh8EVoqcdng E/Gzyy5fkZLGqg0wLIUAh2TfjAeZ4q10HrwuJ1URrnV7iM3EKNIfEFD8acFZ1Q6oxBJu 5Xa+dpLsVQIGKW/npKZHeHfwfck5I8njGjmRIAP8M8cqctfMAK0GLBC1e2EZgzry+a71 kN3rhDv17Z3r/dUL5KrGWmuCED9Shn2wX3gYalnI4qGEZphDw5dw4Urz0ufgofqSpTXK L7QA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b="rr5h/hQX"; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l20-20020a170903005400b001add2b13fb4si9881878pla.620.2023.05.15.13.00.50; Mon, 15 May 2023 13:01:41 -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=@ti.com header.s=ti-com-17Q1 header.b="rr5h/hQX"; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244299AbjEOT7f (ORCPT <rfc822;peekingduck44@gmail.com> + 99 others); Mon, 15 May 2023 15:59:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243501AbjEOT7e (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 15 May 2023 15:59:34 -0400 Received: from fllv0015.ext.ti.com (fllv0015.ext.ti.com [198.47.19.141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1085658D for <linux-kernel@vger.kernel.org>; Mon, 15 May 2023 12:59:31 -0700 (PDT) Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 34FJxO41053692; Mon, 15 May 2023 14:59:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1684180764; bh=ZMmu+Jtm+xCqgH0l6TlKmPYujrA59t9EtYDFwsokG04=; h=From:To:CC:Subject:Date; b=rr5h/hQX+ekYn7BB4x4Osx2Ojjg0N5sq7Mvj3ZI7Xkm2bQ0YhjJ058Z1uxRi9MFxt OlOv0m+562OQNvLuCClXxrtu+AcuyDSxU1Dgw+O+64hqgxSiHgSGPYSew1FZ2O5oif HUTuv1PC9Ub9mpc7o/1rKi3V16+wqlCf+HDsLM8s= Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 34FJxO4S065727 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 15 May 2023 14:59:24 -0500 Received: from DLEE105.ent.ti.com (157.170.170.35) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 15 May 2023 14:59:23 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DLEE105.ent.ti.com (157.170.170.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 15 May 2023 14:59:23 -0500 Received: from fllv0039.itg.ti.com (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 34FJxNP9016442; Mon, 15 May 2023 14:59:23 -0500 From: Andrew Davis <afd@ti.com> To: Vinod Koul <vkoul@kernel.org>, Kishon Vijay Abraham I <kishon@kernel.org>, Siddharth Vadapalli <s-vadapalli@ti.com>, Roger Quadros <rogerq@kernel.org> CC: <linux-phy@lists.infradead.org>, <linux-kernel@vger.kernel.org>, Andrew Davis <afd@ti.com> Subject: [PATCH] phy: ti: gmii-sel: Allow parent to not be syscon node Date: Mon, 15 May 2023 14:59:22 -0500 Message-ID: <20230515195922.617243-1-afd@ti.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765991673238733754?= X-GMAIL-MSGID: =?utf-8?q?1765991673238733754?= |
Series |
phy: ti: gmii-sel: Allow parent to not be syscon node
|
|
Commit Message
Andrew Davis
May 15, 2023, 7:59 p.m. UTC
If the parent node is not a syscon type, then fallback and check
if we can get a regmap from our own node. This no longer forces
us to make the parent of this node a syscon node when that might
not be appropriate.
Signed-off-by: Andrew Davis <afd@ti.com>
---
drivers/phy/ti/phy-gmii-sel.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Comments
Andrew, On 16/05/23 01:29, Andrew Davis wrote: > If the parent node is not a syscon type, then fallback and check > if we can get a regmap from our own node. This no longer forces > us to make the parent of this node a syscon node when that might > not be appropriate. Could you please let me know in which cases it is appropriate versus in which cases it isn't? Is syscon_node_to_regmap() being retained for backward compatibility until the device-tree nodes are cleaned up across all devices? > > Signed-off-by: Andrew Davis <afd@ti.com> > --- > drivers/phy/ti/phy-gmii-sel.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c > index 8c667819c39a..1e67ed9a5cf6 100644 > --- a/drivers/phy/ti/phy-gmii-sel.c > +++ b/drivers/phy/ti/phy-gmii-sel.c > @@ -435,9 +435,12 @@ static int phy_gmii_sel_probe(struct platform_device *pdev) > > priv->regmap = syscon_node_to_regmap(node->parent); > if (IS_ERR(priv->regmap)) { > - ret = PTR_ERR(priv->regmap); > - dev_err(dev, "Failed to get syscon %d\n", ret); > - return ret; > + priv->regmap = device_node_to_regmap(node); If device_node_to_regmap() can always be used with the corresponding changes made to the device-tree nodes, wouldn't it be better to use it directly instead of using it as a fallback? (This is based on the assumption that syscon_node_to_regmap() is only being retained until the device-tree nodes are cleaned up to work with device_node_to_regmap()). > + if (IS_ERR(priv->regmap)) { > + ret = PTR_ERR(priv->regmap); > + dev_err(dev, "Failed to get syscon %d\n", ret); > + return ret; > + } > } > > ret = phy_gmii_sel_init_ports(priv);
Hi Andrew, On 15/05/2023 22:59, Andrew Davis wrote: > If the parent node is not a syscon type, then fallback and check > if we can get a regmap from our own node. This no longer forces > us to make the parent of this node a syscon node when that might > not be appropriate. Trying to understand the motive for this and if it is better to introduce a "syscon = <&syscon_node>" property instead which makes it fool proof for all cases. > > Signed-off-by: Andrew Davis <afd@ti.com> > --- > drivers/phy/ti/phy-gmii-sel.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c > index 8c667819c39a..1e67ed9a5cf6 100644 > --- a/drivers/phy/ti/phy-gmii-sel.c > +++ b/drivers/phy/ti/phy-gmii-sel.c > @@ -435,9 +435,12 @@ static int phy_gmii_sel_probe(struct platform_device *pdev) > > priv->regmap = syscon_node_to_regmap(node->parent); > if (IS_ERR(priv->regmap)) { > - ret = PTR_ERR(priv->regmap); > - dev_err(dev, "Failed to get syscon %d\n", ret); > - return ret; > + priv->regmap = device_node_to_regmap(node); > + if (IS_ERR(priv->regmap)) { > + ret = PTR_ERR(priv->regmap); > + dev_err(dev, "Failed to get syscon %d\n", ret); > + return ret; > + } > } > > ret = phy_gmii_sel_init_ports(priv);
On 5/15/23 11:05 PM, Siddharth Vadapalli wrote: > Andrew, > > On 16/05/23 01:29, Andrew Davis wrote: >> If the parent node is not a syscon type, then fallback and check >> if we can get a regmap from our own node. This no longer forces >> us to make the parent of this node a syscon node when that might >> not be appropriate. > > Could you please let me know in which cases it is appropriate versus in which > cases it isn't? Use of syscon nodes should be discouraged, in most cases they can and should be avoided. The only time we would need to have a syscon parent is when the register space contains multiple sub-devices with bit level interleaving. Most devices should never need syscon, we overuse syscon due to driver like this that have no other option than to make the parent device a syscon node. > Is syscon_node_to_regmap() being retained for backward > compatibility until the device-tree nodes are cleaned up across all devices? > Yes, the old way is left only for backwards compatibility. >> >> Signed-off-by: Andrew Davis <afd@ti.com> >> --- >> drivers/phy/ti/phy-gmii-sel.c | 9 ++++++--- >> 1 file changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c >> index 8c667819c39a..1e67ed9a5cf6 100644 >> --- a/drivers/phy/ti/phy-gmii-sel.c >> +++ b/drivers/phy/ti/phy-gmii-sel.c >> @@ -435,9 +435,12 @@ static int phy_gmii_sel_probe(struct platform_device *pdev) >> >> priv->regmap = syscon_node_to_regmap(node->parent); >> if (IS_ERR(priv->regmap)) { >> - ret = PTR_ERR(priv->regmap); >> - dev_err(dev, "Failed to get syscon %d\n", ret); >> - return ret; >> + priv->regmap = device_node_to_regmap(node); > > If device_node_to_regmap() can always be used with the corresponding changes > made to the device-tree nodes, wouldn't it be better to use it directly instead > of using it as a fallback? (This is based on the assumption that > syscon_node_to_regmap() is only being retained until the device-tree nodes are > cleaned up to work with device_node_to_regmap()). > Yes, that could work too. I was trying to make the minimal changes here, but if we feel it works better we can have the default be to check the self node first. Andrew >> + if (IS_ERR(priv->regmap)) { >> + ret = PTR_ERR(priv->regmap); >> + dev_err(dev, "Failed to get syscon %d\n", ret); >> + return ret; >> + } >> } >> >> ret = phy_gmii_sel_init_ports(priv); >
On 5/16/23 1:33 PM, Roger Quadros wrote: > Hi Andrew, > > On 15/05/2023 22:59, Andrew Davis wrote: >> If the parent node is not a syscon type, then fallback and check >> if we can get a regmap from our own node. This no longer forces >> us to make the parent of this node a syscon node when that might >> not be appropriate. > > Trying to understand the motive for this and if it is better to > introduce a "syscon = <&syscon_node>" property instead which > makes it fool proof for all cases. > My motivation is to reduce our overuse of syscon nodes, IMHO syscon is almost always a broken design in DT and goes against the standard usage. Some drivers like this one force us to make the parent node a syscon device, even what that is not needed otherwise (the register space is standalone and the standard DT "reg" property can be used to describe the device register space). Using "syscon = <&syscon_node>" could be a useful option for devices when syscon is actually needed. But I think that should only be used when the whole node itself cannot be made a child of the syscon node, making it a child when we can is better for DT organization vs. having a bunch of top-level nodes that point around to their register spaces with phandles. Andrew >> >> Signed-off-by: Andrew Davis <afd@ti.com> >> --- >> drivers/phy/ti/phy-gmii-sel.c | 9 ++++++--- >> 1 file changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c >> index 8c667819c39a..1e67ed9a5cf6 100644 >> --- a/drivers/phy/ti/phy-gmii-sel.c >> +++ b/drivers/phy/ti/phy-gmii-sel.c >> @@ -435,9 +435,12 @@ static int phy_gmii_sel_probe(struct platform_device *pdev) >> >> priv->regmap = syscon_node_to_regmap(node->parent); >> if (IS_ERR(priv->regmap)) { >> - ret = PTR_ERR(priv->regmap); >> - dev_err(dev, "Failed to get syscon %d\n", ret); >> - return ret; >> + priv->regmap = device_node_to_regmap(node); >> + if (IS_ERR(priv->regmap)) { >> + ret = PTR_ERR(priv->regmap); >> + dev_err(dev, "Failed to get syscon %d\n", ret); >> + return ret; >> + } >> } >> >> ret = phy_gmii_sel_init_ports(priv); >
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c index 8c667819c39a..1e67ed9a5cf6 100644 --- a/drivers/phy/ti/phy-gmii-sel.c +++ b/drivers/phy/ti/phy-gmii-sel.c @@ -435,9 +435,12 @@ static int phy_gmii_sel_probe(struct platform_device *pdev) priv->regmap = syscon_node_to_regmap(node->parent); if (IS_ERR(priv->regmap)) { - ret = PTR_ERR(priv->regmap); - dev_err(dev, "Failed to get syscon %d\n", ret); - return ret; + priv->regmap = device_node_to_regmap(node); + if (IS_ERR(priv->regmap)) { + ret = PTR_ERR(priv->regmap); + dev_err(dev, "Failed to get syscon %d\n", ret); + return ret; + } } ret = phy_gmii_sel_init_ports(priv);