Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1305346 > unrolled thread
| Started by | Sjoerd Simons <sjoerd.simons@collabora.co.uk> |
|---|---|
| First post | 2016-01-09 19:50 +0100 |
| Last post | 2016-01-14 21:30 +0100 |
| Articles | 5 — 4 participants |
Back to article view | Back to linux.kernel
[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
| From | Sjoerd Simons <sjoerd.simons@collabora.co.uk> |
|---|---|
| Date | 2016-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]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2016-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]
| From | Andrew Lunn <andrew@lunn.ch> |
|---|---|
| Date | 2016-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]
| From | Florian Fainelli <f.fainelli@gmail.com> |
|---|---|
| Date | 2016-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]
| From | Sjoerd Simons <sjoerd.simons@collabora.co.uk> |
|---|---|
| Date | 2016-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