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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 22 Oct 2022 18:05:43 +0100 From: "Russell King (Oracle)" <linux@...linux.org.uk> To: Frank Wunderlich <frank-w@...lic-files.de> Cc: 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: Re: Re: Re: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops On Sat, Oct 22, 2022 at 12:52:00PM +0200, Frank Wunderlich wrote: > > Gesendet: Samstag, 22. Oktober 2022 um 11:11 Uhr > > Von: "Russell King (Oracle)" <linux@...linux.org.uk> > > > Please try this untested patch, which should setup the PCS to perform > > autonegotiation when using in-band mode for 1000base-X, write the > > correct to offset 8, and set the link timer correctly. > > hi, > > this patch breaks connectivity at least on the sfp-port (eth1). > > root@...-r3:~# ip link set eth1 up > [ 65.457521] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode > root@...-r3:~# [ 65.522936] offset:0 0x2c1140 > [ 65.522950] offset:4 0x4d544950 > [ 65.525914] offset:8 0x40e041a0 > [ 65.529064] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 1Gbps/Unknown - flow control off > [ 65.540733] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready > > root@...-r3:~# ip a a 192.168.0.19/24 dev eth1 > root@...-r3:~# ip r a default via 192.168.0.10 > root@...-r3:~# iperf3 -c 192.168.0.21 #ping does not work too > iperf3: error - unable to send control message: Bad file descriptor > root@...-r3:~# ethtool eth1 > [ 177.346183] offset:0 0x2c1140 > [ 177.346202] offset:4 0x4d544950 > Settings for eth[ 177.349168] offset:8 0x40e041a0 > 1: > Supported p[ 177.352477] offset:0 0x2c1140 > [ 177.356952] offset:4 0x4d544950 > > Supported link modes: 1000baseX/Full > Supported pause frame use: Symmetric Receive-only > Supports auto-negotiation: Yes > Supported FEC modes: Not reported > Advertised link modes: 1000baseX/Full > Advertised pause frame use: Symmetric Receive-only > Advertised auto-negotiation: Yes > Advertised FEC modes: Not reported > Speed: 1000Mb/s > Duplex: Unknown! (255) > 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 > root@...-r3:~# > > from sgmii_init > [ 1.091796] dev: 1 offset:0 0x81140 > [ 1.094977] dev: 1 offset:4 0x4d544950 > [ 1.098456] dev: 1 offset:8 0x1 > ... > pcs_get_state > [ 65.522936] offset:0 0x2c1140 > [ 65.522950] offset:4 0x4d544950 > [ 65.525914] offset:8 0x40e041a0 > [ 177.346183] offset:0 0x2c1140 > [ 177.346202] offset:4 0x4d544950 > [ 177.349168] offset:8 0x40e041a0 > [ 177.352477] offset:0 0x2c1140 > [ 177.356952] offset:4 0x4d544950 Hi, Thanks. Well, the results suggest that the register at offset 8 is indeed the advertisement and link-partner advertisement register. So we have a bit of progress and a little more understanding of this hardware. Do you know if your link partner also thinks the link is up? What I notice is: mtk_soc_eth 15100000.ethernet eth1: Link is Up - 1Gbps/Unknown - flow control off The duplex is "unknown" which means you're not filling in the state->duplex field in your pcs_get_state() function. Given the link parter adverisement is 0x00e0, this means the link partner supports PAUSE, 1000base-X/Half and 1000base-X/Full. The resolution is therefore full duplex, so can we hack that in to your pcs_get_state() so we're getting that right for this testing please? Now, I'm wondering what SGMII_IF_MODE_BIT0 and SGMII_IF_MODE_BIT5 do in the SGMSYS_SGMII_MODE register. Does one of these bits set the format for the 16-bit control word that's used to convey the advertisements. I think the next step would be to play around with these and see what effect setting or clearing these bits has - please can you give that a go? Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists