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
signature.asc
Description: PGP signature
