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:

quoted

On Thu, Aug 24, 2017 at 04:56:09PM +0200, Andrew Lunn wrote:

quoted

On Thu, Aug 24, 2017 at 10:38:19AM +0200, Antoine Tenart wrote:

quoted

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