All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net: ethtool: allow MAC drivers to override ethtool get_ts_info
Date: Wed, 20 Jan 2021 20:04:51 -0800	[thread overview]
Message-ID: <20210121040451.GB14465@hoboy.vegasvil.org> (raw)
In-Reply-To: <20210114223800.GR1605@shell.armlinux.org.uk>

On Thu, Jan 14, 2021 at 10:38:00PM +0000, Russell King - ARM Linux admin wrote:

> So, I think the only way to prevent a regression with the code as
> it is today is that we _never_ support PTP on Marvell PHYs - because
> doing so _will_ break the existing MVPP2 driver's implementation and
> cause a regression.

The situation isn't as bad as it seems.

For one thing, mvpp2 incorrectly selects NETWORK_PHY_TIMESTAMPING.
It really shouldn't.  I'm submitting a fix soon.

As long as the new PHY driver (or at least the PTP bit) depends on
NETWORK_PHY_TIMESTAMPING, then that allows users who _really_ want
that to enable the option at compile time.  This option adds extra
checks into the networking hot path, and almost everyone should avoid
enabling it.

> Right now, there is no option: if a PHY supports PTP, then the only
> option is to use the PHYs PTP. Which is utterly rediculous.
> 
> Unless you can see a way around it. Because I can't.

I still think the original and best method is to hide the two (and
with your new driver, three) esoteric PHY time stamping drivers behind
a Kconfig option, and structure the code to favor PHY devices.

The idea to favor the MACs, from back in July, doesn't really change
the fundamental limitations that

- MAC and PHY time stamping cannot work simultaneously, and

- Users of PHY devices (representing a tiny minority) must enable the
  otherwise uninteresting NETWORK_PHY_TIMESTAMPING option at compile
  time.

Thanks,
Richard

  reply	other threads:[~2021-01-21  4:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-10 11:13 [PATCH net-next] net: ethtool: allow MAC drivers to override ethtool get_ts_info Russell King
2021-01-10 16:35 ` Andrew Lunn
2021-01-14  3:05   ` Jakub Kicinski
2021-01-14 17:09   ` Russell King - ARM Linux admin
2021-01-14 17:27     ` Russell King - ARM Linux admin
2021-01-14 12:55 ` Richard Cochran
2021-01-14 13:22   ` Russell King - ARM Linux admin
2021-01-14 13:32     ` Russell King - ARM Linux admin
2021-01-14 17:27       ` Richard Cochran
2021-01-14 17:31         ` Russell King - ARM Linux admin
2021-01-14 22:38           ` Russell King - ARM Linux admin
2021-01-21  4:04             ` Richard Cochran [this message]
2021-01-21 10:27               ` Russell King - ARM Linux admin
2021-01-21 15:06                 ` Richard Cochran
2021-01-21 16:22                   ` Andrew Lunn
2021-01-21 17:03                     ` Richard Cochran
2021-01-21 18:55                       ` Andrew Lunn
2021-01-21 22:59                         ` Russell King - ARM Linux admin
2021-01-21 18:18                   ` Russell King - ARM Linux admin

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=20210121040451.GB14465@hoboy.vegasvil.org \
    --to=richardcochran@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --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.