Re: [PATCH net-next] net: sfp: add quirk for OEM DFP-34X-2C2 GPON ONU SFP

[Sergio Palumbo]

Hello Russell,
I never wanted to discuss your skills and I bag your pardon if this was 
your perception.
My skills are not so high and my horse is not so high (probably lower 
than a pony).
My intention was simply to give the possibility to other users to get 
the module working at the higher speed in order to support internet 
connections at 2500 kb without recompling the system with a patch.
If this is not possible I can accept it without problems and I bag your 
pardon again for the waste of time this can have generated.
I thank you for the time you spent with me (I learned a lot) and for the 
great job you and the net-dev group are doing for the linux community.
Best regards

Sergio Palumbo



Il 17/02/2024 11:28, Russell King (Oracle) ha scritto:
> On Sat, Feb 17, 2024 at 11:13:14AM +0100, Sergio Palumbo wrote:
> > [   15.459629] sfp sfp-1: module OEM              DFP-34X-2C2      rev      sn XPONxxxxxxxx     dc 230912
> > [   15.469121] mtk_soc_eth 15100000.ethernet eth1: requesting link mode inband/2500base-x with support 0000000,00000200,0000e440
> > [   15.509967] sfp sfp-2: module                                   rev 1.0  sn 2307210038       dc 230721
> > [   15.519434] mt7530-mdio mdio-bus:1f sfp2: requesting link mode inband/2500base-x with support 0000000,00000000,0000e440
> > [   24.360320] mt7530-mdio mdio-bus:1f sfp2: configuring for inband/2500base-x link mode
> > [   24.368145] mt7530-mdio mdio-bus:1f sfp2: major config 2500base-x
> > [   24.374258] mt7530-mdio mdio-bus:1f sfp2: phylink_mac_config: mode=inband/2500base-x/Unknown/Unknown adv=0000000,00000000,0000e440 pause=04 link=0 an=1
> > [   24.389679] br-lan: port 5(sfp2) entered blocking state
> > [   24.394948] br-lan: port 5(sfp2) entered disabled state
> > [   24.402405] device sfp2 entered promiscuous mode
> This shows that the interface has been configured for 2500base-X.
> However, there is no link report.
>
> > A stated by you the system is still connecting at 2500base-X even if the
> > module is set for 1000base-X, as far as I can see, without any error.
> Right, because, as I've said many times, the kernel has *no* idea that
> the module internals has been configured to operate at 1000base-X.
>
> > My assumption that the module could have forced the speed down to
> > 1000base-X was completely wrong.
> Correct - considering that I wrote all this code, it is insulting to
> have to go to this extent to get the point across.
>
> So now that we have agreement that the kernel is trying to use
> 2500base-X, you now need to get off your high horse and accept that
> it isn't working because there is _no_ _link_ with the module.
>
> In other words, you need to accept that I'm right and you're wrong.