Re: [PATCH net-next 2/2] net: dsa: microchip: Add SGMII port support to KSZ9477 switch

[Andrew Lunn <andrew@lunn.ch>]

> When the SFP EEPROM says it does not support 1000Base-T then the SFP bus
> code does not consider the SFP has a PHY and skips creating a MDIO bus
> for it and phylink_sfp_config_optical() is called to create the phylink.

There are many SFPs out there with broken EEPROM contents. Do the SFPs
you have say they are not 1000Base-T but actually are? If so, they are
broken, and need a quirk adding.

Russell King keeps a database of SFP EEPROM contents. Send him the
output of `ethtool -m eth42 raw on hex on` 

> Now back to the discussion of the different modes used by the SGMII
> module.  I think a better term like SerDes can be used to help
> understanding the operation, although I still cannot narrow down the
> precise definitions from looking at the internet.  SGMII mode is
> said to support 10/100/1000Mbit.  This is the default setting, so
> plugging such SFP allows the port to communicate without any register
> programming.  The other mode is SerDes, which is fixed at 1000Mbit.  This
> is typically used by SFP using fiber optics.  This requires changing a
> register to make the port works.  It seems those 1000Base-T SFPs all run
> in SerDes mode, at least from all SFPs I tried.

There is a comment in the code:

/* Probe a SFP for a PHY device if the module supports copper - the PHY
 * normally sits at I2C bus address 0x56, and may either be a clause 22
 * or clause 45 PHY.
 *
 * Clause 22 copper SFP modules normally operate in Cisco SGMII mode with
 * negotiation enabled, but some may be in 1000base-X - which is for the
 * PHY driver to determine.

So the default is SGMII for copper SFPs, but there are a few oddballs
using 1000BaseX. The Marvell PHY driver should figure this out, and
the phylink will tell you want mode to use.


> The issue is then phylink assigns SGMII phy mode to such SFP as its
> EEPROM just says 1000Base-T support and not 1000BASEX phy mode so that
> the DSA driver can program the register correspondingly.  Because of that
> the driver still needs to rely on its own detection to find out which
> mode to use.
>  
> > Have you set pcs.poll? phylink will then poll the PCS every
> > second. You can report PCS status any time.
> 
> I know about PCS polling.  The SFP cage driver can provide link_up and
> link_down indications to the phylink driver.

The SPF cage provides LOS, Loss of Signal. This basically means there
is light coming into the SFP, but not much more. It is not a
trustworthy signal on its own. Phylink combines this with the PCS
status, does the PCS also have link. You need the combination.

> One more issue is if a SFP is not plugged in eventually the SFP driver
> says "please wait, module slow to respond."

Something is wrong with your GPIOs. Phylink thinks there is a module
inserted, when in fact there is not. Add #define DEBUG 1 to the very
top of sfp.c, so you can see the state transitions. I guess there is
something wrong with the MODDEF0 GPIO.

	Andrew