All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Grant Grundler <grundler@chromium.org>
Cc: Oliver Neukum <oneukum@suse.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Roland Dreier <roland@kernel.org>,
	nic_swsd <nic_swsd@realtek.com>, netdev <netdev@vger.kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next v4 0/4] usbnet: speed reporting for devices without MDIO
Date: Tue, 6 Apr 2021 15:00:12 +0200	[thread overview]
Message-ID: <YGxbXOXquilXNV2W@lunn.ch> (raw)
In-Reply-To: <CANEJEGsYQm9EhqVLA4oedP2fuKrP=3bOUDV9=7owfdZzX7SpUA@mail.gmail.com>

> > 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.

Is this same interface used by WiFi? Ethernet does not support
different rates in each direction. So if RX and TX are different, i
would actually say something is broken. 10 Half is still doing 10Mbps
in each direction, it just cannot do both at the same time.
WiFi can have asymmetric speeds.

> 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);

So i would say this is wrong. I would just set DUPLEX_UNKNOWN and be
done.

> I can send this out later once this series lands or you are welcome to
> post this with additional checks if you like.

Yes, this discussion should not prevent this patchset from being
merged.

> 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.

I pretty much agree autoneg has to be on. If it is not, and it is
using a forced speed, there would need to be an additional API to set
what it is forced to. There could be such proprietary calls, but the
generic cdc_ncm/cdc_ether won't support them.

But i also don't know how setting autoneg actually helps the user.
Everybody just assumes it is supported. If you really know auto-neg is
not supported and you can reliably indicate that autoneg is not
supported, that would be useful. But i expect most users want to know
if their USB 2.0 device is just doing 100Mbps, or if their USB 3.0
device can do 2.5G. For that, you need to see what is actually
supported.

	Andrew

  reply	other threads:[~2021-04-06 13:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05 23:13 [PATCH net-next v4 0/4] usbnet: speed reporting for devices without MDIO Grant Grundler
2021-04-05 23:13 ` [PATCH net-next v4 1/4] usbnet: add _mii suffix to usbnet_set/get_link_ksettings Grant Grundler
2021-04-05 23:13 ` [PATCH net-next v4 2/4] usbnet: add method for reporting speed without MII Grant Grundler
2021-04-05 23:13 ` [PATCH net-next v4 3/4] net: cdc_ncm: record speed in status method Grant Grundler
2021-04-05 23:13 ` [PATCH net-next v4 4/4] net: cdc_ether: " Grant Grundler
2021-04-06  0:09 ` [PATCH net-next v4 0/4] usbnet: speed reporting for devices without MDIO Andrew Lunn
2021-04-06  4:47   ` Grant Grundler
2021-04-06 13:00     ` Andrew Lunn [this message]
2021-04-06 18:01       ` Grant Grundler
2021-04-07 11:36         ` Oliver Neukum
2021-04-06 23:30 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YGxbXOXquilXNV2W@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=grundler@chromium.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nic_swsd@realtek.com \
    --cc=oneukum@suse.com \
    --cc=roland@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.