Re: [Linuxptp-devel] [PATCH 1/1] TLV management messages need to be aligned to 16 bits.
On 3/8/22, Erez Geva wrote: > struct PortIdentity portIdentity; > Integer32 phc_index; > UInteger8 flags; > + uint8_t reserved; What is the difference between uint8_t and UInteger8 ? Shouldn't these be the same type? I don't know, but it looks fishy to me. -Dale ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 1/1] Add new managements TLVs get size.
Add missing managements TLVs to pmc_tlv_datalen. Ensure alignment to 16 bits. Signed-off-by: Erez Geva --- pmc_common.c | 40 +++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/pmc_common.c b/pmc_common.c index 1141957..43ad22c 100644 --- a/pmc_common.c +++ b/pmc_common.c @@ -54,6 +54,25 @@ #define EMPTY_CLOCK_DESCRIPTION 22 /* Includes one extra byte to make length even. */ #define EMPTY_PTP_TEXT 2 +/* Field Len Type + * --- + * portIdentity 10UInteger16 + 8 * Octets + * port_state 1uint8_t + * timestamping 1uint8_t + * interface 1PTPText + * extra 1make length even + * --- + * TOTAL 14 + */ +#define EMPTY_PORT_PROPERTIES_NP 14 +/* Field Len Type + * --- + * actualTableSize2UInteger16 + * unicast_masters0Zero length array + * --- + * TOTAL 2 + */ +#define EMPTY_UNICAST_MASTER_TABLE_NP 2 static void do_get_action(struct pmc *pmc, int action, int index, char *str); static void do_set_action(struct pmc *pmc, int action, int index, char *str); @@ -517,6 +536,7 @@ static int pmc_tlv_datalen(struct pmc *pmc, int id) case MID_TRACEABILITY_PROPERTIES: case MID_TIMESCALE_PROPERTIES: case MID_MASTER_ONLY: + case MID_SYNCHRONIZATION_UNCERTAIN_NP: len += sizeof(struct management_tlv_datum); break; case MID_TIME_STATUS_NP: @@ -525,6 +545,9 @@ static int pmc_tlv_datalen(struct pmc *pmc, int id) case MID_GRANDMASTER_SETTINGS_NP: len += sizeof(struct grandmaster_settings_np); break; + case MID_SUBSCRIBE_EVENTS_NP: + len += sizeof(struct subscribe_events_np); + break; case MID_NULL_MANAGEMENT: break; case MID_CLOCK_DESCRIPTION: @@ -536,6 +559,21 @@ static int pmc_tlv_datalen(struct pmc *pmc, int id) case MID_PORT_DATA_SET_NP: len += sizeof(struct port_ds_np); break; + case MID_PORT_PROPERTIES_NP: + len += EMPTY_PORT_PROPERTIES_NP; + break; + case MID_PORT_STATS_NP: + len += sizeof(struct port_stats_np); + break; + case MID_PORT_SERVICE_STATS_NP: + len += sizeof(struct port_service_stats_np); + break; + case MID_UNICAST_MASTER_TABLE_NP: + len += EMPTY_UNICAST_MASTER_TABLE_NP; + break; + case MID_PORT_HWCLOCK_NP: + len += sizeof(struct port_hwclock_np); + break; case MID_LOG_ANNOUNCE_INTERVAL: case MID_ANNOUNCE_RECEIPT_TIMEOUT: case MID_LOG_SYNC_INTERVAL: @@ -545,7 +583,7 @@ static int pmc_tlv_datalen(struct pmc *pmc, int id) len += sizeof(struct management_tlv_datum); break; } - return len; + return len + len % 2; } int pmc_get_transport_fd(struct pmc *pmc) -- 2.30.2 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 1/1] TLV management messages need to be aligned to 16 bits.
On Tue, 15 Mar 2022 at 17:14, Miroslav Lichvar wrote:
> On Tue, Mar 08, 2022 at 10:55:14PM +0100, Erez Geva wrote:
> > Add reserved octet to the new port hardware clock structure.
>
> > @@ -354,6 +354,7 @@ struct port_hwclock_np {
> > struct PortIdentity portIdentity;
> > Integer32 phc_index;
> > UInteger8 flags;
> > + uint8_t reserved;
> > } PACKED;
>
> FWIW, there is a code in the {clock,port}_management_fill_response
> functions that pads the TLVs to 16 bits:
>
> if (datalen % 2) {
>
> tlv->data[datalen] = 0;
>
> datalen++;
>
> }
>
>
>
The reserved field was added in other cases.
Regardless of the padding.
P.S.
I check pmc_tlv_datalen()
It lacks most of the new TLVs and it does not pad to 16 bits.
If we require the TLV declarations to be correctly padded, it might be
> a good idea to replace this code with an assertion or return error to
> catch bugs when new TLVs are introduced.
>
Fine by me.
If Richard agrees, we can add a warning, a error or assertion.
Erez
> --
> Miroslav Lichvar
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] [PATCH 0/1] Add new managements TLVs get size
Add missing managements TLVs to pmc_tlv_datalen. Ensure alignment to 16 bits. Erez Geva (1): Add new managements TLVs get size. pmc_common.c | 40 +++- 1 file changed, 39 insertions(+), 1 deletion(-) -- 2.30.2 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 1/1] TLV management messages need to be aligned to 16 bits.
On Tue, 15 Mar 2022 at 23:38, Erez wrote:
>
>
> On Tue, 15 Mar 2022 at 17:14, Miroslav Lichvar
> wrote:
>
>> On Tue, Mar 08, 2022 at 10:55:14PM +0100, Erez Geva wrote:
>> > Add reserved octet to the new port hardware clock structure.
>>
>> > @@ -354,6 +354,7 @@ struct port_hwclock_np {
>> > struct PortIdentity portIdentity;
>> > Integer32 phc_index;
>> > UInteger8 flags;
>> > + uint8_t reserved;
>> > } PACKED;
>>
>> FWIW, there is a code in the {clock,port}_management_fill_response
>> functions that pads the TLVs to 16 bits:
>>
>> if (datalen % 2) {
>>
>> tlv->data[datalen] = 0;
>>
>> datalen++;
>>
>> }
>>
>>
>>
> The reserved field was added in other cases.
> Regardless of the padding.
>
> P.S.
> I check pmc_tlv_datalen()
> It lacks most of the new TLVs and it does not pad to 16 bits.
>
>
> If we require the TLV declarations to be correctly padded, it might be
>> a good idea to replace this code with an assertion or return error to
>> catch bugs when new TLVs are introduced.
>>
>
> Fine by me.
> If Richard agrees, we can add a warning, a error or assertion.
>
The padding is for variable length TLVs, like CLOCK_DESCRIPTION.
Fixed size TLVs should be aligned.
So we can not issue a warning or error there.
We can issue a warning in pmc_tlv_datalen().
But as committers skip it not sure if it is helpful.
Erez
> Erez
>
>
>> --
>> Miroslav Lichvar
>>
>>
>>
>> ___
>> Linuxptp-devel mailing list
>> Linuxptp-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>>
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 3/4] port: unicast client - do not add master to foreign master table if not in the unicast master table.
> -Original Message-
> From: vincent.cheng...@renesas.com
> Sent: Sunday, March 13, 2022 10:01 PM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH v2 3/4] port: unicast client - do not add
> master
> to foreign master table if not in the unicast master table.
>
> From: Vincent Cheng
>
> Signed-off-by: Vincent Cheng
Looks like some whitespace got changed on accident. Otherwise this patch looks
good to me.
Reviewed-by: Jacob Keller
> ---
> port.c | 28 +++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/port.c b/port.c
> index f2b666c..0169161 100644
> --- a/port.c
> +++ b/port.c
> @@ -167,6 +167,27 @@ static int msg_source_equal(struct ptp_message *m1,
> struct foreign_clock *fc)
> return 0 == memcmp(id1, id2, sizeof(*id1));
> }
>
> +static int port_unicast_message_valid(struct port *p, struct ptp_message *m)
> +{
> + struct unicast_master_address master;
> +
> + if (!unicast_client_unicast_master_table_received(p, m)) {
> + memset(, 0, sizeof(master));
> + master.address = m->address;
> + master.portIdentity = m->header.sourcePortIdentity;
> +
> + pr_warning("%s: new foreign master %s not in unicast master
> table",
> +p->log_name, pid2str(
> >header.sourcePortIdentity));
> +
> + if (unicast_client_tx_cancel(p, )) {
> + pr_warning("%s: cancel unicast transmission to %s
> failed",
> +p->log_name, pid2str(
> >header.sourcePortIdentity));
> + }
> + return 0;
> + }
> + return 1;
> +}
> +
> int source_pid_eq(struct ptp_message *m1, struct ptp_message *m2)
> {
> return pid_eq(>header.sourcePortIdentity,
> @@ -351,8 +372,13 @@ static int add_foreign_master(struct port *p, struct
> ptp_message *m)
> }
> }
> if (!fc) {
> + if (unicast_client_enabled(p)) {
> + if (!port_unicast_message_valid(p, m)) {
> + return 0;
> + }
> + }
> pr_notice("%s: new foreign master %s", p->log_name,
> - pid2str(>header.sourcePortIdentity));
> + pid2str(>header.sourcePortIdentity));
What's going on here? some whitespace fixup?
>
> fc = malloc(sizeof(*fc));
> if (!fc) {
> --
> 2.34.1
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 4/4] port: cancel unicast transmission when closing port.
> -Original Message-
> From: vincent.cheng...@renesas.com
> Sent: Sunday, March 13, 2022 10:01 PM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH v2 4/4] port: cancel unicast transmission
> when
> closing port.
>
> From: Vincent Cheng
>
> Signed-off-by: Vincent Cheng
Reviewed-by: Jacob Keller
> ---
> port.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/port.c b/port.c
> index 0169161..1480630 100644
> --- a/port.c
> +++ b/port.c
> @@ -167,6 +167,21 @@ static int msg_source_equal(struct ptp_message *m1,
> struct foreign_clock *fc)
> return 0 == memcmp(id1, id2, sizeof(*id1));
> }
>
> +static void port_cancel_unicast(struct port *p)
> +{
> + struct unicast_master_address *ucma;
> +
> + if (!unicast_client_enabled(p)) {
> + return;
> + }
> +
> + STAILQ_FOREACH(ucma, >unicast_master_table->addrs, list) {
> + if (ucma) {
> + unicast_client_tx_cancel(p, ucma);
> + }
> + }
> +}
> +
> static int port_unicast_message_valid(struct port *p, struct ptp_message *m)
> {
> struct unicast_master_address master;
> @@ -2488,6 +2503,7 @@ void process_sync(struct port *p, struct ptp_message
> *m)
> void port_close(struct port *p)
> {
> if (port_is_enabled(p)) {
> + port_cancel_unicast(p);
> port_disable(p);
> }
>
> --
> 2.34.1
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 2/4] unicast: Add support to send CANCEL_UNICAST_TRANSMISSION TLVs.
> -Original Message-
> From: vincent.cheng...@renesas.com
> Sent: Sunday, March 13, 2022 10:01 PM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH v2 2/4] unicast: Add support to send
> CANCEL_UNICAST_TRANSMISSION TLVs.
>
> From: Vincent Cheng
>
> Signed-off-by: Vincent Cheng
> ---
This one looks good to me.
Reviewed-by: Jacob Keller
> unicast_client.c | 50
> unicast_client.h | 8
> 2 files changed, 58 insertions(+)
>
> diff --git a/unicast_client.c b/unicast_client.c
> index 4d6386e..7688814 100644
> --- a/unicast_client.c
> +++ b/unicast_client.c
> @@ -64,6 +64,23 @@ static int attach_request(struct ptp_message *msg, int
> log_period,
> return 0;
> }
>
> +static int attach_cancel(struct ptp_message *msg, uint8_t message_type)
> +{
> + struct cancel_unicast_xmit_tlv *req;
> + struct tlv_extra *extra;
> +
> + extra = msg_tlv_append(msg, sizeof(*req));
> + if (!extra) {
> + return -1;
> + }
> + req = (struct cancel_unicast_xmit_tlv *) extra->tlv;
> + req->type = TLV_CANCEL_UNICAST_TRANSMISSION;
> + req->length = sizeof(*req) - sizeof(req->type) - sizeof(req->length);
> + req->message_type_flags = message_type << 4;
> +
> + return 0;
> +}
> +
> static int unicast_client_announce(struct port *p,
> struct unicast_master_address *dst)
> {
> @@ -563,3 +580,36 @@ int unicast_client_unicast_master_table_received(struct
> port *p, struct ptp_mess
> return ucma ? 1 : 0;
> }
>
> +int unicast_client_tx_cancel(struct port *p,
> + struct unicast_master_address *dst)
> +{
> + struct ptp_message *msg;
> + int err;
> +
> + msg = port_signaling_uc_construct(p, >address,
> >portIdentity);
> + if (!msg) {
> + return -1;
> + }
> + err = attach_cancel(msg, ANNOUNCE);
> + if (err) {
> + goto out;
> + }
> + err = attach_cancel(msg, SYNC);
> + if (err) {
> + goto out;
> + }
> + if (p->delayMechanism != DM_P2P) {
> + err = attach_cancel(msg, DELAY_RESP);
> + if (err) {
> + goto out;
> + }
> + }
> +
> + err = port_prepare_and_send(p, msg, TRANS_GENERAL);
> + if (err) {
> + pr_err("%s: signaling message failed", p->log_name);
> + }
> +out:
> + msg_put(msg);
> + return err;
> +}
> diff --git a/unicast_client.h b/unicast_client.h
> index b24c4eb..bb0f80a 100644
> --- a/unicast_client.h
> +++ b/unicast_client.h
> @@ -93,4 +93,12 @@ int unicast_client_timer(struct port *p);
> int unicast_client_unicast_master_table_received(struct port *p,
>struct ptp_message *m);
>
> +/**
> + * Transmit CANCEL_UNICAST_TRANSMISSION TLV to destination address.
> + * @param p The port in question.
> + * @param dstThe destination address.
> + * @return Zero on success, non-zero otherwise.
> + */
> +int unicast_client_tx_cancel(struct port *p,
> + struct unicast_master_address *dst);
> #endif
> --
> 2.34.1
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 1/4] unicast: Add support to check if message was received from an entry in the unicast master table.
> -Original Message-
> From: vincent.cheng...@renesas.com
> Sent: Sunday, March 13, 2022 10:01 PM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH v2 1/4] unicast: Add support to check if
> message was received from an entry in the unicast master table.
>
> From: Vincent Cheng
>
> Signed-off-by: Vincent Cheng
> ---
> unicast_client.c | 16
> unicast_client.h | 11 +++
> 2 files changed, 27 insertions(+)
>
> diff --git a/unicast_client.c b/unicast_client.c
> index 87d8471..4d6386e 100644
> --- a/unicast_client.c
> +++ b/unicast_client.c
> @@ -547,3 +547,19 @@ int unicast_client_timer(struct port *p)
> unicast_client_set_tmo(p);
> return err;
> }
> +
> +int unicast_client_unicast_master_table_received(struct port *p, struct
> ptp_message *m)
> +{
> + struct unicast_master_address *ucma;
> +
> + if (!unicast_client_enabled(p)) {
> + return 0;
> + }
> + STAILQ_FOREACH(ucma, >unicast_master_table->addrs, list) {
> + if (addreq(transport_type(p->trp), >address,
> >address)) {
> + break;
> + }
> + }
Does STALQ_FOREACH guarantee that ucma is NULL after exiting?
For code clarity I'd rather have a separate variable set set to 1 when addreq
returns true. That is far easier to read, since not every for each iterator
works this way.
> + return ucma ? 1 : 0;
> +}
> +
> diff --git a/unicast_client.h b/unicast_client.h
> index 16e291f..b24c4eb 100644
> --- a/unicast_client.h
> +++ b/unicast_client.h
> @@ -82,4 +82,15 @@ void unicast_client_state_changed(struct port *p);
> */
> int unicast_client_timer(struct port *p);
>
> +/**
> + * Check whether a message was received from an entry in the unicast
> + * master table.
> + * @param p The port in question.
> + * @param m The message in question.
> + * @return One (1) if the message is from an entry in the unicast
> + * master table, or zero otherwise.
> + */
> +int unicast_client_unicast_master_table_received(struct port *p,
> + struct ptp_message *m);
> +
> #endif
The name of the function doesn't quite capture its meaning to me.
Perhaps something like "unicast_message_is_from_master_table_entry"?
I'm ok with the name if Richard is, but thought I'd voice my bikeshed opinion.
> --
> 2.34.1
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 0/4] port: Cancel unicast service when closing port.
> -Original Message- > From: vincent.cheng...@renesas.com > Sent: Sunday, March 13, 2022 10:01 PM > To: linuxptp-devel@lists.sourceforge.net > Subject: [Linuxptp-devel] [PATCH v2 0/4] port: Cancel unicast service when > closing port. > > From: Vincent Cheng > > ptp4l currently does not cancel unicast service on program exit. > This causes problems for subsequent ptp4l session that is using different > masters. > > Below example has debug statements to print out announce master address and > received packet address. > > Start unicast slave session with master 10.64.10.13, and unicast_req_duration > 300. > > ptp4l[682807.352]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[682811.352]: debug: announce master 10.64.10.13 > ptp4l[682812.770]: debug: sk_receive from 10.64.10.13 > ptp4l[682812.810]: debug: sk_receive from 10.64.10.13 > ptp4l[682813.120]: selected local clock 000a35.fffe.002201 as best master > ptp4l[682814.755]: port 1 (eth0): new foreign master 84c807.fffe.10c570-1 > > Exit ptp4l. > > The unicast master continues to send SYNC packets to slave until renewal > period > expires. > > Start unicast same slave, but different master 10.64.10.14. This master is > not > online, so ptp4l should choose local clock as best master. > > However, because there is no checking of received unicast master to configured > unicast table, ptp4l is quite content with packets from previous master > 10.64.10.13. > > ptp4l[682848.858]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[682848.892]: debug: sk_receive from 10.64.10.13 > ... > ptp4l[682850.704]: debug: sk_receive from 10.64.10.13 > ptp4l[682850.751]: debug: sk_receive from 10.64.10.13 > ptp4l[682850.751]: port 1 (eth0): new foreign master 84c807.fffe.10c570-1 > ptp4l[682850.766]: debug: sk_receive from 10.64.10.13 > ... > ptp4l[682852.829]: debug: sk_receive from 10.64.10.13 > ptp4l[682852.858]: debug: announce master 10.64.10.14 > ptp4l[682852.891]: debug: sk_receive from 10.64.10.13 > ptp4l[682854.751]: port 1 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE > ptp4l[682854.766]: debug: sk_receive from 10.64.10.13 > ... > ptp4l[682854.891]: master offset -3269 s0 freq-397 path delay > 4757 > > Add check to ensure a unicast client will check the source address of an > announce > message is from an entry in the unicast master table before adding to foreign > master table. > Add canceling unicast session on exit so that subsequent session is not > polluted > by lingering unicast session traffic. > So with this series, we now fix our program to be nice and stop the session, and we also fix our program to verify that we got a valid unicast address before accepting it. Excellent. > Vincent Cheng (4): > unicast: Add support to check if message was received from an entry in > the unicast master table. > unicast: Add support to send CANCEL_UNICAST_TRANSMISSION TLVs. > port: unicast client - do not add master to foreign master table if > not in the unicast master table. > port: cancel unicast transmission when closing port. > > port.c | 44 +++- > unicast_client.c | 66 > unicast_client.h | 19 ++ > 3 files changed, 128 insertions(+), 1 deletion(-) > > -- > 2.34.1 > > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] phc2sys: Don't exit when reading of PHC fails.
> -Original Message-
> From: Miroslav Lichvar
> Sent: Thursday, March 10, 2022 3:23 AM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH] phc2sys: Don't exit when reading of PHC
> fails.
>
> Reading of the PHC can occasionally fail with some drivers, e.g. the ice
> driver returns -EBUSY when it fails to get a lock. Change do_loop() to
> ignore the error instead of exiting.
>
> Signed-off-by: Miroslav Lichvar
> ---
Yep. Thanks for fixing this. I'd like to clarify why ice does sometimes return
-EBUSY for reviewers on this list.
The ice hardware has a semaphore to protect accesses to the clock register.
Multiple functions might access the clock at the same time. The semaphore
prevents this. If we fail to acquire the semaphore in a short time, we give up
on the gettime function and exit with -EBUSY.
Does the inner call log a debug message? if not perhaps we might want to add
such a debug message to this as well?
Thanks,
Jake
> phc2sys.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/phc2sys.c b/phc2sys.c
> index 15dd689..281ec9d 100644
> --- a/phc2sys.c
> +++ b/phc2sys.c
> @@ -730,7 +730,7 @@ static int do_loop(struct phc2sys_private *priv)
> priv->master->sysoff_method,
> priv->phc_readings,
> , , ) < 0)
> - return -1;
> + continue;
> } else if (priv->master->clkid == CLOCK_REALTIME &&
> clock->sysoff_method >= 0) {
> /* use reversed sysoff */
> @@ -738,7 +738,7 @@ static int do_loop(struct phc2sys_private *priv)
> clock->sysoff_method,
> priv->phc_readings,
> , , ) < 0)
> - return -1;
> + continue;
> offset = -offset;
> ts += offset;
> } else {
> @@ -747,7 +747,7 @@ static int do_loop(struct phc2sys_private *priv)
>clock->clkid,
>priv->phc_readings,
>, , ))
> - return -1;
> + continue;
> }
> update_clock(priv, clock, offset, ts, delay);
> }
> --
> 2.35.1
>
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 1/1] TLV management messages need to be aligned to 16 bits.
On Tue, Mar 08, 2022 at 10:55:14PM +0100, Erez Geva wrote:
> Add reserved octet to the new port hardware clock structure.
> @@ -354,6 +354,7 @@ struct port_hwclock_np {
> struct PortIdentity portIdentity;
> Integer32 phc_index;
> UInteger8 flags;
> + uint8_t reserved;
> } PACKED;
FWIW, there is a code in the {clock,port}_management_fill_response
functions that pads the TLVs to 16 bits:
if (datalen % 2) {
tlv->data[datalen] = 0;
datalen++;
}
If we require the TLV declarations to be correctly padded, it might be
a good idea to replace this code with an assertion or return error to
catch bugs when new TLVs are introduced.
--
Miroslav Lichvar
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
