Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1305346 > unrolled thread

[PATCH] net: phy: turn carrier off on phy attach

Started bySjoerd Simons <sjoerd.simons@collabora.co.uk>
First post2016-01-09 19:50 +0100
Last post2016-01-14 21:30 +0100
Articles 5 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] net: phy: turn carrier off on phy attach Sjoerd Simons <sjoerd.simons@collabora.co.uk> - 2016-01-09 19:50 +0100
    Re: [PATCH] net: phy: turn carrier off on phy attach David Miller <davem@davemloft.net> - 2016-01-11 23:20 +0100
    Re: [PATCH] net: phy: turn carrier off on phy attach Andrew Lunn <andrew@lunn.ch> - 2016-01-12 02:00 +0100
    Re: [PATCH] net: phy: turn carrier off on phy attach Florian Fainelli <f.fainelli@gmail.com> - 2016-01-13 02:40 +0100
      Re: [PATCH] net: phy: turn carrier off on phy attach Sjoerd Simons <sjoerd.simons@collabora.co.uk> - 2016-01-14 21:30 +0100

#1305346 — [PATCH] net: phy: turn carrier off on phy attach

FromSjoerd Simons <sjoerd.simons@collabora.co.uk>
Date2016-01-09 19:50 +0100
Subject[PATCH] net: phy: turn carrier off on phy attach
Message-ID<qP6Kl-Zs-13@gated-at.bofh.it>
The operstate of a networking device initially IF_OPER_UNKNOWN aka
"unknown", updated on carrier state changes (with carrier state being on
by default). This means it will stay unknown unless the carrier state
goes to off at some point, which is not the case if the phy is already
up/connected at startup.

Explicitly turn off the carrier on phy attach, leaving the phy state
machine to turn the carrier on when it has done the initial negotiation.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

---

 drivers/net/phy/phy_device.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0bfbaba..a30ce1a 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -668,6 +668,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
 
 	phydev->state = PHY_READY;
 
+	/* Signal to the core network layer the phy supports
+	 *  carrier detection
+	 */
+	netif_carrier_off(phydev->attached_dev);
+
 	/* Do initial configuration here, now that
 	 * we have certain key parameters
 	 * (dev_flags and interface)
-- 
2.7.0.rc3

[toc] | [next] | [standalone]


#1306768

FromDavid Miller <davem@davemloft.net>
Date2016-01-11 23:20 +0100
Message-ID<qPSYG-bV-15@gated-at.bofh.it>
In reply to#1305346
From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Date: Sat,  9 Jan 2016 19:44:05 +0100

> The operstate of a networking device initially IF_OPER_UNKNOWN aka
> "unknown", updated on carrier state changes (with carrier state being on
> by default). This means it will stay unknown unless the carrier state
> goes to off at some point, which is not the case if the phy is already
> up/connected at startup.
> 
> Explicitly turn off the carrier on phy attach, leaving the phy state
> machine to turn the carrier on when it has done the initial negotiation.
> 
> Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

Florian or Andrew, please review this.

Thanks.

> 
> ---
> 
>  drivers/net/phy/phy_device.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 0bfbaba..a30ce1a 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -668,6 +668,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
>  
>  	phydev->state = PHY_READY;
>  
> +	/* Signal to the core network layer the phy supports
> +	 *  carrier detection
> +	 */
> +	netif_carrier_off(phydev->attached_dev);
> +
>  	/* Do initial configuration here, now that
>  	 * we have certain key parameters
>  	 * (dev_flags and interface)
> -- 
> 2.7.0.rc3
> 

[toc] | [prev] | [next] | [standalone]


#1306873

FromAndrew Lunn <andrew@lunn.ch>
Date2016-01-12 02:00 +0100
Message-ID<qPVtw-1Mg-5@gated-at.bofh.it>
In reply to#1305346
On Sat, Jan 09, 2016 at 07:44:05PM +0100, Sjoerd Simons wrote:
> The operstate of a networking device initially IF_OPER_UNKNOWN aka
> "unknown", updated on carrier state changes (with carrier state being on
> by default). This means it will stay unknown unless the carrier state
> goes to off at some point, which is not the case if the phy is already
> up/connected at startup.
> 
> Explicitly turn off the carrier on phy attach, leaving the phy state
> machine to turn the carrier on when it has done the initial negotiation.

RFC 2863 says:

   Whenever an interface table entry is created (usually as a result
   of system initialization), the relevant instance of ifAdminStatus
   is set to down, and ifOperStatus will be down or notPresent.

and

   The notPresent state is a refinement on the down state which
   indicates that the relevant interface is down specifically because
   some component (typically, a hardware component) is not present in
   the managed system.

So if we have a PHY, setting it to down is correct with respect to the
RFC.

> Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
> 
> ---
> 
>  drivers/net/phy/phy_device.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 0bfbaba..a30ce1a 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -668,6 +668,11 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
>  
>  	phydev->state = PHY_READY;
>  
> +	/* Signal to the core network layer the phy supports
> +	 *  carrier detection
> +	 */

I don't agree with the comment. All we are doing is getting the core
state to agree with the phy state. The next thing we do with the phy
is reset it, so the carrier is going to be off.

Please rewrite the comment, and then i can give a reviewed-by.

Thanks
	Andrew

> +	netif_carrier_off(phydev->attached_dev);
> +
>  	/* Do initial configuration here, now that
>  	 * we have certain key parameters
>  	 * (dev_flags and interface)
> -- 
> 2.7.0.rc3
> 

[toc] | [prev] | [next] | [standalone]


#1307959

FromFlorian Fainelli <f.fainelli@gmail.com>
Date2016-01-13 02:40 +0100
Message-ID<qQizM-PV-5@gated-at.bofh.it>
In reply to#1305346
On January 9, 2016 10:44:05 AM PST, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
>The operstate of a networking device initially IF_OPER_UNKNOWN aka
>"unknown", updated on carrier state changes (with carrier state being
>on
>by default). This means it will stay unknown unless the carrier state
>goes to off at some point, which is not the case if the phy is already
>up/connected at startup.

Correct, drivers typically call netif_carrier_off prior to registering the network device to give a predictable link state, regardless of whether or not they use PHYLIB.

>
>Explicitly turn off the carrier on phy attach, leaving the phy state
>machine to turn the carrier on when it has done the initial
>negotiation.

Same comment as Andrew on the comment below.

Out of curiosity, was there a particular driver you ran into issues with?

-- 
Florian

[toc] | [prev] | [next] | [standalone]


#1309635

FromSjoerd Simons <sjoerd.simons@collabora.co.uk>
Date2016-01-14 21:30 +0100
Message-ID<qQWGT-3K7-17@gated-at.bofh.it>
In reply to#1307959
On Tue, 2016-01-12 at 17:31 -0800, Florian Fainelli wrote:
> On January 9, 2016 10:44:05 AM PST, Sjoerd Simons <sjoerd.simons@coll
> abora.co.uk> wrote:
> > The operstate of a networking device initially IF_OPER_UNKNOWN aka
> > "unknown", updated on carrier state changes (with carrier state
> > being
> > on
> > by default). This means it will stay unknown unless the carrier
> > state
> > goes to off at some point, which is not the case if the phy is
> > already
> > up/connected at startup.
> 
> Correct, drivers typically call netif_carrier_off prior to
> registering the network device to give a predictable link state,
> regardless of whether or not they use PHYLIB.
> 
> > 
> > Explicitly turn off the carrier on phy attach, leaving the phy
> > state
> > machine to turn the carrier on when it has done the initial
> > negotiation.
> 
> Same comment as Andrew on the comment below.
> 
> Out of curiosity, was there a particular driver you ran into issues
> with?

Prepping a v2. This came up on Rada Rock2 board, so the (Rockchip)
DWMAC driver combined with a realtek phy (RTL8211E). Thanks for the
review

-- 
Sjoerd Simons
Collabora Ltd.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web