Re: ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150

Re: ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150

[Russell King (Oracle)]

On Mon, Nov 22, 2021 at 02:51:36PM +0400, Jordan Vrtanoski wrote:
> Hi,
>     After bisecting, the regression defect was introduced in 5.4.90 with the following patch:
> "[PATCH net v3] net: mvpp2: disable force link UP during port init procedure”
> 
>     The patch is changing the configuration of the port during the initialisation of MVPP22_XLG_CTRL0_REG, which
> on ClearFog GT 8K is preventing the MVPP2 to properly start the MAC after the transceiver is detected. After reverting 
> the patch, the transceiver works properly.

Right, the problem will be 875082244853 ("net: mvpp2: disable force
link UP during port init procedure") that has been backported to
kernels that it shouldn't have been applied to.

There is a subtle interaction between that commit and development work
leading up to it that wasn't obvious during the review. Specifically,
any kernel without fefeae73ac7a ("net: mvpp2: ensure the port is forced
down while changing modes") will now be broken.

However, fefeae73ac7a is development work, and so can't be backported.

Adding stable to this thread so they're aware of the issue.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150

[Greg KH]

On Mon, Nov 22, 2021 at 07:53:44PM +0000, Russell King (Oracle) wrote:
> On Mon, Nov 22, 2021 at 02:51:36PM +0400, Jordan Vrtanoski wrote:
> > Hi,
> >     After bisecting, the regression defect was introduced in 5.4.90 with the following patch:
> > "[PATCH net v3] net: mvpp2: disable force link UP during port init procedure”
> > 
> >     The patch is changing the configuration of the port during the initialisation of MVPP22_XLG_CTRL0_REG, which
> > on ClearFog GT 8K is preventing the MVPP2 to properly start the MAC after the transceiver is detected. After reverting 
> > the patch, the transceiver works properly.
> 
> Right, the problem will be 875082244853 ("net: mvpp2: disable force
> link UP during port init procedure") that has been backported to
> kernels that it shouldn't have been applied to.
> 
> There is a subtle interaction between that commit and development work
> leading up to it that wasn't obvious during the review. Specifically,
> any kernel without fefeae73ac7a ("net: mvpp2: ensure the port is forced
> down while changing modes") will now be broken.
> 
> However, fefeae73ac7a is development work, and so can't be backported.
> 
> Adding stable to this thread so they're aware of the issue.

I've now reverted the commit in the 5.4.y tree.

thanks,

greg k-h