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

[Grygorii Strashko]

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