From: Andrew Davis <afd@ti.com>
To: Roger Quadros <rogerq@kernel.org>, Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Siddharth Vadapalli <s-vadapalli@ti.com>
Cc: <linux-phy@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] phy: ti: gmii-sel: Allow parent to not be syscon node
Date: Mon, 10 Jul 2023 09:45:30 -0500 [thread overview]
Message-ID: <0d28eb47-a564-2155-875b-5c8dc8aa806e@ti.com> (raw)
In-Reply-To: <3c7d7d0b-b859-8921-952c-870c9474969c@kernel.org>
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);
>
prev parent reply other threads:[~2023-07-10 14:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 19:59 Andrew Davis
2023-05-16 4:05 ` Siddharth Vadapalli
2023-07-10 14:38 ` Andrew Davis
2023-05-16 18:33 ` Roger Quadros
2023-07-10 14:45 ` Andrew Davis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0d28eb47-a564-2155-875b-5c8dc8aa806e@ti.com \
--to=afd@ti.com \
--cc=kishon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=rogerq@kernel.org \
--cc=s-vadapalli@ti.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®