All of lore.kernel.org
 help / color / mirror / Atom feed
From: antoine.tenart@bootlin.com (Antoine Tenart)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH net-next v3 02/10] net: mvpp2: phylink support
Date: Fri, 31 Aug 2018 17:08:38 +0200	[thread overview]
Message-ID: <20180831150838.GE32574@kwain> (raw)
In-Reply-To: <20180831141123.GM30658@n2100.armlinux.org.uk>

Hi Russell,

On Fri, Aug 31, 2018 at 03:11:23PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 31, 2018 at 03:36:51PM +0200, Antoine Tenart wrote:
> > With the above code remove one case did not worked anymore: when the
> > port is configured as a fixed-link because the SFP cage can't be
> > described and used (on the 7040-db and 8040-db boards). In such cases
> > phylink is called, mac_config() is called, but link_up() is never
> > called. I'm not sure this is actually an issue in phylink, but the PPv2
> > driver should probably take care of this weird case itself (by calling
> > explicitly link_up()). What do you think?
> 
> Fixed link should work:
> 
> - when a fixed link is configured, link_config.link is set true.
> - when phylink_start() is called, mac_config() will be called to do the
>   initial setup, and a resolve is triggered.
> - phylink_resolve() will read the fixed link state, which in the case
>   of no GPIO, will inherit link_config.link.
>   - you will then see another mac_config() call.
> 
> Now what happens depends whether you've set the netdev's carrier state
> in the driver - if you haven't, the netdev's carrier state should be
> off.  Since the state mismatches the link_state.link (which will be
> true), you will get a mac_link_up() call.

OK, that makes sense. Thanks for the explanations.

> mvneta ensures this state by always calling netif_carrier_off() in
> mvneta_open(), maybe that ought to be in phylink_start() as that's the
> state that phylink expects when phylink_start() has been called.  So,
> maybe it's a phylink bug.
> 
> Can you see any down-sides to moving the netif_carrier_off() in
> mvneta_open() to phylink_start() ?

I removed most of my previous fix, and called netif_carrier_off() just
before phylink_start() in PPv2. I worked, and it seemed to me all cases
were working fine.

As calling netif_carrier_off() seems to be a phylink assumption, I would
agree to call it directly from within phylink_start(). But I don't have
the full picture here.

If such a solution is OK for you, and if no one raises an issue in the
next days, I can send a series to add a netif_carrier_off() call, fix
PPv2, and remove mvneta's call to netif_carrier_off() in mvneta_open().

Thanks!
Antoine

-- 
Antoine T?nart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

WARNING: multiple messages have this Message-ID (diff)
From: Antoine Tenart <antoine.tenart@bootlin.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Antoine Tenart <antoine.tenart@bootlin.com>,
	davem@davemloft.net, kishon@ti.com, gregory.clement@bootlin.com,
	andrew@lunn.ch, jason@lakedaemon.net,
	sebastian.hesselbarth@gmail.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
	maxime.chevallier@bootlin.com, miquel.raynal@bootlin.com,
	nadavh@marvell.com, stefanc@marvell.com, ymarkman@marvell.com,
	mw@semihalf.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support
Date: Fri, 31 Aug 2018 17:08:38 +0200	[thread overview]
Message-ID: <20180831150838.GE32574@kwain> (raw)
In-Reply-To: <20180831141123.GM30658@n2100.armlinux.org.uk>

Hi Russell,

On Fri, Aug 31, 2018 at 03:11:23PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 31, 2018 at 03:36:51PM +0200, Antoine Tenart wrote:
> > With the above code remove one case did not worked anymore: when the
> > port is configured as a fixed-link because the SFP cage can't be
> > described and used (on the 7040-db and 8040-db boards). In such cases
> > phylink is called, mac_config() is called, but link_up() is never
> > called. I'm not sure this is actually an issue in phylink, but the PPv2
> > driver should probably take care of this weird case itself (by calling
> > explicitly link_up()). What do you think?
> 
> Fixed link should work:
> 
> - when a fixed link is configured, link_config.link is set true.
> - when phylink_start() is called, mac_config() will be called to do the
>   initial setup, and a resolve is triggered.
> - phylink_resolve() will read the fixed link state, which in the case
>   of no GPIO, will inherit link_config.link.
>   - you will then see another mac_config() call.
> 
> Now what happens depends whether you've set the netdev's carrier state
> in the driver - if you haven't, the netdev's carrier state should be
> off.  Since the state mismatches the link_state.link (which will be
> true), you will get a mac_link_up() call.

OK, that makes sense. Thanks for the explanations.

> mvneta ensures this state by always calling netif_carrier_off() in
> mvneta_open(), maybe that ought to be in phylink_start() as that's the
> state that phylink expects when phylink_start() has been called.  So,
> maybe it's a phylink bug.
> 
> Can you see any down-sides to moving the netif_carrier_off() in
> mvneta_open() to phylink_start() ?

I removed most of my previous fix, and called netif_carrier_off() just
before phylink_start() in PPv2. I worked, and it seemed to me all cases
were working fine.

As calling netif_carrier_off() seems to be a phylink assumption, I would
agree to call it directly from within phylink_start(). But I don't have
the full picture here.

If such a solution is OK for you, and if no one raises an issue in the
next days, I can send a series to add a netif_carrier_off() call, fix
PPv2, and remove mvneta's call to netif_carrier_off() in mvneta_open().

Thanks!
Antoine

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  parent reply	other threads:[~2018-08-31 15:08 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17  8:29 [PATCH net-next v3 00/10] net: mvpp2: phylink conversion Antoine Tenart
2018-05-17  8:29 ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 01/10] net: mvpp2: align the ethtool ops definition Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 02/10] net: mvpp2: phylink support Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-08-27 16:50   ` Russell King - ARM Linux
2018-08-27 16:50     ` Russell King - ARM Linux
2018-08-31 13:36     ` Antoine Tenart
2018-08-31 13:36       ` Antoine Tenart
2018-08-31 13:36       ` Antoine Tenart
2018-08-31 14:11       ` Russell King - ARM Linux
2018-08-31 14:11         ` Russell King - ARM Linux
2018-08-31 14:37         ` Andrew Lunn
2018-08-31 14:37           ` Andrew Lunn
2018-08-31 15:21           ` Russell King - ARM Linux
2018-08-31 15:21             ` Russell King - ARM Linux
2018-09-12 14:34             ` Antoine Tenart
2018-09-12 14:34               ` Antoine Tenart
2018-08-31 15:08         ` Antoine Tenart [this message]
2018-08-31 15:08           ` Antoine Tenart
2018-08-31 14:18       ` Andrew Lunn
2018-08-31 14:18         ` Andrew Lunn
2018-08-31 14:23         ` Antoine Tenart
2018-08-31 14:23           ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 03/10] phy: add 2.5G SGMII mode to the phy_mode enum Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 04/10] phy: cp110-comphy: 2.5G SGMII mode Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 05/10] net: mvpp2: 1000baseX support Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 06/10] net: mvpp2: 2500baseX support Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 07/10] arm64: dts: marvell: mcbin: add 10G SFP support Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 08/10] arm64: dts: marvell: mcbin: enable the fourth network interface Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 09/10] arm64: dts: marvell: 8040-db: describe the 10G interfaces as fixed-link Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  8:29 ` [PATCH net-next v3 10/10] arm64: dts: marvell: 7040-db: describe the 10G interface " Antoine Tenart
2018-05-17  8:29   ` Antoine Tenart
2018-05-17  9:18 ` [PATCH net-next v3 00/10] net: mvpp2: phylink conversion Russell King - ARM Linux
2018-05-17  9:18   ` Russell King - ARM Linux
2018-05-17  9:26   ` Antoine Tenart
2018-05-17  9:26     ` Antoine Tenart
2018-05-17  9:26     ` Antoine Tenart
2018-05-17 12:23 ` Gregory CLEMENT
2018-05-17 12:23   ` Gregory CLEMENT
2018-05-17 20:12 ` David Miller
2018-05-17 20:12   ` David Miller

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=20180831150838.GE32574@kwain \
    --to=antoine.tenart@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.