netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Michal Kubecek <mkubecek@suse.cz>,
	netdev@vger.kernel.org, Marek Vasut <marex@denx.de>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jean Delvare <jdelvare@suse.com>, Jiri Pirko <jiri@resnulli.us>,
	Jakub Kicinski <kuba@kernel.org>,
	mkl@pengutronix.de, David Miller <davem@davemloft.net>,
	kernel@pengutronix.de,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	David Jander <david@protonic.nl>
Subject: Re: RFC: future of ethtool tunables (Re: [RFC][PATCH 1/2] ethtool: Add BroadRReach Master/Slave PHY tunable)
Date: Thu, 26 Mar 2020 10:05:37 +0100	[thread overview]
Message-ID: <20200326090537.GA23804@pengutronix.de> (raw)
In-Reply-To: <20200325215538.GB27427@lunn.ch>

On Wed, Mar 25, 2020 at 10:55:38PM +0100, Andrew Lunn wrote:
> > What might be useful, on the other hand, would be device specific
> > tunables: an interface allowing device drivers to define a list of
> > tunables and their types for each device. It would be a generalization
> > of private flags. There is, of course, the risk that we could end up
> > with multiple NIC vendors defining the same parameters, each under
> > a different name and with slightly different semantics.
>  
> Hi Michal
> 
> I'm not too happy to let PHY drivers do whatever they want. So far,
> all PHY tunables have been generic. Any T1 PHY can implement control
> of master/slave, and there is no reason for each PHY to do it
> different to any other PHY. Downshift is a generic concept, multiple
> PHYs have implemented it, and they all implement it the same. Only
> Marvell currently supports fast link down, but the API is generic
> enough that other PHYs could implement it, if the hardware supports
> it.
> 
> I don't however mind if it gets a different name, or a different tool,
> etc.
> 
> I will let others comment on NICs. They are a different beast.

IMO, this is not a T1 specific feature. Since T1 lacks the auto
negotiation functionality, we are forced to use Master/Slave
configuration in one or other way. But even (non T1) PHYs with autoneg
available, implement this feature.

We may need to be able to force master or slave mode, at least as
workaround for existing errata. Here is one example:

-------------------------------------------------------------------------------
http://ww1.microchip.com/downloads/en/DeviceDoc/80000692D.pdf
Module 2: Duty cycle variation for optional 125MHz reference output clock

DESCRIPTION

When the device links in the 1000BASE-T slave mode only, the optional
125MHz reference output clock (CLK125_NDO, Pin 41) has wide duty cycle
variation.

END USER IMPLICATIONS

The optional CLK125_NDO clock does not meet the RGMII 45/55 percent
(min/max) duty cycle requirement and there- fore cannot be used directly
by the MAC side for clocking applications that have setup/hold time
requirements on rising and falling clock edges (e.g., to clock out RGMII
transmit data from MAC to PHY (KSZ9031RNX device)).

Work around
[...]
Another solution requires the device to always operate in master mode
(Register 9h, Bits [12:11] = '11') whenever there is 1000BASE-T link-up,
which is workable only in those applications where the link partner is
known and can always be configured to slave mode for 1000BASE-T.
-------------------------------------------------------------------------------

In this example we see, that even on non T1 PHYs we sometimes want to
force Master or Slave mode. At least for testing or workaround.

The BASE-T1 related example is described in 802.3-2018:
-------------------------------------------------------------------------------
45.2.1.185.1 MASTER-SLAVE config value (1.2100.14)

Bit 1.2100.14 is used to select MASTER or SLAVE operation when
Auto-Negotiation enable bit 7.512.12 is set to zero, or if
Auto-Negotiation is not implemented. If bit 1.2100.14 is set to one the
PHY shall operate as MASTER. If bit 1.2100.14 is set to zero the PHY
shall operate as SLAVE.  This bit shall be ignored when the
Auto-Negotiation enable bit 7.512.12 is set to one.
-------------------------------------------------------------------------------

This example shows, that forcing Master or Slave modes is documented
part of 802.3-2018 specification.

IMO, this feature fits to the already existing LINKMODES_SET interface,
as forcing of Master/Slave Mode only makes sense of autoneg is not
implemented or disabled.

LINKMODES_SET/GET:

Request contents:
  ====================================  ======  ==========================
  ``ETHTOOL_A_LINKMODES_HEADER``        nested  request header
  ``ETHTOOL_A_LINKMODES_AUTONEG``       u8      autonegotiation status
  ``ETHTOOL_A_LINKMODES_OURS``          bitset  advertised link modes
  ``ETHTOOL_A_LINKMODES_PEER``          bitset  partner link modes
  ``ETHTOOL_A_LINKMODES_SPEED``         u32     link speed (Mb/s)
  ``ETHTOOL_A_LINKMODES_DUPLEX``        u8      duplex mode
  ====================================  ======  ==========================


Regards,
Oleksij & Marc
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

      parent reply	other threads:[~2020-03-26  9:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 10:17 [RFC][PATCH 1/2] ethtool: Add BroadRReach Master/Slave PHY tunable Marek Vasut
2020-03-25 10:17 ` [RFC][PATCH 2/2] net: phy: tja11xx: Add BroadRReach Master/Slave support into TJA11xx PHY driver Marek Vasut
2020-03-25 13:47   ` Andrew Lunn
2020-03-25 13:43 ` [RFC][PATCH 1/2] ethtool: Add BroadRReach Master/Slave PHY tunable Andrew Lunn
2020-03-25 13:51   ` Marek Vasut
2020-03-25 16:49 ` RFC: future of ethtool tunables (Re: [RFC][PATCH 1/2] ethtool: Add BroadRReach Master/Slave PHY tunable) Michal Kubecek
2020-03-25 21:55   ` Andrew Lunn
2020-03-25 22:04     ` Florian Fainelli
2020-03-25 23:42       ` Michal Kubecek
2020-03-26  9:05     ` Oleksij Rempel [this message]

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=20200326090537.GA23804@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=david@protonic.nl \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=jdelvare@suse.com \
    --cc=jiri@resnulli.us \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@roeck-us.net \
    --cc=marex@denx.de \
    --cc=mkl@pengutronix.de \
    --cc=mkubecek@suse.cz \
    --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).