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

[Michael Walle]

Am 2022-04-04 17:20, schrieb Andrew Lunn:
> 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.

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.

-michael