[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170824161945.GG28443@kwain>
Date: Thu, 24 Aug 2017 18:19:45 +0200
From: Antoine Tenart <antoine.tenart@...e-electrons.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Antoine Tenart <antoine.tenart@...e-electrons.com>,
davem@...emloft.net, kishon@...com, jason@...edaemon.net,
sebastian.hesselbarth@...il.com,
gregory.clement@...e-electrons.com,
thomas.petazzoni@...e-electrons.com, nadavh@...vell.com,
linux@...linux.org.uk, linux-kernel@...r.kernel.org,
mw@...ihalf.com, stefanc@...vell.com,
miquel.raynal@...e-electrons.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 09/13] net: mvpp2: dynamic reconfiguration of
the PHY mode
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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists