netdev - Re: [PATCH net-next] net: phy: improve link partner capability detection

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:   Fri, 5 Apr 2019 21:48:21 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: phy: improve link partner capability
 detection

On Fri, Apr 05, 2019 at 09:23:13PM +0200, Heiner Kallweit wrote:
> genphy_read_status() so far checks phydev->supported, not the actual
> PHY capabilities. This can make a difference if the supported speeds
> have been limited by of_set_phy_supported() or phy_set_max_speed().
> 
> It seems that this issue only affects the link partner advertisements
> as displayed by ethtool. Also this patch wouldn't apply to older
> kernels because linkmode bitmaps have been introduced recently.
> Therefore net-next.

Hi Heiner

Are you saying, if the local PHY/MAC does not support 1000Base-T, we
should not check if the peer is advertising 1000Base-T? That seems
wrong. We should report everything it offers. The fact we cannot make
use of 1000Base-T should not matter, and resolving of the auto-get
should do the right thing when presented with modes it cannot use.

What do we do in the c45 case? The peer can do 2.5G, 5G and
10G, but the local can only do 2.5G? Do we just report the peers 2.5G
and skip the others? Or do we report them all?

    Andrew