LKML Archive on
help / color / mirror / Atom feed
From: Esben Haabendal <>
To: Florian Fainelli <>
Cc: Richard Cochran <>,
	Andrew Lunn <>,
	open list <>,
	Rasmus Villemoes <>
Subject: Re: [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings
Date: Thu, 05 Apr 2018 22:34:35 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Florian Fainelli's message of "Thu, 5 Apr 2018 09:02:38 -0700")

Florian Fainelli <> writes:

> On 04/05/2018 04:44 AM, wrote:
>> From: Esben Haabendal <>
>> Read configration settings, to allow automatic forced speed/duplex setup
>> by hardware strapping.
> OK but why? What problem is this solving for you?

It is ensuring that the PHY is configured according to the HW design.
If the HW design has set the strap configuration to fx. fixed 100 Mbit
full-duplex, this avoids Linux configuring it for auto-negotiation.

> In general, we do not really want to preserve too much of what the PHY
> has been previously configured with,

Even when this "previous" configuration is the configuration selected by
the board configuration?

> provided that the PHY driver can re-instate these configuration
> values.

This is sort of what I try to do here.  The PHY driver needs to check
the BMCR register to figure out what the strapped configuration was.
Without that, it is necessary for software configuration to duplicate
the exact same configuration as is encoded in the strap configuration in
order for the PHY to be configured as it is supposed to.

> I just wonder how this can be robust when you connect this PHY with
> auto-negotiation disabled to a peer that expects a set of link
> parameters not covered by the default advertisement values?

I assume it will fail just as it will if you use ethtool to configure
the PHY wrongly.

> This really looks like a recipe for disaster when you could just
> disable auto-negotiation with ethtool.

The current PHY driver approach to always default to enable
auto-negotation, and then allow user-space to configure it differently
with ethtool.

With this patch, the default configuration is chosen based on the strap
configuration, but user-space can still change the configuration with
ethtool if needed / desired.

I don't think it is such a big change.

Bringing up the PHY with a default configuration according to HW
strapping instead of an in-kernel SW hard-coded value sounds like a good
idea to me.


  parent reply	other threads:[~2018-04-05 20:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 11:44 [PATCH 1/2] net: phy: Helper function for reading strapped configuration values esben.haabendal
2018-04-05 11:44 ` [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings esben.haabendal
2018-04-05 16:02   ` Florian Fainelli
2018-04-05 20:30     ` Esben Haabendal
2018-04-05 20:40       ` Andrew Lunn
2018-04-06  2:24         ` David Miller
2018-04-06 11:05           ` Esben Haabendal
2018-04-05 20:34     ` Esben Haabendal [this message]
2018-04-05 16:00 ` [PATCH 1/2] net: phy: Helper function for reading strapped configuration values Florian Fainelli
2018-04-05 20:18   ` Esben Haabendal
2018-04-05 20:34   ` Esben Haabendal

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:

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

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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