Messages in this thread | | | Date | Mon, 04 Apr 2022 19:12:11 +0200 | From | Michael Walle <> | Subject | Re: [PATCH RFC V1 net-next 3/4] net: Let the active time stamping layer be selectable. |
| |
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
| |