| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <875yd61fg3.fsf@miraculix.mork.no>
Date: Mon, 16 Jan 2023 19:50:52 +0100
From: Bjørn Mork <bjorn@...k.no>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Frank Wunderlich <frank-w@...lic-files.de>,
Frank Wunderlich <linux@...web.de>,
linux-mediatek@...ts.infradead.org,
Alexander Couzens <lynxis@...0.eu>,
Felix Fietkau <nbd@....name>, John Crispin <john@...ozen.org>,
Sean Wang <sean.wang@...iatek.com>,
Mark Lee <Mark-MC.Lee@...iatek.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Matthias Brugger <matthias.bgg@...il.com>,
netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops
Bjørn Mork <bjorn@...k.no> writes:
> "Russell King (Oracle)" <linux@...linux.org.uk> writes:
>
>> That all looks fine. However, I'm running out of ideas.
>
> Thanks a lot for the effort in any case. It's comforting that even the
> top experts can't figure out this one :-)
>
>
>> What we seem to have is:
>>
>> PHY:
>> VSPEC1_SGMII_CTRL = 0x34da
>> VSPEC1_SGMII_STAT = 0x000e
>>
>> The PHY is programmed to exchange SGMII with the host PCS, and it
>> says that it hasn't completed that exchange (bit 5 of STAT).
>>
>> The Mediatek PCS says:
>> BMCR = 0x1140 AN enabled
>> BMSR = 0x0008 AN capable
>> ADVERTISE = 0x0001 SGMII response (bit 14 is clear, hardware is
>> supposed to manage that bit)
>> LPA = 0x0000 SGMII received control word (nothing)
>> SGMII_MODE = 0x011b SGMII mode, duplex AN, 1000M, Full duplex,
>> Remote fault disable
>>
>> which all looks like it should work - but it isn't.
>>
>> One last thing I can think of trying at the moment would be writing
>> the VSPEC1_SGMII_CTRL with 0x36da, setting bit 9 which allegedly
>> restarts the SGMII exchange. There's some comments in the PHY driver
>> that this may be needed - maybe it's necessary once the MAC's PCS
>> has been switched to SGMII mode.
>
>
> Tried that now. Didn't change anything. And still no packets.
>
> root@...nWrt:/# mdio mdio-bus 6:30 raw 8
> 0x34da
> root@...nWrt:/# mdio mdio-bus 6:30 raw 9
> 0x000e
> root@...nWrt:/# mdio mdio-bus 6:30 raw 8 0x36da
> root@...nWrt:/# mdio mdio-bus 6:30 raw 8
> 0x34da
> root@...nWrt:/# mdio mdio-bus 6:30 raw 9
> 0x000e
And just as we were about to give up I got another datapoint.
Changed phy-mode and managed mode as follows in the device tree as a
last desperate attempt:
mac@1 {
compatible = "mediatek,eth-mac";
reg = <1>;
label = "wan";
// phy-mode = "2500base-x";
phy-mode = "sgmii";
managed = "in-band-status";
phy-handle = <&phy6>;
};
Made things fail with 2.5G, as expected I guess. But this actually works
with 1G!
Except for an unexpected packet drop. But at least there are packets
coming through at 1G now. This is the remote end of the link:
ns-enp3s0# ethtool -s enp3s0 autoneg off speed 1000 duplex full
ns-enp3s0# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.544 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.283 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.261 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.295 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=0.273 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=0.290 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=0.266 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=0.269 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=0.270 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=0.261 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=0.261 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=0.266 ms
^C
--- 192.168.0.1 ping statistics ---
13 packets transmitted, 12 received, 7.69231% packet loss, time 12282ms
rtt min/avg/max/mdev = 0.261/0.294/0.544/0.075 ms
ns-enp3s0# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP ]
Supported link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
2500baseT/Full
5000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: off
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: g
Current message level: 0x00000005 (5)
drv link
Link detected: yes
.
The MT7986 end looks like this:
root@...nWrt:/# [ 55.659413] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
[ 55.664380] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
[ 58.779924] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
[ 58.784884] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
[ 58.789841] mtk_sgmii_select_pcs: id=1
[ 58.793581] mtk_pcs_config: interface=4
[ 58.797399] offset:0 0x81140
[ 58.797401] offset:4 0x4d544950
[ 58.800273] offset:8 0x1a0
[ 58.803397] offset:0x20 0x31120118
[ 58.806089] forcing AN
[ 58.811826] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
[ 58.822759] mtk_pcs_restart_an
[ 58.825800] mtk_pcs_get_state: bm=0x81140, adv=0xda014001
[ 58.831184] mtk_pcs_get_state: bm=0x2c1140, adv=0xda014001
[ 58.836649] mtk_pcs_link_up: interface=4
[ 58.840559] offset:0 0xac1140
[ 58.840561] offset:4 0x4d544950
[ 58.843512] offset:8 0xda014001
[ 58.846636] offset:0x20 0x3112011b
[ 58.849780] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
[ 58.861521] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
root@...nWrt:/# ethtool wan
Settings for wan:
Supported ports: [ ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: master
Port: Twisted Pair
PHYAD: 6
Transceiver: external
MDI-X: on (auto)
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
root@...nWrt:/# mdio mdio-bus 6:30 raw 8
0x34da
root@...nWrt:/# mdio mdio-bus 6:30 raw 9
0x002e
And naturally 100M works too:
root@...nWrt:/# [ 528.859412] mtk_pcs_get_state: bm=0x2c1140, adv=0x5a014001
[ 528.864908] mtk_soc_eth 15100000.ethernet wan: Link is Down
[ 528.870513] mtk_pcs_get_state: bm=0x2c1140, adv=0x5a014001
[ 528.875983] mtk_pcs_get_state: bm=0x2c1140, adv=0x5a014001
[ 530.939756] mtk_pcs_get_state: bm=0x2c1140, adv=0xd6014001
[ 530.945238] mtk_pcs_link_up: interface=4
[ 530.949143] offset:0 0x2c1140
[ 530.949145] offset:4 0x4d544950
[ 530.952107] offset:8 0xd6014001
[ 530.955232] offset:0x20 0x3112011b
[ 530.958368] mtk_soc_eth 15100000.ethernet wan: Link is Up - 100Mbps/Full - flow control rx/tx
root@...nWrt:/# mdio mdio-bus 6:30 raw 8
0x34da
root@...nWrt:/# mdio mdio-bus 6:30 raw 9
0x002d
Now, if we only could figure out what the difference is between this and
what we configure when the mode is changed from 2500base-x to sgmii.
Bjørn
Powered by blists - more mailing lists