Re: [RFC PATCH net-next 0/6] ptp: Support hardware clocks with additional free running time

From: Miroslav Lichvar <mlichvar@redhat.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: Michael Walle <michael@walle.cc>,
	gerhard@engleder-embedded.com, davem@davemloft.net,
	kuba@kernel.org, netdev@vger.kernel.org,
	vinicius.gomes@intel.com, yangbo.lu@nxp.com
Subject: Re: [RFC PATCH net-next 0/6] ptp: Support hardware clocks with additional free running time
Date: Mon, 7 Mar 2022 15:23:58 +0100	[thread overview]
Message-ID: <YiYVfrulOJ5RtWOy@localhost> (raw)
In-Reply-To: <20220307140531.GA29247@hoboy.vegasvil.org>

On Mon, Mar 07, 2022 at 06:05:31AM -0800, Richard Cochran wrote:
> On Mon, Mar 07, 2022 at 01:07:51PM +0100, Michael Walle wrote:
> > Richard Cochran wrote:
> > > You are adding eight bytes per frame for what is arguably an extreme
> > > niche case.
> > 
> > I don't think it is a niche case, btw. I was always wondering why
> > NXP introduced the vclock thingy. And apparently it is for
...
> 
> Niche is relative.
> 
> Believe it or not, the overwhelmingly great majority of people using
> Linux have no interest in TSN.

Is this not the same issue as what was recently discussed about some
devices being able to provide two (e.g. PHY+MAC) or even more
timestamps at the same time?

There is a need to have multiple PHCs per device and for that to work
the drivers need to be able to save multiple timestamps per packet.

In this series it is an additional freerunning clock. That seems too
specific. I think we need a more general approach that will support
two and more physical PHCs per device. Virtual clocks are not involved
here.

-- 
Miroslav Lichvar