> On Fri, Aug 09, 2024 at 04:38:40PM -0700, Tristram.Ha@xxxxxxxxxxxxx wrote: > > From: Tristram Ha <tristram.ha@xxxxxxxxxxxxx> > > > > The SGMII module of KSZ9477 switch can be setup in 3 ways: 0 for direct > > connect, 1 for 1000BaseT SFP, and 2 for 10/100/1000 SFP. > > > > SFP is typically used so the default is 1. The driver can detect > > 10/100/1000 SFP and change the mode to 2. For direct connect this mode > > has to be explicitly set to 0 as driver cannot detect that > > configuration. > > > > The SGMII module can only report basic link status of the SFP, so it is > > simulated as a regular internal PHY. > > > > Since the regular PHY in the switch uses interrupt instead of polling the > > driver has to handle the SGMII interrupt indicating link on/off. > > > > One issue for the 1000BaseT SFP is there is no link down interrupt, so > > the driver has to use polling to detect link down when the link is up. > > > > Recent change in the DSA operation can setup the port before the PHY > > interrupt handling function is registered. As the SGMII interrupt can > > be triggered after port setup there is extra code in the interrupt > > processing to handle this situation. Otherwise a kernel fault can be > > triggered. > > > > Note the SGMII interrupt cannot be masked in hardware. Also the module > > is not reset when the switch is reset. It is important to reset the > > module properly to make sure the interrupt is not triggered prematurely. > > Why not model this as a PCS? Russell has been converting all PCS like > things in DSA into try PCS drivers. So i suspect Russell will not like > this code, and would prefer a PCS driver. I am not familiar with PCS. It seems too complicated after looking at the phylink_pcs structure and associated phylink_pcs_ops functions. The SGMII module can only report link and does not even restart auto-negotiation. It is a set once and forget operation.
