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-201
On Wed, Jun 01, 2022 at 10:38:29AM +0530, SyncMonk Technologies wrote:
> As per IEEE1588-2019, Table 21 adding NO_MECHANISM support. In this
> case port does not implement the delay mechanism.
> static struct config_enum delay_mech_enu[] = {
> - { "Auto", DM_AUTO },
> - { "E2E", DM_E2E }
As per IEEE1588-2019, Table 21 adding NO_MECHANISM support. In this
case port does not implement the delay mechanism.
Signed-off-by: Greg Armstrong
Signed-off-by: Leon Goldin
Signed-off-by: Devasish Dey
Signed-off-by: Vipin Sharma
---
config.c | 16 +---
dm.h |
On Mon, May 30, 2022 at 09:34:10PM +0200, Arkadiusz Kubalewski wrote:
> Extend interface struct, allow to keep information about SyncE parent
> device.
>
> Add helper function (util.c) to acquire Do Not Use - Quality Level
> value.
> --- a/util.c
> +++ b/util.c
> @@ -30,6 +30,7 @@
> #include "pr
On Mon, May 30, 2022 at 09:34:15PM +0200, Arkadiusz Kubalewski wrote:
> Used by synce_dev to interact with its ports.
> +struct synce_port *synce_port_create(const char *port_name)
> +{
> + struct synce_port *p = NULL;
> +
> + if (!port_name) {
> + pr_err("%s failed - port_name
On Mon, May 30, 2022 at 09:34:16PM +0200, Arkadiusz Kubalewski wrote:
> Used by synce_port to create, control and destroy RX/TX threads.
> Ports in sync mode can use only TX thread (device in external input
> mode) or both RX and TX threads (device in internal input mode).
> +static void *tx_threa
On Mon, May 30, 2022 at 09:34:17PM +0200, Arkadiusz Kubalewski wrote:
> Interface used for:
> - creation, building and storing new SyncE PDU's for later transmission
> - obtain Quality Level TLV and Extended Quality Level TLV from existing
> SyncE PDU's
>
> synce_msg_private.h has constants and
On Wed, Jun 01, 2022 at 02:40:05PM +0530, SyncMonk Technologies wrote:
> As per IEEE1588-2019, Table 21 adding NO_MECHANISM support. In this
> case port does not implement the delay mechanism.
>
> Signed-off-by: Greg Armstrong
> Signed-off-by: Leon Goldin
> Signed-off-by: Devasish Dey
> Signed-
Hi Miroslav,
On Wed, 1 Jun 2022 at 13:52, Miroslav Lichvar wrote:
> On Wed, Jun 01, 2022 at 10:38:29AM +0530, SyncMonk Technologies wrote:
> > As per IEEE1588-2019, Table 21 adding NO_MECHANISM support. In this
> > case port does not implement the delay mechanism.
>
> > static struct config_enu
On Wed, Jun 01, 2022 at 04:08:23PM +0530, Devasish Dey wrote:
> As of now the *"tsproc_update_offset" * looks for a valid *t3 * and
> *filtered_delay_valid
> *to be True to calculate the offset.
It doesn't check t3 in the default (filter) mode. The initial_delay
option relies on that. The other ts
As far as I can tell, three new management TLVs were added recently
without updating the pmc.8 man page:
* PORT_SERVICE_STATS_NP
* UNICAST_MASTER_TABLE_NP
* PORT_HWCLOCK_NP
This simple change fixes this omission.
Signed-off-by: Alexander Bulimov
---
pmc.8 | 6 ++
1 file changed, 6 insertion
> 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 la
-Original Message-
From: Miroslav Lichvar
Sent: Wednesday, June 1, 2022 11:52 AM
> On Mon, May 30, 2022 at 09:34:16PM +0200, Arkadiusz Kubalewski wrote:
> > Used by synce_port to create, control and destroy RX/TX threads.
> > Ports in sync mode can use only TX thread (device in external
-Original Message-
From: Miroslav Lichvar
Sent: Wednesday, June 1, 2022 11:55 AM
> On Mon, May 30, 2022 at 09:34:17PM +0200, Arkadiusz Kubalewski wrote:
> > Interface used for:
> > - creation, building and storing new SyncE PDU's for later transmission
> > - obtain Quality Level TLV and E
-Original Message-
From: Miroslav Lichvar
Sent: Wednesday, June 1, 2022 11:28 AM
> On Mon, May 30, 2022 at 09:34:10PM +0200, Arkadiusz Kubalewski wrote:
> > Extend interface struct, allow to keep information about SyncE parent
> > device.
> >
> > Add helper function (util.c) to acquire
-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 synchroni
-Original Message-
From: Miroslav Lichvar
Sent: Wednesday, June 1, 2022 11:39 AM
> On Mon, May 30, 2022 at 09:34:15PM +0200, Arkadiusz Kubalewski wrote:
> > Used by synce_dev to interact with its ports.
>
> > +struct synce_port *synce_port_create(const char *port_name)
> > +{
> > + s
On Wed, 1 Jun 2022 at 14:56, Alexander Bulimov via Linuxptp-devel <
linuxptp-devel@lists.sourceforge.net> wrote:
> As far as I can tell, three new management TLVs were added recently
> without updating the pmc.8 man page:
> * PORT_SERVICE_STATS_NP
> * UNICAST_MASTER_TABLE_NP
> * PORT_HWCLOCK_NP
>
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
On Wed, Jun 01, 2022 at 01:18:09PM +, 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 dis
On Wed, Jun 01, 2022 at 02:44:14PM +, Kubalewski, Arkadiusz wrote:
> > Maybe the create and init function could be merged to make the
> > error handling easier?
>
> Well, init is already long function, I would rather leave it separated,
> Isn't it enough to zero-memory here?
Maybe. I didn't t
On Wed, 1 Jun 2022 at 17:22, Miroslav Lichvar wrote:
> On Wed, Jun 01, 2022 at 01:18:09PM +, 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 descr
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 nee
23 matches
Mail list logo
