Re: [PATCH RFC V1 net-next 3/4] net: Let the active time stamping layer be selectable.

From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Kurt Kanzenbach <kurt@linutronix.de>, Michael Walle <michael@walle.cc>
Cc: Andrew Lunn <andrew@lunn.ch>, <richardcochran@gmail.com>,
	<davem@davemloft.net>, <kuba@kernel.org>,
	<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: Tue, 5 Apr 2022 16:15:05 +0300	[thread overview]
Message-ID: <defe77d9-1a41-7112-0ef6-a12aa2b725ab@ti.com> (raw)
In-Reply-To: <87wng3pyjl.fsf@kurt>

On 05/04/2022 14:19, Kurt Kanzenbach wrote:
> On Tue Apr 05 2022, Michael Walle wrote:
>> Am 2022-04-05 11:01, schrieb Kurt Kanzenbach:
>>> On Mon Apr 04 2022, Michael Walle wrote:
>>>> That would make sense. I guess what bothers me with the current
>>>> mechanism is that a feature addition to the PHY in the *future* (the
>>>> timestamping support) might break a board - or at least changes the
>>>> behavior by suddenly using PHY timestamping.
>>>
>>> Currently PHY timestamping is hidden behind a configuration option
>>> (NETWORK_PHY_TIMESTAMPING). By disabling this option the default
>>> behavior should stay at MAC timestamping even if additional features
>>> are added on top of the PHY drivers at later stages. Or not?
>>
>> That is correct. But a Kconfig option has several drawbacks:
>> (1) Doesn't work with boards where I might want PHY timestamping
>>       on *some* ports, thus I need to enable it and then stumple
>>       across the same problem.
>> (2) Doesn't work with generic distro support, which is what is
>>       ARM pushing right now with their SystemReady stuff (among other
>>       things also for embeddem system). Despite that, I have two boards
>>       which are already ready for booting debian out of the box for
>>       example. While I might convince Debian to enable that option
>>       (as I see it, that option is there to disable the additional
>>       overhead) it certainly won't be on a per board basis.
>>       Actually for keeping the MAC timestamping as is, you'd need to
>>       convince a distribution to never enable the PHY timestamping
>>       kconfig option.
>>
>> So yes, I agree it will work when you have control over your
>> kconfig options, after all (1) might be more academic. But I'm
>> really concerned about (2).
> 
> Yes, the limitations described above are exactly one of the reasons to
> make the timestamping layer configurable at run time as done by these
> patches.

Seems like PHY TS support belongs to HW description category, so could it be device tree material,
like generic property defining which layer should do timestamping?

-- 
Best regards,
Grygorii, Ukraine