linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).