linux-kernel - Re: [PATCH] usbnet_link_change() fails to call netif_carrier

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]

Message-ID: <m35xogg1qt.fsf@t19.piap.pl>
Date: Thu, 21 Nov 2024 14:22:50 +0100
From: Krzysztof Hałasa <khalasa@...p.pl>
To: netdev <netdev@...r.kernel.org>
Cc: Oliver Neukum <oneukum@...e.com>,  Andrew Lunn <andrew+netdev@...n.ch>,
  "David S. Miller" <davem@...emloft.net>,  Eric Dumazet
 <edumazet@...gle.com>,  Jakub Kicinski <kuba@...nel.org>,  Paolo Abeni
 <pabeni@...hat.com>,  linux-usb@...r.kernel.org,
  linux-kernel@...r.kernel.org,  Jose Ignacio Tornos Martinez
 <jtornosm@...hat.com>,  Ming Lei <ming.lei@...onical.com>
Subject: Re: [PATCH] usbnet_link_change() fails to call netif_carrier_on()

Hi,

I'm still trying to understand how is it all (phy + phylink) supposed to
work. My adapter uses fixed PHY mode (uses a special SFP module and the
ASIX AX88772B internal PHY, configured by internal SROM memory).

This is not a fixed *MII connection, though. This is a regular clause 22
transceiver, a part of the ASIX MAC IC.

The MDIO registers are initialized (on power-up) to (BMCR) 0x2100 and
(BMSR) 0x780D, meaning autonegotiation is supported but disabled,
100 Mbps FD is selected. Link is established.

Ethtool shows the following:
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/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
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
the above is generally true, but:
        Speed: Unknown!
        Duplex: Unknown! (255)
        Auto-negotiation: on <<<<<<<<<<<<<<<<
        Port: Twisted Pair
        PHYAD: 10
        Transceiver: internal
        MDI-X: Unknown
        Link detected: no <<<<<<<<<<<<<<<<

Autonegotiation is definitely off.

Perhaps this code is responsible (in phy_probe()):

	if (!linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
			       phydev->supported))
		phydev->autoneg = 0;

Shouldn't it check if the actual PHY BMCR autoneg bit (aka 0.12) isn't
zero, and if it is, set autoneg = 0?

The other part which may be contributing (in genphy_update_link()):

	/* Consider the case that autoneg was started and "aneg complete"
	 * bit has been reset, but "link up" bit not yet.
	 */
	if (phydev->autoneg == AUTONEG_ENABLE && !phydev->autoneg_complete)
		phydev->link = 0;

Since phydev->autoneg apparently means "autoneg is supported", the above
doesn't seem very right.

But I guess phydev->autoneg is supposed to mean "autoneg is actually
enabled".

What do you think?
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa