| 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
| ||
|
Date: Fri, 21 Oct 2022 21:52:36 +0200
From: Frank Wunderlich <frank-w@...lic-files.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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: Aw: Re: Re: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops
> 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
[ 172.102964] offset:4 0x4d544950
[ 172.105842] offset:8 0x1
[ 172.108992] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 1Gbps/Unknown - flow control off
[ 172.120058] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
so no change on link up
maybe ethtool-output is interesting
root@...-r3:~# ethtool -m eth1
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x07 (LC)
Transceiver codes : 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00
Transceiver type : Ethernet: 1000BASE-SX
Encoding : 0x01 (8B/10B)
BR, Nominal : 1300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 550m
Length (62.5um) : 270m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 850nm
Vendor name : OEM
Vendor OUI : 00:90:65
Vendor PN : GLC-SX-MMD _
Vendor rev : _e
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : CSCGE1M14134
Date code : 220120
Optical diagnostics support : Yes
Laser bias current : 3.634 mA
Laser output power : 0.3181 mW / -4.97 dBm
Receiver signal average optical power : 0.3444 mW / -4.63 dBm
Module temperature : 35.32 degrees C / 95.58 degrees F
Module voltage : 3.3101 V
Alarm/warning flags implemented : Yes
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser output power high alarm : Off
Laser output power low alarm : Off
Laser output power high warning : Off
Laser output power low warning : Off
Module temperature high alarm : Off
Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : Off
Laser rx power high warning : Off
Laser rx power low warning : Off
Laser bias current high alarm threshold : 100.000 mA
Laser bias current low alarm threshold : 0.000 mA
Laser bias current high warning threshold : 90.000 mA
Laser bias current low warning threshold : 0.100 mA
Laser output power high alarm threshold : 1.2589 mW / 1.00 dBm
Laser output power low alarm threshold : 0.0501 mW / -13.00 dBm
Laser output power high warning threshold : 0.7943 mW / -1.00 dBm
Laser output power low warning threshold : 0.0631 mW / -12.00 dBm
Module temperature high alarm threshold : 90.00 degrees C / 194.00 degrees F
Module temperature low alarm threshold : -45.00 degrees C / -49.00 degrees F
Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
Module temperature low warning threshold : -40.00 degrees C / -40.00 degrees F
Module voltage high alarm threshold : 3.8000 V
Module voltage low alarm threshold : 2.7000 V
Module voltage high warning threshold : 3.7000 V
Module voltage low warning threshold : 2.8000 V
Laser rx power high alarm threshold : 0.7943 mW / -1.00 dBm
Laser rx power low alarm threshold : 0.0079 mW / -21.02 dBm
Laser rx power high warning threshold : 0.5012 mW / -3.00 dBm
Laser rx power low warning threshold : 0.0126 mW / -19.00 dBm
root@...-r3:~# ethtool eth1
[ 295.755349] offset:0 0x40140
[ 295.755368] offset:4 0x4d544950
Settings for eth[ 295.758247] offset:8 0x1
1:
Supported p[ 295.761551] offset:0 0x40140
[ 295.765446] 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
> At that point, we should try programming the low 16-bits of offset 8
> to see whether that advertisement makes it to the far end of the link.
have only my switch on the other side where i imho cannot read out these advertising. and programming to which values at which point (in the get-state callback to be done on link-up)?
> It would be well worth trying to work this out, because it will then
> vastly improve the knowledge of this hardware, and improve the
> driver no end.
>
> Is this something you could investigate please?
regards Frank
Powered by blists - more mailing lists