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

Groups > linux.kernel > #1718997 > unrolled thread

[PATCH net-next 00/13] net: mvpp2: comphy configuration

Back to article view | Back to linux.kernel

Contents

  [PATCH net-next 00/13] net: mvpp2: comphy configuration Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:40 +0200
    [PATCH net-next 05/13] net: mvpp2: do not force the link mode Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:40 +0200
    [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:40 +0200
      Re: [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver Andrew Lunn <andrew@lunn.ch> - 2017-08-24 15:40 +0200
        Re: [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 15:50 +0200
          Re: [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver Andrew Lunn <andrew@lunn.ch> - 2017-08-24 16:00 +0200
            RE: [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver Stefan Chulski <stefanc@marvell.com> - 2017-08-24 16:00 +0200
              Re: [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver Andrew Lunn <andrew@lunn.ch> - 2017-08-24 16:10 +0200
              Re: [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 16:10 +0200
      Re: [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver Andrew Lunn <andrew@lunn.ch> - 2017-08-24 15:50 +0200
        Re: [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 16:00 +0200
    [PATCH net-next 04/13] net: mvpp2: initialize the comphy Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:50 +0200
    [PATCH net-next 13/13] arm64: defconfig: enable Marvell CP110 comphy Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:50 +0200
    [PATCH net-next 06/13] net: mvpp2: simplify the link_event function Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:50 +0200
    [PATCH net-next 01/13] phy: add sgmii and 10gkr modes to the phy_mode enum Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:50 +0200
      Re: [PATCH net-next 01/13] phy: add sgmii and 10gkr modes to the  phy_mode enum Andrew Lunn <andrew@lunn.ch> - 2017-08-24 15:30 +0200
        Re: [PATCH net-next 01/13] phy: add sgmii and 10gkr modes to the  phy_mode enum Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 15:40 +0200
    [PATCH net-next 03/13] Documentation/bindings: phy: document the Marvell comphy driver Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:50 +0200
    [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:50 +0200
      Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Andrew Lunn <andrew@lunn.ch> - 2017-08-24 17:00 +0200
        Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 18:00 +0200
          Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Andrew Lunn <andrew@lunn.ch> - 2017-08-24 18:10 +0200
            Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 18:20 +0200
              Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Andrew Lunn <andrew@lunn.ch> - 2017-08-24 19:00 +0200
                Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-08-24 19:10 +0200
                  Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 19:20 +0200
                    RE: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic  reconfiguration of the PHY mode Stefan Chulski <stefanc@marvell.com> - 2017-08-24 19:30 +0200
              RE: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic  reconfiguration of the PHY mode Stefan Chulski <stefanc@marvell.com> - 2017-08-24 19:10 +0200
                Re: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic  reconfiguration of the PHY mode Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 19:20 +0200
                  RE: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic  reconfiguration of the PHY mode Stefan Chulski <stefanc@marvell.com> - 2017-08-24 19:20 +0200
                  Re: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic  reconfiguration of the PHY mode Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-08-25 10:30 +0200
        Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-08-24 19:10 +0200
          Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Andrew Lunn <andrew@lunn.ch> - 2017-08-24 19:50 +0200
            Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of  the PHY mode Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-08-25 00:20 +0200
    [PATCH net-next 12/13] arm64: dts: marvell: mcbin: add comphy references to Ethernet ports Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:50 +0200
      Re: [PATCH net-next 12/13] arm64: dts: marvell: mcbin: add comphy  references to Ethernet ports Andrew Lunn <andrew@lunn.ch> - 2017-08-24 16:00 +0200
        Re: [PATCH net-next 12/13] arm64: dts: marvell: mcbin: add comphy  references to Ethernet ports Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 16:10 +0200
    [PATCH net-next 08/13] net: mvpp2: check the netif is running in the link_event function Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:50 +0200
    [PATCH net-next 07/13] net: mvpp2: improve the link management function Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 10:50 +0200
      Re: [PATCH net-next 07/13] net: mvpp2: improve the link management  function Andrew Lunn <andrew@lunn.ch> - 2017-08-24 16:10 +0200
        Re: [PATCH net-next 07/13] net: mvpp2: improve the link management  function Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 16:20 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1719360 — Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

[Multipart message — attachments visible in raw view] — view raw

Hi Andrew,

On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > This patch adds logic to reconfigure the comphy/gop when the link status
> > change at runtime. This is very useful on boards such as the mcbin which
> > have SFP and Ethernet ports connected to the same MAC port: depending on
> > what the user connects the driver will automatically reconfigure the
> > link mode.
> 
> I would expect each of these external Ethernet ports to have its own
> Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> connect to the other Ethernet PHY when you change external Ethernet
> port?

That's the other way around. The engines outputs (say GoP#) are
connected to the comphy inputs. In the SoC. Then there's a single output
of this comphy lane to the board. So when switching modes, you do not
have to connect to a different Ethernet PHY, it's the same.

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

#1719376 — Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

On Thu, Aug 24, 2017 at 05:52:41PM +0200, Antoine Tenart wrote:
> Hi Andrew,
> 
> On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> > On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > > This patch adds logic to reconfigure the comphy/gop when the link status
> > > change at runtime. This is very useful on boards such as the mcbin which
> > > have SFP and Ethernet ports connected to the same MAC port: depending on
> > > what the user connects the driver will automatically reconfigure the
> > > link mode.
> > 
> > I would expect each of these external Ethernet ports to have its own
> > Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> > connect to the other Ethernet PHY when you change external Ethernet
> > port?
> 
> That's the other way around. The engines outputs (say GoP#) are
> connected to the comphy inputs. In the SoC. Then there's a single output
> of this comphy lane to the board. So when switching modes, you do not
> have to connect to a different Ethernet PHY, it's the same.

Hi Antoine

I think there is a mixup here between generic PHY and Ethernet PHY.

When you swap from the copper RJ45 to the fibre SFP, the phylib needs
to swap from the Copper Ethernet PHY driving the RJ45, to the PHY
driving the SFP module, which is probably a fixed-phy.

I actually think this is why you have the carrier_on/off calls in the
link modify callback.

Imagine phylib is using the copper Ethernet PHY, but the MAC is using
the SFP port. Somebody pulls out the copper cable, phylib says the
link is down, turns the carrier off and calls the callback. Not good,
since your SFP cable is still plugged in...  Ethtool is
returning/setting stuff in the Copper Ethernet PHY, when in fact you
intend to be setting SFP settings.

       Andrew

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

#1719380 — Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 24, 2017 at 06:01:24PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 05:52:41PM +0200, Antoine Tenart wrote:
> > On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> > > On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > > > This patch adds logic to reconfigure the comphy/gop when the link status
> > > > change at runtime. This is very useful on boards such as the mcbin which
> > > > have SFP and Ethernet ports connected to the same MAC port: depending on
> > > > what the user connects the driver will automatically reconfigure the
> > > > link mode.
> > > 
> > > I would expect each of these external Ethernet ports to have its own
> > > Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> > > connect to the other Ethernet PHY when you change external Ethernet
> > > port?
> > 
> > That's the other way around. The engines outputs (say GoP#) are
> > connected to the comphy inputs. In the SoC. Then there's a single output
> > of this comphy lane to the board. So when switching modes, you do not
> > have to connect to a different Ethernet PHY, it's the same.
> 
> I think there is a mixup here between generic PHY and Ethernet PHY.
> 
> When you swap from the copper RJ45 to the fibre SFP, the phylib needs
> to swap from the Copper Ethernet PHY driving the RJ45, to the PHY
> driving the SFP module, which is probably a fixed-phy.

Or on the mcbin the Alaska X 88X3310 which can operate from 10G to 10M.
This PHY changes its interface mode depending on what speed is
negotiated.

> I actually think this is why you have the carrier_on/off calls in the
> link modify callback.

Well, I still do not know if these calls are *really* needed. At least
in our case.

> Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> the SFP port. Somebody pulls out the copper cable, phylib says the
> link is down, turns the carrier off and calls the callback. Not good,
> since your SFP cable is still plugged in...  Ethtool is
> returning/setting stuff in the Copper Ethernet PHY, when in fact you
> intend to be setting SFP settings.

I see what could be the issue but I do not understand one aspect though:
how could we switch from one PHY to another, as there's only one output
between the SoC (and so a given GoP#) and the board. So if a given PHY
can handle multiple modes I see, but in the other case a muxing
somewhere would be needed? Or did I miss something?

Thanks!
Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

#1719434 — Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

> I see what could be the issue but I do not understand one aspect though:
> how could we switch from one PHY to another, as there's only one output
> between the SoC (and so a given GoP#) and the board. So if a given PHY
> can handle multiple modes I see, but in the other case a muxing
> somewhere would be needed? Or did I miss something?

I think we need a hardware diagram...

How are the RJ45, copper PHY, SFP module connected to the SoC?

Somewhere there must be a mux, to select between copper and
fibre. Where is that mux?

    Andrew

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

#1719446 — Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

On Thu, Aug 24, 2017 at 06:57:43PM +0200, Andrew Lunn wrote:
> > I see what could be the issue but I do not understand one aspect though:
> > how could we switch from one PHY to another, as there's only one output
> > between the SoC (and so a given GoP#) and the board. So if a given PHY
> > can handle multiple modes I see, but in the other case a muxing
> > somewhere would be needed? Or did I miss something?
> 
> I think we need a hardware diagram...
> 
> How are the RJ45, copper PHY, SFP module connected to the SoC?
> 
> Somewhere there must be a mux, to select between copper and
> fibre. Where is that mux?

In the 88x3310 PHY:

                     .------- RJ45
MVPP2 ----- 88x3310 PHY
                     `------- SFP+

Here's the commentry I've provided at the very top of the 88x3310 driver
which describes all these modes:

 * There appears to be several different data paths through the PHY which
 * are automatically managed by the PHY.  The following has been determined
 * via observation and experimentation:
 *
 *       SGMII PHYXS -- BASE-T PCS -- 10G PMA -- AN -- Copper (for <= 1G)
 *  10GBASE-KR PHYXS -- BASE-T PCS -- 10G PMA -- AN -- Copper (for 10G)
 *  10GBASE-KR PHYXS -- BASE-R PCS -- Fiber
 *
 * If both the fiber and copper ports are connected, the first to gain
 * link takes priority and the other port is completely locked out.

It's not a copper-only PHY, it's just like most other PHYs out there
that support multiple connections, like the 88e151x series that support
both RJ45 and fibre and can auto-switch between them.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

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

#1719450 — Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 24, 2017 at 06:04:01PM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 24, 2017 at 06:57:43PM +0200, Andrew Lunn wrote:
> > > I see what could be the issue but I do not understand one aspect though:
> > > how could we switch from one PHY to another, as there's only one output
> > > between the SoC (and so a given GoP#) and the board. So if a given PHY
> > > can handle multiple modes I see, but in the other case a muxing
> > > somewhere would be needed? Or did I miss something?
> > 
> > I think we need a hardware diagram...
> > 
> > How are the RJ45, copper PHY, SFP module connected to the SoC?
> > 
> > Somewhere there must be a mux, to select between copper and
> > fibre. Where is that mux?
> 
> In the 88x3310 PHY:
> 
>                      .------- RJ45
> MVPP2 ----- 88x3310 PHY
>                      `------- SFP+

And the "MVPP2" part can be expended to:

        .-- GoP #0 --.
MVPP2 ----- GoP #1 ---- Comphy lane #X -- 88x3310
        `-- GoP #2 --'

Thanks!
Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

#1719460 — RE: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

> >                      .------- RJ45
> > MVPP2 ----- 88x3310 PHY
> >                      `------- SFP+
> 
> And the "MVPP2" part can be expended to:
> 
>         .-- GoP #0 --.
> MVPP2 ----- GoP #1 ---- Comphy lane #X -- 88x3310
>         `-- GoP #2 --'
> 
> Thanks!
> Antoine

One more point, Alaska 3310 PHY SoC and Marvell Embedded Processor SoC(A8K) are different SoC's.
Comphy driver configures Serdes IP in Marvell Embedded Processor SoC and media(SFP or RJ45) autodetect is done in Alaska 3310 PHY SoC(mostly by firmware).

Regards,
Stefan

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

#1719445 — RE: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

> > Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> > the SFP port. Somebody pulls out the copper cable, phylib says the
> > link is down, turns the carrier off and calls the callback. Not good,
> > since your SFP cable is still plugged in...  Ethtool is
> > returning/setting stuff in the Copper Ethernet PHY, when in fact you
> > intend to be setting SFP settings.
> 
> I see what could be the issue but I do not understand one aspect though:
> how could we switch from one PHY to another, as there's only one output
> between the SoC (and so a given GoP#) and the board. So if a given PHY can
> handle multiple modes I see, but in the other case a muxing somewhere would
> be needed? Or did I miss something?

I think PHY name and PHY mode struct that describe here both MAC to PHY and PHY to PHY connection create confusion...
Serdes IP lane doesn't care if connector is SFP, RJ45 or direct attached cable. mvpp22_comphy_init only configures MAC to PHY
connection. SFI for 10G(KR in mainline), SGMII for 1G and HS_SGMII for 2.5G.

Regards,
Stefan.

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

#1719451 — Re: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 24, 2017 at 05:08:29PM +0000, Stefan Chulski wrote:
> > > Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> > > the SFP port. Somebody pulls out the copper cable, phylib says the
> > > link is down, turns the carrier off and calls the callback. Not good,
> > > since your SFP cable is still plugged in...  Ethtool is
> > > returning/setting stuff in the Copper Ethernet PHY, when in fact you
> > > intend to be setting SFP settings.
> > 
> > I see what could be the issue but I do not understand one aspect though:
> > how could we switch from one PHY to another, as there's only one output
> > between the SoC (and so a given GoP#) and the board. So if a given PHY can
> > handle multiple modes I see, but in the other case a muxing somewhere would
> > be needed? Or did I miss something?
> 
> I think PHY name and PHY mode struct that describe here both MAC to
> PHY and PHY to PHY connection create confusion...  Serdes IP lane
> doesn't care if connector is SFP, RJ45 or direct attached cable.
> mvpp22_comphy_init only configures MAC to PHY
> connection. SFI for 10G(KR in mainline), SGMII for 1G and HS_SGMII for
> 2.5G.

So maybe one confusion was to name them PHY_MODE_10GKR and
PHY_MODE_SGMII. It could be PHY_MODE_10G and PHY_MODE_1G instead.

Does that sound right?

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

#1719452 — RE: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

> So maybe one confusion was to name them PHY_MODE_10GKR and
> PHY_MODE_SGMII. It could be PHY_MODE_10G and PHY_MODE_1G instead.

1G can be RGMII...

Regards,
Stefan.

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

#1719825 — Re: [EXT] Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

On Thu, Aug 24, 2017 at 07:14:18PM +0200, Antoine Tenart wrote:
> On Thu, Aug 24, 2017 at 05:08:29PM +0000, Stefan Chulski wrote:
> > > > Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> > > > the SFP port. Somebody pulls out the copper cable, phylib says the
> > > > link is down, turns the carrier off and calls the callback. Not good,
> > > > since your SFP cable is still plugged in...  Ethtool is
> > > > returning/setting stuff in the Copper Ethernet PHY, when in fact you
> > > > intend to be setting SFP settings.
> > > 
> > > I see what could be the issue but I do not understand one aspect though:
> > > how could we switch from one PHY to another, as there's only one output
> > > between the SoC (and so a given GoP#) and the board. So if a given PHY can
> > > handle multiple modes I see, but in the other case a muxing somewhere would
> > > be needed? Or did I miss something?
> > 
> > I think PHY name and PHY mode struct that describe here both MAC to
> > PHY and PHY to PHY connection create confusion...  Serdes IP lane
> > doesn't care if connector is SFP, RJ45 or direct attached cable.
> > mvpp22_comphy_init only configures MAC to PHY
> > connection. SFI for 10G(KR in mainline), SGMII for 1G and HS_SGMII for
> > 2.5G.
> 
> So maybe one confusion was to name them PHY_MODE_10GKR and
> PHY_MODE_SGMII. It could be PHY_MODE_10G and PHY_MODE_1G instead.

SGMII mode supports 100M and 10M as well using data repetition, so 1G
makes it look like those speeds are not supported.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

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

#1719448 — Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:
> On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:
> > This patch adds logic to reconfigure the comphy/gop when the link status
> > change at runtime. This is very useful on boards such as the mcbin which
> > have SFP and Ethernet ports connected to the same MAC port: depending on
> > what the user connects the driver will automatically reconfigure the
> > link mode.
> 
> Hi Antoine
> 
> I would expect each of these external Ethernet ports to have its own
> Ethernet PHY. Don't you need to disconnect from one Ethernet phy and
> connect to the other Ethernet PHY when you change external Ethernet
> port?

I think you're all getting confused.  The link mode has very little to
do with whether you're using SFP+ or whether you're using the RJ45 at
10G speeds.  The link mode has everything to do with the speed at which
the link is negotiated at.

So please, put SFP+ out of your minds for this - SFP+ isn't the reason
why you need to switch the MAC link mode.

In all cases, the mvpp2 to 88x3310 link ends up in one of two modes:
1. SGMII for RJ45 speeds less than 10G.  Autonegotiation on SGMII
    at the mvpp2 end *must* be enabled for the PHY to work.

2. 10Gbase-R for 10G speeds, whether that be for SFP+ or RJ45 at 10G.
   Note: mcbin does not support SFP (1G) modules on the SFP+ ports.

The 88x3310 driver in the kernel knows about these combinations and
sets the phy interface parameter correctly depending on whether the
PHY has configured itself for copper at whatever speed or SFP+.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

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

#1719474 — Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

Hi Russell

> I think you're all getting confused.

Yes, i was at least.

> The 88x3310 driver in the kernel knows about these combinations and
> sets the phy interface parameter correctly depending on whether the
> PHY has configured itself for copper at whatever speed or SFP+.

So when the PHY decides to swap from copper to fibre etc, is the
phylib state machine kept up to date. Does it see a down, followed by
an up?

   Andrew

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

#1719615 — Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of the PHY mode

On Thu, Aug 24, 2017 at 07:45:19PM +0200, Andrew Lunn wrote:
> > The 88x3310 driver in the kernel knows about these combinations and
> > sets the phy interface parameter correctly depending on whether the
> > PHY has configured itself for copper at whatever speed or SFP+.
> 
> So when the PHY decides to swap from copper to fibre etc, is the
> phylib state machine kept up to date. Does it see a down, followed by
> an up?

I'd have to re-check to make sure, but I believe it does, because the
negotiation is held off on the "other" media until the currently active
link has gone down.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

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

#1719017 — [PATCH net-next 12/13] arm64: dts: marvell: mcbin: add comphy references to Ethernet ports

This patch adds comphy phandles to the Ethernet ports in the mcbin
device tree. The comphy is used to configure the serdes PHYs used by
these ports.

Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index 6cb4b000e1ac..dc4b6f3f25f6 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -148,6 +148,7 @@
 &cpm_eth0 {
 	status = "okay";
 	phy = <&phy0>;
+	phys = <&cpm_comphy4 0>;
 	phy-mode = "10gbase-kr";
 };
 
@@ -181,6 +182,7 @@
 &cps_eth0 {
 	status = "okay";
 	phy = <&phy1>;
+	phys = <&cps_comphy4 0>;
 	phy-mode = "10gbase-kr";
 };
 
@@ -189,6 +191,7 @@
 	status = "okay";
 	phy = <&ge_phy>;
 	phy-mode = "sgmii";
+	phys = <&cps_comphy0 1>;
 };
 
 &cps_sata0 {
-- 
2.13.5

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

#1719261 — Re: [PATCH net-next 12/13] arm64: dts: marvell: mcbin: add comphy references to Ethernet ports

> @@ -189,6 +191,7 @@
>  	status = "okay";
>  	phy = <&ge_phy>;
>  	phy-mode = "sgmii";
> +	phys = <&cps_comphy0 1>;

Does the binding document describe the meaning of the specifier?

     Andrew

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

#1719274 — Re: [PATCH net-next 12/13] arm64: dts: marvell: mcbin: add comphy references to Ethernet ports

[Multipart message — attachments visible in raw view] — view raw

Hi Andrew,

On Thu, Aug 24, 2017 at 03:58:13PM +0200, Andrew Lunn wrote:
> > @@ -189,6 +191,7 @@
> >  	status = "okay";
> >  	phy = <&ge_phy>;
> >  	phy-mode = "sgmii";
> > +	phys = <&cps_comphy0 1>;
> 
> Does the binding document describe the meaning of the specifier?

Ahhh no you're right! It's the port number i.e. there are multiple
inputs, each of which can support different modes. So say the input is
GoP#0, it can support 10G and SGMII.

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

#1719018 — [PATCH net-next 08/13] net: mvpp2: check the netif is running in the link_event function

This patch adds an extra check when the link_event function is called,
so that it won't do anything when the netif isn't running.

Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
 drivers/net/ethernet/marvell/mvpp2.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 99847fec1c5a..e9fd4fa81a2e 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5741,6 +5741,9 @@ static void mvpp2_link_event(struct net_device *dev)
 	struct mvpp2_port *port = netdev_priv(dev);
 	struct phy_device *phydev = dev->phydev;
 
+	if (!netif_running(dev))
+		return;
+
 	if (phydev->link) {
 		if ((port->speed != phydev->speed) ||
 		    (port->duplex != phydev->duplex)) {
-- 
2.13.5

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

#1719019 — [PATCH net-next 07/13] net: mvpp2: improve the link management function

When the link status changes, the phylib calls the link_event function
in the mvpp2 driver. Before this patch only the egress/ingress transmit
was enabled/disabled. This patch adds more functionality to the link
status management code by enabling/disabling the port per-cpu
interrupts, and the port itself. The queues are now stopped as well, and
the netif carrier helpers are called.

Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
 drivers/net/ethernet/marvell/mvpp2.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index ebcc89b8f792..99847fec1c5a 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5753,14 +5753,24 @@ static void mvpp2_link_event(struct net_device *dev)
 		port->link = phydev->link;
 
 		if (phydev->link) {
+			mvpp2_interrupts_enable(port);
+			mvpp2_port_enable(port);
+
 			mvpp2_egress_enable(port);
 			mvpp2_ingress_enable(port);
+			netif_carrier_on(dev);
+			netif_tx_wake_all_queues(dev);
 		} else {
 			port->duplex = -1;
 			port->speed = 0;
 
+			netif_tx_stop_all_queues(dev);
+			netif_carrier_off(dev);
 			mvpp2_ingress_disable(port);
 			mvpp2_egress_disable(port);
+
+			mvpp2_port_disable(port);
+			mvpp2_interrupts_disable(port);
 		}
 
 		phy_print_status(phydev);
-- 
2.13.5

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

#1719273 — Re: [PATCH net-next 07/13] net: mvpp2: improve the link management function

On Thu, Aug 24, 2017 at 10:38:17AM +0200, Antoine Tenart wrote:
> When the link status changes, the phylib calls the link_event function
> in the mvpp2 driver. Before this patch only the egress/ingress transmit
> was enabled/disabled. This patch adds more functionality to the link
> status management code by enabling/disabling the port per-cpu
> interrupts, and the port itself. The queues are now stopped as well, and
> the netif carrier helpers are called.
> 
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
>  drivers/net/ethernet/marvell/mvpp2.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
> index ebcc89b8f792..99847fec1c5a 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -5753,14 +5753,24 @@ static void mvpp2_link_event(struct net_device *dev)
>  		port->link = phydev->link;
>  
>  		if (phydev->link) {
> +			mvpp2_interrupts_enable(port);
> +			mvpp2_port_enable(port);
> +
>  			mvpp2_egress_enable(port);
>  			mvpp2_ingress_enable(port);
> +			netif_carrier_on(dev);

Hi Antoine

Have you seen cases where it is required to change the carrier state?
The phy state machine should be doing this. e.g. when autoneg has
completed, force link configuration, the link goes down etc.

	   Andrew

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web