RFC: blueprint for proxy PHY module

RFC: blueprint for proxy PHY module

[Tomas Hlavacek]

Hello!

We have a board with a MAC in SoC that has SGMII connected through a 
signal switch to either 10/100/1000 wired PHY or to a SFP cage. The 
signal switch is set to pass signal to the wired PHY by default. When 
the MOD-DEF0 pin from SFP cage is low (which acts as a 
transceiver-present signal) the wired PHY is being disconnected and the 
SGMII is passed to the SFP cage. We also have the signal connected to a 
GPIO input, so we can detect the SFP presence from software. And there 
is always-connected MDIO to the wired PHY.

Now I use two different DTBs for testing purposes, one has a 
configuration for the wired PHY and another one uses fixed-link for 
SFP. And I have to reboot in order to switch from one to another.

My idea is to create a "proxy PHY" module that would take state from 
one of two (or more) underlying PHYs and pass it to the NIC driver. The 
selection of the active PHY would come from userspace. (There will be a 
board-specific
daemon that would react to the GPIO change and set the proper PHY 
accordingly.) Question is how to connect the userspace? I think that 
corresponding file in /sys would do the job, but I am not sure whether 
it is the proper way of doing that. (?)

What do you think about it?

Thanks,
Tomas

Re: RFC: blueprint for proxy PHY module

[Andrew Lunn]

On Thu, Feb 25, 2016 at 02:26:00PM +0100, Tomas Hlavacek wrote:
> Hello!
> 
> We have a board with a MAC in SoC that has SGMII connected through a
> signal switch to either 10/100/1000 wired PHY or to a SFP cage. The
> signal switch is set to pass signal to the wired PHY by default.
> When the MOD-DEF0 pin from SFP cage is low (which acts as a
> transceiver-present signal) the wired PHY is being disconnected and
> the SGMII is passed to the SFP cage. We also have the signal
> connected to a GPIO input, so we can detect the SFP presence from
> software. And there is always-connected MDIO to the wired PHY.
> 
> Now I use two different DTBs for testing purposes, one has a
> configuration for the wired PHY and another one uses fixed-link for
> SFP. And I have to reboot in order to switch from one to another.
> 
> My idea is to create a "proxy PHY" module that would take state from
> one of two (or more) underlying PHYs and pass it to the NIC driver.
> The selection of the active PHY would come from userspace. (There
> will be a board-specific
> daemon that would react to the GPIO change and set the proper PHY
> accordingly.) Question is how to connect the userspace? I think that
> corresponding file in /sys would do the job, but I am not sure
> whether it is the proper way of doing that. (?)
> 
> What do you think about it?

Hi Tomas

Have you looked at Russell Kings phylink patchset?

https://lwn.net/Articles/667055/

	Andrew

Re: RFC: blueprint for proxy PHY module

[Andrew Lunn]

> Question is how to connect the userspace? I think that corresponding
> file in /sys would do the job, but I am not sure whether it is the
> proper way of doing that. (?)

A historian might be able to help you. Going back to the days of
10MBps Ethernet, cards used to have a few different ports, AUI, BNC
and TP. The kernel probably supports configuring which to use,
probably via ethtool. Your use case is not that different, so you can
probably reuse it.

	 Andrew

Re: RFC: blueprint for proxy PHY module

[Tomas Hlavacek]

Hi Andrew!

On Thu, Feb 25, 2016 at 4:31 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  Question is how to connect the userspace? I think that corresponding
>>  file in /sys would do the job, but I am not sure whether it is the
>>  proper way of doing that. (?)
> 
> A historian might be able to help you. Going back to the days of
> 10MBps Ethernet, cards used to have a few different ports, AUI, BNC
> and TP. The kernel probably supports configuring which to use,
> probably via ethtool. Your use case is not that different, so you can
> probably reuse it.

Extending the ethtool ops in the driver (namely mvneta) seems to be 
possible and it seems that I could add more phy_dev pointers to the 
private data of the driver and switch among them quite easily. But it 
would be driver specific hack and I believe this problem is more 
general.

Perhaps I can pass some common PHY switch command from the driver to 
the prospective phy-proxy module. I'll come back to this question when 
I haveproof-of-concept code.

Btw. thanks for the pointer to the phylink patchset.

Tomas