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=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,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 502CAC433B4 for ; Tue, 6 Apr 2021 04:48:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1A147613B3 for ; Tue, 6 Apr 2021 04:48:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243600AbhDFEsG (ORCPT ); Tue, 6 Apr 2021 00:48:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243599AbhDFEsE (ORCPT ); Tue, 6 Apr 2021 00:48:04 -0400 Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE3CDC061574 for ; Mon, 5 Apr 2021 21:47:56 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id c2so4245972uaj.3 for ; Mon, 05 Apr 2021 21:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ClOiyYZKz95OIO54J0VorNj6tqXyN9Hb3E0W6gOaVhI=; b=U887KtV1EvddId/O9RvxsuXKBXhf3+i8S1FqCjXp++g2o5QFeWRsDP4LeG+FA3gLvo JZMNPUByMXQOcDRZ8ovj2XIARL8SMTJRPDzgA2Gln9kXXVSjOwYEJnO7cmOqjor/mZAA 3VlAN/Hlf5RZyxvNF+Wf499nC8BOfMp8t2+H4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ClOiyYZKz95OIO54J0VorNj6tqXyN9Hb3E0W6gOaVhI=; b=m458hcQ/3Jpg6dPkhN2IvVY+hTF3+TExCQVG0dRn9sELNKEuVW06j0P+dz7hvAgthW DQddGbGDNAUNV6Xr4jPwd4G5l6vc0wOo4UpTSaUb5iILwXh0vKYRfhbBAkqnhSnz6cO+ kxM1o8mnIsuTcwngS+pzFK1Kejuu1K8bYFzHuD5lu4px4ADLqhKOnsc0yszAFh+1wKd6 uCulen/iyMtCZ9wei7DxCn41cIsXqiL5ktNIOcy+Ncs6TjRvTKIV1hAuC1z6/sqeV+hh 3W1B22oMafK8YWmQeG+bjRcFmqmCZmx4zWcwTY2xt7/L8PxngZDyI81tCnV9eTHHDihX Gy7A== X-Gm-Message-State: AOAM530qKO70+X9hDyU/c6TawVdh+fMBq5+R6gwL+5pAiCdBftfnTYqw zwMLdi+3S6qFNs9mRqoQmhW6Dkq1SsYvF6nPn89GFw== X-Google-Smtp-Source: ABdhPJyB+i4AGUkCIU/V7q7e8lqa2S6L4kkRMUZ8IjPMo2GRduKRnjSxHUNwc3Tt2Z7FX4YgOyALK+2psTUEu0lbo0E= X-Received: by 2002:ab0:3c8f:: with SMTP id a15mr16303813uax.66.1617684475522; Mon, 05 Apr 2021 21:47:55 -0700 (PDT) MIME-Version: 1.0 References: <20210405231344.1403025-1-grundler@chromium.org> In-Reply-To: From: Grant Grundler Date: Tue, 6 Apr 2021 04:47:43 +0000 Message-ID: Subject: Re: [PATCH net-next v4 0/4] usbnet: speed reporting for devices without MDIO To: Andrew Lunn Cc: Grant Grundler , Oliver Neukum , Jakub Kicinski , Roland Dreier , nic_swsd , netdev , "David S . Miller" , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 6, 2021 at 12:09 AM Andrew Lunn wrote: > > On Mon, Apr 05, 2021 at 04:13:40PM -0700, Grant Grundler wrote: > > This series introduces support for USB network devices that report > > speed as a part of their protocol, not emulating an MII to be accessed > > over MDIO. > > > > v2: rebased on recent upstream changes > > v3: incorporated hints on naming and comments > > v4: fix misplaced hunks; reword some commit messages; > > add same change for cdc_ether > > v4-repost: added "net-next" to subject and Andrew Lunn's Reviewed-by > > > > I'm reposting Oliver Neukum's patch series with > > fix ups for "misplaced hunks" (landed in the wrong patches). > > Please fixup the "author" if "git am" fails to attribute the > > patches 1-3 (of 4) to Oliver. > > > > I've tested v4 series with "5.12-rc3+" kernel on Intel NUC6i5SYB > > and + Sabrent NT-S25G. Google Pixelbook Go (chromeos-4.4 kernel) > > + Alpha Network AUE2500C were connected directly to the NT-S25G > > to get 2.5Gbps link rate: > > # ethtool enx002427880815 > > Settings for enx002427880815: > > Supported ports: [ ] > > Supported link modes: Not reported > > Supported pause frame use: No > > Supports auto-negotiation: No > > Supported FEC modes: Not reported > > Advertised link modes: Not reported > > Advertised pause frame use: No > > Advertised auto-negotiation: No > > Advertised FEC modes: Not reported > > Speed: 2500Mb/s > > Duplex: Half > > Auto-negotiation: off > > Port: Twisted Pair > > PHYAD: 0 > > Transceiver: internal > > MDI-X: Unknown > > Current message level: 0x00000007 (7) > > drv probe link > > Link detected: yes > > > > > > "Duplex" is a lie since we get no information about it. > > You can ask the PHY. At least those using mii or phylib. If you are > using mii, then mii_ethtool_get_link_ksettings() should set it > correctly. If you are using phylib, phy_ethtool_get_link_ksettings() > will correctly set it. If you are not using either of these, you are > on your own. > > Speed: 2500Mb/s and Duplex: Half is very unlikely. You really only > ever see 10 Half and occasionally 100 Half. Anything above that will > be full duplex. > > It is probably best to admit the truth and use DUPLEX_UNKNOWN. Agreed. I didn't notice this "lie" until I was writing the commit message and wasn't sure off-hand how to fix it. Decided a follow on patch could fix it up once this series lands. You are right that DUPLEX_UNKNOWN is the safest (and usually correct) default. Additionally, if RX and TX speed are equal, I am willing to assume this is DUPLEX_FULL. I can propose something like this in a patch: grundler <1637>git diff diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index 86eb1d107433..a7ad9a0fb6ae 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -978,6 +978,11 @@ int usbnet_get_link_ksettings_internal(struct net_device *net, else cmd->base.speed = SPEED_UNKNOWN; + if (dev->rx_speed == dev->tx_speed) + cmd->base.duplex = DUPLEX_FULL; + else + cmd->base.duplex =DUPLEX_UNKNOWN; + return 0; } EXPORT_SYMBOL_GPL(usbnet_get_link_ksettings_internal); Probably should check that link speed is > 100Mbps to be more certain about this assumption (based on your comments above). I can send this out later once this series lands or you are welcome to post this with additional checks if you like. The messy case is when RX != TX speed and I didn't want to delay landing the current series to figure out DUPLEX. > > I expect "Auto-Negotiation" is always true for cdc_ncm and > > cdc_ether devices and perhaps someone knows offhand how > > to have ethtool report "true" instead. > > ethtool_link_ksettings contains three bitmaps: > > supported: The capabilities of this device. > advertising: What this device is telling the link peer it can do. > lp_advertising: What the link peer is telling us it can do. > > So to get Supports auto-negotiation to be true you need to set bit > ETHTOOL_LINK_MODE_Autoneg_BIT in supported. > For Advertised auto-negotiation: you need to set the same bit in > advertising. > > Auto-negotiation: off is i think from base.autoneg. Thanks for explaining! :) I understand the three bitmaps. I just hadn't taken the time to figure out how to access/set those from link_ksettings API. If we want to assume autoneg is always on (regardless of which type of media cdc_ncm/cdc_ether are talking to), we could set both supported and advertising to AUTO and lp_advertising to UNKNOWN. But I would prefer to add more checks to prove this is correct (vs making "well intentioned" assumptions). cheers, grant