From: Andrew Lunn <andrew@lunn.ch>
To: Igor Russkikh <Igor.Russkikh@aquantia.com>
Cc: "David S . Miller" <davem@davemloft.net>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Dmitry Bezrukov <Dmitry.Bezrukov@aquantia.com>
Subject: [net-next,06/19] net: usb: aqc111: Introduce link management
Date: Sat, 6 Oct 2018 19:35:10 +0200 [thread overview]
Message-ID: <20181006173510.GE6990@lunn.ch> (raw)
> @@ -202,6 +319,9 @@ static int aqc111_bind(struct usbnet *dev, struct usb_interface *intf)
> dev->net->netdev_ops = &aqc111_netdev_ops;
>
> aqc111_read_fw_version(dev, aqc111_data);
> + aqc111_data->autoneg = AUTONEG_ENABLE;
> + aqc111_data->advertised_speed = (usb_speed == USB_SPEED_SUPER) ?
> + SPEED_5000 : SPEED_1000;
Hi Igor
I'd be interested in knowing the reasoning behind this.
USB 3 has a raw bandwidth of 5Gbps. But it is a shared bus. So you
have no guaranteed you are actually going to get the needed bandwidth
to support line rate.
USB 2.0 only gives you 480Mbps. So it won't even give you the full
1G. So using the same reasoning for USB3, maybe you should limit it to
100Mbps?
I personally would not apply restrictions on the PHY depending on what
USB is being used.
This becomes more important when using SFPs. If i have an SFP peer
which is expecting 2500Base-X, but because the device is plugged into
USB 2 port it is forced to use 1000Base-X, it is not going to get
link.
Andrew
next reply other threads:[~2018-10-06 17:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-06 17:35 Andrew Lunn [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-10-08 13:59 [net-next,06/19] net: usb: aqc111: Introduce link management Oliver Neukum
2018-10-08 13:22 Igor Russkikh
2018-10-08 12:12 Andrew Lunn
2018-10-08 9:29 Igor Russkikh
2018-10-05 17:46 David Miller
2018-10-05 17:11 Andrew Lunn
2018-10-05 10:24 Igor Russkikh
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=20181006173510.GE6990@lunn.ch \
--to=andrew@lunn.ch \
--cc=Dmitry.Bezrukov@aquantia.com \
--cc=Igor.Russkikh@aquantia.com \
--cc=davem@davemloft.net \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).