linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Michael Walle <michael@walle.cc>
Cc: richardcochran@gmail.com, davem@davemloft.net,
	grygorii.strashko@ti.com, kuba@kernel.org, kurt@linutronix.de,
	linux-kernel@vger.kernel.org, linux@armlinux.org.uk,
	mlichvar@redhat.com, netdev@vger.kernel.org,
	qiangqing.zhang@nxp.com, vladimir.oltean@nxp.com
Subject: Re: [PATCH RFC V1 net-next 3/4] net: Let the active time stamping layer be selectable.
Date: Mon, 4 Apr 2022 17:20:28 +0200	[thread overview]
Message-ID: <YksMvHgXZxA+YZci@lunn.ch> (raw)
In-Reply-To: <20220404150508.3945833-1-michael@walle.cc>

On Mon, Apr 04, 2022 at 05:05:08PM +0200, Michael Walle wrote:
> Sorry for digging out this older thread, but it seems to be discussed
> in [1].
> 
> > IMO, the default should be PHY because up until now the PHY layer was
> > prefered.
> > 
> > Or would you say the MAC layer should take default priority?
> > 
> > (that may well break some existing systems)
> 
> Correct me if I'm wrong, but for systems with multiple interfaces,
> in particular switches, you'd need external circuits to synchronize
> the PHCs within in the PHYs.

If the PHYs are external. There are switches with internal PHYs, so
they might already have the needed synchronisation.

> (And if you use a time aware scheduler
> you'd need to synchronize the MAC, too). Whereas for switches there
> is usually just one PHC in the MAC which just works.

And there could be switches with the MACs being totally
independent. In theory.

> On these systems, pushing the timestamping to the PHY would mean
> that this external circuitry must exist and have to be in use/
> supported. MAC timestamping will work in all cases without any
> external dependencies.

And if the MAC are independent, you need the external dependency.

> I'm working on a board with the LAN9668 switch which has one LAN8814
> PHY and two GPY215 PHYs and two internal PHYs. The LAN9668 driver
> will forward all timestamping ioctls to the PHY if it supports
> timestamping (unconditionally). As soon as the patches to add ptp
> support to the LAN8814 will be accepted, I guess it will break the
> PTP/TAS support because there is no synchronization between all the
> PHCs on that board. Thus, IMHO MAC timestamping should be the default.

There are arguments for MAC being the defaults. But we must have the
option to do different, see above. But the real problem here is
history. It is very hard to change a default without breaking systems
which depend on that default. I believe Russell has a system which
will break if the default is changed.

So i suspect the default cannot be changed, but maybe we need a
mechanism where an interface or a board can express a preference it
would prefer be used when there are multiple choices, in addition to
the user space API to make the selection.

   Andrew

  reply	other threads:[~2022-04-04 15:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-03 23:25 [PATCH RFC V1 net-next 3/4] net: Let the active time stamping layer be selectable Richard Cochran
2022-01-03 23:53 ` Russell King (Oracle)
2022-01-04  1:42   ` Richard Cochran
2022-04-04 15:05     ` Michael Walle
2022-04-04 15:20       ` Andrew Lunn [this message]
2022-04-04 17:12         ` Michael Walle
2022-04-05  5:59           ` Richard Cochran
2022-04-05  8:48             ` Michael Walle
2022-04-05 15:46               ` Richard Cochran
2022-04-05  9:01           ` Kurt Kanzenbach
2022-04-05  9:19             ` Michael Walle
2022-04-05 11:19               ` Kurt Kanzenbach
2022-04-05 13:15                 ` Grygorii Strashko
2022-04-05 13:29                   ` Andrew Lunn
2022-04-05 15:48                     ` Richard Cochran
2022-04-06 11:18                       ` Grygorii Strashko
2022-01-20 16:48 ` Vladimir Oltean
2022-01-21  3:38   ` Andrew Lunn
2022-01-21  4:05     ` Richard Cochran
2022-01-21 14:50       ` Vladimir Oltean
2022-01-21 15:28         ` Richard Cochran
2022-01-21 16:23           ` Vladimir Oltean
2022-01-22  2:08             ` Richard Cochran
2022-01-24  9:28           ` Miroslav Lichvar
2022-01-24 15:37             ` Richard Cochran
2022-01-25 15:37               ` Vladimir Oltean
2022-01-21 11:05   ` Kurt Kanzenbach
2022-01-21 15:31     ` Richard Cochran

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=YksMvHgXZxA+YZci@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=grygorii.strashko@ti.com \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=michael@walle.cc \
    --cc=mlichvar@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=qiangqing.zhang@nxp.com \
    --cc=richardcochran@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    /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).