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 08:25:26 +0200 From: Frank Wunderlich <linux@...web.de> To: "Russell King (Oracle)" <linux@...linux.org.uk>, Frank Wunderlich <frank-w@...lic-files.de> CC: 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: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops Am 21. Oktober 2022 23:28:09 MESZ schrieb "Russell King (Oracle)" <linux@...linux.org.uk>: >On Fri, Oct 21, 2022 at 09:52:36PM +0200, Frank Wunderlich wrote: >> > Gesendet: Freitag, 21. Oktober 2022 um 20:31 Uhr >> > Von: "Russell King (Oracle)" <linux@...linux.org.uk> >> >> > On Fri, Oct 21, 2022 at 07:47:47PM +0200, Frank Wunderlich wrote: >> > > > Gesendet: Freitag, 21. Oktober 2022 um 11:06 Uhr >> > > > Von: "Russell King (Oracle)" <linux@...linux.org.uk> >> >> > > > Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in >> > > > the low 16 bits, and BMSR in the upper 16 bits, so: >> > > > >> > > > At address 4, I'd expect the PHYSID. >> > > > At address 8, I'd expect the advertisement register in the low 16 bits >> > > > and the link partner advertisement in the upper 16 bits. >> > > > >> > > > Can you try an experiment, and in mtk_sgmii_init() try accessing the >> > > > regmap at address 0, 4, and 8 and print their contents please? >> > > >> > > is this what you want to see? >> >> > > [ 1.083359] dev: 0 offset:0 0x840140 >> > > [ 1.083376] dev: 0 offset:4 0x4d544950 >> > > [ 1.086955] dev: 0 offset:8 0x1 >> > > [ 1.090697] dev: 1 offset:0 0x81140 >> > > [ 1.093866] dev: 1 offset:4 0x4d544950 >> > > [ 1.097342] dev: 1 offset:8 0x1 >> > >> > Thanks. Decoding these... >> > >> > dev 0: >> > BMCR: fixed, full duplex, 1000Mbps, !autoneg >> > BMSR: link up >> > Phy ID: 0x4d54 0x4950 >> > Advertise: 0x0001 (which would correspond with the MAC side of SGMII) >> > Link partner: 0x0000 (no advertisement received, but we're not using >> > negotiation.) >> > >> > dev 1: >> > BMCR: autoneg (full duplex, 1000Mbps - both would be ignored) >> > BMSR: able to do autoneg, no link >> > Phy ID: 0x4d54 0x4950 >> > Advertise: 0x0001 (same as above) >> > Link partner: 0x0000 (no advertisement received due to no link) >> > >> > Okay, what would now be interesting is to see how dev 1 behaves when >> > it has link with a 1000base-X link partner that is advertising >> > properly. If this changes to 0x01e0 or similar (in the high 16-bits >> > of offset 8) then we definitely know that this is an IEEE PHY register >> > set laid out in memory, and we can program the advertisement and read >> > the link partner's abilities. >> >> added register-read on the the new get_state function too >> >> on bootup it is now a bit different >> >> [ 1.086283] dev: 0 offset:0 0x40140 #was previously 0x840140 >> [ 1.086301] dev: 0 offset:4 0x4d544950 >> [ 1.089795] dev: 0 offset:8 0x1 >> [ 1.093584] dev: 1 offset:0 0x81140 >> [ 1.096716] dev: 1 offset:4 0x4d544950 >> [ 1.100191] dev: 1 offset:8 0x1 >> >> root@...-r3:~# ip link set eth1 up >> [ 172.037519] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode >> root@...-r3:~# >> [ 172.102949] offset:0 0x40140 #still same value > >If this is "dev: 1" the value has changed - the ANENABLE bit has been >turned off, which means it's not going to bother receiving or sending >the 16-bit control word. Bit 12 needs to stay set for it to perform >the exchange. Your right,was confused that dev 0 (fixed link to switch chip) had different value. offset:0 0x81140 => 0x40140 So i should change offset 8 (currently 0x1) to at least 0x1 | BIT(12)? I can try to set this in the get_state callback,but i'm unsure i can read out it on my switch (basic mode changes yes,but not the value directly)...if mode is not autoneg i will see no change there. regards Frank
Powered by blists - more mailing lists