Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet
ain, it does not suggest using the ITU-T concept of SyncE (in fact, HA Profile recommends using a coherent, congruent physical layer clock managed by PTP itself - referenced as L1Sync). **GA. You are correct the ITU-T G.8275.1 Profile recommends the use of physical layer "assistance" (and G.8275.2, as optional) - but to be clear, it's assisting the local PTP clock, it is not managing the PTP clock nor does the PTP protocol have any influence on the ESMC protocol/SyncE clock. Thus, Annex L in 1588 is not applicable for the ITU-T Profiles (nor is it referenced by either profile) - as ITU-T assumes the physical layer clock is managed by the ESMC protocol (not PTP, so does not use L1Sync). **GA. Again, my push back is that any implementation of the ESMC protocol does not belong in the linuxptp project. Instead, the community should focus on how to interface to the ESMC to meet the recommendations of the applicable 1588 Profiles (i.e. ITU-T). And for those profiles that use L1Sync (i.e. HA Profile), by all means, this belongs in linuxptp project as it's part of PTP (and in this case, the L1Sync interface is likely going through PHC) - but please don't confuse this with ITU-T's SyncE as they are not related. Regards, Greg Greg Armstrong Principal System Architect, Timing Products Division Renesas Electronics Canada Limited Mobile: 1-613-218-9373 -Original Message- From: Kubalewski, Arkadiusz Sent: Wednesday, August 31, 2022 5:23 PM To: Miroslav Lichvar ; Greg Armstrong ; Richard Cochran ; Michalik, Michal Cc: Kwapulinski, Piotr ; Sawula, Andrzej ; linuxptp-devel@lists.sourceforge.net; Gerasymenko, Anatolii Subject: RE: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet >-Original Message- >From: Miroslav Lichvar mlich...@redhat.com >Sent: Thursday, August 4, 2022 11:08 AM > >On Wed, Jul 20, 2022 at 03:50:04AM +, Greg Armstrong wrote: >> To address this concern, Renesas has submitted our open implementation of >> the ESMC protocol to github, also under the same name: >> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenesas%2Fsynce4ldata=05%7C01%7Cgreg.armstrong.uw%40renesas.com%7C225abee1857f447103e708da8b970d52%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637975778118848397%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=y90x7DrMn4mLlZGxMCE4ja4oT3OCudPWhVozrAO9zuw%3Dreserved=0. >> This is an open project under GPLv2, and we welcome contributions to it. > >I looked at the project to better understand the differences between >this and the Intel implementation. Here are my observations. > >The code doesn't build on its own. It requires "clockmatrix api", which >doesn't seem to be available without registration. > >There are some HW-specific ioctls. > >I don't see an abstraction which would allow one binary to support >different types of hardware. > >About 20% of the code comes from linuxptp (per copyright). > >-- >Miroslav Lichvar > Thanks Miroslav! I assume that silence on this thread (from the rest of the members), same as silence on any other community mailing list thread, is actually a quiet approval (or at least no one has any objections). Greg, You are saying that your project is open source, and you would welcome contribution to it, but at the same time seems that your code: - requires third party proprietary module for compilation, - uses HW specific i2c to configure your NIC/timecard. Is that true? If so, do you think that it is proper way to cooperate with an open source community? Excuses me but I hardly understand what you would like to achieve except blocking delivery of this solution. As I see it, your only argument is that SyncE is not a part of 1588. Well sure, SyncE is only mentioned in appendices, but you know, Telecom Profiles are not part of 1588, they are only mentioned in appendices. Should support for them be removed from linuxptp? In my humble opinion, it wouldn't make any sense. Maybe SyncE without PTP does make some sense, but for telecoms it makes most sense to use them both (if hardware supports it). Following this idea, it makes most sense to have both in the same package, as for full support of "Annex L" (1588), the SyncE daemon shall provide data to the PTP daemon. It is easiest to maintain both applications in one repository, this prevents any incompatibility issues between shared interfaces. Richard, I know our solution in its current state is far from being perfect. It communicates with EEC by shell commands specified by the user, but at least it is not specific for any particular hardware. Although it doesn't configure EEC, as it shall be preconfigured before using our solution. Our next steps would be: - introduce in-kernel interface which allows control of EEC, - implement a
Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet
Hi Michał, Please see my responses inline. Regards, Greg -Original Message- From: Michalik, Michal Sent: Friday, July 29, 2022 12:25 PM To: Greg Armstrong ; richardcoch...@gmail.com Cc: linuxptp-devel@lists.sourceforge.net; Kubalewski, Arkadiusz ; Miroslav Lichvar ; Erez Subject: RE: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet Hello Greg, Much thanks for your valuable input - we appreciate it a lot. Please see my answers inline. Have a great day, Michał Michalik > As I highlighted earlier, I, along with other users of ptp4l, don't feel the > linuxptp project is the right place for the submission of the ITU-T ESMC > Protocol (which is based on recommendations G.8274 & G.781). There are no > dependencies on ESMC with the 1588 protocol or the Linux PHC, nor is the > linuxptp maintainer wanting to be a bottleneck for contributions to the ESMC > protocol (as highlighted below from Richard). If you don't mind, please let me ask you a question - I am definitely missing something. Whom are you talking about while using expression "along with other users of ptp4l"? **GA. We have been working with a number of PHY/SoC partners and have received the feedback once they saw the submission to linuxptp (as they were confused). They felt this looked like an "Intel-implementation" and should not be called synce4l. They feel an implementation of synce4l should use a defined standard interface pushed into the Linux kernel and not specific ones within the scope of ptp4l. This has been the direction Renesas has been taking with our synce4l implementation. To my best understanding right now we have a situation, where: - you are against including it into linuxptp, - Miroslav Lichvar is for including it, - Erez is for including it, - if I understand Richard communicate well, he did not say firm "no" - just raised some concerns about his bandwidth, - we (as Intel) are good with both ways - we just need to know. In which point my understanding is faulty? **GA. I don't think there is any fault. My concern is that an implementation submitted to the linuxptp project may mistakenly use interfaces with the scope of ptp4l, not allowing it to be a stand-alone protocol (which it is, as this is an ITU-T defined protocol with no dependencies on PTP). We have several customers who only need the ESMC protocol for their equipment. Richard - since you obviously have the last word, would you mind to state your final decision clearly to avoid any further interpretations of your answer? > > >My main concern is the fact that my time is limited to work on >linuxptp, > >and I already have a back log of patches. If synce will have >rapid > >development, new features, etc, then I don't want to be the >bottleneck. > > To address this concern, Renesas has submitted our open implementation of the > ESMC protocol to github, also under the same name: > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frenesas%2Fsynce4ldata=05%7C01%7Cgreg.armstrong.uw%40renesas.com%7C0c14b6faa12f4fd3f67b08da717ee2ec%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637947087036059280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=jHoJi7jEC4ZxQ5fUbqVe15UPwpkmFjud2%2B%2F29RYglVQ%3Dreserved=0. > This is an open project under GPLv2, and we welcome contributions to it. The > implementation not only addresses the ESMC protocol per G.8264, but also > includes some additional features from G.781. We realize there will be a need > to provide QL and other information from synce4l to ptp4l, per applicable > ITU-T 1588 Profiles, and look forward to collaborating with the linuxptp > community to produce these interfaces. Since working in community should be based on honesty, let me be honest here. I feel we have a little awkward situation we need to solve somehow together. Some facts about the issue I'm thinking about: We have pushed first patches of synce4l to linuxptp newsletter on 26th May. Then we see that Renesas have pushed one initial commit with only empty README mentioning the synce4l name (8th Jul) and second commit with full code implementation (15th Jul) - both commits were uploaded few weeks after our initial submission using synce4l name. I am perfectly aware that neither of us has any trademark rights to the name, so technically Renesas did nothing wrong. Still, we feel a little bad about the situation where we wanted to be fair and waited for final linuxptp community decision before pushing the synce4l somewhere else and in the meantime see other project started with the same exact name. Let me be perfectly clear here **GA. Again, an implementation of "synce4l" should not concern the linuxptp community. However, yes, we've been working on our im
Re: [Linuxptp-devel] [PATCH] Inclusion of a virtual PTP port on a PTP clock
Hi Richard, Virtual PTP Port is defined in Annex B of G.8275. It was moved to recommendation G.8275 since it can be used in both G.8275.1 and G.8275.2 Profiles. It was defined before 1588-2019 Special Port. There are similarities, but not the same. APTS stands for Assisted Partial Time Support and is an option of the G.8275.2 Profile. IWF stands for Inter-Working Function and is defined in Appendix III of G.8275. It describes how to connect synchronization network segments that are running different PTP profiles. Greg -Original Message- From: Richard Cochran Sent: Sunday, July 24, 2022 7:19 PM To: SyncMonk Technologies Cc: Leon Goldin ; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Inclusion of a virtual PTP port on a PTP clock On Fri, Jun 17, 2022 at 02:55:02PM +0530, SyncMonk Technologies wrote: > As per G.8275 (Annex-B) including virtual PTP ports on a PTP clock. > This virtual port will be used to support APTS, IWF between different > clock_domains. What the heck is a "virtual PTP port"? Is that anything like a Special Port from 1588? My copy of 8275.2 (ITU-T G.8275.2/Y.1369.2 (03/2020)) has this in Annex-B: Annex B Options to establish the PTP topology with the Alternate BMCA No mention of virtual. Also, I have no idea what APTS or IWF is. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cgreg.armstrong.uw%40renesas.com%7Ce071f1ae6584404b2ae608da6dcb3c0a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637943016900753631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=CfdSe4EIVccp1QD%2BxysxCw5HPhO9PmFCwh4gQuLCsnI%3Dreserved=0 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet
As I highlighted earlier, I, along with other users of ptp4l, don't feel the linuxptp project is the right place for the submission of the ITU-T ESMC Protocol (which is based on recommendations G.8274 & G.781). There are no dependencies on ESMC with the 1588 protocol or the Linux PHC, nor is the linuxptp maintainer wanting to be a bottleneck for contributions to the ESMC protocol (as highlighted below from Richard). >My main concern is the fact that my time is limited to work on >linuxptp, and >I already have a back log of patches. If synce will have >rapid development, >new features, etc, then I don't want to be the >bottleneck. To address this concern, Renesas has submitted our open implementation of the ESMC protocol to github, also under the same name: https://github.com/renesas/synce4l. This is an open project under GPLv2, and we welcome contributions to it. The implementation not only addresses the ESMC protocol per G.8264, but also includes some additional features from G.781. We realize there will be a need to provide QL and other information from synce4l to ptp4l, per applicable ITU-T 1588 Profiles, and look forward to collaborating with the linuxptp community to produce these interfaces. We will also be working with the Network Time Foundation to see if they would be willing to oversee synce4l project like the other Linux projects they already manage, including linuxptp. We have also already shared synce4l project with other MAC/PHY/SoC vendors looking for an ESMC protocol solution. Regards, Greg Greg Armstrong Principal System Architect, Timing Products Division Renesas Electronics Canada Limited Mobile: 1-613-218-9373 -Original Message- From: Miroslav Lichvar Sent: Thursday, June 2, 2022 6:23 AM To: Erez Cc: Greg Armstrong ; piotr.kwapulin...@intel.com; andrzej.saw...@intel.com; linuxptp-devel@lists.sourceforge.net; anatolii.gerasyme...@intel.com Subject: Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet On Wed, Jun 01, 2022 at 05:37:10PM +0200, Erez wrote: > I do hope my project > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsf.net%2Fp%2Flibptpmgmt%2Fdata=05%7C01%7Cgreg.armstrong.uw%40renesas.com%7C08ec39f69e6347d0a63d08da4481ecaa%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637897622057580969%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Ud1Te2%2BA87xSSj9z1qkhgPyQ4MoLr5tHmUvB58XygW0%3Dreserved=0, > does help to fill this gap and helps with reducing the overhead from this > project. > phc2sys can be implemented with libptpmgmt. > I already cloned pmc with libptpmgmt. > > Maybe it is time that this project focuses on ptp4l and let other > applications have their own projects. phc2sys shares quite a lot of code with ptp4l, it's not just the PTP management support. It it was a separate project, it would need to duplicate the code, or linuxptp would need to provide and maintain a library. If some components had a different maintainer, it doesn't mean it has to be a separate project or repository. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet
I see synce4l as an implementation of the ESMC protocol, thus, the name fits. As you highlighted, there will be challenges for synce4l to configure and monitor the L1 properties of the hardware, and also interface the EEC hardware. If this wasn't the intent of synce4l, then I agree, the name needs to change to remove "synce", which is an ITU-T term. For the implementation of L1_SYNC, it may or may not have the same interfaces to hardware - especially when looking at how HA profile uses it. Also, the ITU-T 1588 profiles do not use L1_SYNC to manage the physical layer - I'm only aware of the HA profile using it right now. Greg -Original Message- From: Miroslav Lichvar Sent: June 1, 2022 11:19 AM To: Greg Armstrong Cc: Richard Cochran ; piotr.kwapulin...@intel.com; anatolii.gerasyme...@intel.com; andrzej.saw...@intel.com; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet On Wed, Jun 01, 2022 at 01:18:09PM +0000, Greg Armstrong wrote: > > The difference in the protocol (L1_SYNC TLV vs SSM) seems to me quite small > > when compared to the rest. > > This is my concern, as this statement is false. SyncE describes an ITU-T > network synchronization method for the distribution of frequency over a > transport network, using the L1 physical layer clock (Ethernet or OTN). > Details of the network limits, equipment clock requirements, protocol and > architecture are contained in numerous ITU-T recommendations (G.826x). The > use of the SyncE clock to assist PTP is described in G.8273.2 for T-BC/T-TSC > (and also in G.8273.4 as a option for T-BC-P/T-TSC-P). In this case, the > SyncE clock does not need to be coherent or congruent with the PTP clock. > > The L1_SYNC TLV is a Layer-1 based synchronization performance enhancement > for PTP (described in Annex L of IEEE 1588-2019). The key aspect of the > scheme illustrated by the high accuracy model is that the physical clock > signal and the time of the PTP Instance are coherent. The HA profile (corresponding to White Rabbit) requires that, but not the L1 support in PTP in general. That's the point of the L1_SYNC TLV to communicate the requirements for coherency and congruency between the peers. > Yes, both methods can be used to syntonize the Timestamping Clocks in all PTP > Instances to within the required tolerance with respect to the Grandmaster > Clock, but how to use SyncE vs L1_SYNC in the protocol (ptp4l) is different - > one is managed with the protocol (L1_SYNC) the other by it's own protocol > (synce4l). Right. But consider what the L1 support is in essence. The main point is to configure and monitor the L1 properties of the hardware. A proper kernel interface doesn't exist yet. It might be ethtool netlink, which is not very easy to use (at least for me). > I'm not arguing there could not be shared support code, but to the uninformed > developer, synce4l could be mistaken for L1_SYNC (i.e. mistakenly use the PHC > for "SyncE" clock management). Also, as Richard highlighted, the development > of synce4l and ptp4l are mutual exclusive, so it does not make sense for the > synce4l code submissions to be reviewed by the linuxptp development > community, as they are not the right audience (as unlikely familiar with the > ITU-T recommendations that synce4l must follow). As I said, the confusion could be avoided by different naming if necessary. To me that doesn't look like a big concern. linuxptp includes utilities like phc2sys and phc_ctl that don't have much to do with the PTP protocol, but they are useful when PTP is used for synchronization. Same applies to synce4l. There already is support for some telco profiles, so I'd say it's a very good fit for the project. Whether Richard has or doesn't have time to review/maintain the code, I think that is a different matter. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet
Again, I'm not arguing there is no interface between synce4l and ptp4l; but the development of synce4l, which is a implementation of the ITU-T G.8264 ESMC protocol and interfaces the synchronous Ethernet Equipment Clock (EEC), should not be under the linuxptp project, which is an implementation of the IEEE 1588 protocol which interfaces the Local PTP Clock (via the Linux PHC). Below is a snip from the Network Time Foundation: The Linux PTP Project is a Linux-focused software implementation of the Precision Time Protocol (PTP) specification that meets or exceeds the IEEE 1588 Standard. Its dual design goals are to provide the highest possible performance levels and be a thoroughly robust implementation of the PTP Standard. Thus, I would be more supportive of get NTF to start a Linux ESMC Project (synce4l) and allow your submission to be there. This will also make sure one does not "break" either protocol to support L1 syntonization in PTP (i.e. make sure the interfaces are vetted properly, and that there is no undesired influences on either clock by the other protocol). Greg -Original Message- From: Kubalewski, Arkadiusz Sent: June 1, 2022 10:44 AM To: Greg Armstrong ; Miroslav Lichvar Cc: Kwapulinski, Piotr ; Sawula, Andrzej ; linuxptp-devel@lists.sourceforge.net; Gerasymenko, Anatolii Subject: RE: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet -Original Message----- From: Greg Armstrong Sent: Wednesday, June 1, 2022 3:18 PM > > The difference in the protocol (L1_SYNC TLV vs SSM) seems to me quite small > > when compared to the rest. > > This is my concern, as this statement is false. SyncE describes an ITU-T > network synchronization method for the distribution of frequency over a > transport network, using the L1 physical layer clock (Ethernet or OTN). > Details of the network limits, equipment clock requirements, protocol and > architecture are contained in numerous ITU-T recommendations (G.826x). The > use of the SyncE clock to assist PTP is described in G.8273.2 for T-BC/T-TSC > (and also in G.8273.4 as a option for T-BC-P/T-TSC-P). In this case, the > SyncE clock does not need to be coherent or congruent with the PTP clock. > > The L1_SYNC TLV is a Layer-1 based synchronization performance enhancement > for PTP (described in Annex L of IEEE 1588-2019). The key aspect of the > scheme illustrated by the high accuracy model is that the physical clock > signal and the time of the PTP Instance are coherent. > > Yes, both methods can be used to syntonize the Timestamping Clocks in all PTP > Instances to within the required tolerance with respect to the Grandmaster > Clock, but how to use SyncE vs L1_SYNC in the protocol (ptp4l) is different - > one is managed with the protocol (L1_SYNC) the other by it's own protocol > (synce4l). According to the Annex L, L.1 General, L1Sync is optional feature that can be used to support cooperation between PTP and physical layer (L1) based syntonization, also example of Synchronous Ethernet is given. My understanding: First there must be physical layer (L1) based synchronization, then PTP protocol can support L1Sync. Or in other words, the one will not be able to support optional PTP L1Sync, without physical layer (L1) based syntonization (e.g. SyncE) Am I wrong somewhere? Thanks, Arkadiusz > > I'm not arguing there could not be shared support code, but to the uninformed > developer, synce4l could be mistaken for L1_SYNC (i.e. mistakenly use the PHC > for "SyncE" clock management). Also, as Richard highlighted, the development > of synce4l and ptp4l are mutual exclusive, so it does not make sense for the > synce4l code submissions to be reviewed by the linuxptp development > community, as they are not the right audience (as unlikely familiar with the > ITU-T recommendations that synce4l must follow). > > Greg > > Greg Armstrong > Principal System Architect, Timing Products Division Renesas > Electronics Canada Limited > Mobile: 1-613-218-9373 > > -Original Message- > From: Miroslav Lichvar > Sent: June 1, 2022 3:33 AM > To: Greg Armstrong > Cc: Richard Cochran ; > piotr.kwapulin...@intel.com; anatolii.gerasyme...@intel.com; > andrzej.saw...@intel.com; linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for > Synchronous Ethernet > > On Tue, May 31, 2022 at 02:42:00PM +, Greg Armstrong wrote: > > This is the reason synce4l (based on an ITU-T physical layer protocol, > > G.8264) should be separate from linuxptp project and be it's own standalone > > project; so that it does NOT get confused with L1_SYNC TLV from IEEE > > 1588-2019 (if/when it gets added to linuxptp). The HA profile's use of the
Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet
> The difference in the protocol (L1_SYNC TLV vs SSM) seems to me quite small > when compared to the rest. This is my concern, as this statement is false. SyncE describes an ITU-T network synchronization method for the distribution of frequency over a transport network, using the L1 physical layer clock (Ethernet or OTN). Details of the network limits, equipment clock requirements, protocol and architecture are contained in numerous ITU-T recommendations (G.826x). The use of the SyncE clock to assist PTP is described in G.8273.2 for T-BC/T-TSC (and also in G.8273.4 as a option for T-BC-P/T-TSC-P). In this case, the SyncE clock does not need to be coherent or congruent with the PTP clock. The L1_SYNC TLV is a Layer-1 based synchronization performance enhancement for PTP (described in Annex L of IEEE 1588-2019). The key aspect of the scheme illustrated by the high accuracy model is that the physical clock signal and the time of the PTP Instance are coherent. Yes, both methods can be used to syntonize the Timestamping Clocks in all PTP Instances to within the required tolerance with respect to the Grandmaster Clock, but how to use SyncE vs L1_SYNC in the protocol (ptp4l) is different - one is managed with the protocol (L1_SYNC) the other by it's own protocol (synce4l). I'm not arguing there could not be shared support code, but to the uninformed developer, synce4l could be mistaken for L1_SYNC (i.e. mistakenly use the PHC for "SyncE" clock management). Also, as Richard highlighted, the development of synce4l and ptp4l are mutual exclusive, so it does not make sense for the synce4l code submissions to be reviewed by the linuxptp development community, as they are not the right audience (as unlikely familiar with the ITU-T recommendations that synce4l must follow). Greg Greg Armstrong Principal System Architect, Timing Products Division Renesas Electronics Canada Limited Mobile: 1-613-218-9373 -Original Message- From: Miroslav Lichvar Sent: June 1, 2022 3:33 AM To: Greg Armstrong Cc: Richard Cochran ; piotr.kwapulin...@intel.com; anatolii.gerasyme...@intel.com; andrzej.saw...@intel.com; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet On Tue, May 31, 2022 at 02:42:00PM +, Greg Armstrong wrote: > This is the reason synce4l (based on an ITU-T physical layer protocol, > G.8264) should be separate from linuxptp project and be it's own standalone > project; so that it does NOT get confused with L1_SYNC TLV from IEEE > 1588-2019 (if/when it gets added to linuxptp). The HA profile's use of the > physical layer clock is not the same as ITU-T definition of SyncE. If synce4l remained specific to G.8264, the confusion could be avoided by renaming it to something else. (I don't have a suggestion at the moment.) There are plenty of conflicting options in linuxptp. The advantage of having both supported in linuxptp, no matter if the actual HW support is for both in synce4l or separately in ptp4l and synce4l, is that the support code can be shared. The difference in the protocol (L1_SYNC TLV vs SSM) seems to me quite small when compared to the rest. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet
This is the reason synce4l (based on an ITU-T physical layer protocol, G.8264) should be separate from linuxptp project and be it's own standalone project; so that it does NOT get confused with L1_SYNC TLV from IEEE 1588-2019 (if/when it gets added to linuxptp). The HA profile's use of the physical layer clock is not the same as ITU-T definition of SyncE. This is not to say there is no interaction between synce4l and ptp4l to support the ITU-T profiles that have physical layer assistance, but the two protocols themselves are mutually exclusive. Also, similar to the PHC to abstract the hardware for user space programs, I would suspect a similar SyncE Hardware Clock infrastructure will be needed in Linux to allow for abstraction of hardware used by synce4l (i.e. as this project matures to meet the full recommendations in G.8264 and, as required, G.781). Greg Greg Armstrong Principal System Architect, Timing Products Division Renesas Electronics Canada Limited Mobile: 1-613-218-9373 -Original Message- From: Miroslav Lichvar Sent: May 31, 2022 10:07 AM To: Richard Cochran Cc: piotr.kwapulin...@intel.com; anatolii.gerasyme...@intel.com; andrzej.saw...@intel.com; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet On Thu, May 26, 2022 at 10:51:01AM -0700, Richard Cochran wrote: > On Mon, May 02, 2022 at 11:05:54AM +0200, Arkadiusz Kubalewski wrote: > > synce4l is a software implementation of Synchronous Ethernet > > (Sync-E) according to ITU-T Recommendation G.8264. The design goal > > is to provide logic to supported hardware by processing Ethernet > > Synchronization Messaging Channel (ESMC) and control Digital Phase > > Locked Loop (DPLL) clock on Network Card Interface (NIC). > > The bulk of this is a new, stand alone program. One comment that I > received off list questioned whether this program should be part of > linuxptp, or does it deserve its own project? synce4l as submitted doesn't share much with the rest of linuxptp, but that could change with support for the L1_SYNC TLV from 1588-2019. I think it would need to be handled by ptp4l itself, or at least by something communicating with ptp4l over UDS. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cgreg.armstrong.uw%40renesas.com%7Cece84de7784b43f32e4908da430f2242%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637896029522150943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=9fqPCkzVsPbjxXg%2Bn2%2FwKztjJiWq5RXsRUEXmHTC4JA%3Dreserved=0 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Question regarding terminology of Master and Slave
We should be following the guidelines being set by the IEEE 1588 working group – on this topic, specifically IEEE SA - P1588g<https://standards.ieee.org/ieee/1588g/10478/> This amendment adds an optional alternative suitable and inclusive terminology to the terms “master” and “slave” but it does not replace the terms “master” and “slave” In addition, the amendment fixes errors in the standard and clarifies unclear passages. The latest D1.1 has gone through Ballot 2. Hopefully below summary text from the amendment will help: If alternative terms for “master” and “slave” are used in PTP implementations or PTP Profiles, then the guidelines below should be followed: •In place of the term “master”, use the term “timeTransmitter”. In place of the term “slave”, use the term “timeReceiver”. •Capitalization of the terms remains unchanged. For example, “master” becomes “timeTransmitter”, and “Master” becomes “TimeTransmitter”. •Replacements include parts of compound words. For example, the “” becomes "”. •“BMCA” is replaced by “BTCA”, because “Best Master Clock Algorithm” is replaced by “Best TimeTransmitter Clock Algorithm”. •For PTP Port state names: use “TIME_TRANSMITTER” in place of “MASTER”; use “TIME_RECEIVER” in place of “SLAVE”. •When PTP Instance, Clock roles, or PTP Port states are abbreviated in diagrams, the abbreviations are “TT” for timeTransmitter and TIME_TRANSMITTER, and “TR” for timeReceiver and TIME_RECEIVER. The term “Grandmaster” should remain “Grandmaster”. Use of other terms (i.e. client) should be avoided to prevent disconnect from the IEEE standard. Greg Greg Armstrong Principal System Architect, Timing Products Division Renesas Electronics Canada Limited Mobile: 1-613-218-9373 From: Erez Sent: May 16, 2022 6:02 AM To: linuxptp-devel@lists.sourceforge.net; Richard Cochran Subject: [Linuxptp-devel] Question regarding terminology of Master and Slave Hi, I remember we had a discussion on the matter. And decide to rename "Master" to "source" and "Slave" to "sink". My questions are: 1. I see in the code "client", for example "clientOnly" mode. When do we use "client" and when do we use "sink"? Are they the same or represent different things? 2. Did we define the border? When do we use the official IEEE "master" and "slave", and when do we use the new "source" and "sink"? I see, for example, the management IDs remain with IEEE terminologie. 3. What about "grandmaster", do we call it grandsource? I think we should set clear rules, so we can minimize the confusion in the project. Something simple like 4-5 rules perhaps. Erez ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] Add setting of PTP_TIMESCALE flag
The latest 802.1AS has clarified ptpTimescale flag is only used for Announce. For all other messages, it should be FALSE (and still ignored on reception). Thus, the patch should not be the default. I agree with Jacob that a use of a flag may be better to allow interop with other gPTP implementations, if required. Regards, Greg -Original Message- From: Jacob Keller Sent: June 14, 2021 1:24 PM To: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH 2/2] Add setting of PTP_TIMESCALE flag On 6/14/2021 5:03 AM, Miklas, Marcin via Linuxptp-devel wrote: > From: Marcin Miklas > > In gPTP PTP_TIMESCALE flag should be set to 1. It looks like the flags > where not properly set for any of messages used in gPTP. > > Some of the automotive gPTP bridges where rejecting the PDelayReq > messages because of missing flag. > > I would say that both linuxptp and the bridge doesn't conform to gPTP > specification where it is said that the PTP_TIMESCALE should be set to > 1 and ignored on reception. > If I recall, this has been discussed on the list multiple times before. https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinuxptp%2Fmailman%2Fmessage%2F34977023%2Fdata=04%7C01%7Cgreg.armstrong.uw%40renesas.com%7Cb75bed15e76447ee90ca08d92f597610%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637592883546134077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=mQsYdNT4%2FoGcra850CRlM%2BufYLSfRUvwhKY7V8UnXqo%3Dreserved=0 According to the normal 1588 standard, the bit is not supposed to be set for these messages. Perhaps an optional configuration to set these would be acceptable though. (Then the gPTP config file could use that flag to make sure it is set) > Signed-off-by: Marcin Miklas > --- > port.c | 5 + > port_signaling.c | 1 + > 2 files changed, 6 insertions(+) > > diff --git a/port.c b/port.c > index 8175f28..f906a6c 100644 > --- a/port.c > +++ b/port.c > @@ -1362,6 +1362,7 @@ static int port_pdelay_request(struct port *p) > msg->header.ver= PTP_VERSION; > msg->header.messageLength = sizeof(struct pdelay_req_msg); > msg->header.domainNumber = clock_domain_number(p->clock); > + msg->header.flagField[1] = clock_time_properties(p->clock).flags; > msg->header.correction = -p->asymmetry; > msg->header.sourcePortIdentity = p->portIdentity; > msg->header.sequenceId = p->seqnum.delayreq++; > @@ -1556,6 +1557,7 @@ int port_tx_sync(struct port *p, struct address *dst) > msg->header.ver= PTP_VERSION; > msg->header.messageLength = sizeof(struct sync_msg); > msg->header.domainNumber = clock_domain_number(p->clock); > + msg->header.flagField[1] = clock_time_properties(p->clock).flags; > msg->header.sourcePortIdentity = p->portIdentity; > msg->header.sequenceId = p->seqnum.sync++; > msg->header.control= CTL_SYNC; > @@ -1592,6 +1594,7 @@ int port_tx_sync(struct port *p, struct address *dst) > fup->header.ver= PTP_VERSION; > fup->header.messageLength = sizeof(struct follow_up_msg); > fup->header.domainNumber = clock_domain_number(p->clock); > + fup->header.flagField[1] = clock_time_properties(p->clock).flags; > fup->header.sourcePortIdentity = p->portIdentity; > fup->header.sequenceId = p->seqnum.sync - 1; > fup->header.control= CTL_FOLLOW_UP; > @@ -2123,6 +2126,7 @@ int process_pdelay_req(struct port *p, struct > ptp_message *m) > rsp->header.ver= PTP_VERSION; > rsp->header.messageLength = sizeof(struct pdelay_resp_msg); > rsp->header.domainNumber = m->header.domainNumber; > + rsp->header.flagField[1] = clock_time_properties(p->clock).flags; > rsp->header.sourcePortIdentity = p->portIdentity; > rsp->header.sequenceId = m->header.sequenceId; > rsp->header.control= CTL_OTHER; > @@ -2170,6 +2174,7 @@ int process_pdelay_req(struct port *p, struct > ptp_message *m) > fup->header.ver= PTP_VERSION; > fup->header.messageLength = sizeof(struct pdelay_resp_fup_msg); > fup->header.domainNumber = m->header.domainNumber; > + fup->header.flagField[1] = clock_time_properties(p->clock).flags; > fup->header.correction = m->header.correction; > fup->header.sourcePortIdentity = p->portIdentity; > fup->header.sequenceId = m->header.sequenceId; > diff --git a/port_signaling.c b/port_signaling.c index > ed217c0..c76bfdf 100644 > --- a/port_signaling.c > +++ b/port_signaling.c > @@ -44,6 +44,7 @@ struct ptp_message *port_signaling_construct(struct port *p, > msg->header.ver= PTP_VERSION; > msg->header.messageLength =
Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1)
It may not break anything at the protocol, but I suspect the state decision algorithm is what's breaking. By setting clientOnly, you don't allow any PTP port to enter the MASTER (or PASSIVE) state (see IEEE1588-2019 Figure 31 for slave-only state machine). However, a BC would normally put any PTP port that is not SLAVE/UNCALIBRATED into the MASTER/PRE_MASTER or PASSIVE state - these are not allowed in slave-only. I suspect this is why LISTENING is used by the 2nd PTP port (when the 1st PTP port is in the SLAVE state). However, once the Announce is received by the 2nd GM, the local PTP port needed to change to UNCALIBRATED state. From this state, the only allowed transition is to SLAVE state - and this is likely what breaks as there is already a port in the SLAVE state. I have not dwelled into ptp4l state machine, but suspect this causes all the PTP ports to enter FAULTY state. This would explain what was observed of toggling in/out of FAULTY state. Greg -Original Message- From: Miroslav Lichvar Sent: May 10, 2021 7:58 AM To: Greg Armstrong Cc: Amar Subramanyam ; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1) On Fri, May 07, 2021 at 02:27:46PM +, Greg Armstrong wrote: > Just to add, the key reason it is not supported by BC is that if true, then > clockClass must be 255. This clockClass is only for slave-only OC. > > From IEEE1588-2019 clause 8.2.1.3.1.2: > If defaultDS.slaveOnly is TRUE, the initialization value [of > defaultDS.clockQuality.clockClass] shall be 255 as specified in 7.6.2.5. > > From IEEE1588-2019 Table 4: > 255 | Shall be the clockClass of a slave-only PTP Instance > (see 9.2.2.1). > > And clause 9.2.2.1 title is "Slave-Only Ordinary Clocks". Good point. But this doesn't break anything at the protocol level, right? A slaveOnly clock should never send an annoucement message with its clockClass. It is an extension that we can support in linuxptp, assuming we can make it work as expected, e.g. avoid those "priority1 probably misconfigured" warnings, etc. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1)
Just to add, the key reason it is not supported by BC is that if true, then
clockClass must be 255. This clockClass is only for slave-only OC.
>From IEEE1588-2019 clause 8.2.1.3.1.2:
If defaultDS.slaveOnly is TRUE, the initialization value [of
defaultDS.clockQuality.clockClass] shall be 255 as specified in 7.6.2.5.
>From IEEE1588-2019 Table 4:
255 | Shall be the clockClass of a slave-only PTP Instance
(see 9.2.2.1).
And clause 9.2.2.1 title is "Slave-Only Ordinary Clocks".
Greg
-Original Message-
From: Greg Armstrong
Sent: May 7, 2021 10:00 AM
To: Amar Subramanyam ; Miroslav Lichvar
Cc: linuxptp-devel@lists.sourceforge.net
Subject: RE: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran
with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1)
One possible issue is you are setting clientOnly=1 for a BC; this is not
allowed per IEEE1588 (as a BC shall not be a slaveOnly PTP Instance).
>From IEEE1588-2019:
9.2.3 Non-slaveOnly PTP Instances
A Boundary Clock shall not be a slaveOnly PTP Instance. Ordinary Clocks
not designed or configured as slaveOnly and Boundary Clocks shall
implement the state machine illustrated in Figure 30.
Greg
-Original Message-
From: Amar Subramanyam via Linuxptp-devel
Sent: May 7, 2021 7:37 AM
To: Miroslav Lichvar
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran
with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1)
Hi Miroslav,
Please find our response in line.
Thanks,
Amar B S
-Original Message-
From: Miroslav Lichvar [mailto:mlich...@redhat.com]
Sent: 06 May 2021 19:41
To: Amar Subramanyam
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran
with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1)
CAUTION: This email originated from outside of Altiostar. Do not click on links
or open attachments unless you recognize the sender and you are sure the
content is safe. You will never be asked to reset your Altiostar password via
email.
On Tue, May 04, 2021 at 01:51:24PM +0300, Amar Subramanyam via Linuxptp-devel
wrote:
> This patch addresses the following issues when ptp4l is ran on
> multiple ports with jbod and client only mode (i.e clientOnly=1 and
> boundary_clock_jbod=1):-
>
> 1.SYNCHRONIZATION FAULT occurs at every ANNOUNCE RECEIPT Timeout on
> LISTENING port, which leads to PTP port state of SLAVE port to flap
> between SLAVE and UNCALIBRATED states continuously.
>> It's not clear to me what exactly is happening here and how does the patch
>> fix it. The faults are happening due to the clock check getting out of order
>> timestamps from two unsynchronized clocks, right? Any chance it is an issue
>> with phc2sys not synchronizing the clocks?
Please find the attached diagram, which details our use case. Two active grand
masters are connected to the same Telecom Slave Clock in two different ports,
PORT1 and PORT2. Single instance of Ptp4l and phc2sys are running in the
Telecom Slave Clock with boundary_clock_jbod=1 and clientOnly=1 configurations.
The expected behaviour here is ptp4l will take into account GM1 and GM2 and
choose the best master using BMCA algorithm. The port which has the best master
will be in SLAVE state while the other port will remain in LISTENING state,
acting as a redundant port.
Let GM1 be a better master than GM2, resulting in Port1 to be in SLAVE state
and Port2 in LISTENING state. While running the latest ptp4l, we are
observing the following issues, for which we have proposed our patch :-
Since Port 2 is in LISTENING state even though we are receving announce packets
from GM2, the function add_foreign_master() is called for every Announce
message received. Here, the announce receipt timer is not re-armed and hence
will trigger BMCA for every 375ms (Default Announce reciept timeout). This is
expected behaviour for normal client only mode with only 1 port but when
multiple client/slave ports are involved(say port1, port 2), we dont expect
port 2 to trigger BMCA unless there is a change in the Announce message
recevied from GM2.
Continuous BMCA triggering in port 2 causes a SYNCHRONIZATION FAULT in
port1.This causes port1 to jump from SLAVE to UNCALIBRATED and vice versa
repeatedly.
Hence, we are re-arming the Announce receipt timer in the function
add_foreign_master(), only when boundary_clock_jbod=1 and clientOnly=1 is
configured and atleast one port (Port1 here) is in SLAVE/UNCALIBRATED state.
> +int clock_get_client_state(struct clock *c) +{
> + struct port *piter;
> +
> + if (!clock_slave_only(c)) {
> + return 1;
> + }
> +
> + LIST_FOREACH(piter, >ports, list) {
> + enum
Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1)
One possible issue is you are setting clientOnly=1 for a BC; this is not
allowed per IEEE1588 (as a BC shall not be a slaveOnly PTP Instance).
>From IEEE1588-2019:
9.2.3 Non-slaveOnly PTP Instances
A Boundary Clock shall not be a slaveOnly PTP Instance. Ordinary Clocks
not designed or configured as slaveOnly and Boundary Clocks shall
implement the state machine illustrated in Figure 30.
Greg
-Original Message-
From: Amar Subramanyam via Linuxptp-devel
Sent: May 7, 2021 7:37 AM
To: Miroslav Lichvar
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran
with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1)
Hi Miroslav,
Please find our response in line.
Thanks,
Amar B S
-Original Message-
From: Miroslav Lichvar [mailto:mlich...@redhat.com]
Sent: 06 May 2021 19:41
To: Amar Subramanyam
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran
with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1)
CAUTION: This email originated from outside of Altiostar. Do not click on links
or open attachments unless you recognize the sender and you are sure the
content is safe. You will never be asked to reset your Altiostar password via
email.
On Tue, May 04, 2021 at 01:51:24PM +0300, Amar Subramanyam via Linuxptp-devel
wrote:
> This patch addresses the following issues when ptp4l is ran on
> multiple ports with jbod and client only mode (i.e clientOnly=1 and
> boundary_clock_jbod=1):-
>
> 1.SYNCHRONIZATION FAULT occurs at every ANNOUNCE RECEIPT Timeout on
> LISTENING port, which leads to PTP port state of SLAVE port to flap
> between SLAVE and UNCALIBRATED states continuously.
>> It's not clear to me what exactly is happening here and how does the patch
>> fix it. The faults are happening due to the clock check getting out of order
>> timestamps from two unsynchronized clocks, right? Any chance it is an issue
>> with phc2sys not synchronizing the clocks?
Please find the attached diagram, which details our use case. Two active grand
masters are connected to the same Telecom Slave Clock in two different ports,
PORT1 and PORT2. Single instance of Ptp4l and phc2sys are running in the
Telecom Slave Clock with boundary_clock_jbod=1 and clientOnly=1 configurations.
The expected behaviour here is ptp4l will take into account GM1 and GM2 and
choose the best master using BMCA algorithm. The port which has the best master
will be in SLAVE state while the other port will remain in LISTENING state,
acting as a redundant port.
Let GM1 be a better master than GM2, resulting in Port1 to be in SLAVE state
and Port2 in LISTENING state. While running the latest ptp4l, we are
observing the following issues, for which we have proposed our patch :-
Since Port 2 is in LISTENING state even though we are receving announce packets
from GM2, the function add_foreign_master() is called for every Announce
message received. Here, the announce receipt timer is not re-armed and hence
will trigger BMCA for every 375ms (Default Announce reciept timeout). This is
expected behaviour for normal client only mode with only 1 port but when
multiple client/slave ports are involved(say port1, port 2), we dont expect
port 2 to trigger BMCA unless there is a change in the Announce message
recevied from GM2.
Continuous BMCA triggering in port 2 causes a SYNCHRONIZATION FAULT in
port1.This causes port1 to jump from SLAVE to UNCALIBRATED and vice versa
repeatedly.
Hence, we are re-arming the Announce receipt timer in the function
add_foreign_master(), only when boundary_clock_jbod=1 and clientOnly=1 is
configured and atleast one port (Port1 here) is in SLAVE/UNCALIBRATED state.
> +int clock_get_client_state(struct clock *c) +{
> + struct port *piter;
> +
> + if (!clock_slave_only(c)) {
> + return 1;
> + }
> +
> + LIST_FOREACH(piter, >ports, list) {
> + enum port_state ps = port_state(piter);
> + if (ps == PS_SLAVE || ps == PS_UNCALIBRATED) {
> + return 0;
> + }
> + }
> + return 1;
> +}
> + * Inform if any of the port is in SLAVE state.
> + * @param c The clock instance.
> + * @return Return 0 if any port is in SLAVE state, 1 otherwise.
> + */
> +int clock_get_client_state(struct clock *c);
>> The function seems to be specific to the slave-only mode and it checks for
>> two port states. The description and name of the function indicate something
>> else.
Noted. Please find the updated description and function name below, we will
send out the modified patch after full review.
+ * Get port SLAVE state for client only mode.
+ * @param c The clock instance.
+ * @return Return 0 if any port is in SLAVE state, 1 otherwise.
+ */
+int clock_get_port_slave_state(struct clock *c);
> + * In multiport slave
