Aw: Re: [PATCH net-next v12 08/18] net: ethernet: mtk_eth_soc: fix 1000Base-X and 2500Base-X modes
Frank Wunderlich
frank-w at public-files.de
Tue Mar 14 06:59:11 PDT 2023
Hi
very good...do not need the manual autoneg with the last Patch :)
> Gesendet: Dienstag, 14. März 2023 um 11:10 Uhr
> Von: "Russell King (Oracle)" <linux at armlinux.org.uk>
> For 802.3z modes, MLO_AN_INBAND with Autoneg clear in the advertising mode
> disables in-band negotiation. This is exactly how "ethtool -s ethX
> autoneg off" works.
ok, this seems now correctly set.
> > > The patch below should result in ethtool reporting 2500baseT rather than
> > > 2500baseX, and that an=1 should now be an=0. Please try it, and dump the
> > > ethtool eth1 before asking for autoneg to be manually disabled, and also
> > > report the kernel messages.
root at bpi-r3:~# ip link set eth1 up
[ 91.624075] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/2500base-x link mode
[ 91.632485] mtk_soc_eth 15100000.ethernet eth1: major config 2500base-x
[ 91.639094] mtk_soc_eth 15100000.ethernet eth1: phylink_mac_config: mode=inband/2500base-x/Unknown/Unknown/none adv=00,00000000,00008000,00006400 pause=00 link=0 an=0
root at bpi-r3:~# [ 95.808983] mtk_soc_eth 15100000.ethernet eth1: Link is Up - Unknown/Unknown - flow control off
[ 95.817706] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
root at bpi-r3:~# ethtool eth1
Settings for eth1:
Supported ports: [ FIBRE ]
Supported link modes: 2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: off
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
root at bpi-r3:~# dmesg | grep -i 'sfp\|eth1'
[ 0.000000] Linux version 6.3.0-rc1-bpi-r3-sfp13 (frank at frank-G5) (aarch64-linux-gnu-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #2 SMP Tue Mar 143
[ 1.658048] sfp sfp-1: Host maximum power 1.0W
[ 1.663128] sfp sfp-2: Host maximum power 1.0W
[ 1.812401] mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffffffc00af80000, irq 123
[ 2.001796] sfp sfp-1: module OEM SFP-2.5G-T rev 1.0 sn SK2301110008 dc 230110
[ 2.011307] mtk_soc_eth 15100000.ethernet eth1: optical SFP: interfaces=[mac=2-4,21-22, sfp=22]
[ 2.020000] mtk_soc_eth 15100000.ethernet eth1: optical SFP: chosen 2500base-x interface
[ 2.028080] mtk_soc_eth 15100000.ethernet eth1: requesting link mode inband/2500base-x with support 00,00000000,00008000,00006400
[ 91.624075] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/2500base-x link mode
[ 91.632485] mtk_soc_eth 15100000.ethernet eth1: major config 2500base-x
[ 91.639094] mtk_soc_eth 15100000.ethernet eth1: phylink_mac_config: mode=inband/2500base-x/Unknown/Unknown/none adv=00,00000000,00008000,00006400 pause=00 link=0 an=0
[ 95.808983] mtk_soc_eth 15100000.ethernet eth1: Link is Up - Unknown/Unknown - flow control off
[ 95.817706] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
so you can see the link-up comes directly after the interface up
does the ethtool-output look like expected? i see speed/duplex is set as supported/advertised but not active
Supported link modes: 2500baseT/Full
Advertised link modes: 2500baseT/Full
vs.
Speed: Unknown!
Duplex: Unknown! (255)
maybe because of the
@@ -3003,7 +3007,8 @@ static int phylink_sfp_config_optical(struct phylink *pl)
config.speed = SPEED_UNKNOWN;
config.duplex = DUPLEX_UNKNOWN;
config.pause = MLO_PAUSE_AN;
imho ETHTOOL_LINK_MODE_2500baseT_Full_BIT sets only the supported which intersected with the advertised from the other side maximum should be taken as actual mode...so this part seems not correctly working at the moment.
the "Supported ports: [ FIBRE ]" is also misleading for copper sfp, but imho all SFP are shown like this.
full log if needed:
https://pastebin.com/6yWe4Kyi
next step:
is it possible to have pause for rate adaption (handling rx pause frames correctly)?
regards Frank
More information about the linux-arm-kernel
mailing list