| 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: <87o7qy39v5.fsf@miraculix.mork.no>
Date: Mon, 16 Jan 2023 14:08:30 +0100
From: Bjørn Mork <bjorn@...k.no>
To: Frank Wunderlich <frank-w@...lic-files.de>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
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
Frank Wunderlich <frank-w@...lic-files.de> writes:
> apart from this little problem it works much better than it actually is so imho more
> people should test it on different platforms.
Hello! I've been banging my head against an MT7986 board with two
Maxlinear GPY211C phys for a while. One of those phys is connected to
port 5 of the MT7531 switch. This is working perfectly.
The other GPY211C is connected to the second MT7986 mac. This one is
giving me a headache...
I can only get the port to work at 2500Mb/s. Changing the speed to
anything lower looks fine in ethtool etc, but traffic is blocked.
Not knowing the first thing about MACs and PHYs and such, my best guess
is that there is something wrong with the PCS config.
Now I am currently testing this on an older kernel (using OpenWrt -
booting mainline is not straight forward). But I have backported all the
patches which came out of this thread. The resulting mtk_sgmii.c is
identical to the one currently in next-next, except for some additional
debug printk's. Since this is a small file, I've attached my current
mtk_sgmii.c copy for reference.
The output of those printks when changing peer speed to to 1000Mb/s is:
[ 363.099410] mtk_soc_eth 15100000.ethernet wan: Link is Down
[ 365.189945] mtk_sgmii_select_pcs: id=1
[ 365.193709] mtk_pcs_config: interface=4
[ 365.197530] offset:0 0x140
[ 365.197533] offset:4 0x4d544950
[ 365.200237] offset:8 0x20
[ 365.203365] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x1, bmcr=0x0
[ 365.215601] mtk_pcs_link_up: interface=4
[ 365.219511] offset:0 0x140
[ 365.219513] offset:4 0x4d544950
[ 365.222204] offset:8 0x1
[ 365.225328] mtk_pcs_link_up: sgm_mode=0x18
[ 365.231940] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
and when changing peer back to autoneg (i.e. 2500Mb/s):
[ 878.939417] mtk_soc_eth 15100000.ethernet wan: Link is Down
[ 883.099857] mtk_sgmii_select_pcs: id=1
[ 883.103620] mtk_pcs_config: interface=22
[ 883.107527] offset:0 0x140
[ 883.107529] offset:4 0x4d544950
[ 883.110234] offset:8 0x1
[ 883.113363] mtk_pcs_config: rgc3=0x4, advertise=0x20 (changed), link_timer=10000000, sgm_mode=0x0, bmcr=0x0
[ 883.125686] mtk_pcs_link_up: interface=22
[ 883.129683] offset:0 0x40140
[ 883.129685] offset:4 0x4d544950
[ 883.132550] offset:8 0x20
[ 883.135687] mtk_soc_eth 15100000.ethernet wan: Link is Up - 2.5Gbps/Full - flow control rx/tx
ethtool output looks as expected in both cases:
# 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: slave
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
# 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: 100baseT/Full
1000baseT/Full
2500baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/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
The behaviour looks similar to the GPY211C attached to switch port 5.
Except that the latter works regardless of speed..
I did however notice one difference, which may or may not be
significant, in the VSPEC1_SGMII_STAT register of the phys after
changing to 1000Mb/s. The switch attached phy reports:
root@...nWrt:/# mdio mdio-bus 5:30 raw 9
0x002e
while the soc mac attached phy reports
root@...nWrt:/# mdio mdio-bus 6:30 raw 9
0x000e
According to
https://assets.maxlinear.com/web/documents/617810_gpy211b1vc_gpy211c0vc_ds_rev1.4.pdf
bit 5 is "Auto-Negotiation Completed". So it does look like the switch
mac is doing AN on the SGMII link, and the soc mac is not. Is that
correct?
Any hints on where I should look next?
The ethernet part of my device tree looks like this:
ð {
status = "okay";
gmac0: mac@0 {
compatible = "mediatek,eth-mac";
reg = <0>;
phy-mode = "2500base-x";
fixed-link {
speed = <2500>;
full-duplex;
pause;
};
};
mac@1 {
compatible = "mediatek,eth-mac";
reg = <1>;
label = "wan";
phy-mode = "2500base-x";
phy-handle = <&phy6>;
};
mdio: mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
};
};
&mdio {
reset-gpios = <&pio 6 GPIO_ACTIVE_LOW>;
reset-delay-us = <50000>;
reset-post-delay-us = <20000>;
phy5: phy@5 {
compatible = "ethernet-phy-ieee802.3-c45";
reg = <5>;
};
phy6: phy@6 {
compatible = "ethernet-phy-ieee802.3-c45";
reg = <6>;
};
switch: switch@1f {
compatible = "mediatek,mt7531";
reg = <31>;
reset-gpios = <&pio 5 GPIO_ACTIVE_HIGH>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&pio>;
interrupts = <66 IRQ_TYPE_LEVEL_HIGH>;
};
};
&switch {
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan3";
};
port@1 {
reg = <1>;
label = "lan2";
};
port@2 {
reg = <2>;
label = "lan1";
};
port@5 {
reg = <5>;
label = "lan4";
phy-mode = "2500base-x";
phy-handle = <&phy5>;
};
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "2500base-x";
fixed-link {
speed = <2500>;
full-duplex;
pause;
};
};
};
};
Bjørn
View attachment "mtk_sgmii.c" of type "text/x-csrc" (5842 bytes)
Powered by blists - more mailing lists