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

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

[Sergio Palumbo]

     DFP-34X-2C2 is a GPON spf module working at both 1000baseX
     and 2500baseX.
     Setting the module to LAN_SDS_MODE=6 the module is working
     at 2500baseX with auto negotiation see at
     https://hack-gpon.org/ont-odi-realtek-dfp-34x-2c2/
     Unfortunatly the module's PHY is accessible at 1000baseX only.
     ethtool returning:
     Supported ports: [ Fibre ]
     Supported link modes: 1000baseX/Full

     After applying the quirk:
     Supported ports: [ Fibre ]
     Supported link modes: 1000baseX/Full
                           2500baseX/Full
     Tested on BANANA PI R3 in OpenWRT v 23.05.2 Kernel 5.15.137
     Tested on sfp to ethernet Media Converter.
     Autonegotiating 1000baseX or 2500baseX according to the
     connected host speed.

     This module is existing in 2 versions:
     Vendor = "ODI"
     Vendor = "OEM"
     This is the patch for vendor "OEM"

     Patch has been inserted keeping the list in alphabetical order
     first by vendor first and then by part string.

Signed-off-by: Sergio Palumbo <palumbo.ser@outlook.it>
---
 drivers/net/phy/sfp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index f75c9eb3958e..3c0028a4af92 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -502,6 +502,9 @@ static const struct sfp_quirk sfp_quirks[] = {
 	SFP_QUIRK_F("Walsun", "HXSX-ATRC-1", sfp_fixup_fs_10gt),
 	SFP_QUIRK_F("Walsun", "HXSX-ATRI-1", sfp_fixup_fs_10gt),
 
+	// OEM DFP-34X-2C2 GPON ONU support 2500base-X
+	SFP_QUIRK_M("OEM", "DFP-34X-2C2", sfp_quirk_2500basex),
+
 	SFP_QUIRK_F("OEM", "SFP-10G-T", sfp_fixup_rollball_cc),
 	SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_oem_2_5g),
 	SFP_QUIRK_F("OEM", "RTSFP-10", sfp_fixup_rollball_cc),
-- 
2.34.1

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

[Russell King (Oracle)]

Oh, you re-posted it already...

On Sun, Jan 28, 2024 at 03:06:33PM +0100, Sergio Palumbo wrote:
>      DFP-34X-2C2 is a GPON spf module working at both 1000baseX
>      and 2500baseX.
>      Setting the module to LAN_SDS_MODE=6 the module is working
>      at 2500baseX with auto negotiation see at
>      https://hack-gpon.org/ont-odi-realtek-dfp-34x-2c2/

Please don't indent commit messages unnecessarily.

Also, good to know what this module *requires* AN with 2500base-X.

However, what mode does this module normally come up in, and does
it reflect the operating mode in the module EEPROM?

If we accept this patch, and the modules normally come up at 1000base-X
we will try to use 2500base-X and the link won't come up. So it's
important to clarify this point.

Thanks.

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

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

[Sergio Palumbo]

Dear Russell,
sorry for the indenting. I will no longer use indenting in future postings.
As explained in the description setting up the module via telnet with
LAN_SDS_MODE=6 puts the module in 2500X autonegotiating mode.
Without applying the patch the module shows up to linux at 1000X
because the EEPROM is not correctly reporting the 2500X speeds.
Ethtool lines in the description repporting only 1000X and host
connecting only at 1000X.
After the quirk as you can see from the ethtool lines I put in the 
description
the module shows up to linux with both speeds 1000X and 2500X.
According to the above if the host has the ability to connect at 2500X
the module is connecting at 2500X, if the host has the ability to connect at
1000X only it will connect at 1000X.

On the other side after the quirk and the module set to LAN_SDS_MODE=1
1000X mode. Linux host is connecting at 1000X only.

Therefore will all the possible combination the patch allows linux host to
connect at the maximum speed of the host up to 2500X.

Please note that, as exlained in the description, this patch is for the 
"OEM"
vendor version.
I posted anothe patch for the "ODI" vendor version.
Harware for both version is the same only vendor name is different.
If better I can post a patch having both quirks in two different places 
according
to the alphabetical sorting.
I thought it was bettere to post two patches one for each vendor name.

Hope this clarifies.
I remain at your disposal for any further information.
Thanks and regards

Sergio Palumbo



Il 28/01/2024 15:42, Russell King (Oracle) ha scritto:
> Oh, you re-posted it already...
>
> On Sun, Jan 28, 2024 at 03:06:33PM +0100, Sergio Palumbo wrote:
>>       DFP-34X-2C2 is a GPON spf module working at both 1000baseX
>>       and 2500baseX.
>>       Setting the module to LAN_SDS_MODE=6 the module is working
>>       at 2500baseX with auto negotiation see at
>>       https://hack-gpon.org/ont-odi-realtek-dfp-34x-2c2/
> Please don't indent commit messages unnecessarily.
>
> Also, good to know what this module *requires* AN with 2500base-X.
>
> However, what mode does this module normally come up in, and does
> it reflect the operating mode in the module EEPROM?
>
> If we accept this patch, and the modules normally come up at 1000base-X
> we will try to use 2500base-X and the link won't come up. So it's
> important to clarify this point.
>
> Thanks.
>

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

[Russell King (Oracle)]

On Fri, Feb 02, 2024 at 06:41:51PM +0100, Sergio Palumbo wrote:
> Dear Russell,
> sorry for the indenting. I will no longer use indenting in future postings.
> As explained in the description setting up the module via telnet with
> LAN_SDS_MODE=6 puts the module in 2500X autonegotiating mode.

Okay, so this requires manual configuration to switch the module into
2500base-X.

> Without applying the patch the module shows up to linux at 1000X
> because the EEPROM is not correctly reporting the 2500X speeds.

Okay, so in its default as-new state without reconfiguring the module,
it reports 1000base-X and Linux drives it as such. This sounds fine.

> Ethtool lines in the description repporting only 1000X and host
> connecting only at 1000X.

That would be expected.

> After the quirk as you can see from the ethtool lines I put in the
> description the module shows up to linux with both speeds 1000X and 2500X.

Yes, adding the quirk will have that effect, but it will also have the
effect that we will choose 2500base-X for host interfaces that support
it, whether or not the module has been reconfigured to operate at
2500base-X. This will result in a mismatch between the module and the
host, and the link will not come up.

> According to the above if the host has the ability to connect at 2500X
> the module is connecting at 2500X, if the host has the ability to connect
> at 1000X only it will connect at 1000X.

The current situation:

Host supports		Module		Mode		Functional
1000base-X		default		1000base-X	Yes
1000base-X		LAN_SDS_MODE=6	1000base-X	No
1000base-X + 2500base-X	default		1000base-X	Yes	***
1000base-X + 2500base-X	LAN_SDS_MODE=6	1000base-X	No

With the quirk:
Host supports		Module		Mode		Functional
1000base-X		default		1000base-X	Yes
1000base-X		LAN_SDS_MODE=6	1000base-X	No
1000base-X + 2500base-X	default		2500base-X	No	***
1000base-X + 2500base-X	LAN_SDS_MODE=6	2500base-X	Yes

The lines marked "***" are what I'm concerned about - by adding this
quirk, it has the effect of trading one working configuration (the
one where the module is in its default factory configuration) for one
which requires special configuration of the module _and_ which breaks
the factory configuration.

On the plus side, ethtool _can_ be used to switch the interface mode
back to 1000base-X, but given that this was working it seems backwards
to need manual intervention.

> On the other side after the quirk and the module set to LAN_SDS_MODE=1
> 1000X mode. Linux host is connecting at 1000X only.

No it won't. The module will still be detected, the quirk will be used,
which will indicate to the kernel that the module supports both
1000base-X and 2500base-X. With a host interface that supports both,
the kernel will choose 2500base-X, but the module will be using
1000base-X - and the link will not come up.

At the very least, this needs to be mentioned in the commit message,
so that the implications of this can be properly considered.

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

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

[Sergio Palumbo]

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


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



I also  tested them a Linux PC with ethernet at 1GB (Host) attached to
a media converter ethertnet <-> sfp 2.5G module working at 1000base-X
(speed of the host ehternet) with module set at both LAN_SDS_MODE=1 and
LAN_SDS_MODE=6

Do you think this could be enough?

Waitng your comments.

Best regards

Sergio Palumbo


Il 02/02/2024 19:01, Russell King (Oracle) ha scritto:
> On Fri, Feb 02, 2024 at 06:41:51PM +0100, Sergio Palumbo wrote:
>> Dear Russell,
>> sorry for the indenting. I will no longer use indenting in future postings.
>> As explained in the description setting up the module via telnet with
>> LAN_SDS_MODE=6 puts the module in 2500X autonegotiating mode.
> Okay, so this requires manual configuration to switch the module into
> 2500base-X.
>
>> Without applying the patch the module shows up to linux at 1000X
>> because the EEPROM is not correctly reporting the 2500X speeds.
> Okay, so in its default as-new state without reconfiguring the module,
> it reports 1000base-X and Linux drives it as such. This sounds fine.
>
>> Ethtool lines in the description repporting only 1000X and host
>> connecting only at 1000X.
> That would be expected.
>
>> After the quirk as you can see from the ethtool lines I put in the
>> description the module shows up to linux with both speeds 1000X and 2500X.
> Yes, adding the quirk will have that effect, but it will also have the
> effect that we will choose 2500base-X for host interfaces that support
> it, whether or not the module has been reconfigured to operate at
> 2500base-X. This will result in a mismatch between the module and the
> host, and the link will not come up.
>
>> According to the above if the host has the ability to connect at 2500X
>> the module is connecting at 2500X, if the host has the ability to connect
>> at 1000X only it will connect at 1000X.
> The current situation:
>
> Host supports		Module		Mode		Functional
> 1000base-X		default		1000base-X	Yes
> 1000base-X		LAN_SDS_MODE=6	1000base-X	No
> 1000base-X + 2500base-X	default		1000base-X	Yes	***
> 1000base-X + 2500base-X	LAN_SDS_MODE=6	1000base-X	No
>
> With the quirk:
> Host supports		Module		Mode		Functional
> 1000base-X		default		1000base-X	Yes
> 1000base-X		LAN_SDS_MODE=6	1000base-X	No
> 1000base-X + 2500base-X	default		2500base-X	No	***
> 1000base-X + 2500base-X	LAN_SDS_MODE=6	2500base-X	Yes
>
> The lines marked "***" are what I'm concerned about - by adding this
> quirk, it has the effect of trading one working configuration (the
> one where the module is in its default factory configuration) for one
> which requires special configuration of the module _and_ which breaks
> the factory configuration.
>
> On the plus side, ethtool _can_ be used to switch the interface mode
> back to 1000base-X, but given that this was working it seems backwards
> to need manual intervention.
>
>> On the other side after the quirk and the module set to LAN_SDS_MODE=1
>> 1000X mode. Linux host is connecting at 1000X only.
> No it won't. The module will still be detected, the quirk will be used,
> which will indicate to the kernel that the module supports both
> 1000base-X and 2500base-X. With a host interface that supports both,
> the kernel will choose 2500base-X, but the module will be using
> 1000base-X - and the link will not come up.
>
> At the very least, this needs to be mentioned in the commit message,
> so that the implications of this can be properly considered.
>

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

[Russell King (Oracle)]

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.

Add #define DEBUG in phylink.c, rebuild and run that kernel. Try
that exact configuration. Report to me the kernel messages.

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.

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

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

[Sergio Palumbo]

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.
>

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

[Sergio Palumbo]

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.
>>
>

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

[Russell King (Oracle)]

Hi Sergio,

I did ask for the kernel messages from a specific scenario:

- host that supports 1000base-X and 2500base-X with your quirk
- SFP inserted with LAN_SDS_MODE=1

What I expet to see in the kernel messages is that the system will
use 2500base-X, and a failure.

You claim that the kernel will link at 1000base-X. There is no
mechanism in the kernel for this to happen, and I believe that
if you look at the kernel messages, this will prove my point.

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

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

[Sergio Palumbo]

Hello Russell,
I did the requested test

- host that supports 1000base-X and 2500base-X with your quirk (Banana PI R3)
- SFP inserted with LAN_SDS_MODE=1 (DFP-34X-2C2

and here below system messages concerning sfp:

Sun Feb  4 00:35:06 2024 kern.info kernel: [   14.686771] sfp sfp-1: 
Host maximum power 3.0W
Sun Feb  4 00:35:06 2024 kern.info kernel: [   14.692137] sfp sfp-2: 
Host maximum power 3.0W
Sun Feb  4 00:35:06 2024 kern.info kernel: [   15.029727] sfp sfp-1: 
module OEM              DFP-34X-2C2      rev      sn XPONxxxxxxxx     dc 
230912
Sun Feb  4 00:35:06 2024 kern.info kernel: [   15.068806] sfp sfp-2: 
module                                   rev 1.0  sn 2307210038       dc 
230721
Sun Feb  4 00:35:08 2024 kern.info kernel: [   22.767328] mt7530-mdio 
mdio-bus:1f sfp2: configuring for inband/2500base-x link mode
Sun Feb  4 00:35:08 2024 kern.info kernel: [   22.777097] br-lan: port 
5(sfp2) entered blocking state
Sun Feb  4 00:35:08 2024 kern.info kernel: [   22.782390] br-lan: port 
5(sfp2) entered disabled state
Sun Feb  4 00:35:12 2024 kern.info kernel: [   26.970294] mt7530-mdio 
mdio-bus:1f sfp2: Link is Up - 2.5Gbps/Full - flow control off
Sun Feb  4 00:35:12 2024 kern.info kernel: [   26.978403] br-lan: port 
5(sfp2) entered blocking state
Sun Feb  4 00:35:12 2024 kern.info kernel: [   26.983623] br-lan: port 
5(sfp2) entered forwarding state
Sun Feb  4 00:35:12 2024 daemon.notice netifd: Network device 'sfp2' 
link is up
Sun Feb  4 00:35:08 2024 kern.info kernel: [   22.834307] mtk_soc_eth 
15100000.ethernet eth1: configuring for inband/2500base-x link mode
Sun Feb  4 00:35:08 2024 kern.info kernel: [   22.846214] device eth1 
entered promiscuous mode
Sun Feb  4 00:35:58 2024 kern.info kernel: [   72.800035] mtk_soc_eth 
15100000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off

sfp-1 is linked to eth1
eth1 is running at 2500base-x

Same result with ethtool:

Settings for eth1:
         Supported ports: [ FIBRE ]
         Supported link modes:   2500baseX/Full
                                 1000baseX/Full
         Supported pause frame use: Symmetric Receive-only
         Supports auto-negotiation: Yes
         Supported FEC modes: Not reported
         Advertised link modes:  2500baseX/Full
         Advertised pause frame use: Symmetric Receive-only
         Advertised auto-negotiation: Yes
         Advertised FEC modes: Not reported
         Speed: 2500Mb/s
         Duplex: Full
         Auto-negotiation: on
         Port: FIBRE
         PHYAD: 0
         Transceiver: internal
         Current message level: 0x000000ff (255)
                                drv probe link timer ifdown ifup rx_err 
tx_err
         Link detected: yes

Please let me have your comments.

Sergio Palumbo


Il 06/02/2024 15:15, Russell King (Oracle) ha scritto:
> Hi Sergio,
>
> I did ask for the kernel messages from a specific scenario:
>
> - host that supports 1000base-X and 2500base-X with your quirk
> - SFP inserted with LAN_SDS_MODE=1
>
> What I expet to see in the kernel messages is that the system will
> use 2500base-X, and a failure.
>
> You claim that the kernel will link at 1000base-X. There is no
> mechanism in the kernel for this to happen, and I believe that
> if you look at the kernel messages, this will prove my point.
>

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

[Russell King (Oracle)]

On Thu, Feb 08, 2024 at 09:30:48AM +0100, Sergio Palumbo wrote:
> Hello Russell,
> I did the requested test

I asked for it with a kernel that has #define DEBUG in phylink.c, but I
see no debug messages from phylink in your quoted output. There's no
mention of what's going on behind the scenes, so this gives me
absolutely no new information.

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

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

[Sergio Palumbo]

Dear Russel,
this is the first time I do such a test and kindly ask you to help me in 
preparing it.
In my openwrt environment I have found phylink.c file in two different 
directories:
/build_dir/toolchain-aarch64_cortex-a53__gcc-112.30_musl/linux-5.15.137/drivers/net/phy
/build_dir/toolchain-aarch64_cortex-a53__gcc-112.30_musllinux-mediatek_filogic/linux-5.15.137/drivers/net/phy

do I have to change both adding a line:
#define DEBUG

before the first #define line:
#define SUPPORTED_interfaces \

and then rebuild the system?

Thanks in advance for your patience in teaching me something totally new 
to me.
Best regards

Sergio Palumbo


Il 08/02/2024 10:07, Russell King (Oracle) ha scritto:
> On Thu, Feb 08, 2024 at 09:30:48AM +0100, Sergio Palumbo wrote:
>> Hello Russell,
>> I did the requested test
> I asked for it with a kernel that has #define DEBUG in phylink.c, but I
> see no debug messages from phylink in your quoted output. There's no
> mention of what's going on behind the scenes, so this gives me
> absolutely no new information.
>

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

[Russell King (Oracle)]

On Thu, Feb 08, 2024 at 03:00:08PM +0100, Sergio Palumbo wrote:
> Dear Russel,
> this is the first time I do such a test and kindly ask you to help me in
> preparing it.
> In my openwrt environment I have found phylink.c file in two different
> directories:
> /build_dir/toolchain-aarch64_cortex-a53__gcc-112.30_musl/linux-5.15.137/drivers/net/phy
> /build_dir/toolchain-aarch64_cortex-a53__gcc-112.30_musllinux-mediatek_filogic/linux-5.15.137/drivers/net/phy

Oh, openwrt. That means I need to re-understand their build system to
advise how to do it. I only know the mainline kernel.

> do I have to change both adding a line:
> #define DEBUG
> 
> before the first #define line:
> #define SUPPORTED_interfaces \

Mainline has never had "SUPPORTED_interfaces" in phylink.c, so I'm
wondeirng what that's about. I'm also wondering what other changes
there are to it. I'm also wondering whether the behaviour you're
seeing is somehow special to openwrt. Too many things to wonder about
and effectively means there's too much that I don't know.

Therefore, I don't think I can help you, and I don't think I can
possibly accept your proposal for this quirk. For mainline, as far
as I'm aware, it will cause these modules to regress when they are
in the manufacturer default state when used with a host that supports
both 1000base-X and 2500base-X.

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

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

[Sergio Palumbo]

Dear Russell,
I understand your point, but I think ODI DFP-34X-2C2 situation is quite 
similar to:
FS GPON-INU-34-20BI
HUAWEI MA5671A
which are incorrectly reporting the speed in their EEPROM
These modules are working at both 1000-X and 2500-X but in order to work 
at 2500-X they need the quirk.
Same as ODI DFP-34X-2C2
I'm also quite sure that those modules are used and working in openwrt 
being GPON modules.
Was this test also done before accepting the patch/quirk for those modules?
Thanks for your help and regards

Sergio Palumbo




Il 08/02/2024 16:28, Russell King (Oracle) ha scritto:
> On Thu, Feb 08, 2024 at 03:00:08PM +0100, Sergio Palumbo wrote:
>> Dear Russel,
>> this is the first time I do such a test and kindly ask you to help me in
>> preparing it.
>> In my openwrt environment I have found phylink.c file in two different
>> directories:
>> /build_dir/toolchain-aarch64_cortex-a53__gcc-112.30_musl/linux-5.15.137/drivers/net/phy
>> /build_dir/toolchain-aarch64_cortex-a53__gcc-112.30_musllinux-mediatek_filogic/linux-5.15.137/drivers/net/phy
> Oh, openwrt. That means I need to re-understand their build system to
> advise how to do it. I only know the mainline kernel.
>
>> do I have to change both adding a line:
>> #define DEBUG
>>
>> before the first #define line:
>> #define SUPPORTED_interfaces \
> Mainline has never had "SUPPORTED_interfaces" in phylink.c, so I'm
> wondeirng what that's about. I'm also wondering what other changes
> there are to it. I'm also wondering whether the behaviour you're
> seeing is somehow special to openwrt. Too many things to wonder about
> and effectively means there's too much that I don't know.
>
> Therefore, I don't think I can help you, and I don't think I can
> possibly accept your proposal for this quirk. For mainline, as far
> as I'm aware, it will cause these modules to regress when they are
> in the manufacturer default state when used with a host that supports
> both 1000base-X and 2500base-X.
>

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

[Russell King (Oracle)]

On Thu, Feb 08, 2024 at 05:19:24PM +0100, Sergio Palumbo wrote:
> Dear Russell,
> I understand your point, but I think ODI DFP-34X-2C2 situation is quite
> similar to:
> FS GPON-INU-34-20BI
> HUAWEI MA5671A

MA5671A is configured by the OLT. The user can't configure it.

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

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

[Sergio Palumbo]

Hi Russell,
GPON modules we are talking about are all ONT/ONU and all the ONT ONU 
are configured by OLT unless you have a modded firmware.
ODI DFP-34X-2C2 is an ONT/ONU.
https://hack-gpon.org/ont-huawei-ma5671a/
https://hack-gpon.org/ont-fs-com-gpon-onu-stick-with-mac/
https://hack-gpon.org/ont-odi-realtek-dfp-34x-2c2/

I think the discussion on LAN_SDS_MODE=1 or LAN_SDS_MODE=6, started by 
me is not part of the problem as the system after the quirk is working 
at 2500-X with both settings. My fault!
The problem for these kind of modules is simply that they are not 
showing up at 2500-X because EEPROM or Virtual EEPROM (in case of 
MA5671A) failure to provide the correct speed to the linux driver.

Huawei MA5671A and Fiberstone GPON-ONU-34-20BI require:
"sfp_quirk_2500basex" and "sfp_fixup_ignore_tx_fault" quirks
ODI DFP-34X-2C2
only require "sfp_quirk_2500basex"

Hope this may help.

Regards

Sergio Palumbo














Il 08/02/2024 17:28, Russell King (Oracle) ha scritto:
> On Thu, Feb 08, 2024 at 05:19:24PM +0100, Sergio Palumbo wrote:
>> Dear Russell,
>> I understand your point, but I think ODI DFP-34X-2C2 situation is quite
>> similar to:
>> FS GPON-INU-34-20BI
>> HUAWEI MA5671A
> MA5671A is configured by the OLT. The user can't configure it.
>

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

[Sergio Palumbo]

Hello Russell,
unfortunately I did not have time imediately to run tests.
Now I had some time available to run some more test, this is the result:

The current situation:
Host supports		Module		Mode		Functional
1000base-X		LAN_SDS_MODE=1	1000base-X	Not tested
1000base-X		LAN_SDS_MODE=6	1000base-X	Not tested
1000base-X + 2500base-X	LAN_SDS_MODE=1	1000base-X	Yes
1000base-X + 2500base-X	LAN_SDS_MODE=6	1000base-X	Yes

I recompiled the linux firmware with the #define DEBUG in phylink.c

With the quirk:
Host supports		Module		Mode		Functional
1000base-X		LAN_SDS_MODE=1	1000base-X	Not tested
1000base-X		LAN_SDS_MODE=6	1000base-X	Not tested
1000base-X + 2500base-X	LAN_SDS_MODE=1	2500base-X	Yes
1000base-X + 2500base-X	LAN_SDS_MODE=6	2500base-X	Yes

 From the above it is clear that:
- using the quirk the module is always working at 2500base-X if the host is capable of 2500base-X
- the internal settings of te module does not affect the speed

Here below an extract of the kernel log with phylink debug for 1000base-X + 2500base-X	LAN_SDS_MODE=1	2500base-X :
sfp-1/eth1= DFP-34X-2C2 module
sfp-2/lan = sfp/ethernet copper module working at 2500base-X

Sat Feb 10 19:17:29 2024 kern.info kernel: [    2.111137] mt7530-mdio mdio-bus:1f: configuring for fixed/2500base-x link mode
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    2.118440] mt7530-mdio mdio-bus:1f: major config 2500base-x
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    2.124099] mt7530-mdio mdio-bus:1f: phylink_mac_config: mode=fixed/2500base-x/2.5Gbps/Full adv=0000000,00008000,00006240 pause=03 link=0 an=1
Sat Feb 10 19:17:29 2024 kern.info kernel: [    2.138585] mt7530-mdio mdio-bus:1f: Link is Up - 2.5Gbps/Full - flow control rx/tx
Sat Feb 10 19:17:29 2024 kern.info kernel: [    2.147273] mt7530-mdio mdio-bus:1f wan (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7531 PHY] (irq=146)
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    2.157515] mt7530-mdio mdio-bus:1f wan (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef
Sat Feb 10 19:17:29 2024 kern.info kernel: [    2.180320] mt7530-mdio mdio-bus:1f lan1 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7531 PHY] (irq=147)
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    2.190651] mt7530-mdio mdio-bus:1f lan1 (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef
Sat Feb 10 19:17:29 2024 kern.info kernel: [    2.213265] mt7530-mdio mdio-bus:1f lan2 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7531 PHY] (irq=148)
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    2.223598] mt7530-mdio mdio-bus:1f lan2 (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef
Sat Feb 10 19:17:29 2024 kern.info kernel: [    2.246219] mt7530-mdio mdio-bus:1f lan3 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7531 PHY] (irq=149)
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    2.256552] mt7530-mdio mdio-bus:1f lan3 (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef
Sat Feb 10 19:17:29 2024 kern.info kernel: [    2.279159] mt7530-mdio mdio-bus:1f lan4 (uninitialized): PHY [mt7530-0:04] driver [MediaTek MT7531 PHY] (irq=150)
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    2.289490] mt7530-mdio mdio-bus:1f lan4 (uninitialized): phy: setting supported 0000000,00000000,000062ef advertising 0000000,00000000,000062ef
Sat Feb 10 19:17:29 2024 kern.info kernel: [    7.482162] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/2500base-x link mode
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    7.490445] mtk_soc_eth 15100000.ethernet eth0: major config 2500base-x
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    7.497041] mtk_soc_eth 15100000.ethernet eth0: phylink_mac_config: mode=fixed/2500base-x/2.5Gbps/Full adv=0000000,00008000,00006240 pause=03 link=0 an=1
Sat Feb 10 19:17:29 2024 kern.info kernel: [    7.510911] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
Sat Feb 10 19:17:29 2024 kern.info kernel: [    7.556750] mt7530-mdio mdio-bus:1f lan1: configuring for phy/gmii link mode
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    7.563831] mt7530-mdio mdio-bus:1f lan1: major config gmii
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    7.569386] mt7530-mdio mdio-bus:1f lan1: phylink_mac_config: mode=phy/gmii/Unknown/Unknown adv=0000000,00000000,00000000 pause=00 link=0 an=0
Sat Feb 10 19:17:29 2024 kern.debug kernel: [    7.585159] mt7530-mdio mdio-bus:1f lan1: phy link up gmii/1Gbps/Full/rx/tx
Sat Feb 10 19:17:29 2024 kern.info kernel: [    7.586893] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control rx/tx
Sat Feb 10 19:17:29 2024 kern.info kernel: [   15.122661] sfp sfp-1: Host maximum power 3.0W
Sat Feb 10 19:17:29 2024 kern.info kernel: [   15.127875] sfp sfp-2: Host maximum power 3.0W
Sat Feb 10 19:17:29 2024 kern.info kernel: [   15.459629] sfp sfp-1: module OEM              DFP-34X-2C2      rev      sn XPONxxxxxxxx     dc 230912
Sat Feb 10 19:17:29 2024 kern.debug kernel: [   15.469121] mtk_soc_eth 15100000.ethernet eth1: requesting link mode inband/2500base-x with support 0000000,00000200,0000e440
Sat Feb 10 19:17:29 2024 kern.info kernel: [   15.509967] sfp sfp-2: module                                   rev 1.0  sn 2307210038       dc 230721
Sat Feb 10 19:17:29 2024 kern.debug kernel: [   15.519434] mt7530-mdio mdio-bus:1f sfp2: requesting link mode inband/2500base-x with support 0000000,00000000,0000e440
Sat Feb 10 19:17:31 2024 kern.info kernel: [   24.360320] mt7530-mdio mdio-bus:1f sfp2: configuring for inband/2500base-x link mode
Sat Feb 10 19:17:31 2024 kern.debug kernel: [   24.368145] mt7530-mdio mdio-bus:1f sfp2: major config 2500base-x
Sat Feb 10 19:17:31 2024 kern.debug kernel: [   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
Sat Feb 10 19:17:31 2024 kern.info kernel: [   24.389679] br-lan: port 5(sfp2) entered blocking state
Sat Feb 10 19:17:31 2024 kern.info kernel: [   24.394948] br-lan: port 5(sfp2) entered disabled state
Sat Feb 10 19:17:31 2024 kern.info kernel: [   24.402405] device sfp2 entered promiscuous mode
Sat Feb 10 19:17:31 2024 kern.info kernel: [   24.414853] mt7530-mdio mdio-bus:1f wan: configuring for phy/gmii link mode
Sat Feb 10 19:17:31 2024 kern.debug kernel: [   24.421873] mt7530-mdio mdio-bus:1f wan: major config gmii
Sat Feb 10 19:17:31 2024 kern.debug kernel: [   24.427355] mt7530-mdio mdio-bus:1f wan: phylink_mac_config: mode=phy/gmii/Unknown/Unknown adv=0000000,00000000,00000000 pause=00 link=0 an=0
Sat Feb 10 19:17:31 2024 kern.debug kernel: [   24.443005] mt7530-mdio mdio-bus:1f wan: phy link down gmii/Unknown/Unknown/off
Sat Feb 10 19:17:31 2024 kern.info kernel: [   24.472639] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/2500base-x link mode
Sat Feb 10 19:17:31 2024 kern.debug kernel: [   24.481074] mtk_soc_eth 15100000.ethernet eth1: major config 2500base-x
Sat Feb 10 19:17:31 2024 kern.debug kernel: [   24.487693] mtk_soc_eth 15100000.ethernet eth1: phylink_mac_config: mode=inband/2500base-x/Unknown/Unknown adv=0000000,00000000,0000e440 pause=04 link=0 an=1

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.
My assumption that the module could have forced the speed down to 1000base-X was completely wrong.

Making a final recap:
- The module without the quirk is only showing up at 1000base-X due to a wrong EEPROM data
- The module without the quirk is working at 1000base-X in both of the 2 internal configurations
- The module with the quirk is only showing up at 1000base-X and 2500base-X
- The module with the quirk is working at 2500base-X in both of the 2 internal configurations

This module as is a GPON-ONU/ONT and is configured by the OLT same as FS GPON-INU-34-20BI and HUAWEI MA5671A already validated for the quirk.

Thanks for your patience and suggestions.
I remain at your disposal for any further test I can do.
I hope that with the above evidence the patch could be acceptable for both OEM and ODI vendor.

Sergio Palumbo

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

[Russell King (Oracle)]

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.

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

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.
>