From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F3A4C282CE for ; Fri, 5 Apr 2019 20:04:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 45912206BA for ; Fri, 5 Apr 2019 20:04:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZLQ3vj2c" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731653AbfDEUEb (ORCPT ); Fri, 5 Apr 2019 16:04:31 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:37337 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731183AbfDEUEa (ORCPT ); Fri, 5 Apr 2019 16:04:30 -0400 Received: by mail-wr1-f68.google.com with SMTP id w10so9400493wrm.4 for ; Fri, 05 Apr 2019 13:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fgoIRsSr4bXtnHhRMCEhgu9o3+BgXWCqSOQIqVYMdjU=; b=ZLQ3vj2cRjX0uRgvN/VhC4FbYkST2bAgu+IAe3/ZQgauF2G9rh3t4h7oKrciMjp3cX 4F+UVq9ii30X5FORlj36H3Sxtw18h0ss5c2ZL2O2UUdjm7TbpoJfGHjnNJE2xLBbN2pF 7XIcbePUBhW2Lnez8GoNXPJktEqT6Rl4ILd9BCm9BTpxeSFa7/P6yRjpv3xv+R5CScHU CLlgDdjPcTV79wUS5xvZIGpMa95Pu8A6BGtJIg5Z5co0C78zu1romQ2D+l2eBEejh05J awibYqD3EMVEzu5G7neQf1XMDUFNKDDt6zHuF6saExdeVQAi1FklAVVgXQr2Zvyq+bZH eOVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fgoIRsSr4bXtnHhRMCEhgu9o3+BgXWCqSOQIqVYMdjU=; b=cfdMO4RyvXDEGEm0hL9JSzrkUGTtmz0C7Epjh6tRDlXMMM+GxpgSgRJaPWojay3biw ZOI6uaY1vz72+i3NvrecDZMmgubCZkLy/gb788XthsDgPlsB5iNdhodsRhewEPInTyJI 7qWcy+3sRDHCn9IU/OZR10wiyVrQQ+Op/DJ6UtdKj9wTfIOguB34eAC75VSeTMzaxNZI g9MefStFeLazn3I9mnESD5bPWPLVEcMfhp6s9m4OC+Tm4SAUCMcyWa1Xe+FTSk8bGtTq PdJQZXfOGNvV/10t+RsmIqVoBuPy7sJUqcfdmmFQ9La+6bDLO1p32PSH3sAXS1l0ao4b sghQ== X-Gm-Message-State: APjAAAUxryztuXPCc2gjK2dkkgMxT8beizYgQTduRmF9Mb1tmG5ub54l S2BirupvtBrp0j2FSF/8ZLL8hPkI X-Google-Smtp-Source: APXvYqyxPh2N59rQuPRpHHa0q/07Tz+l5iqDPRjGdgiZJ4V5rrVlV34wnLctg544UMfxb+lvgGDE6Q== X-Received: by 2002:adf:f68d:: with SMTP id v13mr9541772wrp.6.1554494668753; Fri, 05 Apr 2019 13:04:28 -0700 (PDT) Received: from ?IPv6:2003:ea:8be1:dd00:c5f4:1013:b1cb:d123? (p200300EA8BE1DD00C5F41013B1CBD123.dip0.t-ipconnect.de. [2003:ea:8be1:dd00:c5f4:1013:b1cb:d123]) by smtp.googlemail.com with ESMTPSA id v184sm5998633wma.6.2019.04.05.13.04.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 13:04:27 -0700 (PDT) Subject: Re: [PATCH net-next] net: phy: improve link partner capability detection To: Andrew Lunn Cc: Florian Fainelli , David Miller , "netdev@vger.kernel.org" References: <20190405194821.GI23536@lunn.ch> From: Heiner Kallweit Message-ID: <6a86f31f-dda8-77d9-aace-9ad1ad770a28@gmail.com> Date: Fri, 5 Apr 2019 22:04:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190405194821.GI23536@lunn.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 05.04.2019 21:48, Andrew Lunn wrote: > 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 > Hi Andrew, > 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. > Link partner gigabit advertisement is reported in register MII_STAT1000. If we have a 100MBit PHY w/o this register, then we will never know whether the link partner supports gigabit. I would have to check the 802.3 specs, but it could even be that the gigabit autoneg is a separate step in the autoneg process. If this separate step isn't supported by a 100MBit PHY, then this PHY per se has no chance to detect whether link partner is gigabit-capable. > 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? > We report everything the chip reports. But similar to what I wrote about C22 and gigabit, what the chip reports may depend on which autoneg steps it does. Again I would have to check the standard whether e.g. NBase-T (2.5Gbps, 5Gbps) uses a separate autoneg step. If we don't advertise at least of these modes, then the PHY may decide to skip this autoneg step, and in the end we won't know whether link partner supports 2.5Gbps/5Gbps. > Andrew > Heiner