netdev - RE: [PATCH net-next 5/6] net: txgbe: Implement phylink pcs

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 11 Apr 2023 10:34:27 +0800
From:   Jiawen Wu <jiawenwu@...stnetic.com>
To:     "'Russell King \(Oracle\)'" <linux@...linux.org.uk>
Cc:     <netdev@...r.kernel.org>, <mengyuanlou@...-swift.com>
Subject: RE: [PATCH net-next 5/6] net: txgbe: Implement phylink pcs

On Monday, April 10, 2023 6:41 PM, Russell King (Oracle) wrote:
> On Mon, Apr 10, 2023 at 03:32:12PM +0800, Jiawen Wu wrote:
> > > > +				       struct phylink_link_state
*state)
> > > > +{
> > > > +	int lpa, bmsr;
> > > > +
> > > > +	/* For C37 1000BASEX mode */
> > > > +	if (linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
> > > > +			      state->advertising)) {
> > > > +		/* Reset link state */
> > > > +		state->link = false;
> > > > +
> > > > +		/* Poll for link jitter */
> > > > +		read_poll_timeout(pcs_read, lpa, lpa,
> > > > +				  100, 50000, false, txgbe,
> > > > +				  MDIO_MMD_VEND2, MII_LPA);
> > >
> > > What jitter are you referring to? If the link is down (and thus
this
> > > register reads zero), why do we have to spin here for 50ms each
time?
> > >
> >
> > I found that when the last interrupt arrives, the link status is
often
> > still down, but it will become up after a while. It is about 30ms on
my
> > test.
> 
> It is normal for the first read of the BMSR to report that the link is
> down after it has come up. This is so that software can see if the
link
> has failed since it last read the BMSR. Phylink knows this, and will
> re-request the link state via the pcs_get_state() callback
> appropriately.
> 
> Is it reporting that the link is down after the second read of the
> link status after the interrupt?
> 
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
> 

The link status bit of bmsr will report 1 after the second read. But
auto-negotiation looks like it will take some time to complete.
In my test case, 10000baseSR/1000baseX supported SFP on enp4s0f0, and
1000baseX supported SFP on enp4s0f1, to connect each other by optical
fiber.
Here is the log from probe the module and then change the speed with
enp4s0f0.

root@...-System-Product-Name:~/net-next# modprobe txgbe
root@...-System-Product-Name:~/net-next# dmesg -c
[63894.334069] txgbe 0000:04:00.0: 16.000 Gb/s available PCIe bandwidth,
limited by 5.0 GT/s PCIe x4 link at 0000:02:02.0 (capable of 32.000 Gb/s
with 5.0 GT/s PCIe x8 link)
[63894.337488] txgbe 0000:04:00.0 enp4s0f0: renamed from eth0
[63894.338181] sfp sfp.1024: Host maximum power 1.0W
[63894.351172] txgbe 0000:04:00.0 enp4s0f0: 30:09:f9:21:b9:5b
[63894.407234] txgbe 0000:04:00.0 enp4s0f0: configuring for
inband/10gbase-r link mode
[63894.889942] txgbe 0000:04:00.1: 16.000 Gb/s available PCIe bandwidth,
limited by 5.0 GT/s PCIe x4 link at 0000:02:02.0 (capable of 32.000 Gb/s
with 5.0 GT/s PCIe x8 link)
[63894.891155] txgbe 0000:04:00.1 enp4s0f1: renamed from eth0
[63894.906564] txgbe 0000:04:00.1 enp4s0f1: 30:09:f9:21:b9:5c
[63894.957750] txgbe 0000:04:00.1 enp4s0f1: configuring for
inband/10gbase-r link mode
[63895.208990] txgbe 0000:04:00.1 enp4s0f1: switched to
inband/1000base-x link mode
[63895.361265] txgbe 0000:04:00.1: [1] lpa=0x0, bmsr=0x189
[63895.361274] txgbe 0000:04:00.1: [2] lpa=0x0, bmsr=0x189
[63895.361282] txgbe 0000:04:00.1: [1] lpa=0x0, bmsr=0x189
[63895.361290] txgbe 0000:04:00.1: [2] lpa=0x0, bmsr=0x189
root@...-System-Product-Name:~/net-next# ethtool -s enp4s0f0 advertise
0x20000000000
root@...-System-Product-Name:~/net-next# dmesg -c
[63927.627708] txgbe 0000:04:00.1: [1] lpa=0x0, bmsr=0x189
[63927.627723] txgbe 0000:04:00.1: [2] lpa=0x0, bmsr=0x18d
[63927.627731] txgbe 0000:04:00.1: [1] lpa=0x0, bmsr=0x18d
[63927.627738] txgbe 0000:04:00.1: [2] lpa=0x0, bmsr=0x18d
[63927.647128] txgbe 0000:04:00.0: [1] lpa=0x0, bmsr=0x189
[63927.647144] txgbe 0000:04:00.0: [1] lpa=0x0, bmsr=0x18d
[63927.647148] txgbe 0000:04:00.0: [2] lpa=0x0, bmsr=0x18d
[63927.647154] txgbe 0000:04:00.0: [2] lpa=0x0, bmsr=0x18d
[63927.647162] txgbe 0000:04:00.0: [1] lpa=0x0, bmsr=0x18d
[63927.647168] txgbe 0000:04:00.0: [1] lpa=0x0, bmsr=0x18d
[63927.647172] txgbe 0000:04:00.0: [2] lpa=0x0, bmsr=0x18d
[63927.647177] txgbe 0000:04:00.0: [2] lpa=0x0, bmsr=0x18d
root@...-System-Product-Name:~/net-next# ethtool enp4s0f0
Settings for enp4s0f0:
        Supported ports: [ FIBRE ]
        Supported link modes:   1000baseX/Full
                                10000baseSR/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: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  1000baseX/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
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Link detected: no
root@...-System-Product-Name:~/net-next# dmesg -c
[63980.779785] txgbe 0000:04:00.0: [1] lpa=0x41a0, bmsr=0x1ad
[63980.779801] txgbe 0000:04:00.0: [2] lpa=0x41a0, bmsr=0x1ad

PS: "[1]" print for the first read, and "[2]" for the second.

By the way, I can't use the command "ethtool -s enp4s0f0 speed 1000
duplex full autoneg on" to set link, and the log shows "Cannot set new
settings: Invalid argument".