All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
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 22:51:44 +0200	[thread overview]
Message-ID: <7e6fc94d-5da9-b87d-a0d3-3e2ee5ff5961@gmail.com> (raw)
In-Reply-To: <20190405204319.GM23536@lunn.ch>

On 05.04.2019 22:43, Andrew Lunn wrote:
>> Right. BMSR_ESTATEN should not be set on a Fast PHY. Handling of this
>> case didn't change.
>>
>>> A Fast MAC connected to a Giga PHY. The MAC driver will of used
>>> phy_set_max_speed() to indicate its limits. In that case, MII_STAT1000
>>> does exist and we should report what the peer is advertising.
>>>
>> That's what we're doing now with this patch.
> 
> Hi Heiner
> 
> What i don't get is why we need to do anything based on the MAC. All
> we need to do is look at BMSR_ESTATEN, and from that decided if we
> should look at MII_STAT1000 or not. When reporting what the peer can
> do, we should not care what the local MAC can do.
> 
Do we have a misunderstanding? What you describe is exactly what we're
doing now. BMSR_ESTATEN is read by genphy_read_abilities().
I just don't want to read BMSR whenever genphy_read_status() is called.

>     Andrew
> 
Heiner

  reply	other threads:[~2019-04-05 20:51 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
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 [this message]
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=7e6fc94d-5da9-b87d-a0d3-3e2ee5ff5961@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@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.