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

Sergio Palumbo
2024-02-05T18:55:53Z

Hello Russell,
I back home and did the test for line 3 after the quirk:
SFP module still showing up
Supported ports: [ FIBRE ]
Supported link modes:   2500baseX/Full
1000baseX/Full
Speed: 2500Mb/s
Duplex: Full
Probably auto-negotiating at 2500base-X

Tried to change speed to 1000 using ethtool, but retuning an error.

However taking in consideration that without the quirk the module
is working at 1000base-X with both LAN_SDS_MODE=1 and
LAN_SDS_MODE=6 on my host 1000+2500 there i no reason why
it should not work at 1000base-X with an host only supporting 1000.

Unfortunately I do not have any host only supporting 1000base-X.

Awaiting your comments

regards

Sergio Palumbo

Il 03/02/2024 10:16, Sergio Palumbo ha scritto:
> Hello Russell,
> I understand your point on third line, but I quite sure that it is
> working at
> 1000-X because with LAN_SDS_MODE=1 makes the module to show up
> at 1000-X to Linux host, but now you made me doubtful.
> I'm now out of home and cannot do this test. I will test it on monday
> evening
> when will be back at home.
> Unfortunately not so skilled to:
> "Add #define DEBUG in phylink.c, rebuild and run that kernel. Try
> that exact configuration. Report to me the kernel messages."
> Would it be enough to check if using LAN_SDS_MODULE=1 with the quirk, the
> confirmation that  ethtool will report 1000-X only and speed connectioin
> reported by ethtool will be 1000?
> Will let you know the result of this test.
> Thanks for your kind support.
> Regards
>
> Sergio Palumbo
>
> Il 03/02/2024 00:45, Russell King (Oracle) ha scritto:
>> On Sat, Feb 03, 2024 at 12:18:13AM +0100, Sergio Palumbo wrote:
>>> Hello Russell,
>>> thanks for your  explanation. I have to say that:
>>> Module default is LAN_SDS_MODE=1
>>> Host banana PI R3 supporting 1000base-X + 2500base-X
>>> I would update the table as follows:
>>>
>>> The current situation:
>>> Host supports        Module        Mode        Functional
>>> 1000base-X        LAN_SDS_MODE=1    1000base-X    Not tested, but
>>> expect to work as 1000base-X + 2500base-X
>>> 1000base-X        LAN_SDS_MODE=6    1000base-X    Not tested, but
>>> expect to work as 1000base-X + 2500base-X
>>> 1000base-X + 2500base-X    LAN_SDS_MODE=1    1000base-X    Yes
>>> 1000base-X + 2500base-X    LAN_SDS_MODE=6    1000base-X    Yes (host
>>> forcing module at 1000base-X)
>>>
>>> I suppose that Banana PI R3 host is forced by linux drivers
>>> at 1000base-X so first two cases should be same as second two cases.
>>>
>>>
>>> With the quirk:
>>> Host supports        Module        Mode        Functional
>>> 1000base-X        LAN_SDS_MODE=1    1000base-X    Not tested, but
>>> expect to work as 1000base-X + 2500base-X host
>>> 1000base-X        LAN_SDS_MODE=6    1000base-X    Not tested, but
>>> expect to work as 1000base-X + 2500base-X host
>>> 1000base-X + 2500base-X    LAN_SDS_MODE=1    1000base-X    Yes
>>> (module forcing host at 1000base-X)
>>> 1000base-X + 2500base-X    LAN_SDS_MODE=6    2500base-X    Yes
>> Your third line is just wrong. Given the capabilities of the host
>> _and_ the capabilities of the module adjusted by your quirk, phylink
>> _will_ choose 2500base-X _not_ 1000base-X for that. With your quirk,
>> there is no way for Linux to know what LAN_SDS_MODE has been set
>> in the module. Even without your quirk, _unless_ the module updates
>> the EEPROM contents which is unlikely, there isn't a way to know.
>>
>>
>> Adding a quirk that makes it not work in its default state is
>> technically a regression. We can't know whether people are already
>> using this module with Linux in this state. Adding this change
>> potentially breaks users setups.
>>
>>> I suppose Banana PI R3 forcing Linux drivers at 1000-X when
>>> module in LAN_SDS_MODE=1 and expect it should work alpso with
>>> hosts at 1000base-X only in LAN_SDS_MODE=1 and LAN_SDS_MODE=6
>> There is no way for Linux to know what LAN_SDS_MODE the module is
>> in.
>>
>