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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 3D452C282CE for ; Fri, 5 Apr 2019 19:48:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E695A2173C for ; Fri, 5 Apr 2019 19:48:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="MEj33yEq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731707AbfDETsZ (ORCPT ); Fri, 5 Apr 2019 15:48:25 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:51913 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731183AbfDETsZ (ORCPT ); Fri, 5 Apr 2019 15:48:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jxyQeZBwJxZj94j9O/anDHBpmhPuw0BqFfaBwX22pu4=; b=MEj33yEqwxgA81X6XrsbJBV/e7 7q8kxdycmwTyRlIMveWzlxfgyagUXIc4fE42nj88zE5/TrFYZoUZew5BUxuHrmYfDJYcHrZu+NwdK yAHiQT13/kA5DIGJS7afV9ZPkGlyDztb0j68uEsF9r/hgX471N7eqRVDKLU/6BKD6RnM=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1hCUp3-0006TO-57; Fri, 05 Apr 2019 21:48:21 +0200 Date: Fri, 5 Apr 2019 21:48:21 +0200 From: Andrew Lunn To: Heiner Kallweit Cc: Florian Fainelli , David Miller , "netdev@vger.kernel.org" Subject: Re: [PATCH net-next] net: phy: improve link partner capability detection Message-ID: <20190405194821.GI23536@lunn.ch> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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