On Thursday, 22 October 2020, 09:30:57 CEST, Christian Eggers wrote: > On Thursday, 22 October 2020, 04:42:01 CEST, Richard Cochran wrote: > > On Thu, Oct 22, 2020 at 02:39:35AM +0300, Vladimir Oltean wrote: > > > On Mon, Oct 19, 2020 at 07:24:33PM +0200, Christian Eggers wrote: > > > > The PTP hardware performs internal detection of PTP frames (likely > > > > similar as ptp_classify_raw() and ptp_parse_header()). As these > > > > filters > > > > cannot be disabled, the current delay mode (E2E/P2P) and the clock > > > > mode > > > > (master/slave) must be configured via sysfs attributes. > > > > This is a complete no-go. NAK. > > I didn't design the hardware nor do I have access to adequate documentation. > I will try to figure out what functionality is concretely affected by these > two settings. I tried to study the effect of setting the ocmode bit on the KSZ either to master or to slave. The main visible change is, that some PTP message types are be filtered out on RX: - in "master" mode, "Sync" messages from other nodes will not be received (but everything else like "Announce" seem to work) - in "slave" mode, "Delay_Req" messages from other nodes will not be received I am not an expert for PTP, so the following is only the idea of a beginner how this could probably be handled: As PTP announce messages are received all the time, the BMCA should always be able to work. The KSZ hardware needs to be set to "master" when a node is becoming master (in order to be able to receive (and answer) Delay_Req messages). The setting "slave" is equired when the BCMA decides not being master anymore (in order to receive Sync messages). Handling the transition to "master" mode could probably be done easily in the driver (when a Sync message is seen in TX direction by the time stamping code). But transition to slave seems to be difficult, because the tagging driver cannot see when the node stops being master. For user space (ptp4l), the decision for master/slave mode could probably be done easier. If Richard (or somebody else) decides that "mode switching" of the KSZ device would not be appropriate, I suspect the functionality of the KSZ has to be limited to "Slave Only Clock". regards Christian
