From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Milind Parab <mparab@cadence.com>
Cc: "nicolas.nerre@microchip.com" <nicolas.nerre@microchip.com>,
"andrew@lunn.ch" <andrew@lunn.ch>,
"antoine.tenart@bootlin.com" <antoine.tenart@bootlin.com>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dhananjay Vilasrao Kangude <dkangude@cadence.com>,
"a.fatoum@pengutronix.de" <a.fatoum@pengutronix.de>,
"brad.mouring@ni.com" <brad.mouring@ni.com>,
Parshuram Raju Thombare <pthombar@cadence.com>
Subject: Re: [PATCH 1/3] net: macb: fix for fixed-link mode
Date: Tue, 10 Dec 2019 11:38:30 +0000 [thread overview]
Message-ID: <20191210113829.GT25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <BY5PR07MB6514923C4D3127F43C54FE5ED35B0@BY5PR07MB6514.namprd07.prod.outlook.com>
On Tue, Dec 10, 2019 at 09:14:13AM +0000, Milind Parab wrote:
> >> This patch fix the issue with fixed link. With fixed-link
> >> device opening fails due to macb_phylink_connect not
> >> handling fixed-link mode, in which case no MAC-PHY connection
> >> is needed and phylink_connect return success (0), however
> >> in current driver attempt is made to search and connect to
> >> PHY even for fixed-link.
> >>
> >> Signed-off-by: Milind Parab <mparab@cadence.com>
> >> ---
> >> drivers/net/ethernet/cadence/macb_main.c | 17 ++++++++---------
> >> 1 file changed, 8 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> >> index 9c767ee252ac..6b68ef34ab19 100644
> >> --- a/drivers/net/ethernet/cadence/macb_main.c
> >> +++ b/drivers/net/ethernet/cadence/macb_main.c
> >> @@ -615,17 +615,13 @@ static int macb_phylink_connect(struct macb *bp)
> >> {
> >> struct net_device *dev = bp->dev;
> >> struct phy_device *phydev;
> >> + struct device_node *dn = bp->pdev->dev.of_node;
> >> int ret;
> >>
> >> - if (bp->pdev->dev.of_node &&
> >> - of_parse_phandle(bp->pdev->dev.of_node, "phy-handle", 0)) {
> >> - ret = phylink_of_phy_connect(bp->phylink, bp->pdev-
> >>dev.of_node,
> >> - 0);
> >> - if (ret) {
> >> - netdev_err(dev, "Could not attach PHY (%d)\n", ret);
> >> - return ret;
> >> - }
> >> - } else {
> >> + if (dn)
> >> + ret = phylink_of_phy_connect(bp->phylink, dn, 0);
> >> +
> >> + if (!dn || (ret && !of_parse_phandle(dn, "phy-handle", 0))) {
> >
> >Hi,
> >If of_parse_phandle() returns non-null, the device_node it returns will
> >have its reference count increased by one. That reference needs to be
> >put.
> >
>
> Okay, as per your suggestion below addition will be okay to store the "phy_node" and then of_node_put(phy_node) on error
>
> phy_node = of_parse_phandle(dn, "phy-handle", 0);
> if (!dn || (ret && !phy_node)) {
> phydev = phy_find_first(bp->mii_bus);
...
> if (phy_node)
> of_node_put(phy_node);
As you're only interested in whether phy-handle exists or not, you
could do this instead:
phy_node = of_parse_phandle(dn, "phy-handle", 0);
of_node_put(phy_node);
if (!dn || (ret && !phy_node)) {
...
Yes, it looks a bit weird, but the only thing you're interested in
here is whether of_parse_phandle() returned NULL or non-NULL. You're
not interested in dereferencing the pointer.
Some may raise some eye-brows at that, so it may be better to have
this as a helper:
static bool macb_phy_handle_exists(struct device_node *dn)
{
dn = of_parse_phandle(dn, "phy-handle", 0);
of_node_put(dn);
return dn != NULL;
}
and use it as:
if (!dn || (ret && !macb_phy_handle_exists(dn))) {
which is more obvious what is going on.
>
> return ret;
>
> >I assume you're trying to determine whether phylink_of_phy_connect()
> >failed because of a missing phy-handle rather than of_phy_attach()
> >failing? Maybe those two failures ought to be distinguished by errno
> >return value?
>
> Yes, PHY will be scanned only if phylink_of_phy_connect() returns error due to missing "phy-handle".
> Currently, phylink_of_phy_connect() returns same error for missing "phy-handle" and of_phy_attach() failure.
>
> >of_phy_attach() may fail due to of_phy_find_device() failing to find
> >the PHY, or phy_attach_direct() failing. We could switch from using
> >of_phy_attach(), to using of_phy_find_device() directly so we can then
> >propagate phy_attach_direct()'s error code back, rather than losing it.
> >That would then leave the case of of_phy_find_device() failure to be
> >considered in terms of errno return value.
Here's a patch I quickly knocked up that does this - may not apply to
the kernel you're using as there's a whole bunch of work I have
outstanding, but gives the outline idea. Does this help?
8<===
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] net: phylink: avoid of_phy_attach()
of_phy_attach() hides the return value of phy_attach_direct(), forcing
us to return a "generic" ENODEV error code that is indistinguishable
from the lack-of-phy-property case.
Switch to using of_phy_find_device() to find the PHY device, and then
propagating any phy_attach_direct() error back to the caller.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/phylink.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index e9036b72114c..5a5109428d9e 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -887,14 +887,17 @@ int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn,
return 0;
}
- phy_dev = of_phy_attach(pl->netdev, phy_node, flags,
- pl->link_interface);
+ phy_dev = of_phy_find_device(phy_node);
/* We're done with the phy_node handle */
of_node_put(phy_node);
-
if (!phy_dev)
return -ENODEV;
+ ret = phy_attach_direct(pl->netdev, phy_dev, flags,
+ pl->link_interface);
+ if (ret)
+ return ret;
+
ret = phylink_bringup_phy(pl, phy_dev, pl->link_config.interface);
if (ret)
phy_detach(phy_dev);
--
2.20.1
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
next prev parent reply other threads:[~2019-12-10 11:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 11:13 [PATCH 0/3] net: macb: fix for fixed link, support for c45 mdio and 10G Milind Parab
2019-12-09 11:14 ` [PATCH 1/3] net: macb: fix for fixed-link mode Milind Parab
2019-12-09 11:26 ` Russell King - ARM Linux admin
2019-12-10 9:14 ` Milind Parab
2019-12-10 11:38 ` Russell King - ARM Linux admin [this message]
2019-12-11 8:21 ` Milind Parab
2019-12-09 11:15 ` [PATCH 2/3] net: macb: add support for C45 MDIO read/write Milind Parab
2019-12-09 11:16 ` [PATCH 3/3] net: macb: add support for high speed interface Milind Parab
2019-12-09 11:36 ` Russell King - ARM Linux admin
2019-12-10 11:20 ` Milind Parab
2019-12-10 13:33 ` Andrew Lunn
2019-12-11 9:20 ` Milind Parab
[not found] ` <20191210114053.GU25745@shell.armlinux.org.uk>
[not found] ` <BY5PR07MB65147AEF32345E351E920188D35A0@BY5PR07MB6514.namprd07.prod.outlook.com>
2019-12-11 9:37 ` Russell King - ARM Linux admin
2019-12-11 11:55 ` Milind Parab
-- strict thread matches above, loose matches on Subject: below --
2019-11-26 9:09 [PATCH 0/3] net: macb: cover letter Milind Parab
2019-11-26 9:09 ` [PATCH 1/3] net: macb: fix for fixed-link mode Milind Parab
2019-11-26 14:30 ` Andrew Lunn
2019-11-27 18:02 ` Nicolas.Ferre
2019-11-28 6:50 ` Milind Parab
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=20191210113829.GT25745@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=a.fatoum@pengutronix.de \
--cc=andrew@lunn.ch \
--cc=antoine.tenart@bootlin.com \
--cc=brad.mouring@ni.com \
--cc=davem@davemloft.net \
--cc=dkangude@cadence.com \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mparab@cadence.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.nerre@microchip.com \
--cc=pthombar@cadence.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.