diff mbox series

Aw: Re: [PATCH net-next v12 08/18] net: ethernet: mtk_eth_soc: fix 1000Base-X and 2500Base-X modes

Message ID trinity-a69cee2e-40c5-44b5-ac97-2cb35e1d2462-1678541173568@3c-app-gmx-bs24 (mailing list archive)
State New, archived
Headers show
Series Aw: Re: [PATCH net-next v12 08/18] net: ethernet: mtk_eth_soc: fix 1000Base-X and 2500Base-X modes | expand

Commit Message

Frank Wunderlich March 11, 2023, 1:26 p.m. UTC 
> Gesendet: Samstag, 11. März 2023 um 13:05 Uhr
> Von: "Frank Wunderlich" <frank-w@public-files.de>
> > Gesendet: Mittwoch, 08. März 2023 um 16:24 Uhr
> > Von: "Russell King (Oracle)" <linux@armlinux.org.uk>
> > > > It would be nice to add these to my database - please send me the
> > > > output of ethtool -m $iface raw on > foo.bin for each module.
> > 
> > so if you can do that for me, then I can see whether it's likely that
> > the patches that are already in mainline will do anything to solve
> > the workaround you've had to add for the hw signals.
> 
> i got the 2.5G copper sfps, and tried them...they work well with the v12 (including this patch), but not in v13...
> 
> i dumped the eeprom like you mention for your database:
> 
> $ hexdump -C 2g5_sfp.bin 
> 00000000  03 04 07 00 01 00 00 00  00 02 00 05 19 00 00 00  |................|
> 00000010  1e 14 00 00 4f 45 4d 20  20 20 20 20 20 20 20 20  |....OEM         |
> 00000020  20 20 20 20 00 00 00 00  53 46 50 2d 32 2e 35 47  |    ....SFP-2.5G|
> 00000030  2d 54 20 20 20 20 20 20  31 2e 30 20 03 52 00 19  |-T      1.0 .R..|
> 00000040  00 1a 00 00 53 4b 32 33  30 31 31 31 30 30 30 38  |....SK2301110008|
> 00000050  20 20 20 20 32 33 30 31  31 30 20 20 68 f0 01 e8  |    230110  h...|
> 00000060  00 00 11 37 4f 7a dc ff  3d c0 6e 74 9b 7c 06 ca  |...7Oz..=.nt.|..|
> 00000070  e1 d0 f9 00 00 00 00 00  00 00 00 00 08 f0 fc 64  |...............d|
> 00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000100  5f 00 ce 00 5a 00 d3 00  8c a0 75 30 88 b8 79 18  |_...Z.....u0..y.|
> 00000110  1d 4c 01 f4 19 64 03 e8  4d f0 06 30 3d e8 06 f2  |.L...d..M..0=...|
> 00000120  2b d4 00 c7 27 10 00 df  00 00 00 00 00 00 00 00  |+...'...........|
> 00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00000140  00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  |....?...........|
> 00000150  01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 f1  |................|
> 00000160  29 1a 82 41 0b b8 13 88  0f a0 ff ff ff ff 80 ff  |)..A............|
> 00000170  00 00 ff ff 00 00 ff ff  04 ff ff ff ff ff ff 00  |................|
> 00000180  43 4e 53 38 54 55 54 41  41 43 33 30 2d 31 34 31  |CNS8TUTAAC30-141|
> 00000190  30 2d 30 34 56 30 34 20  49 fb 46 00 00 00 00 29  |0-04V04 I.F....)|
> 000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 aa aa  |................|
> 000001c0  47 4c 43 2d 54 20 20 20  20 20 20 20 20 20 20 20  |GLC-T           |
> 000001d0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 97  |               .|
> 000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 000001f0  00 00 00 00 00 00 00 00  00 40 00 40 00 00 00 00  |.........@.@....|
> 
> how can we add a quirk to support this?

tried to add the quirk like this onto v13


how can i verify the quirk was applied? see only this in dmesg:

[    2.192274] sfp sfp-1: module OEM              SFP-2.5G-T       rev 1.0  sn SK2301110008     dc 230110  

also tried to force speed (module should support 100/1000/2500), but it seems i can set speed option only on
gmac (eth1) and not on the sfp (phy).

i guess between mac and sfp speed is always 2500base-X and after the phy (if there is any) the link speed is
maybe different.

regards Frank

Comments

Daniel Golle March 11, 2023, 2:51 p.m. UTC | #1 
On Sat, Mar 11, 2023 at 02:26:13PM +0100, Frank Wunderlich wrote:
> > Gesendet: Samstag, 11. März 2023 um 13:05 Uhr
> > Von: "Frank Wunderlich" <frank-w@public-files.de>
> > > Gesendet: Mittwoch, 08. März 2023 um 16:24 Uhr
> > > Von: "Russell King (Oracle)" <linux@armlinux.org.uk>
> > > > > It would be nice to add these to my database - please send me the
> > > > > output of ethtool -m $iface raw on > foo.bin for each module.
> > > 
> > > so if you can do that for me, then I can see whether it's likely that
> > > the patches that are already in mainline will do anything to solve
> > > the workaround you've had to add for the hw signals.
> > 
> > i got the 2.5G copper sfps, and tried them...they work well with the v12 (including this patch), but not in v13...
> > 
> > i dumped the eeprom like you mention for your database:
> > 
> > $ hexdump -C 2g5_sfp.bin 
> > 00000000  03 04 07 00 01 00 00 00  00 02 00 05 19 00 00 00  |................|
> > 00000010  1e 14 00 00 4f 45 4d 20  20 20 20 20 20 20 20 20  |....OEM         |
> > 00000020  20 20 20 20 00 00 00 00  53 46 50 2d 32 2e 35 47  |    ....SFP-2.5G|
> > 00000030  2d 54 20 20 20 20 20 20  31 2e 30 20 03 52 00 19  |-T      1.0 .R..|
> > 00000040  00 1a 00 00 53 4b 32 33  30 31 31 31 30 30 30 38  |....SK2301110008|
> > 00000050  20 20 20 20 32 33 30 31  31 30 20 20 68 f0 01 e8  |    230110  h...|
> > 00000060  00 00 11 37 4f 7a dc ff  3d c0 6e 74 9b 7c 06 ca  |...7Oz..=.nt.|..|
> > 00000070  e1 d0 f9 00 00 00 00 00  00 00 00 00 08 f0 fc 64  |...............d|
> > 00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > *
> > 00000100  5f 00 ce 00 5a 00 d3 00  8c a0 75 30 88 b8 79 18  |_...Z.....u0..y.|
> > 00000110  1d 4c 01 f4 19 64 03 e8  4d f0 06 30 3d e8 06 f2  |.L...d..M..0=...|
> > 00000120  2b d4 00 c7 27 10 00 df  00 00 00 00 00 00 00 00  |+...'...........|
> > 00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > 00000140  00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  |....?...........|
> > 00000150  01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 f1  |................|
> > 00000160  29 1a 82 41 0b b8 13 88  0f a0 ff ff ff ff 80 ff  |)..A............|
> > 00000170  00 00 ff ff 00 00 ff ff  04 ff ff ff ff ff ff 00  |................|
> > 00000180  43 4e 53 38 54 55 54 41  41 43 33 30 2d 31 34 31  |CNS8TUTAAC30-141|
> > 00000190  30 2d 30 34 56 30 34 20  49 fb 46 00 00 00 00 29  |0-04V04 I.F....)|
> > 000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > 000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 aa aa  |................|
> > 000001c0  47 4c 43 2d 54 20 20 20  20 20 20 20 20 20 20 20  |GLC-T           |
> > 000001d0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 97  |               .|
> > 000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > 000001f0  00 00 00 00 00 00 00 00  00 40 00 40 00 00 00 00  |.........@.@....|
> > 
> > how can we add a quirk to support this?
> 
> tried to add the quirk like this onto v13
> 
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
> @@ -403,6 +403,8 @@ static const struct sfp_quirk sfp_quirks[] = {
>         SFP_QUIRK_F("OEM", "RTSFP-10G", sfp_fixup_rollball_cc),
>         SFP_QUIRK_F("Turris", "RTSFP-10", sfp_fixup_rollball),
>         SFP_QUIRK_F("Turris", "RTSFP-10G", sfp_fixup_rollball),
> +
> +       SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_2500basex),
>  };
> 
> but still no link...
> 
> how can i verify the quirk was applied? see only this in dmesg:
> 
> [    2.192274] sfp sfp-1: module OEM              SFP-2.5G-T       rev 1.0  sn SK2301110008     dc 230110  
> 
> also tried to force speed (module should support 100/1000/2500), but it seems i can set speed option only on
> gmac (eth1) and not on the sfp (phy).
> 
> i guess between mac and sfp speed is always 2500base-X and after the phy (if there is any) the link speed is
> maybe different.

As discussed in the previous iteration of the series where I suggested to
add work-arounds disabling in-band AN for 1000Base-X and 2500Base-X having
those will also affect fiber transceivers which transparently pass-through
the electrical SerDes signal into light. Russell explained it very well
and I now agree that a good solution would be to add a new SFP quirk
indicating that a SFP module got a "hidden" PHY which doesn't like in-band
autonegotiation.

tl;dr What you are seeing is the expected behavior.
Try 'ethtool -s eth1 autoneg off', and the link should come up.


Cheers


Daniel


> 
> regards Frank
>
Russell King (Oracle) March 11, 2023, 8:02 p.m. UTC | #2 
On Sat, Mar 11, 2023 at 02:51:27PM +0000, Daniel Golle wrote:
> On Sat, Mar 11, 2023 at 02:26:13PM +0100, Frank Wunderlich wrote:
> > > Gesendet: Samstag, 11. März 2023 um 13:05 Uhr
> > > Von: "Frank Wunderlich" <frank-w@public-files.de>
> > > > Gesendet: Mittwoch, 08. März 2023 um 16:24 Uhr
> > > > Von: "Russell King (Oracle)" <linux@armlinux.org.uk>
> > > > > > It would be nice to add these to my database - please send me the
> > > > > > output of ethtool -m $iface raw on > foo.bin for each module.
> > > > 
> > > > so if you can do that for me, then I can see whether it's likely that
> > > > the patches that are already in mainline will do anything to solve
> > > > the workaround you've had to add for the hw signals.
> > > 
> > > i got the 2.5G copper sfps, and tried them...they work well with the v12 (including this patch), but not in v13...
> > > 
> > > i dumped the eeprom like you mention for your database:
> > > 
> > > $ hexdump -C 2g5_sfp.bin 
> > > 00000000  03 04 07 00 01 00 00 00  00 02 00 05 19 00 00 00  |................|
> > > 00000010  1e 14 00 00 4f 45 4d 20  20 20 20 20 20 20 20 20  |....OEM         |
> > > 00000020  20 20 20 20 00 00 00 00  53 46 50 2d 32 2e 35 47  |    ....SFP-2.5G|
> > > 00000030  2d 54 20 20 20 20 20 20  31 2e 30 20 03 52 00 19  |-T      1.0 .R..|
> > > 00000040  00 1a 00 00 53 4b 32 33  30 31 31 31 30 30 30 38  |....SK2301110008|
> > > 00000050  20 20 20 20 32 33 30 31  31 30 20 20 68 f0 01 e8  |    230110  h...|
> > > 00000060  00 00 11 37 4f 7a dc ff  3d c0 6e 74 9b 7c 06 ca  |...7Oz..=.nt.|..|
> > > 00000070  e1 d0 f9 00 00 00 00 00  00 00 00 00 08 f0 fc 64  |...............d|
> > > 00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > > *
> > > 00000100  5f 00 ce 00 5a 00 d3 00  8c a0 75 30 88 b8 79 18  |_...Z.....u0..y.|
> > > 00000110  1d 4c 01 f4 19 64 03 e8  4d f0 06 30 3d e8 06 f2  |.L...d..M..0=...|
> > > 00000120  2b d4 00 c7 27 10 00 df  00 00 00 00 00 00 00 00  |+...'...........|
> > > 00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > > 00000140  00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  |....?...........|
> > > 00000150  01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 f1  |................|
> > > 00000160  29 1a 82 41 0b b8 13 88  0f a0 ff ff ff ff 80 ff  |)..A............|
> > > 00000170  00 00 ff ff 00 00 ff ff  04 ff ff ff ff ff ff 00  |................|
> > > 00000180  43 4e 53 38 54 55 54 41  41 43 33 30 2d 31 34 31  |CNS8TUTAAC30-141|
> > > 00000190  30 2d 30 34 56 30 34 20  49 fb 46 00 00 00 00 29  |0-04V04 I.F....)|
> > > 000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > > 000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 aa aa  |................|
> > > 000001c0  47 4c 43 2d 54 20 20 20  20 20 20 20 20 20 20 20  |GLC-T           |
> > > 000001d0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 97  |               .|
> > > 000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > > 000001f0  00 00 00 00 00 00 00 00  00 40 00 40 00 00 00 00  |.........@.@....|
> > > 
> > > how can we add a quirk to support this?
> > 
> > tried to add the quirk like this onto v13
> > 
> > --- a/drivers/net/phy/sfp.c
> > +++ b/drivers/net/phy/sfp.c
> > @@ -403,6 +403,8 @@ static const struct sfp_quirk sfp_quirks[] = {
> >         SFP_QUIRK_F("OEM", "RTSFP-10G", sfp_fixup_rollball_cc),
> >         SFP_QUIRK_F("Turris", "RTSFP-10", sfp_fixup_rollball),
> >         SFP_QUIRK_F("Turris", "RTSFP-10G", sfp_fixup_rollball),
> > +
> > +       SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_2500basex),
> >  };
> > 
> > but still no link...
> > 
> > how can i verify the quirk was applied? see only this in dmesg:
> > 
> > [    2.192274] sfp sfp-1: module OEM              SFP-2.5G-T       rev 1.0  sn SK2301110008     dc 230110  
> > 
> > also tried to force speed (module should support 100/1000/2500), but it seems i can set speed option only on
> > gmac (eth1) and not on the sfp (phy).
> > 
> > i guess between mac and sfp speed is always 2500base-X and after the phy (if there is any) the link speed is
> > maybe different.
> 
> As discussed in the previous iteration of the series where I suggested to
> add work-arounds disabling in-band AN for 1000Base-X and 2500Base-X having
> those will also affect fiber transceivers which transparently pass-through
> the electrical SerDes signal into light. Russell explained it very well
> and I now agree that a good solution would be to add a new SFP quirk
> indicating that a SFP module got a "hidden" PHY which doesn't like in-band
> autonegotiation.

I do not believe that fibre SFPs have hidden PHYs that disrupt the
autonegotiation. What makes you think that they do? Do you have
autonegotiation working with some fibre SFP modules but not other
fibre modules?
Daniel Golle March 11, 2023, 8:34 p.m. UTC | #3 
On Sat, Mar 11, 2023 at 08:02:47PM +0000, Russell King (Oracle) wrote:
> On Sat, Mar 11, 2023 at 02:51:27PM +0000, Daniel Golle wrote:
> > On Sat, Mar 11, 2023 at 02:26:13PM +0100, Frank Wunderlich wrote:
> > > > Gesendet: Samstag, 11. März 2023 um 13:05 Uhr
> > > > Von: "Frank Wunderlich" <frank-w@public-files.de>
> > > > > Gesendet: Mittwoch, 08. März 2023 um 16:24 Uhr
> > > > > Von: "Russell King (Oracle)" <linux@armlinux.org.uk>
> > > > > > > It would be nice to add these to my database - please send me the
> > > > > > > output of ethtool -m $iface raw on > foo.bin for each module.
> > > > > 
> > > > > so if you can do that for me, then I can see whether it's likely that
> > > > > the patches that are already in mainline will do anything to solve
> > > > > the workaround you've had to add for the hw signals.
> > > > 
> > > > i got the 2.5G copper sfps, and tried them...they work well with the v12 (including this patch), but not in v13...
> > > > 
> > > > i dumped the eeprom like you mention for your database:
> > > > 
> > > > $ hexdump -C 2g5_sfp.bin 
> > > > 00000000  03 04 07 00 01 00 00 00  00 02 00 05 19 00 00 00  |................|
> > > > 00000010  1e 14 00 00 4f 45 4d 20  20 20 20 20 20 20 20 20  |....OEM         |
> > > > 00000020  20 20 20 20 00 00 00 00  53 46 50 2d 32 2e 35 47  |    ....SFP-2.5G|
> > > > 00000030  2d 54 20 20 20 20 20 20  31 2e 30 20 03 52 00 19  |-T      1.0 .R..|
> > > > 00000040  00 1a 00 00 53 4b 32 33  30 31 31 31 30 30 30 38  |....SK2301110008|
> > > > 00000050  20 20 20 20 32 33 30 31  31 30 20 20 68 f0 01 e8  |    230110  h...|
> > > > 00000060  00 00 11 37 4f 7a dc ff  3d c0 6e 74 9b 7c 06 ca  |...7Oz..=.nt.|..|
> > > > 00000070  e1 d0 f9 00 00 00 00 00  00 00 00 00 08 f0 fc 64  |...............d|
> > > > 00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > > > *
> > > > 00000100  5f 00 ce 00 5a 00 d3 00  8c a0 75 30 88 b8 79 18  |_...Z.....u0..y.|
> > > > 00000110  1d 4c 01 f4 19 64 03 e8  4d f0 06 30 3d e8 06 f2  |.L...d..M..0=...|
> > > > 00000120  2b d4 00 c7 27 10 00 df  00 00 00 00 00 00 00 00  |+...'...........|
> > > > 00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > > > 00000140  00 00 00 00 3f 80 00 00  00 00 00 00 01 00 00 00  |....?...........|
> > > > 00000150  01 00 00 00 01 00 00 00  01 00 00 00 00 00 00 f1  |................|
> > > > 00000160  29 1a 82 41 0b b8 13 88  0f a0 ff ff ff ff 80 ff  |)..A............|
> > > > 00000170  00 00 ff ff 00 00 ff ff  04 ff ff ff ff ff ff 00  |................|
> > > > 00000180  43 4e 53 38 54 55 54 41  41 43 33 30 2d 31 34 31  |CNS8TUTAAC30-141|
> > > > 00000190  30 2d 30 34 56 30 34 20  49 fb 46 00 00 00 00 29  |0-04V04 I.F....)|
> > > > 000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > > > 000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 aa aa  |................|
> > > > 000001c0  47 4c 43 2d 54 20 20 20  20 20 20 20 20 20 20 20  |GLC-T           |
> > > > 000001d0  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 97  |               .|
> > > > 000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> > > > 000001f0  00 00 00 00 00 00 00 00  00 40 00 40 00 00 00 00  |.........@.@....|
> > > > 
> > > > how can we add a quirk to support this?
> > > 
> > > tried to add the quirk like this onto v13
> > > 
> > > --- a/drivers/net/phy/sfp.c
> > > +++ b/drivers/net/phy/sfp.c
> > > @@ -403,6 +403,8 @@ static const struct sfp_quirk sfp_quirks[] = {
> > >         SFP_QUIRK_F("OEM", "RTSFP-10G", sfp_fixup_rollball_cc),
> > >         SFP_QUIRK_F("Turris", "RTSFP-10", sfp_fixup_rollball),
> > >         SFP_QUIRK_F("Turris", "RTSFP-10G", sfp_fixup_rollball),
> > > +
> > > +       SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_2500basex),
> > >  };
> > > 
> > > but still no link...
> > > 
> > > how can i verify the quirk was applied? see only this in dmesg:
> > > 
> > > [    2.192274] sfp sfp-1: module OEM              SFP-2.5G-T       rev 1.0  sn SK2301110008     dc 230110  
> > > 
> > > also tried to force speed (module should support 100/1000/2500), but it seems i can set speed option only on
> > > gmac (eth1) and not on the sfp (phy).
> > > 
> > > i guess between mac and sfp speed is always 2500base-X and after the phy (if there is any) the link speed is
> > > maybe different.
> > 
> > As discussed in the previous iteration of the series where I suggested to
> > add work-arounds disabling in-band AN for 1000Base-X and 2500Base-X having
> > those will also affect fiber transceivers which transparently pass-through
> > the electrical SerDes signal into light. Russell explained it very well
> > and I now agree that a good solution would be to add a new SFP quirk
> > indicating that a SFP module got a "hidden" PHY which doesn't like in-band
> > autonegotiation.
> 
> I do not believe that fibre SFPs have hidden PHYs that disrupt the
> autonegotiation. What makes you think that they do?

This is not a fiber SFP, but rather a 2500Base-T RJ-45 module.
Hence it quite certainly has some kind of PHY.

> Do you have
> autonegotiation working with some fibre SFP modules but not other
> fibre modules?

I've tried only with one 1000Base-SX module and can confirm (like
Frank already did in your previous discussion some weeks ago) that
with that autonegotiation is working fine. Only those RJ-45 which
do not expose the PHY via i2c-mdio are problematic apparently, as
Linux/phylink *assumes* that they do in-band AN, but at least some
of them don't.
diff mbox series

Patch

--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -403,6 +403,8 @@  static const struct sfp_quirk sfp_quirks[] = {
        SFP_QUIRK_F("OEM", "RTSFP-10G", sfp_fixup_rollball_cc),
        SFP_QUIRK_F("Turris", "RTSFP-10", sfp_fixup_rollball),
        SFP_QUIRK_F("Turris", "RTSFP-10G", sfp_fixup_rollball),
+
+       SFP_QUIRK_M("OEM", "SFP-2.5G-T", sfp_quirk_2500basex),
 };

but still no link...