From: Andrew Lunn <andrew@lunn.ch>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
David Miller <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] net: phy: improve link partner capability detection
Date: Fri, 5 Apr 2019 21:48:21 +0200 [thread overview]
Message-ID: <20190405194821.GI23536@lunn.ch> (raw)
In-Reply-To: <ba751e0e-7fa1-d687-24ac-303c5f54c08f@gmail.com>
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
next prev parent reply other threads:[~2019-04-05 19:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-05 19:23 [PATCH net-next] net: phy: improve link partner capability detection Heiner Kallweit
2019-04-05 19:48 ` Andrew Lunn [this message]
2019-04-05 20:04 ` Heiner Kallweit
2019-04-05 20:27 ` Andrew Lunn
2019-04-05 20:32 ` Heiner Kallweit
2019-04-05 20:43 ` Andrew Lunn
2019-04-05 20:51 ` Heiner Kallweit
2019-04-05 21:11 ` Florian Fainelli
2019-04-05 21:16 ` Heiner Kallweit
2019-04-05 21:20 ` Heiner Kallweit
2019-04-05 21:28 ` Florian Fainelli
2019-04-05 21:27 ` Andrew Lunn
2019-04-05 21:38 ` Heiner Kallweit
2019-04-05 21:52 ` Heiner Kallweit
2019-04-05 21:54 ` Florian Fainelli
2019-04-06 16:25 ` Heiner Kallweit
2019-04-06 20:21 ` Florian Fainelli
2019-04-06 20:21 ` Florian Fainelli
2019-04-08 22:18 ` David Miller
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=20190405194821.GI23536@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--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 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.