Re: [Linuxptp-devel] [PATCH v3 4/6] Add a push notification for the CMLDS TLV.
On Tue, 5 Dec 2023 at 08:59, Miroslav Lichvar wrote:
> On Mon, Dec 04, 2023 at 11:25:00PM +0100, Andrew Zaborowski wrote:
> > On Sun, 3 Dec 2023 at 00:39, Richard Cochran
> wrote:
> > > @@ -306,13 +307,15 @@ static void do_set_action(struct pmc *pmc, int
> action, int index, char *str)
> > > "duration %hu "
> > > "NOTIFY_PORT_STATE %3s "
> > > "NOTIFY_TIME_SYNC %3s "
> > > -"NOTIFY_PARENT_DATA_SET %3s ",
> > > +"NOTIFY_PARENT_DATA_SET %3s "
> > > +"NOTIFY_CMLDS %3s ",
> > > ,
> > > onoff_port_state,
> > > onoff_time_status,
> > > -onoff_parent_data_set);
> > > - if (cnt != 4) {
> > > - fprintf(stderr, "%s SET needs 4 values\n",
> > > +onoff_parent_data_set,
> > > +onoff_cmlds);
> > > + if (cnt != 5) {
> > > + fprintf(stderr, "%s SET needs 5 values\n",
> >
> > Doing cnt != 4 && cnt != 5 should just work as sscanf() should stop
> > parsing when it doesn't find NOTIFY_CMLDS and leave onoff_cmlds as
> > "off". Obviously this won't scale as more events are added but it'd
> > keep syntax backwards-compatible for scripts.
>
> Good idea. The PARENT_DATA_SET notification is new too (added after
> 4.1) and I guess there is no reason to require even the original two
> notifications, so change that to "cnt < 1" with "%s SET needs at least
> 1 value", requiring only the duration, which would effectively reset
> all existing notifications?
>
+
>
> --
> 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] [PMC] delay_timeout counter of PortServiceStats unusable
On Wed, 29 Nov 2023 at 15:45, Paz Cohen wrote: > I have noticed that "delay_timeout" returned by pmc with > "PORT_SERVICE_STATS_NP" is always increasing, even when rx delay responses > are arriving as expected. > It appears to happen because code flow does not get to resetting the delay > timeout(FD_DELAY_TIMER), unless poll woke on this fd. The problem is that > the delay_timeout counter is incremented together with the timer resetting. > What I expected is that when a legitimate delay response arrives, the > timer should reset. > This is a developers mailing list. You are welcome to find the error and send a patch to fix it. > If I understand the behavior correctly, then delay response timeouts > cannot be detected by pmc. > PMC is not a detection tool. It just retrieves information from the ptp4l service. If you find a "wrong" value, it probably comes from the ptp4l service itself. Erez > > BR, > Paz > ___ > 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] Add support for DELAY_REQ and SYNC packets RX filters
On Wed, 29 Nov 2023 at 13:09, Miroslav Lichvar wrote: > On Tue, Nov 28, 2023 at 03:34:54PM -0800, Richard Cochran wrote: > > On Tue, Nov 28, 2023 at 12:53:38PM +0100, Miroslav Lichvar wrote: > > > However, timestamping only sync messages has an advantage with very > > > large number of clients as they don't have timestamp each other's > > > delay requets and timestamping of sync messages is more reliable. > > > > Actually, in hardware is it much simpler and more efficient just to > > time stamp every frame. (The reporting can be selectable if the > > application doesn't care about some frame types) > > I think it depends on the hardware design, which impacts its cost. If > all hardware was able to accurately and reliably timestamp all > packets, we wouldn't need PTP. PTP was specifically designed to make > the hardware support as simple/cheap as possible. It separates event > messages from the rest and uses multicast messaging in order to reduce > the required timestamping rate. > Although PTP uses multicast. It is only a multicast MAC address, but it is not a real multicast group. As PTP messages are not forward to all peers as is. So PTP messages are actually unicast messages.using a multicast MAC address. > > Timestamping only sync messages on clients is just another trick to > reduce the required timestamping rate. The hardware can keep just one > timestamp at a time and it doesn't matter that if it takes 20 > milliseconds to read it over MDIO. It's good enough for clients, even > if there is a very large number of them on the same communication > path. > It Makes sense, yet using a PTP events filter is sufficient. The PTP service is a master or client, not both. So the amount of traffic you timestamp does not reduce by using a SYNC/ DELY versa events filter. 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] Add scaledLastGmFreqChange computation
Hi, I did not argue whether it is an error or not. Once an enterprise management TLV is published (by a linuxptp official version). The TLV is a public API. We should avoid changing them. If the case is really bad, we may create a new enterprise management TLV with the corrections. TIME_STATUS_NP was added in september 2012 and published in version 1.1. You can fix calculations of values in the TLV, but not sizes, types, order or *NAMES*. Wireshark should follow IEEE 1588 and linuxptp enterprise management TLVs, not the other way around. Erez On Wed, 29 Nov 2023 at 07:52, Choong, Chwee Lin wrote: > Hi Erez, Richard, > > There's a potential misunderstanding among users who may believe that both > lastGmPhaseChange and scaledLastGmPhaseChange are derived from phase > measurements, with the latter representing a scaled version of the former. > This assumption, particularly evident when they are displayed > simultaneously in the PMC readout > > Additionally, it's worth noting that Wireshark has already addressed a > similar naming discrepancy: > https://www.wireshark.org/lists/wireshark-bugs//201602/msg00662.html > > Thanks > CL > > -Original Message- > From: Richard Cochran > Sent: Tuesday, November 28, 2023 7:42 AM > To: Erez > Cc: Choong, Chwee Lin ; > linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH] Add scaledLastGmFreqChange > computation > > On Mon, Nov 27, 2023 at 10:20:56AM +0100, Erez wrote: > > It is public if you change the printed name in PMC. > > You mean scripts that invoke pmc? > > Yeah, that could cause users' setups to break. > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2] Add support for DELAY_REQ and SYNC packets RX filters
On Tue, 28 Nov 2023 at 12:55, Miroslav Lichvar wrote: > On Sun, Nov 26, 2023 at 11:10:05AM -0800, Richard Cochran wrote: > > The Rx filters are applied globally at the device level, but the PTP > > operates at the application level. This means that the Rx filter are > > shared between applications. And so you can see that one application > > cannot simply change the shared global settings at run time. > > This problem already exists, e.g. with ptpv2-l4-event vs ptpv2-l2-event. > We could say that all hardware that cannot timestamp all packets is > broken, but it's so common that it has to be supported. If the > hardware which cannot timestamp all event messages is very rare, ok, > maybe it's not worth the trouble. > > However, timestamping only sync messages has an advantage with very > large number of clients as they don't have timestamp each other's > delay requets and timestamping of sync messages is more reliable. > PTP traffic by its nature is very low. I do not see any benefit for a filter that supports only client or only master PTP traffic. Perhaps the kernel should add a HWTSTAMP_FILTER_PTP_V2_ALL_EVENT, that supports multiple PTP services on several layers. 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] Add support for DELAY_REQ and SYNC packets RX filters
Hi, Debian builds allow using patches during building of Debian packages. Erez On Tue, 28 Nov 2023 at 00:48, Richard Cochran wrote: > On Mon, Nov 27, 2023 at 10:47:48AM +0300, IlorDash wrote: > > Thanks, Richard, for such a detailed answer! > > I'll try to find another solution to handle it. > > You can always keep your patches for your custom build. After all, it > is open source, free for you to adapt. But I don't want to include > those changes in the main project code base. > > Thanks, > Richard > > > > ___ > 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] Add scaledLastGmFreqChange computation
On Sun, 26 Nov 2023 at 22:07, Richard Cochran wrote: > On Thu, Nov 23, 2023 at 01:39:45PM +0100, Erez wrote: > > On Thu, 23 Nov 2023 at 04:26, Chwee-Lin Choong < > chwee.lin.cho...@intel.com> > > wrote: > > > > > Add the computation for scaledLastGmFreqChange, as specified in > > > IEEE 802.1AS-2020, clause 11.4.4.3.9. This incorporates the > > > necessary logic to calculate scaledLastGmFreqChange and > > > appends the result to the follow-up TLV. > > > > > > In addition, a naming error has been rectified from > > > scaledLastGmPhaseChange to scaledLastGmFreqChange. > > > > > > > It might be an error, but we do not change a public API. > > As some users might depend on it. > > No, this does not break an API/ABI. The name of a field in a header > file is a C language identifier, and it does not exist at run time. > > (Changing the size, type, or position of a field, now THAT would break > the ABI) > It is public if you change the printed name in PMC. Erez > > Thanks, > Richard > > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Add scaledLastGmFreqChange computation
On Thu, 23 Nov 2023 at 04:26, Chwee-Lin Choong
wrote:
> Add the computation for scaledLastGmFreqChange, as specified in
> IEEE 802.1AS-2020, clause 11.4.4.3.9. This incorporates the
> necessary logic to calculate scaledLastGmFreqChange and
> appends the result to the follow-up TLV.
>
> In addition, a naming error has been rectified from
> scaledLastGmPhaseChange to scaledLastGmFreqChange.
>
It might be an error, but we do not change a public API.
As some users might depend on it.
You can add a new management TLV if you find it drastic.
Or just add an explanation in the header where the TLV is defined.
Erez
>
> Signed-off-by: Tan Tee Min
> Signed-off-by: Chwee-Lin Choong
> ---
> clock.c | 59 +
> clock.h | 7 +++
> pmc.c | 4 ++--
> port.c | 5 +++--
> tlv.c | 8
> tlv.h | 4 ++--
> 6 files changed, 73 insertions(+), 14 deletions(-)
>
> diff --git a/clock.c b/clock.c
> index b66dda5..c24d496 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -148,6 +148,7 @@ struct clock {
> int step_window_counter;
> int step_window;
> struct time_zone tz[MAX_TIME_ZONES];
> + struct follow_up_info_tlv clksrc_fup_info;
> };
>
> struct clock the_clock;
> @@ -544,13 +545,15 @@ static int clock_management_fill_response(struct
> clock *c, struct port *p,
> tsn->cumulativeScaledRateOffset =
> (Integer32) (c->status.cumulativeScaledRateOffset +
> c->nrr * POW2_41 - POW2_41);
> - tsn->scaledLastGmPhaseChange =
> c->status.scaledLastGmPhaseChange;
> tsn->gmTimeBaseIndicator = c->status.gmTimeBaseIndicator;
> tsn->lastGmPhaseChange = c->status.lastGmPhaseChange;
> - if (cid_eq(>dad.pds.grandmasterIdentity,
> >dds.clockIdentity))
> + if (cid_eq(>dad.pds.grandmasterIdentity,
> >dds.clockIdentity)) {
> tsn->gmPresent = 0;
> - else
> + tsn->scaledLastGmFreqChange =
> c->clksrc_fup_info.scaledLastGmFreqChange;
> + } else {
> tsn->gmPresent = 1;
> + tsn->scaledLastGmFreqChange =
> c->status.scaledLastGmFreqChange;
> + }
> tsn->gmIdentity = c->dad.pds.grandmasterIdentity;
> datalen = sizeof(*tsn);
> break;
> @@ -1289,6 +1292,7 @@ struct clock *clock_create(enum clock_type type,
> struct config *config,
> c->utc_offset = config_get_int(config, NULL, "utc_offset");
> c->time_source = config_get_int(config, NULL, "timeSource");
> c->step_window = config_get_int(config, NULL, "step_window");
> + memset(>clksrc_fup_info, 0 , sizeof(c->clksrc_fup_info));
>
> if (c->free_running) {
> c->clkid = CLOCK_INVALID;
> @@ -1482,12 +1486,21 @@ struct port *clock_first_port(struct clock *c)
> void clock_follow_up_info(struct clock *c, struct follow_up_info_tlv *f)
> {
> c->status.cumulativeScaledRateOffset =
> f->cumulativeScaledRateOffset;
> - c->status.scaledLastGmPhaseChange = f->scaledLastGmPhaseChange;
> + c->status.scaledLastGmFreqChange = f->scaledLastGmFreqChange;
> c->status.gmTimeBaseIndicator = f->gmTimeBaseIndicator;
> memcpy(>status.lastGmPhaseChange, >lastGmPhaseChange,
>sizeof(c->status.lastGmPhaseChange));
> }
>
> +void clock_set_follow_up_info(struct clock *c, struct follow_up_info_tlv
> *f)
> +{
> + if (cid_eq(>dad.pds.grandmasterIdentity,
> >dds.clockIdentity)) {
> + f->scaledLastGmFreqChange =
> c->clksrc_fup_info.scaledLastGmFreqChange;
> + } else {
> + f->scaledLastGmFreqChange =
> c->status.scaledLastGmFreqChange;
> + }
> +}
> +
> int clock_free_running(struct clock *c)
> {
> return c->free_running ? 1 : 0;
> @@ -1991,6 +2004,42 @@ static int clock_synchronize_locked(struct clock
> *c, double adj)
> return 0;
> }
>
> +void calculate_freq_change(struct clock *c, tmv_t ingress, tmv_t origin)
> +{
> + struct freq_estimator *f = >fest;
> + double ratio;
> +
> + /*
> +* The ratio of the local clock freqency to the master clock
> +* is estimated by:
> +*
> +*(origin_2 - origin_1) / (ingress_2 - ingress_1)
> +*
> +* Both of the origin time estimates include the pa
Re: [Linuxptp-devel] [PATCH] lstab: Update leapfile validity
Hi,
The leap file from IETF was removed.
Seems ftp.nist.gov is no longer available.
And I could not find "leap-seconds.list" on nist.gov
I did find the information in web page:
https://www.nist.gov/pml/time-and-frequency-division/time-realization/leap-seconds
Perhaps we should remove these obsolete URLs?
Erez
On Tue, 21 Nov 2023 at 09:35, Maciek Machnikowski
wrote:
> No leap seconds will happen till 28 June 2024. Update leapfile validity
> accordingly.
> Add a new source of leapsecond file from the IERS.
>
> Signed-off-by: Maciek Machnikowski
> ---
> lstab.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lstab.c b/lstab.c
> index df8cce0..2aa87be 100644
> --- a/lstab.c
> +++ b/lstab.c
> @@ -27,6 +27,8 @@
> *
> * ftp://ftp.nist.gov/pub/time/leap-seconds.list
> *
> + * https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
> + *
> * When updating this table, do not forget to set N_HISTORICAL_LEAPS
> * and the expiration date.
> */
> @@ -51,7 +53,7 @@ struct lstab {
> int length;
> };
>
> -static const uint64_t expiration_date_ntp = 3912710400ULL; /* 28 December
> 2023 */
> +static const uint64_t expiration_date_ntp = 3928521600ULL; /* 24 June
> 2024 */
>
> static const uint64_t offset_table[N_LEAPS * 2] = {
> 2272060800ULL, 10, /* 1 Jan 1972 */
> --
> 2.30.2
>
>
>
> ___
> 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] linuxptp doesn't detect HW timestamp capability of BCM57416
On Fri, 17 Nov 2023 at 16:24, Pham, Calvin via Linuxptp-devel < linuxptp-devel@lists.sourceforge.net> wrote: > Hi Richard, > > I am running Oracle Linux 9.1 in my server which is equipped with > BCM57416. This Broadcom NIC supports IEEE-1588. But when I check if it > supports HW Timestamp, it’s not there. > > > > [root@COTS-DL380Gen11-39 ~]# ethtool -T eth0 > > Time stamping parameters for eth0: > > Capabilities: > > software-transmit > > software-receive > > software-system-clock > > *PTP Hardware Clock: none* > You need PHC (PTP hardware clock) on the NIC, to use PTP. It could be a driver issue. Looking on Broadcom page I see no reference to PTP or IEEE 1588. https://www.broadcom.com/products/ethernet-connectivity/network-adapters/bcm57416-1gbase-t-ic I can not tell you if the NIC supports PTP or not. Anyhow this mailing list is for linuxptp and not for Broadcom's NIC. You should try in forums for Broadcom NICs. Or Linux kernel modules forums. Erez Hardware Transmit Timestamp Modes: none > > Hardware Receive Filter Modes: none > > > > The kernel version is 5.14.0-284.30.0.1.el9_2.x86_64. > > The driver is bnxt_en and I cannot find its version. > > I cannot find the version of ptp module cause it is built-in, and I am > using linuxptp-2.0. > > > > Can you give some help? > > > > Thanks! > > > > Calvin P. > > > > > > > > > ___ > 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] Add support for DELAY_REQ and SYNC packets rx_filter
On Mon, 13 Nov 2023 at 18:49, IlorDash wrote:
> From: Ilya Orazov
>
> Added adv_rx_filter config that allows to send SIOCSHWTSTAMP ioctl with
> HWTSTAMP_FILTER_PTP_XXX_SYNC or HWTSTAMP_FILTER_PTP_XXX_DELAY_REQ
> rx filters based on whether the Device is Slave or Master respectively.
> This Feature is added for all transport levels.
> I’m using Ethernet controller with PTP support, which requires to
> determine which PTP packet on Rx it must timestamp: SYNC or DELAY_REQ
> packets based on whether the device is Slave or Masterrespectively.
Unfortunately, I’ve found out that ptp4l can’t send SIOCSHWTSTAMP ioctl
> with HWTSTAMP_FILTER_PTP_XXX_SYNC or HWTSTAMP_FILTER_PTP_XXX_DELAY_REQ
> rx filters, and sends only EVENT rx filters to device driver.
>
This is by design, not a mistake.
Most controllers allow timestamp all RX packets.
Users usually limit, to save resources.
You can set the values using the 'hwstamp_ctl' tool.
The reason to add this functionality to ptp4l is to allow dynamic change
from
master to slave.
Please update the description to explain properly.
> Device driver can only get info about the current PTP port state
> from ptp4l, because it doesn’t have direct access to it.
>
And this helps?
> I assumed, if these filters are defined in Kernel, they might be used in
>
No need to fix the kernel.
> ptp4l utility to fix this. So I added adv_rx_filter config that allows
> to send SIOCSHWTSTAMP ioctl with HWTSTAMP_FILTER_PTP_XXX_SYNC or
> HWTSTAMP_FILTER_PTP_XXX_DELAY_REQ rx filters for all transport levels.
>
This new feature does make sense.
But no need to talk on "Unfortunately" or "fix the kernel".
Just add explanation on why you can *NOT* use RX timestamp on all PTP
packets.
And explanation on the new feature.
>
> Signed-off-by: Ilya Orazov
> ---
> config.c| 1 +
> port.c | 17 ++
> ptp4l.8 | 8 +++
> ptp4l.c | 1 +
> raw.c | 13 +++
> sk.c| 56 -
> sk.h| 15
> transport.c | 7 ++
> transport.h | 5
> transport_private.h | 3 +++
> udp.c | 14
> udp6.c | 14
> 12 files changed, 148 insertions(+), 6 deletions(-)
>
> diff --git a/config.c b/config.c
> index b104f1b..642b78c 100644
> --- a/config.c
> +++ b/config.c
> @@ -268,6 +268,7 @@ struct config_item config_tab[] = {
> PORT_ITEM_INT("G.8275.portDS.localPriority", 128, 1, UINT8_MAX),
> GLOB_ITEM_INT("gmCapable", 1, 0, 1),
> GLOB_ITEM_ENU("hwts_filter", HWTS_FILTER_NORMAL, hwts_filter_enu),
> + GLOB_ITEM_INT("adv_rx_filter", 0, 0, 1),
> PORT_ITEM_INT("hybrid_e2e", 0, 0, 1),
> PORT_ITEM_INT("ignore_source_id", 0, 0, 1),
> PORT_ITEM_INT("ignore_transport_specific", 0, 0, 1),
> diff --git a/port.c b/port.c
> index 5803cd3..2376925 100644
> --- a/port.c
> +++ b/port.c
> @@ -3526,6 +3526,23 @@ int port_state_update(struct port *p, enum
> fsm_event event, int mdiff)
> p->unicast_state_dirty = true;
> }
> if (next != p->state) {
> + if (sk_adv_rx_filter == 1) {
> + pr_debug("port state update prev %d next %d",
> p->state,
> +next);
> +
> + if ((next == PS_MASTER) || (next ==
> PS_GRAND_MASTER))
> + transport_update_rx_filter(p->trp,
> p->iface,
> + >fda,
> + p->timestamping,
> + true);
> +
> + if (next == PS_UNCALIBRATED)
> + transport_update_rx_filter(p->trp,
> p->iface,
> + >fda,
> + p->timestamping,
> + false);
> + }
> +
> port_show_transition(p, next, event);
> p->state = next;
> port_notify_event(p, NOTIFY_PORT_STATE);
> diff --git a/ptp4l.8 b/ptp4l.8
> index 40c66c2..9d838eb 100644
> --- a/ptp4l.8
> +++ b/ptp4l.8
> @@ -142,6 +142,14 @@ See UNICAST DISCOVERY OPTIONS, below.
>
> .SH PORT OPTIONS
>
> +.TP
> +.B adv_rx_filter
> +Enable support of HWTSTAMP_FILTER_PTP_XX_SYNC and
> HWTSTAMP_FILTER_PTP_XX_DELAY_REQ.
> +Some Ethernet controllers doesn't support PTP event packets,
> +thus they must be provided with correct rx_filter for timestamping
> required packets
> +(SYNC or DELAY_REQ) depends on whether it's Slave or Master respectively.
> +The default is 0 or disabled.
>
Do you suggest using HWTSTAMP_FILTER_PTP_V1?
Or only HWTSTAMP_FILTER_PTP_V2?
> +
> .TP
> .B announceReceiptTimeout
> The number of missed
Re: [Linuxptp-devel] [RFC PATCH 0/1] Support for Port level Perforamnce Monitoring Counters
I think Richard means using the SUBSCRIBE_EVENTS_NP. Adding new events, and make sure the ptp4l sends all the statistics you need together. Erez On Sat, 11 Nov 2023 at 19:02, Luigi 'Comio' Mantellini < luigi.mantell...@gmail.com> wrote: > Thanks for your time. > > What do you mean with "PUSH" message? > > I agree with you in order to keep it simple. > > ciao > > luigi > > > > Il giorno ven 10 nov 2023 alle ore 17:58 Richard Cochran < > richardcoch...@gmail.com> ha scritto: > >> On Fri, Nov 10, 2023 at 07:58:14AM +0100, Luigi 'Comio' Mantellini wrote: >> >> > Using just polling on UDS is a bad idea IMHO because you need to >> capture at >> > the exact same time point all counters of all ports spending a lot of >> > effort and cpu. >> >> So make it into a PUSH message. >> >> > It's better to have the gathering >> > under the hood and a way to inquiry the system. >> >> No, I disagree. It should be done externally, because most people >> don't want or need this. These statistics are a waste of time, and I >> won't make the program more complex just to support silly stuff. >> >> Thanks, >> Richard >> > > > -- > *Luigi 'Comio' Mantellini* > My Professional Profile <http://www.linkedin.com/in/comio> > > *"UNIX is very simple, it just needs a genius to understand its > simplicity." [cit.]* > > ___ > 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/2] Some hardware can't properly timestamp packets with the new PTP header version 2.1. This patch adds legacy_ptp_ver config option that allows advertising of the lega
On Fri, 10 Nov 2023 at 14:05, Maciek Machnikowski
wrote:
> Additionally, forcing PTP minor version to be nonzero causes
> interoperability issues with some legacy grandmasters.
>
> Signed-off-by: Maciek Machnikowski
> ---
> config.c| 1 +
> configs/default.cfg | 1 +
> ptp4l.8 | 5 +
> ptp4l.c | 4
> 4 files changed, 11 insertions(+)
>
> diff --git a/config.c b/config.c
> index b104f1b..f03a9d2 100644
> --- a/config.c
> +++ b/config.c
> @@ -279,6 +279,7 @@ struct config_item config_tab[] = {
> PORT_ITEM_INT("interface_rate_tlv", 0, 0, 1),
> GLOB_ITEM_INT("kernel_leap", 1, 0, 1),
> GLOB_ITEM_STR("leapfile", NULL),
> + GLOB_ITEM_INT("legacy_ptp_ver", 0, 0, 1),
> PORT_ITEM_INT("logAnnounceInterval", 1, INT8_MIN, INT8_MAX),
> PORT_ITEM_INT("logMinDelayReqInterval", 0, INT8_MIN, INT8_MAX),
> PORT_ITEM_INT("logMinPdelayReqInterval", 0, INT8_MIN, INT8_MAX),
> diff --git a/configs/default.cfg b/configs/default.cfg
> index 00429b9..f0cc2c2 100644
> --- a/configs/default.cfg
> +++ b/configs/default.cfg
> @@ -46,6 +46,7 @@ power_profile.2011.networkTimeInaccuracy -1
> power_profile.2017.totalTimeInaccuracy -1
> power_profile.grandmasterID0
> power_profile.version none
> +legacy_ptp_ver 0
>
Perhaps legacy_ptp2_min_ver ?
> #
> # Run time options
> #
> diff --git a/ptp4l.8 b/ptp4l.8
> index 40c66c2..43dbd5e 100644
> --- a/ptp4l.8
> +++ b/ptp4l.8
> @@ -676,6 +676,11 @@ one-second offset slowly by changing the clock
> frequency (unless the
> option is set to correct such offset by stepping).
> Relevant only with software time stamping. The default is 1 (enabled).
>
> +.TP
> +.B legacy_ptp_ver
> +This option forces legacy PTP header version 2.0. May be required on some
> +legacy hardware that expects exact match on PTP header version.
>
The default is 1 for 2.1.
You should be explicit.
> +
> .TP
> .B logging_level
> The maximum logging level of messages which should be printed.
> diff --git a/ptp4l.c b/ptp4l.c
> index c61175b..8eaeaf3 100644
> --- a/ptp4l.c
> +++ b/ptp4l.c
> @@ -192,6 +192,10 @@ int main(int argc, char *argv[])
> sk_tx_timeout = config_get_int(cfg, NULL, "tx_timestamp_timeout");
> sk_hwts_filter_mode = config_get_int(cfg, NULL, "hwts_filter");
>
> + if(config_get_int(cfg, NULL, "legacy_ptp_ver")) {
> + ptp_hdr_ver = PTP_MAJOR_VERSION;
>
This looks bad,
It should be:
legacy_ptp2_min_ver = config_get_int(cfg, NULL, ...
ptp_hdr_ver = (legacy_ptp2_min_ver << 4 | PTP_MAJOR_VERSION);
The default should be 1.
config_get_int() return the configured value or the default value.
> + }
> +
> if (config_get_int(cfg, NULL, "clock_servo") ==
> CLOCK_SERVO_NTPSHM) {
> config_set_int(cfg, "kernel_leap", 0);
> config_set_int(cfg, "sanity_freq_limit", 0);
> --
> 2.30.2
>
>
>
> ___
> 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 5/5] phc2sys: Stop synchronization when ptp4l stops responding.
On Fri, 10 Nov 2023 at 07:55, Richard Cochran wrote: > On Thu, Oct 26, 2023 at 02:40:11PM +0200, Miroslav Lichvar wrote: > > > @@ -942,8 +957,8 @@ static int auto_init_ports(struct domain *domain) > > } > > > > err = pmc_agent_subscribe(domain->agent, 1000, > > - (60 > domain->phc_interval ? > > -60 : domain->phc_interval) * 3); > > + (10 > domain->phc_interval ? > > +10 : domain->phc_interval) * 3); > I think it is better to use MAX(10, domain->phc_interval) Instead of (10 > domain->phc_interval ? 10 : domain->phc_interval) You may add #define MAX(a, b) ((a) > (b) ? (a) : (b)) Erez > Would it simplify things just to change the 180,60 constants > into 30,10 ? > > Thanks, > Richard > > > ___ > 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 2/2] linuxptp: Use ${CC} in incdefs.sh
On Fri, 20 Oct 2023 at 18:35, Luca Fancellu wrote:
>
>
> > On 20 Oct 2023, at 16:57, Erez wrote:
> >
> > Hi,
> >
> > Your statement is correct, but not the implementation.
> > You need to export CC from the makefile, to get
> > CC = $(CROSS_COMPILE)gcc
> > Value.
> > In your patch CC may have a different value.
> >
> > I would use:
> > "
> > CC := $(CROSS_COMPILE)gcc
> > export CC
> > "
> >
> > Yes assign with ":=", see
> https://www.gnu.org/software/make/manual/html_node/Setting.html
> >
> > Erez
>
> Hi Erez,
>
> I think you are right, but your solution doesn’t seems to work either
> (I’ve tried with a dummy Makefile).
>
*variables marked with export are only available to [the shells launched
for] recipe commands* (commands that are part of rules), regrettably *not
to invocations of $(shell ...)*
> In Yocto it is working because Yocto exports CC already when calling make.
>
> But I can do these changes (on top of mine) and it should work:
>
> diff --git a/incdefs.sh b/incdefs.sh
> index 391e63c7fac6..55031657a93e 100755
> --- a/incdefs.sh
> +++ b/incdefs.sh
> @@ -18,6 +18,8 @@
> # with this program; if not, write to the Free Software Foundation, Inc.,
> # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>
> +CC=$1
> +
> #
> # Look for functional prototypes in the C library.
> #
> diff --git a/makefile b/makefile
> index 3e3b8b35fc96..5e1de75834a8 100644
> --- a/makefile
> +++ b/makefile
> @@ -39,7 +39,7 @@ OBJECTS = $(OBJ) hwstamp_ctl.o nsm.o phc2sys.o
> phc_ctl.o pmc.o pmc_agent.o \
> SRC= $(OBJECTS:.o=.c)
> DEPEND = $(OBJECTS:.o=.d)
> srcdir := $(dir $(lastword $(MAKEFILE_LIST)))
> -incdefs := $(shell $(srcdir)/incdefs.sh)
> +incdefs := $(shell $(srcdir)/incdefs.sh "$(CC)")
> version := $(shell $(srcdir)/version.sh $(srcdir))
> VPATH = $(srcdir)
>
> What do you think?
>
How about
$(shell CC=${CC} ./incdefs.sh)
And we can change CC to
CC ?= ...
In case CC comes from the build, like in Yocto and Debian.
Erez
>
> >
> >
> >
> >
> > On Thu, 19 Oct 2023 at 17:10, Luca Fancellu
> wrote:
> > The Makefile is defining CC and incdefs.sh is using
> > ${CROSS_COMPILE}cpp inside it, allowing both to use different
> > compilers depending on what the user pass during make invocation
> > as CC.
> >
> > Align them using ${CC} also inside incdefs.sh
> >
> > Signed-off-by: Luca Fancellu
> > ---
> > incdefs.sh | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/incdefs.sh b/incdefs.sh
> > index a9e94f777f6b..391e63c7fac6 100755
> > --- a/incdefs.sh
> > +++ b/incdefs.sh
> > @@ -27,7 +27,7 @@ user_flags()
> > printf " -D_GNU_SOURCE"
> >
> > # Get list of directories searched for header files.
> > - dirs=$(echo "" | ${CROSS_COMPILE}cpp -Wp,-v 2>&1 >/dev/null |
> grep ^" /")
> > + dirs=$(${CC} -E -Wp,-v -xc /dev/null 2>&1 >/dev/null | grep ^"
> /")
> >
> > # Look for clock_adjtime().
> > for d in $dirs; do
> > --
> > 2.34.1
> >
> >
> >
> > ___
> > Linuxptp-devel mailing list
> > Linuxptp-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] linuxptp: Use ${CC} in incdefs.sh
Hi,
Your statement is correct, but not the implementation.
You need to export CC from the makefile, to get
CC = $(CROSS_COMPILE)gcc
Value.
In your patch CC may have a different value.
I would use:
"
CC *:*= $(CROSS_COMPILE)gcc
export CC
"
Yes assign with ":=", see
https://www.gnu.org/software/make/manual/html_node/Setting.html
Erez
On Thu, 19 Oct 2023 at 17:10, Luca Fancellu wrote:
> The Makefile is defining CC and incdefs.sh is using
> ${CROSS_COMPILE}cpp inside it, allowing both to use different
> compilers depending on what the user pass during make invocation
> as CC.
>
> Align them using ${CC} also inside incdefs.sh
>
> Signed-off-by: Luca Fancellu
> ---
> incdefs.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/incdefs.sh b/incdefs.sh
> index a9e94f777f6b..391e63c7fac6 100755
> --- a/incdefs.sh
> +++ b/incdefs.sh
> @@ -27,7 +27,7 @@ user_flags()
> printf " -D_GNU_SOURCE"
>
> # Get list of directories searched for header files.
> - dirs=$(echo "" | ${CROSS_COMPILE}cpp -Wp,-v 2>&1 >/dev/null | grep
> ^" /")
> + dirs=$(${CC} -E -Wp,-v -xc /dev/null 2>&1 >/dev/null | grep ^" /")
>
> # Look for clock_adjtime().
> for d in $dirs; do
> --
> 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 RESEND v1 2/5] phc_ctl: Add phase command to support ADJ_OFFSET
On Wed, 6 Sept 2023 at 00:56, Rahul Rameshbabu via Linuxptp-devel <
linuxptp-devel@lists.sourceforge.net> wrote:
> Take double precision floating point representation of an offset value in
> seconds. Feed this value to the PHC's phase control keyword.
>
> Signed-off-by: Rahul Rameshbabu
> ---
> phc_ctl.8 | 4
> phc_ctl.c | 55 ---
> 2 files changed, 52 insertions(+), 7 deletions(-)
>
> diff --git a/phc_ctl.8 b/phc_ctl.8
> index 650e661..b10566e 100644
> --- a/phc_ctl.8
> +++ b/phc_ctl.8
> @@ -62,6 +62,10 @@ Adjust the frequency of the PHC clock by the specified
> parts per billion. If no
> argument is provided, it will attempt to read the current frequency and
> report
> it.
> .TP
> +.BI phase " seconds"
> +Pass an amount in seconds to the PHC clock's phase control keyword. This
> +argument is required.
> +.TP
> .BI cmp
> Compare the PHC clock device to CLOCK_REALTIME, using the best method
> available.
> .TP
> diff --git a/phc_ctl.c b/phc_ctl.c
> index db89f01..c5430d8 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -106,13 +106,14 @@ static void usage(const char *progname)
> " specify commands with arguments. Can specify multiple\n"
> " commands to be executed in order. Seconds are read as\n"
> " double precision floating point values.\n"
> - " set [seconds] set PHC time (defaults to time on
> CLOCK_REALTIME)\n"
> - " get get PHC time\n"
> - " adjadjust PHC time by offset\n"
> - " freq [ppb] adjust PHC frequency (default returns
> current offset)\n"
> - " cmp compare PHC offset to CLOCK_REALTIME\n"
> - " capsdisplay device capabilities (default if
> no command given)\n"
> - " wait pause between commands\n"
> + " set [seconds] set PHC time (defaults to time on
> CLOCK_REALTIME)\n"
> + " get get PHC time\n"
> + " adj adjust PHC time by offset\n"
> + " freq [ppb] adjust PHC frequency (default returns
> current offset)\n"
> + " phase pass offset to PHC phase control
> keyword\n"
> + " cmp compare PHC offset to CLOCK_REALTIME\n"
> + " caps display device capabilities (default
> if no command given)\n"
> + " waitpause between commands\n"
> "\n",
> progname);
> }
> @@ -277,6 +278,45 @@ static int do_freq(clockid_t clkid, int cmdc, char
> *cmdv[])
> return 1;
> }
>
> +static int do_phase(clockid_t clkid, int cmdc, char *cmdv[])
> +{
> + double offset_arg;
> + long nsecs;
> + enum parser_result r;
> +
> + if (cmdc < 1 || name_is_a_command(cmdv[0])) {
> + pr_err("phase: missing required time argument");
> + return -2;
> + }
> +
> + /* parse the double time offset argument */
> + r = get_ranged_double(cmdv[0], _arg, -DBL_MAX, DBL_MAX);
> + switch (r) {
> + case PARSED_OK:
> + break;
> + case MALFORMED:
> + pr_err("phase: '%s' is not a valid double", cmdv[0]);
> + return -2;
> + case OUT_OF_RANGE:
> + pr_err("phase: '%s' is out of range.", cmdv[0]);
> + return -2;
> + default:
> + pr_err("phase: couldn't process '%s'", cmdv[0]);
> + return -2;
> + }
> +
> + nsecs = (long)(NSEC_PER_SEC * offset_arg);
> +
> + clockadj_init(clkid);
> + clockadj_set_phase(clkid, nsecs);
>
In the other patch, you test for error here and avoid the following
'pr_notice'.
Why not do the same here?
Erez
> +
> + pr_notice("offset of %lf seconds provided to PHC phase control
> keyword",
> + offset_arg);
> +
> + /* phase offset always consumes one argument */
> + return 1;
> +}
> +
> static int do_caps(clockid_t clkid, int cmdc, char *cmdv[])
> {
> struct ptp_clock_caps caps;
> @@ -399,6 +439,7 @@ static const struct cmd_t all_commands[] = {
> { "get", _get },
> { "adj", _adj },
> { "freq", _freq },
> + { "phase", _phase },
> { "cmp", _cmp },
> { "caps", _caps },
> { "wait", _wait },
> --
> 2.40.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 RESEND v1 3/5] phc_ctl: Add maximum offset capability
On Tue, 5 Sept 2023 at 21:56, Rahul Rameshbabu via Linuxptp-devel <
linuxptp-devel@lists.sourceforge.net> wrote:
> Advertise the maximum offset that can be fed to the PHC phase control
> keyword.
>
Someone already sent this patch, a few months ago.
But now we can find it in the official kernel. :-)
https://elixir.bootlin.com/linux/v6.5/source/include/uapi/linux/ptp_clock.h#L204
Erez
>
> Signed-off-by: Rahul Rameshbabu
> ---
> missing.h | 9 +
> phc_ctl.c | 4
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/missing.h b/missing.h
> index 79a87d4..165a297 100644
> --- a/missing.h
> +++ b/missing.h
> @@ -98,9 +98,9 @@ enum {
> #define PTP_PEROUT_REQUEST2 PTP_PEROUT_REQUEST
> #endif
>
> -#if LINUX_VERSION_CODE < KERNEL_VERSION(5,8,0)
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(6,5,0)
>
> -/* from upcoming Linux kernel version 5.8 */
> +/* from upcoming Linux kernel version 6.5 */
> struct compat_ptp_clock_caps {
> int max_adj; /* Maximum frequency adjustment in parts per
> billon. */
> int n_alarm; /* Number of programmable alarms. */
> @@ -112,12 +112,13 @@ struct compat_ptp_clock_caps {
> int cross_timestamping;
> /* Whether the clock supports adjust phase */
> int adjust_phase;
> - int rsv[12]; /* Reserved for future use. */
> + int max_phase_adj;
> + int rsv[11]; /* Reserved for future use. */
> };
>
> #define ptp_clock_caps compat_ptp_clock_caps
>
> -#endif /*LINUX_VERSION_CODE < 5.8*/
> +#endif /*LINUX_VERSION_CODE < 6.5*/
>
> /*
> * Bits of the ptp_perout_request.flags field:
> diff --git a/phc_ctl.c b/phc_ctl.c
> index c5430d8..a814648 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -355,6 +355,10 @@ static int do_caps(clockid_t clkid, int cmdc, char
> *cmdv[])
> "no information regarding"
> #endif
> );
> +
> + if (caps.max_phase_adj)
> + pr_notice(" %d maximum offset adjustment (ns)\n",
> caps.max_phase_adj);
> +
> return 0;
> }
>
> --
> 2.40.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 RESEND v1 5/5] phc_ctl: Handle errors returned by various clockadj helpers
On Tue, 5 Sept 2023 at 21:55, Rahul Rameshbabu via Linuxptp-devel <
linuxptp-devel@lists.sourceforge.net> wrote:
> Do not print success notices if clockadj operation fails using return
> values provided by the clockadj helpers.
>
Good idea.
>
> Signed-off-by: Rahul Rameshbabu
> ---
> phc_ctl.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/phc_ctl.c b/phc_ctl.c
> index 34d9e0c..e174189 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -232,9 +232,8 @@ static int do_adj(clockid_t clkid, int cmdc, char
> *cmdv[])
> nsecs = (int64_t)(NSEC_PER_SEC * time_arg);
>
> clockadj_init(clkid);
> - clockadj_step(clkid, nsecs);
> -
> - pr_notice("adjusted clock by %lf seconds", time_arg);
> + if (!clockadj_step(clkid, nsecs))
>
I think a (clockadj_step(clkid, nsecs) == 0) is better.
> + pr_notice("adjusted clock by %lf seconds", time_arg);
>
>
You can add else and return -2, clockadj_step() already prints an error
message.
> /* adjustment always consumes one argument */
> return 1;
> @@ -271,8 +270,8 @@ static int do_freq(clockid_t clkid, int cmdc, char
> *cmdv[])
> return -2;
> }
>
> - clockadj_set_freq(clkid, ppb);
> - pr_notice("adjusted clock frequency offset to %lfppb", ppb);
> + if (!clockadj_set_freq(clkid, ppb))
> + pr_notice("adjusted clock frequency offset to %lfppb",
> ppb);
>
Same here.
>
> /* consumed one argument to determine the frequency adjustment
> value */
> return 1;
> @@ -308,10 +307,9 @@ static int do_phase(clockid_t clkid, int cmdc, char
> *cmdv[])
> nsecs = (long)(NSEC_PER_SEC * offset_arg);
>
> clockadj_init(clkid);
> - clockadj_set_phase(clkid, nsecs);
> -
> - pr_notice("offset of %lf seconds provided to PHC phase control
> keyword",
> - offset_arg);
> + if (!clockadj_set_phase(clkid, nsecs))
> + pr_notice("offset of %lf seconds provided to PHC phase
> control keyword",
> + offset_arg);
>
And here
Erez
>
> /* phase offset always consumes one argument */
> return 1;
> --
> 2.40.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] [RFC PATCH 0/1] Support for Port level Perforamnce Monitoring Counters
On Fri, 18 Aug 2023 at 14:36, Luigi Mantellini
wrote:
> Dear All,
>
> Starting from IEEE 1588-2019 Annex J, I'm trying to introduce a Performace
> monitoring Counters.
>
> The standard asks to keep up 98 records (96 for 15min records and 2 for 24h
> records).
>
> I tried to follow a more general approach keeping different circular buffer
> for 15min and 24h (and adding also 1h for test purpose).
>
> The patch need to be split, of course, but it's a starting point to have
> any
> feedbacks.
>
> Starting from config, I introduced 3 port level parameters in order to
> configure the circular buffer sizes/history:
>
> performance_monitor.15m_history (default 0, disabled)
> performance_monitor.1h_history (default 0, disabled)
> performance_monitor.24h_history (default 0, disabled)
>
> The parameters can also be changed using the management TLV PM_CONF_NP.
>
> When at least a pm is enabled, a PM_TIMER is armed (TFD_TIMER_ABSTIME
> aligned
> to 15min).
>
> When the PM_TIMER expires the sample is stored into circolar buffer and a
> notification is sent (NOTIFY_{PM15Mm,PM1H,PM24H}_UPDATE).
>
> The notification generates a {PM15M,PM1H,PM24H}_LAST_NP management message.
>
> A monitor process can receive the update and manage the data model
> according
> the IEEE 1588-2019 Annex J.
>
> In addition to above {PM15M,PM1H,PM24H}_LAST_NP management message, I
> introduced also messages to retrive the CURRENT and the complete HISTORY:
>
> x_LAST_NP Get the last SAVED sample with the delta counters.
> x_CURRENT_NP Get the current (NOT saved yet) sample.
> x_HISTORY_NP Get the complete history of all records.
>
> (where x is PM15M, PM1H or PM24H)
>
> All mamagement messages use the same TLV format.
>
> I already known that the implementation is far to be accettable, and
> should be
> split in more patches.
>
> I ask for any feedbacks. My main issue is the x_HISTORY_NP messages. Using
> a
> 1500 bytes frame there is not enough space to keep an huge history,
> causing a
> frame corruption (bad message). Any idea to handle huge management
> messages?
>
> I also tried to imaginate a x_GET_NP to read a specific item. In this case
> I
> need to put an index vale into the GET message in order to handle the
> answer.
> Unfortunately sent GET messages are empty by construction and I cannot
> prefill with an index value. (WA: use SET?).
>
I think using 'SET' is OK.
On request you put the index as first value and leave the rest of the TLV
with zeroes.
Then respond with the same index and fill the TLV with statistics values.
As I remember, the response of a set can use the same TLV.
>From IEEE 1558-2019 "Table 57 - Values of the actionField"
"SET"
"The PTP management message shall carry a single management TLV.
The managementId field of the TLV indicates the specific information values
that need to be set.
If the data identified by the managementId consists of several fields, the
update shall be considered as an atomic action and the failure to update
any item shall be considered an error in the execution of the SET.
Attempts to set a static or nonconfigurable value shall return a management
error status TLV (see 15.5.4).
TLVs with data definitions that mix configurable and nonconfigurable data
are not permitted.
An addressed PTP Port or PTP Instance shall respond with a PTP management
message with the actionField value set to RESPONSE.
If no error occurs, the TLV in the PTP management message shall contain the
current values of the data identified by the managementId.
If an error occurs, the TLV shall be a management error status TLV."
I understand that the response should use the same TLV.
On both the SET and the RESPONSE, the index value is the same.
Although the standard forbids setting a static or nonconfigurable value.
It also forbids mixing, so what about using only nonconfigurable and
non-static values?
I think we can skip this rule for statistics.
And as the index and the statistics are both nonconfigurable and non
static data. I think we are on safe ground.
Erez
> I will appreciate any comments.
>
> Thanks agian and best regards,
>
> luigi
>
>
>
> Luigi Mantellini (1):
> Add Port Performance Monitor support
>
> config.c | 3 +
> ddt.h | 2 +
> e2e_tc.c | 36 +++
> fd.h | 1 +
> makefile | 2 +-
> msg.h | 2 +-
> notification.h | 3 +
> p2p_tc.c | 36 +++
> pmc.c | 123 +-
> pmc_common.c | 66 +++-
> port.c | 277 -
> port_pm.c | 212 +
> port_pm.h | 141 +
> port_priva
Re: [Linuxptp-devel] [PATCH v2 1/6] Add doubly attached clock support
On Wed, 26 Jul 2023 at 04:39, Richard Cochran
wrote:
> On Tue, Jul 04, 2023 at 12:30:38PM +0200, Stephan Wurm wrote:
>
> > diff --git a/fsm.h b/fsm.h
> > index 857af05..919e934 100644
> > --- a/fsm.h
> > +++ b/fsm.h
> > @@ -31,6 +31,7 @@ enum port_state {
> > PS_PASSIVE,
> > PS_UNCALIBRATED,
> > PS_SLAVE,
> > + PS_PASSIVE_SLAVE, /*according to IEC 62439-3 doubly attached
> clocks*/
>
> NAK. There is no such state in IEEE 1588.
>
I Wonder, I thought we already excluded this 2 month ago. :-(
>
> > PS_GRAND_MASTER, /*non-standard extension*/
> > };
> >
> > @@ -53,6 +54,7 @@ enum fsm_event {
> > EV_RS_GRAND_MASTER,
> > EV_RS_SLAVE,
> > EV_RS_PASSIVE,
> > + EV_RS_PSLAVE, /*according to IEC 62439-3 doubly attached clocks*/
>
> There is no such recommended state event.
>
> If you "profile" invents a new BMCA, then you should implement it
> explictily.
>
> We have ptp_fsm() and ptp_slave_fsm(), and you really should add
> ptp_iec_whatevet_fsm() rather than hacking in specialy cases to the
> 1588 state machines.
>
> Thanks,
> Richard
>
>
> ___
> 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] PHC Index is invalid in phc2sys when ptp4l is in free_running mode.
On Sun, 23 Jul 2023 at 21:28, Saravanan Arunachalam via Linuxptp-devel <
linuxptp-devel@lists.sourceforge.net> wrote:
> The pmc call to ptp4l to get phc_index returns invalid value since in
> free_running mode, ptp4l sets phc_index to -1. Adding a socket call in
> phc2sys to get the phc_index.
>
Why is it a problem?
And why do you think phc2sys needs to fix it?
> Signed-off-by: Saravanan Arunachalam
> ---
> phc2sys.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/phc2sys.c b/phc2sys.c
> index 19e8012..6df9fef 100644
> --- a/phc2sys.c
> +++ b/phc2sys.c
> @@ -299,6 +299,7 @@ static void clock_reinit(struct phc2sys_private *priv,
> struct clock *clock,
> {
> int err = -1, phc_index = -1, phc_switched = 0, timestamping;
> char iface[IFNAMSIZ], phc_device[19];
> + struct sk_ts_info ts_info;
> enum port_state state;
> struct port *p;
> clockid_t clkid = CLOCK_INVALID;
> @@ -323,6 +324,10 @@ static void clock_reinit(struct phc2sys_private
> *priv, struct clock *clock,
> free(clock->device);
> clock->device = strdup(iface);
> }
> + if (phc_index < 0) {
> + sk_get_ts_info(iface, _info);
> + phc_index = ts_info.phc_index;
> + }
> /* Check if phc index changed */
> if (clock->phc_index != phc_index) {
> snprintf(phc_device, sizeof(phc_device),
> "/dev/ptp%d",
> @@ -838,6 +843,7 @@ static int phc2sys_recv_subscribed(void *context,
> struct ptp_message *msg,
> static int auto_init_ports(struct phc2sys_private *priv, int add_rt)
> {
> int err, number_ports, phc_index, timestamping;
> + struct sk_ts_info ts_info;
> enum port_state state;
> char iface[IFNAMSIZ];
> struct clock *clock;
> @@ -887,6 +893,10 @@ static int auto_init_ports(struct phc2sys_private
> *priv, int add_rt)
> /* ignore ports with software time stamping */
> continue;
> }
> + if (phc_index < 0) {
> + sk_get_ts_info(iface, _info);
> + phc_index = ts_info.phc_index;
> + }
> port = port_add(priv, i, iface, phc_index);
> if (!port)
> return -1;
> --
> 2.20.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] G.8275.2 after clearing fault
On Tue, 11 Jul 2023 at 17:28, Vladimir Yakovlev via Linuxptp-devel <
linuxptp-devel@lists.sourceforge.net> wrote:
> In current version, when port fault occurs, unicast service in G.8275.2
> mode will lock up.
>
> When i disconnect cable between master and slave, and reconnect it back,
> master stops sending messages.
>
> Series of events occurs:
> 1. unicast_service_rearm_timer rearms timer, but it can skip execution if
> port fault occurs.
> 2. next time ptp client connects, unicast_service_add will check client
> list and find it in itmp->clients list, so it does not arm timer.
> 3. unicast_service_timer will not fire
>
> Master will receive and process unicast_service_extend messages, but does
> not send announce and sync.
>
That looks like an ugly workaround.
1. The clear seems to apply to slaves as well. Is that necessary?
2. Why is that a problem at all, what is the root problem?
Do you have other traffic? Are you using any link detection protocols
like LLDP?
https://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
3. PS_FAULTY, is a detection for several errors.
If you wish to detect disconnected cable, you should add a new handler
that captures the *RTMGRP_LINK *events and issues a link down event.
https://man7.org/linux/man-pages/man7/netlink.7.html
The netlink link up/down events are a bit problematic as there might be
false events that require a more delicate handling to filter them.
You might need a link detection protocol like LLDP.
Erez
> I used this patch to solve a problem. It clears the client list, if port
> goes to faulty state.
>
That sounds like a daemon restart.
>
> Index: linuxptp-2.0/port.c
> ===
> --- linuxptp-2.0.orig/port.c
> +++ linuxptp-2.0/port.c
> @@ -2976,6 +2976,7 @@ int port_state_update(struct port *p, en
> if (PS_FAULTY == next) {
> struct fault_interval i;
> fault_interval(p, last_fault_type(p), );
> + unicast_service_clear_clients(p);
> if (clear_fault_asap()) {
> pr_notice("port %hu: clearing fault immediately", portnum(p));
> next = p->state_machine(next, EV_FAULT_CLEARED, 0);
> Index: linuxptp-2.0/unicast_service.c
> ===
> --- linuxptp-2.0.orig/unicast_service.c
> +++ linuxptp-2.0/unicast_service.c
> @@ -378,6 +378,23 @@ void unicast_service_cleanup(struct port
> free(p->unicast_service);
> }
>
> +void unicast_service_clear_clients(struct port *p)
> +{
> + struct unicast_service_interval *itmp, *inext;
> + struct unicast_client_address *ctmp, *cnext;
> +
> + if (!p->unicast_service) {
> + return;
> + }
> + LIST_FOREACH_SAFE(itmp, >unicast_service->intervals, list, inext) {
> + LIST_FOREACH_SAFE(ctmp, >clients, list, cnext) {
> + LIST_REMOVE(ctmp, list);
> + free(ctmp);
> + }
> + LIST_REMOVE(itmp, list);
> + }
> +}
> +
> int unicast_service_deny(struct port *p, struct ptp_message *m,
> struct tlv_extra *extra)
> {
> Index: linuxptp-2.0/unicast_service.h
> ===
> --- linuxptp-2.0.orig/unicast_service.h
> +++ linuxptp-2.0/unicast_service.h
> @@ -87,4 +87,6 @@ void unicast_service_remove(struct port
> */
> int unicast_service_timer(struct port *p);
>
> +void unicast_service_clear_clients(struct port *p);
> +
> #endif
> ___
> 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] PTP4L over IPv6 doesn't converge clock
On Mon, 10 Jul 2023 at 04:08, Vladimir Dubrovsky wrote: > Hello Erez, > > Thank you for your time. > > I think the problem is not in Ethernet driver, because all applications > over IPv6 work fine, at least I am not aware of a problem. PTP over IPv4 > works fine as well. > Your conclusion is wrong. As time-stamps and PTP have a separate handling in the Ethernet driver. Other IPv6 applications do not indicate if PTP IPv6 works or not in the Ethernet driver. > The problem is only in PTP over IPv6, and the problem is on receive side, > because I decoded packets in WireShark and I see reasonable time stamps. I > think somehow PTP extracts wrong time stamps. I agree it can > As far as I know, you can not see the TX time-stamp in wireshark, as they are sent in a separate SKB. You should not conclude the PTP state based on wireshark. I use wireshark to see if PTP packets pass from side to side, i.e. the 2 peers are connected. It is better to look at ptp4l 's own log to understand what happens on the PTP itself. > be misconfiguration in PTP or Linux kernel or something else. If you tell > me what information you need I will send it to you. I just don’t know what > can be needed. > Please send it to the group, there are other engineers in the group that might find the proper solution. The ptp4l configuration and the command line used to start ptp4l. A description of your network. Are m1 and m2 connected directly, or through a switch? A short description of the Linux you use. Does the ptp4l come from the Linux distribution or did you build it from source. And the ptp4l log (for 2 to 3 seconds, and errors if you see). Do not send long logs, we will not read it anyway. Is the Linux you use is vanille or is it a vendor kernel? What Ethernet driver do you use with ptp4? You can put in a compressed archive to save space. Erez Thank you. > > Vladimir > > > Vladimir Dubrovsky | Lead Firmware Engineer > Phone: 201‑367‑6695 > Ext: 12422 > Email: vdubrov...@crestron.com > Crestron Electronics, Inc. > 22 Link Drive, Rockleigh, NJ 07647 > [image: Crestron] <https://www.crestron.com/> > CONFIDENTIALITY NOTICE: This e-mail message and any attachments may > contain confidential and/or privileged information and is solely for the > use of the intended recipients. Any unauthorized review, use, disclosure, > or distribution is strictly prohibited. If you have received this message > in error, please promptly notify the sender, and destroy all copies of the > message and any attachments. > > *From:* Erez > *Sent:* Saturday, July 08, 2023 9:36 AM > *To:* Vladimir Dubrovsky > *Cc:* linuxptp-devel@lists.sourceforge.net > *Subject:* Re: [Linuxptp-devel] PTP4L over IPv6 doesn't converge clock > > > > Hi, There are 2 types of time-stamps RX and TX Both are retrieved in the > msghdr of https: //man7. org/linux/man-pages/man3/recvmsg. 3p. html The RX > time-stamp comes with the same message that contains the received packet. > The TX is received with > > ZjQcmQRYFpfptBannerStart > > *This Message Is From an Untrusted Sender * > > You have not previously corresponded with this sender. Please use proper > judgment and caution when opening attachments, clicking links, or > responding to this email. > > ZjQcmQRYFpfptBannerEnd > > Hi, > > > > There are 2 types of time-stamps > > RX and TX > > Both are retrieved in the msghdr of > > https://man7.org/linux/man-pages/man3/recvmsg.3p.html > <https://urldefense.com/v3/__https:/man7.org/linux/man-pages/man3/recvmsg.3p.html__;!!PkykpUBa!Q7GcYl1lDd99tGa7LAsVmwKBZQMFhfSFnATrvhuIKodDXYqGCso13hiCRsbO-3SF35hHKD8ws05CskBAxc3b3g$> > > > > The RX time-stamp comes with the same message that contains the received > packet. > > The TX is received with a message on the error queue after the packet is > sent in the vendor Ethernet driver. > > > > RX time-stamp can be applied to all packets or only PTP (with proper > configuration). > > The TX time-stamp is usually reserved for PTP packets. > > ptp4l can configure your kermel/vendor Ethernet driver. > > > > The mechanizm is identical to all sockets/network layers (raw, ipv4, ipv6) > > in ptp4l and in the kernel netlink (layer 2), > > It fills the message header with the time-stamps in the same manner. > > > > However the mechanism relies on the vendor Ethernet driver (module) to > pass the time-stamp to the net-link on TX time-stamp, and add the > time-stamp to the Linux SKB on RX time-stamp. > > > > According to your description, I would first look in the vendor Ethernet > driver. > > First run with IPv4 and find the RX and TX time stamps. > > And then switch to IPv6. > > > > But there could als
Re: [Linuxptp-devel] PTP4L over IPv6 doesn't converge clock
Hi, There are 2 types of time-stamps RX and TX Both are retrieved in the msghdr of https://man7.org/linux/man-pages/man3/recvmsg.3p.html The RX time-stamp comes with the same message that contains the received packet. The TX is received with a message on the error queue after the packet is sent in the vendor Ethernet driver. RX time-stamp can be applied to all packets or only PTP (with proper configuration). The TX time-stamp is usually reserved for PTP packets. ptp4l can configure your kermel/vendor Ethernet driver. The mechanizm is identical to all sockets/network layers (raw, ipv4, ipv6) in ptp4l and in the kernel netlink (layer 2), It fills the message header with the time-stamps in the same manner. However the mechanism relies on the vendor Ethernet driver (module) to pass the time-stamp to the net-link on TX time-stamp, and add the time-stamp to the Linux SKB on RX time-stamp. According to your description, I would first look in the vendor Ethernet driver. First run with IPv4 and find the RX and TX time stamps. And then switch to IPv6. But there could also be a simple misconfiguration of your ptp4l or your system. You did not provide enough information to defer. Erez On Fri, 7 Jul 2023 at 20:46, Vladimir Dubrovsky via Linuxptp-devel < linuxptp-devel@lists.sourceforge.net> wrote: > Hello, > > I have a problem with ptp4l working with IPv6 messages. > > We use Linux version 4.19.0+ and ptp4l version 3.1. > > Everything works fine with PTP over IPv4. However when I run PTP over IPv6 > I see that clock can’t converge. I checked messages in WireShark, > everything looks reasonable. I run PTP with “- 6” option for IPv6. > > My feeling is PTP doesn’t read timestamp from IPv6 message properly. > > Do you have any idea what can be a problem or how can I debug the case? > > Thank you. > > > Vladimir Dubrovsky | Lead Firmware Engineer > Phone: 201‑367‑6695 > Ext: 12422 > Email: vdubrov...@crestron.com > Crestron Electronics, Inc. > 22 Link Drive, Rockleigh, NJ 07647 > [image: Crestron] <https://www.crestron.com/> > CONFIDENTIALITY NOTICE: This e-mail message and any attachments may > contain confidential and/or privileged information and is solely for the > use of the intended recipients. Any unauthorized review, use, disclosure, > or distribution is strictly prohibited. If you have received this message > in error, please promptly notify the sender, and destroy all copies of the > message and any attachments. > ___ > 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 v4 4/4] phc_ctl: add get_pins_cfg command to display pin functions
On Mon, 26 Jun 2023 at 21:04, Jacob Keller wrote:
> Add a new function to phc_ctl to display the devices pin configuration
> data. First, obtain the device capabilities to determine the number of
> pins. Then, for each pin, print the name, function, and channel
> information.
>
> Signed-off-by: Jacob Keller
> ---
> missing.h | 5 +
> phc.c | 8 +++
> phc.h | 13 +++
> phc_ctl.c | 66 +++
> 4 files changed, 92 insertions(+)
>
> diff --git a/missing.h b/missing.h
> index 9b37dc258c0f..4a71307169ad 100644
> --- a/missing.h
> +++ b/missing.h
> @@ -240,10 +240,15 @@ struct ptp_pin_desc {
> unsigned int rsv[5];
> };
>
> +#define PTP_PIN_GETFUNC_IOWR(PTP_CLK_MAGIC, 6, struct ptp_pin_desc)
> #define PTP_PIN_SETFUNC_IOW(PTP_CLK_MAGIC, 7, struct ptp_pin_desc)
>
> #endif /*!PTP_PIN_SETFUNC*/
>
> +#ifndef PTP_PIN_GETFUNC2
> +#define PTP_PIN_GETFUNC2 _IOWR(PTP_CLK_MAGIC, 15, struct ptp_pin_desc)
> +#endif
> +
> #ifndef PTP_PIN_SETFUNC2
> #define PTP_PIN_SETFUNC2 _IOW(PTP_CLK_MAGIC, 16, struct ptp_pin_desc)
> #endif
> diff --git a/phc.c b/phc.c
> index 4491a91d55f0..11ca23a46cec 100644
> --- a/phc.c
> +++ b/phc.c
> @@ -108,6 +108,14 @@ int phc_number_pins(clockid_t clkid)
> return caps.n_pins;
> }
>
> +int phc_pin_getfunc(clockid_t clkid, struct ptp_pin_desc *desc)
> +{
> + int err = ioctl(CLOCKID_TO_FD(clkid), PTP_PIN_GETFUNC, desc);
> + if (err)
> + fprintf(stderr, "failed to set pin configuration, error:
> %m\n");
> + return err;
> +}
> +
> int phc_pin_setfunc(clockid_t clkid, struct ptp_pin_desc *desc)
> {
> int err = ioctl(CLOCKID_TO_FD(clkid), PTP_PIN_SETFUNC, desc);
> diff --git a/phc.h b/phc.h
> index 830e002a8690..064d29bf36e0 100644
> --- a/phc.h
> +++ b/phc.h
> @@ -66,6 +66,19 @@ int phc_max_adj(clockid_t clkid);
> */
> int phc_number_pins(clockid_t clkid);
>
> +/**
> + * Reads configuration of a pin of a PTP hardware clock device.
> + *
> + * @param clkid A clock ID obtained using phc_open().
> + *
> + * @param desc Pointer to a pin descriptor with the 'index' field set.
> On
> + * success, the rest of the structure is updated with the
> + * current pin configuration.
> + *
> + * @return Zero on success, non-zero otherwise.
> + */
> +int phc_pin_getfunc(clockid_t clkid, struct ptp_pin_desc *desc);
> +
> /**
> * Configures a pin of a PTP hardware clock device.
> *
> diff --git a/phc_ctl.c b/phc_ctl.c
> index d61d27d8f632..bb5337c14de7 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -113,6 +113,7 @@ static void usage(const char *progname)
> " freq [ppb] adjust PHC frequency (default returns
> current offset)\n"
> " cmp compare PHC offset to CLOCK_REALTIME\n"
> " capsdisplay device capabilities (default if
> no command given)\n"
> + " get_pins_cfgdisplay device pins configuration\n"
> " wait pause between commands\n"
> "\n",
> progname);
> @@ -319,6 +320,70 @@ static int do_caps(clockid_t clkid, int cmdc, char
> *cmdv[])
> return 0;
> }
>
> +static const char *pin_func_string(unsigned int func)
> +{
> + switch (func) {
> + /* PTP_PF_NONE is already checked by the caller */
> + case PTP_PF_EXTTS:
> + return "external timestamping";
> + case PTP_PF_PEROUT:
> + return "periodic output";
> + case PTP_PF_PHYSYNC:
> + return "phy sync";
> + default:
> + return "unknown function";
> + }
> +}
> +
> +static int do_get_pins_cfg(clockid_t clkid, int cmdc, char *cmdv[])
> +{
> + struct ptp_pin_desc pin_desc;
> + unsigned int index;
> + int n_pins;
> +
> + if (clkid >= 0) {
> + pr_warning("The provided clock is not a PHC device.");
> + return 0;
> + }
> +
> + n_pins = phc_number_pins(clkid);
> + if (n_pins == 0) {
> + pr_notice("device has no configurable pins");
> + return (0);
>
For the record, it is not that important.
Richard can fix it before applying.
I just like consistency.
Above you return "0"
And here "(0)"
Erez
> + }
> +
> + pr_notice("device has %d configurable input/output pins",
Re: [Linuxptp-devel] [PATCH v3 3/3] phc_ctl: add get_pins_cfg command to display pin functions
On Fri, 23 Jun 2023 at 19:03, Jacob Keller wrote:
>
>
> On 6/23/2023 2:08 AM, Erez wrote:
> > On Fri, 23 Jun 2023 at 09:07, Jacob Keller
> wrote:
> >
> >> Add a new function to phc_ctl to display the devices pin configuration
> >> data. First, obtain the device capabilities to determine the number of
> >> pins. Then, for each pin, print the name, function, and channel
> >> information.
> >>
> >> Signed-off-by: Jacob Keller
> >> ---
> >> missing.h | 5 +
> >> phc.c | 10 +
> >> phc.h | 13 +++
> >> phc_ctl.c | 67 +++
> >> 4 files changed, 95 insertions(+)
> >>
> >> diff --git a/missing.h b/missing.h
> >> index 9b37dc258c0f..4a71307169ad 100644
> >> --- a/missing.h
> >> +++ b/missing.h
> >> @@ -240,10 +240,15 @@ struct ptp_pin_desc {
> >> unsigned int rsv[5];
> >> };
> >>
> >> +#define PTP_PIN_GETFUNC_IOWR(PTP_CLK_MAGIC, 6, struct ptp_pin_desc)
> >> #define PTP_PIN_SETFUNC_IOW(PTP_CLK_MAGIC, 7, struct ptp_pin_desc)
> >>
> >> #endif /*!PTP_PIN_SETFUNC*/
> >>
> >> +#ifndef PTP_PIN_GETFUNC2
> >> +#define PTP_PIN_GETFUNC2 _IOWR(PTP_CLK_MAGIC, 15, struct
> ptp_pin_desc)
> >> +#endif
> >> +
> >> #ifndef PTP_PIN_SETFUNC2
> >> #define PTP_PIN_SETFUNC2 _IOW(PTP_CLK_MAGIC, 16, struct ptp_pin_desc)
> >> #endif
> >> diff --git a/phc.c b/phc.c
> >> index fe8c5eccabda..879a008bd392 100644
> >> --- a/phc.c
> >> +++ b/phc.c
> >> @@ -108,6 +108,16 @@ int phc_number_pins(clockid_t clkid)
> >> return caps.n_pins;
> >> }
> >>
> >> +int phc_pin_getfunc(clockid_t clkid, struct ptp_pin_desc *desc)
> >> +{
> >> + int err = ioctl(CLOCKID_TO_FD(clkid), PTP_PIN_GETFUNC2, desc);
> >>
> >
> > At the moment PTP_PIN_GETFUNC2 do not provide any additional information,
> > We can skip it
> >
> >
>
> Using PTP_PIN_GETFUNC2 enforces that we get zeros for reserved fields
> where as using PTP_PIN_GETFUNC would give us potential garbage data in
> the reserved fields. I think its worth using PTP_PIN_GETFUNC2 now for
> that reason alone, even if we don't rely on this.
>
> We will fall back to using PTP_PIN_GETFUNC on older kernels at a slight
> increase on cost here but that should be negligible.
>
> Yes right now the two behave (mostly) identically with PTP_PIN_GETFUNC2
> enforcing reserved fields are zero, so it would cause an error if we
> didn't already memset the desc structure, where as PTP_PIN_GETFUNC would
> silently zero out those fields for us automatically.
>
> I can drop this part if everyone agrees that its not worth it, but I
> felt that enabling this now would make it easier to use the new versions
> in the future when necessary.
>
As I wrote in the other mail.
The application is NOT a kernel verification tool.
If the reserve fields are not used.
I see no point in using PTP_PIN_GETFUNC2/PTP_PIN_SETFUNC2 at the moment.
>
> >>
> >> +static const char *pin_func_string(unsigned int func)
> >> +{
> >> + switch (func) {
> >> + case PTP_PF_NONE:
> >> + return "no function";
> >>
> >
> > We already filter PTP_PF_NONE in do_get_pins_cfg().
> > As it is a static function, you can skip it here.
> > The default tag will catch missing values for the compiler. So no
> > compilation warnings.
> > Simply leave a note here, that we already filter it.
> >
>
> I guess no one else uses this function so thats reasonable.
>
+1
>
> >
> >> + case PTP_PF_EXTTS:
> >> + return "external timestamping";
> >> + case PTP_PF_PEROUT:
> >> + return "periodic output";
> >> + case PTP_PF_PHYSYNC:
> >> + return "phy sync";
> >> + default:
> >> + return "unknown function";
> >> + }
> >> +}
> >> +
> >> +static int do_get_pins_cfg(clockid_t clkid, int cmdc, char *cmdv[])
> >> +{
> >> + struct ptp_pin_desc pin_desc;
> >> + unsigned int index;
> >> + int n_pins;
> >> +
> >> + if (clkid == CLOCK_REALTIME) {
> >>
> >
> > All PHC are negative values, while the system clock uses positive values
> > (for the different variations).
> > It is better to check "(clkid >= 0)".
> > As the file description to clock ID formula is a public formula, this
> will
> > not change.
> > We might use other system clock variants in the future.
> >
> >
>
> Fair.
>
+1
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 1/3] phc: dynamically try PTP_PIN_SETFUNC2 and fallback to PTP_PIN_SETFUNC
On Fri, 23 Jun 2023 at 18:55, Jacob Keller wrote:
>
>
> On 6/23/2023 1:44 AM, Erez wrote:
> > On Fri, 23 Jun 2023 at 09:07, Jacob Keller
> wrote:
> >
> >> The phc library currently selects whether to use PTP_PIN_SETFUNC2 over
> >> PTP_PIN_SETFUNC based on whether the kernel headers it is compiled
> against
> >> have the PTP_PIN_SETFUNC2 defined.
> >>
> >> This means that the use of PTP_PIN_SETFUNC vs PTP_PIN_SETFUNC2 depends
> on
> >> whether the headers we compiled against have the appropriate definition,
> >> but not whether the running kernel supports the new ioctl.
> >>
> >> Fix this to use dynamic fallback. If PTP_PIN_SETFUNC2 returns -ENOTTY,
> then
> >> try PTP_PIN_SETFUNC. This approach will work on a wider range of kernels
> >> and doesn't need the headers to be up to date.
> >>
> >
> >
> > I look in the kernel
> >
> https://elixir.bootlin.com/linux/v6.4-rc7/source/drivers/ptp/ptp_chardev.c#L399
> > Using PTP_PIN_SETFUNC2 at the moment does not add anything.
> >
> > Perhaps in the future.
> > It is better to checkthe ptp_pin_desc structure
> >
> https://elixir.bootlin.com/linux/v6.4-rc7/source/include/uapi/linux/ptp_clock.h#L174
> > Once we have new properties there.
> > Then we can use PTP_PIN_SETFUNC2.
> >
> > Erez
> >
>
> The reason to use PTP_PIN_SETFUNC2 is that if it *does* exist we *know*
> the kernel sanitized the data structures and returned zeros in the
> reserved fields.
>
And we do not use these reserved fields.
Once the kernel uses these reserved fields, then it will be interesting.
>
> Obviously currently we aren't using any reserved fields so the behavior
> should be identical.
>
> If we use the old command the kernel sanitizes the reserved fields from
> user space as zero and forwards that to the drivers:
>
> See:
>
> > if ((pd.rsv[0] || pd.rsv[1] || pd.rsv[2]
> > || pd.rsv[3] || pd.rsv[4])
> > && cmd == PTP_PIN_SETFUNC2) {
> > err = -EINVAL;
> > break;
> > } else if (cmd == PTP_PIN_SETFUNC) {
> > pd.rsv[0] = 0;
> > pd.rsv[1] = 0;
> > pd.rsv[2] = 0;
> > pd.rsv[3] = 0;
> > pd.rsv[4] = 0;
> > }
>
> and note the checks for PTP_PIN_SETFUNC2 and PTP_PIN_SETFUNC.
>
> This *is* a behavioral difference and I think we should prefer the
> PTP_PIN_SETFUNC2 operation where its available.
>
It is not a different behavior as we zero the structure before we call and
ignore the reserved fields after we get the reply.
It is a waste of time to use PTP_PIN_SETFUNC2 at the moment as long as the
reserved fields are not used.
The application is NOT a kernel verification tool!
Erez
> Unlike PTP_GETCAPS which is EXACTLY the same as PTP_GETCAPS2 I think its
> important to use these variants.
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 3/3] phc_ctl: add get_pins_cfg command to display pin functions
On Fri, 23 Jun 2023 at 09:07, Jacob Keller wrote:
> Add a new function to phc_ctl to display the devices pin configuration
> data. First, obtain the device capabilities to determine the number of
> pins. Then, for each pin, print the name, function, and channel
> information.
>
> Signed-off-by: Jacob Keller
> ---
> missing.h | 5 +
> phc.c | 10 +
> phc.h | 13 +++
> phc_ctl.c | 67 +++
> 4 files changed, 95 insertions(+)
>
> diff --git a/missing.h b/missing.h
> index 9b37dc258c0f..4a71307169ad 100644
> --- a/missing.h
> +++ b/missing.h
> @@ -240,10 +240,15 @@ struct ptp_pin_desc {
> unsigned int rsv[5];
> };
>
> +#define PTP_PIN_GETFUNC_IOWR(PTP_CLK_MAGIC, 6, struct ptp_pin_desc)
> #define PTP_PIN_SETFUNC_IOW(PTP_CLK_MAGIC, 7, struct ptp_pin_desc)
>
> #endif /*!PTP_PIN_SETFUNC*/
>
> +#ifndef PTP_PIN_GETFUNC2
> +#define PTP_PIN_GETFUNC2 _IOWR(PTP_CLK_MAGIC, 15, struct ptp_pin_desc)
> +#endif
> +
> #ifndef PTP_PIN_SETFUNC2
> #define PTP_PIN_SETFUNC2 _IOW(PTP_CLK_MAGIC, 16, struct ptp_pin_desc)
> #endif
> diff --git a/phc.c b/phc.c
> index fe8c5eccabda..879a008bd392 100644
> --- a/phc.c
> +++ b/phc.c
> @@ -108,6 +108,16 @@ int phc_number_pins(clockid_t clkid)
> return caps.n_pins;
> }
>
> +int phc_pin_getfunc(clockid_t clkid, struct ptp_pin_desc *desc)
> +{
> + int err = ioctl(CLOCKID_TO_FD(clkid), PTP_PIN_GETFUNC2, desc);
>
At the moment PTP_PIN_GETFUNC2 do not provide any additional information,
We can skip it
> + if (err == -ENOTTY)
> + err = ioctl(CLOCKID_TO_FD(clkid), PTP_PIN_GETFUNC, desc);
> + if (err)
> + fprintf(stderr, "failed to set pin configuration, error:
> %m\n");
> + return err;
> +}
> +
> int phc_pin_setfunc(clockid_t clkid, struct ptp_pin_desc *desc)
> {
> int err = ioctl(CLOCKID_TO_FD(clkid), PTP_PIN_SETFUNC2, desc);
> diff --git a/phc.h b/phc.h
> index 830e002a8690..064d29bf36e0 100644
> --- a/phc.h
> +++ b/phc.h
> @@ -66,6 +66,19 @@ int phc_max_adj(clockid_t clkid);
> */
> int phc_number_pins(clockid_t clkid);
>
> +/**
> + * Reads configuration of a pin of a PTP hardware clock device.
> + *
> + * @param clkid A clock ID obtained using phc_open().
> + *
> + * @param desc Pointer to a pin descriptor with the 'index' field set.
> On
> + * success, the rest of the structure is updated with the
> + * current pin configuration.
> + *
> + * @return Zero on success, non-zero otherwise.
> + */
> +int phc_pin_getfunc(clockid_t clkid, struct ptp_pin_desc *desc);
> +
> /**
> * Configures a pin of a PTP hardware clock device.
> *
> diff --git a/phc_ctl.c b/phc_ctl.c
> index 4344184c364b..e5076f511813 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -113,6 +113,7 @@ static void usage(const char *progname)
> " freq [ppb] adjust PHC frequency (default returns
> current offset)\n"
> " cmp compare PHC offset to CLOCK_REALTIME\n"
> " capsdisplay device capabilities (default if
> no command given)\n"
> + " get_pins_cfgdisplay device pins configuration\n"
> " wait pause between commands\n"
> "\n",
> progname);
> @@ -319,6 +320,71 @@ static int do_caps(clockid_t clkid, int cmdc, char
> *cmdv[])
> return 0;
> }
>
> +static const char *pin_func_string(unsigned int func)
> +{
> + switch (func) {
> + case PTP_PF_NONE:
> + return "no function";
>
We already filter PTP_PF_NONE in do_get_pins_cfg().
As it is a static function, you can skip it here.
The default tag will catch missing values for the compiler. So no
compilation warnings.
Simply leave a note here, that we already filter it.
> + case PTP_PF_EXTTS:
> + return "external timestamping";
> + case PTP_PF_PEROUT:
> + return "periodic output";
> + case PTP_PF_PHYSYNC:
> + return "phy sync";
> + default:
> + return "unknown function";
> + }
> +}
> +
> +static int do_get_pins_cfg(clockid_t clkid, int cmdc, char *cmdv[])
> +{
> + struct ptp_pin_desc pin_desc;
> + unsigned int index;
> + int n_pins;
> +
> + if (clkid == CLOCK_REALTIME) {
>
All PHC are negative values, while the system clock uses positive values
(for the different variations).
It is better to check "(clkid >= 0)".
As the file description to clock ID formula is a public formula, this will
not change.
We might use other system clock variants in the future.
> + pr_warning("CLOCK_REALTIME is not a PHC device.");
> + return 0;
> + }
> +
> + n_pins = phc_number_pins(clkid);
> + if (n_pins == 0) {
> + pr_notice("device has no configurable pins");
> + return (0);
> + }
> +
> + pr_notice("device has %d
Re: [Linuxptp-devel] [PATCH v3 1/3] phc: dynamically try PTP_PIN_SETFUNC2 and fallback to PTP_PIN_SETFUNC
On Fri, 23 Jun 2023 at 09:07, Jacob Keller wrote:
> The phc library currently selects whether to use PTP_PIN_SETFUNC2 over
> PTP_PIN_SETFUNC based on whether the kernel headers it is compiled against
> have the PTP_PIN_SETFUNC2 defined.
>
> This means that the use of PTP_PIN_SETFUNC vs PTP_PIN_SETFUNC2 depends on
> whether the headers we compiled against have the appropriate definition,
> but not whether the running kernel supports the new ioctl.
>
> Fix this to use dynamic fallback. If PTP_PIN_SETFUNC2 returns -ENOTTY, then
> try PTP_PIN_SETFUNC. This approach will work on a wider range of kernels
> and doesn't need the headers to be up to date.
>
I look in the kernel
https://elixir.bootlin.com/linux/v6.4-rc7/source/drivers/ptp/ptp_chardev.c#L399
Using PTP_PIN_SETFUNC2 at the moment does not add anything.
Perhaps in the future.
It is better to checkthe ptp_pin_desc structure
https://elixir.bootlin.com/linux/v6.4-rc7/source/include/uapi/linux/ptp_clock.h#L174
Once we have new properties there.
Then we can use PTP_PIN_SETFUNC2.
Erez
>
> Signed-off-by: Jacob Keller
> ---
> missing.h | 7 ++-
> phc.c | 7 ---
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/missing.h b/missing.h
> index 79a87d425993..9b37dc258c0f 100644
> --- a/missing.h
> +++ b/missing.h
> @@ -244,11 +244,8 @@ struct ptp_pin_desc {
>
> #endif /*!PTP_PIN_SETFUNC*/
>
> -#ifdef PTP_PIN_SETFUNC2
> -#define PTP_PIN_SETFUNC_FAILED "PTP_PIN_SETFUNC2 failed: %m"
> -#else
> -#define PTP_PIN_SETFUNC_FAILED "PTP_PIN_SETFUNC failed: %m"
> -#define PTP_PIN_SETFUNC2 PTP_PIN_SETFUNC
> +#ifndef PTP_PIN_SETFUNC2
> +#define PTP_PIN_SETFUNC2 _IOW(PTP_CLK_MAGIC, 16, struct ptp_pin_desc)
> #endif
>
> #ifndef LIST_FOREACH_SAFE
> diff --git a/phc.c b/phc.c
> index 37f6b9f6db3c..49e44d1aad65 100644
> --- a/phc.c
> +++ b/phc.c
> @@ -113,9 +113,10 @@ int phc_number_pins(clockid_t clkid)
> int phc_pin_setfunc(clockid_t clkid, struct ptp_pin_desc *desc)
> {
> int err = ioctl(CLOCKID_TO_FD(clkid), PTP_PIN_SETFUNC2, desc);
> - if (err) {
> - fprintf(stderr, PTP_PIN_SETFUNC_FAILED "\n");
> - }
> + if (err == -ENOTTY)
> + err = ioctl(CLOCKID_TO_FD(clkid), PTP_PIN_SETFUNC, desc);
> + if (err)
> + fprintf(stderr, "failed to set pin configuration, error:
> %m\n");
> return err;
> }
>
> --
> 2.41.0.1.g9857a21e0017.dirty
>
>
>
> ___
> 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 0/5] General improvements for linuxptp focused around phase adjustment
On Wed, 21 Jun 2023 at 01:13, Rahul Rameshbabu wrote: > Hi Erez, > > On Wed, 21 Jun, 2023 00:33:28 +0200 Erez wrote: > > Hi, > > > > You already submitted the patch seria. > > Has it changed? > > Yes, I took feedback from the RFC (request for comments) I sent out and > applied it in this submission. In the git notes field in the first patch > of the series, I document the change made since the RFC. Since the first > submission was an RFC, I did not treat it as a formal submission, so I > did not consider it a v1 but rather a draft. I submitted as an RFC due > to pending kernel side changes. > > > If so, please mark it with version 2. "git format-patch -v 2". > > I agree with this if a formal v1 was submitted. However since my > previous submission was an RFC, is the practice still to increment the > official submission as v2? > Rahul, all patches are for review. Do not make our life too much sophisticated. Just add a version tag, please. Whether you add an RFC or not. If you really must , you can add a note in the cover letter for Richard. Linux works with several groups. Linuxptp has only one developer group, it is not that big :-) Thanks Erez > > > If not, why do you send it again? > > Ignoring the fact that I applied changes based on feedback from the RFC > submission, isn't the normal practice to submit an RFC as a normal > submission to the mailing list to indicate readiness for applying the > patches onto the target? > > > I think Richard wanted to close version 4 first. > > Sure, that makes sense. I am hoping RFC patches are not considered for > merging into releases or the default branch of the project. At the time, > the needed kernel side changes were not merged into net-next of the > linux netdev tree. > > Apologize in advance if we are implementing the practice of closing > submissions during release windows (similar to what net-next does in the > linux netdev tree). I did not see a mention of that on the mailing list. > Might have missed it. > > Thanks, > > Rahul Rameshbabu > > > > > Erez > > > > On Tue, 20 Jun 2023 at 19:39, Rahul Rameshbabu via Linuxptp-devel < > linuxptp-devel@lists.sourceforge.net> wrote: > > > > The main focus of this submission is adding support for testing > ADJ_OFFSET with > > phc_ctl and querying the maximum supported ADJ_OFFSET adjustment that a > device > > is capable of. Some other minor cleanups are also included in the > submission. > > > > That patch the introduces support for querying the maximum offset > supported by > > ADJ_OFFSET depends on a kernel patch series (linked below) that is > targeted for > > kernel 6.5. Previously, sent this series out as an RFC to inquire > feedback early > > on. Have incorporated that feedback into this submission. > > > > Link: https://sourceforge.net/p/linuxptp/mailman/message/37854603/ > > Link: > https://lore.kernel.org/netdev/20230612211500.309075-1-rrameshb...@nvidia.com/ > > > > Rahul Rameshbabu (5): > >Rename NSEC2SEC as NSEC_PER_SEC and refactor to util.h > >phc_ctl: Add phase command to support ADJ_OFFSET > >phc_ctl: Add maximum offset capability > >phc_ctl: Use pr_notice instead of pr_err for displaying adjusted > > frequency > >phc_ctl: Handle errors returned by various clockadj helpers > > > > missing.h | 9 +++--- > > phc_ctl.8 | 4 +++ > > phc_ctl.c | 77 ++ > > port.c | 14 - > > port_private.h | 3 +- > > servo.c| 3 +- > > tc.c | 6 ++-- > > util.h | 2 ++ > > 8 files changed, 82 insertions(+), 36 deletions(-) > > > > -- > > 2.40.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 0/5] General improvements for linuxptp focused around phase adjustment
Hi, You already submitted the patch seria. Has it changed? If so, please mark it with version 2. "git format-patch -v 2". If not, why do you send it again? I think Richard wanted to close version 4 first. Erez On Tue, 20 Jun 2023 at 19:39, Rahul Rameshbabu via Linuxptp-devel < linuxptp-devel@lists.sourceforge.net> wrote: > The main focus of this submission is adding support for testing ADJ_OFFSET > with > phc_ctl and querying the maximum supported ADJ_OFFSET adjustment that a > device > is capable of. Some other minor cleanups are also included in the > submission. > > That patch the introduces support for querying the maximum offset > supported by > ADJ_OFFSET depends on a kernel patch series (linked below) that is > targeted for > kernel 6.5. Previously, sent this series out as an RFC to inquire feedback > early > on. Have incorporated that feedback into this submission. > > Link: https://sourceforge.net/p/linuxptp/mailman/message/37854603/ > Link: > https://lore.kernel.org/netdev/20230612211500.309075-1-rrameshb...@nvidia.com/ > > Rahul Rameshbabu (5): > Rename NSEC2SEC as NSEC_PER_SEC and refactor to util.h > phc_ctl: Add phase command to support ADJ_OFFSET > phc_ctl: Add maximum offset capability > phc_ctl: Use pr_notice instead of pr_err for displaying adjusted > frequency > phc_ctl: Handle errors returned by various clockadj helpers > > missing.h | 9 +++--- > phc_ctl.8 | 4 +++ > phc_ctl.c | 77 ++ > port.c | 14 - > port_private.h | 3 +- > servo.c| 3 +- > tc.c | 6 ++-- > util.h | 2 ++ > 8 files changed, 82 insertions(+), 36 deletions(-) > > -- > 2.40.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] LGPL way to talk to pmc
On Fri, 16 Jun 2023 at 13:13, Walfred Tedeschi wrote: > On 15.06.23 17:37, Erez wrote: > > > > On Thu, 15 Jun 2023 at 06:26, Richard Cochran > wrote: > >> On Wed, Jun 14, 2023 at 03:51:08PM +0200, Walfred Tedeschi via >> Linuxptp-devel wrote: >> >> > Covering for Industrial/Process automation customers that are willing >> to use >> > PMC interface to gather status of the time synchronization for their >> stack >> > and enable them to take actions upon the values received. >> >> Here is a nice pmc library licensed under LGPL: >> >> https://github.com/erezgeva/libptpmgmt > > > +1 > > I wrote the library for application integration, as I was working on TSN > :-) > I also add the wrapper languages, so developers can use scripting in > addition to C++. > > Erez > > In terms of license, we see a mix of GPL and LPGL code in the library and > that makes things difficult, as it is not completely clear what is what. > The library is under LGPL https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License The other non library parts are GPL https://en.wikipedia.org/wiki/GNU_General_Public_License I do not see any issue. However, as I am the copyright holder, if you find any issue with licensing, we can fix it. As long as you use the shared library, you can use it with any application and any license you choose: free software or proprietary,. > But more decisive, on the solution we are looking for low latency is > needed and therefore the usage of threads is mandatory. > The library was designed to be used in any manners your application chooses, including threads. Unlike linuxptp that uses an "agent" which sends and receives the management packets. The library breaks down the process to small unblocking functions. The only blocking calls are the socket poll functions. As the library provides the file descriptors of the sockets, you can implement the poll/select yourself. If you need protection on the data, you can wrapp it in your application. As I work with real-time threads. I am aware of how real-time applications are designed, and took it into consideration when writing the library. I was using the library with a real TSN application that sends TSN traffic in real-time! Anyhow, the project is open for more additions and changes on the matter. P.S. threads are not a guarantee of low latency. The TSN application can read the PHC clock directly from the kernel using the clock_gettime(), the library provides the clock ID! > This way, unfortunately, this library might not be used. > Following your questions. I am not sure you looked at the libptpmgmt code, or looked at the samples. > > I will be more verbose in what we are doing. In general, SoftPLC vendors > need a way to control the quality of the running clocks from within their > real-time stacks, while the application will be informed by the stack and > will take the decision on how to proceed. > The library is *NOT *part of the ptp4l itself, but does provide the same functionality the pmc tool provides. The ptp4l does not run very fast. So real-time probing of the PTP does not help much. However the library will not interfere with the application real-time, as it is completely passive by design. The library does not create any threads or change any running thread in any way. > This way the library has to be performant and ready for real-time and > still have a permissive license, LGPL would be fine. > > > From Intel side we would be adding some more code on top to allow for > notifications methods. Considering also for the multidomain topic to join > Chrony and Linuxptp world in a single library, leveraging the work done by > Miroslav ( Libchrony - Thanks again for that) as well. > notifications require active parts in the library. As libptpmgmt is passive, it does not push or notify. Intel can add notifications very easily on top of libptpmgmt. Technically as libptpmgmt is a library, it can be used with any other library. The code is used under C++ namespace, to prevent conflict with other libraries. As for Miroslav Lichvar, Libchrony, I do not know what license it uses. You should ask Miroslav directly. > We would be happy to hear feedback from the community! > > > I can give feedback on libptpmgmt. As for the linuxptp project, I do not think Richard will add any library in the project. Or change the license from GPL. Erez Best regards, > > -Fred > > > >> >> >> HTH, >> Richard >> >> >> ___ >> 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] LGPL way to talk to pmc
On Thu, 15 Jun 2023 at 06:26, Richard Cochran wrote: > On Wed, Jun 14, 2023 at 03:51:08PM +0200, Walfred Tedeschi via > Linuxptp-devel wrote: > > > Covering for Industrial/Process automation customers that are willing to > use > > PMC interface to gather status of the time synchronization for their > stack > > and enable them to take actions upon the values received. > > Here is a nice pmc library licensed under LGPL: > > https://github.com/erezgeva/libptpmgmt +1 I wrote the library for application integration, as I was working on TSN :-) I also add the wrapper languages, so developers can use scripting in addition to C++. Erez > > > HTH, > Richard > > > ___ > 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] [Linuxptp-users] Quarterly release schedule
On Wed, 14 Jun 2023 at 06:25, Richard Cochran wrote: > On Tue, Jun 13, 2023 at 01:01:11PM +0200, Erez wrote: > > > Just so I am clear on the matter. > > I simply suggest taking the same test you run with linuxptp-testsuite. > > And run it in a github action. So we can all run it before we send > patches. > > In addition to the tests you run :-) > > I run the tests _before_ I push anything to github. > Developers can and should run linuxptp-testsuite on their patches > before posting to the list. > That is good advice. Yet looking at the repositories, I can not tell which tests you actually run. Or which tests you expect me to run. > > You can add it into your pre-commit git hook, for example. > This is a good option developers can use. > > Once a commit lands in github, then it is too late. > > You can use github before, if you: 1. push the patch in a forked repository. 2. Open a new branch. for the github action. You can actually mark a github action to skip the master branch, as it is too late, as you say. The benefit of the github action is that we all can run the same test. Of course I can run many tests, but I can never be sure I run the same one you did. Running different tests is great, and yet, I think that a test we all run can benefit too. A regression test that tries to verify we did not break something that is working. Erez > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] Quarterly release schedule
On Tue, 13 Jun 2023 at 12:57, Erez wrote: > > > On Tue, 13 Jun 2023 at 09:48, Richard Cochran > wrote: > >> On Tue, Jun 13, 2023 at 08:02:29AM +0200, Erez wrote: >> > Hi, >> > >> > Using Miroslav's linuxptp-testsuite we can run a simulated HIL in github >> > itself. >> >> "Simulated HIL" is an oxymoron. H stand for hardware. >> > > Simulation of hardware, to be more correct :-) > > >> >> Don't get me wrong, I absolutely love linuxptp-testsuite, and I run it >> on every single patch. >> >> But simulation and actual hardware are two different worlds. >> > > Sure, I do not suggest skipping real hardware. By no means. > Yet automatic testing has benefits, especially regression tests. > > Just so I am clear on the matter. I simply suggest taking the same test you run with linuxptp-testsuite. And run it in a github action. So we can all run it before we send patches. In addition to the tests you run :-) Erez > Erez > > >> Thanks, >> Richard >> > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] Quarterly release schedule
On Tue, 13 Jun 2023 at 09:48, Richard Cochran wrote: > On Tue, Jun 13, 2023 at 08:02:29AM +0200, Erez wrote: > > Hi, > > > > Using Miroslav's linuxptp-testsuite we can run a simulated HIL in github > > itself. > > "Simulated HIL" is an oxymoron. H stand for hardware. > Simulation of hardware, to be more correct :-) > > Don't get me wrong, I absolutely love linuxptp-testsuite, and I run it > on every single patch. > > But simulation and actual hardware are two different worlds. > Sure, I do not suggest skipping real hardware. By no means. Yet automatic testing has benefits, especially regression tests. Erez > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] Quarterly release schedule
Hi, Using Miroslav's linuxptp-testsuite we can run a simulated HIL in github itself. For example, I run a github action to check the libptpmgmt library. I use ptp4l with a dummy clock and run it in github. https://github.com/erezgeva/libptpmgmt/actions/runs/5231114517/jobs/9445059543 I do not suggest passing testing with real hardware and manuals for the changes we do. Using github action allows developers to do some basic smoke tests to ensure they did not break too much. Erez On Tue, 13 Jun 2023 at 06:20, Richard Cochran wrote: > On Fri, Jun 09, 2023 at 07:14:31PM -0700, Richard Cochran wrote: > > On Fri, Jun 09, 2023 at 09:44:04AM -0700, Bernie Gmail wrote: > > > It would really be cool to read mode about your HIL setup. I would > like to create a similar setup > > > > I'll publish the source code. > > https://github.com/richardcochran/hil > > There it is. > > Thanks, > Richard > > > ___ > 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] Use messageLength field to detetmine suffix length
On Mon, 12 Jun 2023 at 20:04, Dylan Robinson wrote: > On Sun, 11 Jun 2023 15:42:23 -0700, Richard Cochran wrote: > > NAK. Please consult the mailing list archives. > > Oops, I can see that this has already been discussed extensively! It > makes sense that this change isn't necessary. I had to do some reading > to convince myself, so I'll include what I found. > > Given the following excerpts, I was originally thinking that the > messageLength field would be the reliable way to know the length of the > user client data in a padded layer 2 packet. > > 802.3-2022 section 3.2.6: > It is the responsibility of the MAC client to ensure that the MAC > client operates properly when the MAC sublayer pads the supplied MAC > Client data > > 802.3-2022 section 4.2.3.3: > The number of extra bits shall be sufficient to ensure that the > frame, from the DA field through the FCS field inclusive, is at > least minFrameSize bits. > > Given the "at least" phrasing, at first I was unclear about whether or > not padding beyond minFrameSize bits could be legally transmitted. > However, after some research, I see that such additional padding is > considered improper by 802.3, but some groups recommend allowing > reception anyway. > > The interoperability lab at UNH actually discusses this situation in the > following document: > https://www.iol.unh.edu/sites/default/files/testsuites/ethernet/MAC/ > MAC_Test_Suite_v4.6.pdf > > MAC Test Suite v4.6 Test #4.1.5 - Receive Frames with Excess Pad: > The IEEE std 802.3-2005 is ambiguous on how a frame with excess > padding should be handled, thus this test part is performed on an > informative basis only. As the frames with excess padding used in > this test are valid in all other respects, the UNH-IOL recommends > that the DUT accept each test frame and reply with a frame that does > not contain padding. This ensures that the valid data is not > discarded. > > This referenced interpretation is interesting as well: > https://www.ieee802.org/3/interp/interp-3-1104.pdf > > Interpretation Number: 03-11/04: > Note however that the example frame in the request should not exist. > This is due to the requirement in subclause 3.2.7 that states that: > The length of PAD field required for MAC client data that is n > octets long is: > max [0, minFrameSize - (8 × n + 2 × addressSize + 48)] bits. > A frame in excess of minFrameSize should always have a PAD field of > size 0. > > So it seems clear that frames with additional padding should not be > transmitted in the first place, but it sounds like implementations > are free to receive or drop such frames due to the ambiguity in the > standard. > > Dylan. just one note. The IEEE 802.3 standard actually follows an already existing Ethernet protocol (Ethernet II). It follows already existing hardware of different vendors and promises backward compatibility. The ambiguity is not a slip but by design! This is not the only standard that follows the market and existing products. It happens everywhere. I do not suggest to ignore standards, Only bear in mind that we can not rely on others to implement the standard to the letter. And that standards in many cases involve politics of many vendors, which lead to ambiguity by design and compromises. Erez > In a few places you mentioned that all transports provide the packet > length. > > On Fri, Feb 01, 2019 at 08:16:41AM -0800, Richard Cochran wrote: > > The rule in communication is to be strict when sending, but generous > > when receiving. This code generously allows incorrect messageLength. > > That field is redundant, because all of the transports already provide > > the packet length. Thus there is no need to check it. > > This is definitely true (or at least should be true) for layer 2 packets > in excess of minFrameSize bits, however, the raw transport does have a > small quirk in that when you send a 44 byte sync message (with no TLV), > layer 2 receivers will receive a 46 byte message as a result of the > transmitter's MAC sublayer appending 2 extra octets to meet the > minFrameSize requirement in 802.3. 802.3 does not provide a way to > determine the user client data length when packets use the etherType > field as a type field like PTP does. > > The code currently works with such sync Ethernet messages because when > parsing the suffix, the TLV header is 4 bytes and padding happens to be > 2 bytes. This means that the while loop in the suffix_post_recv function > is bypassed (since len < sizeof(struct TLV)) and the subsequent > messageLength sanity check also passes because suffix_length ends up > being 0. > >
Re: [Linuxptp-devel] [PATCH] Use the 802.1AS peer delay computation when transportSpecific is 1
Hi,
We tie patches by using the version, so version 2 is named: "[PATCH v2]"
We use "git format-patch -v2"
And add "--cover-letter" in case of several commits.
Next time :-)
Erez
On Tue, 6 Jun 2023 at 21:28, Dylan Robinson wrote:
> If the transportSpecific value is configured to be 1, compute t3c using
> the 802.1AS math instead of the 1588 math.
>
> The 1588 defined computation using variable names from this project is:
> D = [(t4 - t1) - (t3 - t2) - c1 - c2]/2
>
> The existing code combines the corrections into a variable t3c which we
> can get the value of by isolating t3, c1 and c2:
> t3c = t3 + c1 + c2
>
> The 802.1AS defined computation is:
> D = [(t4 - t1) - (t3 - t2) + c1 - c2]/2
>
> Again, isolating t3, c1 and c2 for 802.1AS:
> t3c = t3 + c2 - c1
>
> This has been tested against the MOTU Switch based on the KSZ9567 with
> non-zero correction fields based on the 802.1AS equation as well as MOTU
> audio interfaces that don't utilize the correction fields.
>
> Signed-off-by: Dylan Robinson
> ---
> msg.h | 3 +++
> port.c | 8 +++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/msg.h b/msg.h
> index cbd09e7..484435d 100644
> --- a/msg.h
> +++ b/msg.h
> @@ -37,6 +37,9 @@
>
> #define MAJOR_VERSION_MASK 0x0f
>
> +/* Values for the transportSpecific field */
> +#define TS_IEEE_8021AS (1<<4)
> +
> /* Values for the messageType field */
> #define SYNC 0x0
> #define DELAY_REQ 0x1
> diff --git a/port.c b/port.c
> index d551bef..a97b6f3 100644
> --- a/port.c
> +++ b/port.c
> @@ -2433,7 +2433,13 @@ static void port_peer_delay(struct port *p)
> t3 = timestamp_to_tmv(fup->ts.pdu);
> c2 = correction_to_tmv(fup->header.correction);
> calc:
> - t3c = tmv_add(t3, tmv_add(c1, c2));
> + /* 802.1AS specifies the peer delay computation differently than
> 1588. Do
> +* the 802.1AS computation if transportSpecific matches 802.1AS
> profile. */
> + if (p->transportSpecific == TS_IEEE_8021AS) {
> + t3c = tmv_add(t3, tmv_sub(c2, c1));
> + } else {
> + t3c = tmv_add(t3, tmv_add(c1, c2));
> + }
>
> if (p->follow_up_info)
> port_nrate_calculate(p, t3c, t4);
> --
> 2.30.2
>
>
>
> ___
> 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 RFC 1/5] Rename NSEC2SEC as NSEC_PER_SEC
On Wed, 7 Jun 2023 at 00:09, Rahul Rameshbabu via Linuxptp-devel <
linuxptp-devel@lists.sourceforge.net> wrote:
> The name NSEC2SEC implies converting nanoseconds to seconds, but the value
> used for the macro converts seconds to nanoseconds. NSEC_PER_SEC is the
> accurate name for this macro.
>
+1
And follow Linux kernel.
Erez
> Signed-off-by: Rahul Rameshbabu
> ---
> phc_ctl.c | 8
> port.c | 14 +++---
> port_private.h | 2 +-
> tc.c | 6 +++---
> 4 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/phc_ctl.c b/phc_ctl.c
> index 92e597c..50948e0 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -48,7 +48,7 @@
> #include "util.h"
> #include "version.h"
>
> -#define NSEC2SEC 10.0
> +#define NSEC_PER_SEC 10.0
>
> /* trap the alarm signal so that pause() will wake up on receipt */
> static void handle_alarm(int s)
> @@ -68,7 +68,7 @@ static void double_to_timespec(double d, struct timespec
> *ts)
> * value by our fractional component. This results in a correct
> * timespec from the double representing seconds.
> */
> - ts->tv_nsec = (long)(NSEC2SEC * fraction);
> + ts->tv_nsec = (long)(NSEC_PER_SEC * fraction);
> }
>
> static int install_handler(int signum, void(*handler)(int))
> @@ -230,7 +230,7 @@ static int do_adj(clockid_t clkid, int cmdc, char
> *cmdv[])
> return -2;
> }
>
> - nsecs = (int64_t)(NSEC2SEC * time_arg);
> + nsecs = (int64_t)(NSEC_PER_SEC * time_arg);
>
> clockadj_init(clkid);
> clockadj_step(clkid, nsecs);
> @@ -257,7 +257,7 @@ static int do_freq(clockid_t clkid, int cmdc, char
> *cmdv[])
> }
>
> /* parse the double ppb argument */
> - r = get_ranged_double(cmdv[0], , -NSEC2SEC, NSEC2SEC);
> + r = get_ranged_double(cmdv[0], , -NSEC_PER_SEC, NSEC_PER_SEC);
> switch (r) {
> case PARSED_OK:
> break;
> diff --git a/port.c b/port.c
> index d551bef..b75f850 100644
> --- a/port.c
> +++ b/port.c
> @@ -138,17 +138,17 @@ static int msg_current(struct ptp_message *m, struct
> timespec now)
> {
> int64_t t1, t2, tmo;
>
> - t1 = m->ts.host.tv_sec * NSEC2SEC + m->ts.host.tv_nsec;
> - t2 = now.tv_sec * NSEC2SEC + now.tv_nsec;
> + t1 = m->ts.host.tv_sec * NSEC_PER_SEC + m->ts.host.tv_nsec;
> + t2 = now.tv_sec * NSEC_PER_SEC + now.tv_nsec;
>
> if (m->header.logMessageInterval <= -31) {
> tmo = 0;
> } else if (m->header.logMessageInterval >= 31) {
> tmo = INT64_MAX;
> } else if (m->header.logMessageInterval < 0) {
> - tmo = 4LL * NSEC2SEC / (1 <<
> -m->header.logMessageInterval);
> + tmo = 4LL * NSEC_PER_SEC / (1 <<
> -m->header.logMessageInterval);
> } else {
> - tmo = 4LL * (1 << m->header.logMessageInterval) * NSEC2SEC;
> + tmo = 4LL * (1 << m->header.logMessageInterval) *
> NSEC_PER_SEC;
> }
>
> return t2 - t1 < tmo;
> @@ -340,10 +340,10 @@ static void fc_prune(struct foreign_clock *fc)
>
> static int delay_req_current(struct ptp_message *m, struct timespec now)
> {
> - int64_t t1, t2, tmo = 5 * NSEC2SEC;
> + int64_t t1, t2, tmo = 5 * NSEC_PER_SEC;
>
> - t1 = m->ts.host.tv_sec * NSEC2SEC + m->ts.host.tv_nsec;
> - t2 = now.tv_sec * NSEC2SEC + now.tv_nsec;
> + t1 = m->ts.host.tv_sec * NSEC_PER_SEC + m->ts.host.tv_nsec;
> + t2 = now.tv_sec * NSEC_PER_SEC + now.tv_nsec;
>
> return t2 - t1 < tmo;
> }
> diff --git a/port_private.h b/port_private.h
> index 3b02d2f..c5f55a4 100644
> --- a/port_private.h
> +++ b/port_private.h
> @@ -29,7 +29,7 @@
> #include "power_profile.h"
> #include "tmv.h"
>
> -#define NSEC2SEC 10LL
> +#define NSEC_PER_SEC 10LL
>
> enum syfu_state {
> SF_EMPTY,
> diff --git a/tc.c b/tc.c
> index 1847041..7d1394c 100644
> --- a/tc.c
> +++ b/tc.c
> @@ -256,9 +256,9 @@ static int tc_current(struct ptp_message *m, struct
> timespec now)
> {
> int64_t t1, t2, tmo;
>
> - tmo = 1LL * NSEC2SEC;
> - t1 = m->ts.host.tv_sec * NSEC2SEC + m->ts.host.tv_nsec;
> - t2 = now.tv_sec * NSEC2SEC + now.tv_nsec;
> + tmo = 1LL * NSEC_PER_SEC;
> + t1 = m->ts.host.tv_sec * NSEC_PER_SEC + m->ts.host.tv_nsec;
> + t2 = now.tv_sec * NSEC_PER_SEC + now.tv_nsec;
>
> return t2 - t1 < tmo;
> }
> --
> 2.38.5
>
>
>
> ___
> 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] Two-step peer delay computation 1588 vs 802.1AS
Hi Dylan, We are developers. Please submit a patch. You can add a new configuration option for supporting the 802.1AS equation. As you have the KSZ9567, you can test with it :-) We can only verify with our setups. Bear in mind that we usually do not try to support malfunctioning hardware. But if your patch follows the IEEE standard, then perhaps Richard will apply. Yours Erez On Wed, 31 May 2023 at 19:39, Dylan Robinson wrote: > Hello linuxptp-devel group! > > I would like to discuss the implementation of the two-step peer delay > computation. The 1588 and 802.1AS specifications unfortunately have a small > discrepancy in their use of correction fields for peer delay. This project > appears to be using the 1588 equation rather than the 802.1AS equation. > This is generally not an issue, since 802.1AS implementations typically set > this field to zero, however, there is at least one switch IC on the market, > the KSZ9567, with a silicon errata that results in a non-zero value in this > field. The current version of the MOTU switch uses this IC and implements a > workaround based on the 802.1AS equation. Since the two equations differ, > there is an interoperability issue with the linuxptp project and the MOTU > switch. > > The 1588 specification [section 11.4.3 d) 4) on p.116 of the IEEE > 1588-2008] specifies the following equation to be used to compute mean path > delay: > > = [ > (t4 - t1) - > (responseOriginTimestamp - requestReceiptTimestamp) - > correctionField of Pdelay_Resp - > correctionField of Pdelay_Resp_Follow_Up > ]/2 > > where: > > t4 = Pdelay_Resp Ingress Timestamp > t1 = Pdelay_Req Egress Timestamp > > The 802.1AS specification [section 11.2.19.3.4 computePropTime() on p.186 > of 802.1AS-2020] specifies the following equation: > > D = (r * (t4 - t1) - (t3 - t2)) / 2 > > where: > > t4 = pdelayRespEventIngressTimestamp > t1 = pdelayReqEventEgressTimestamp > t2 = sum of > 1) The nanoseconds field of the requestReceiptTimestamp, > 2) The seconds field of the requestReceiptTimestamp, multiplied by > 10^9 , and > 3) The correction field, divided by 2^16, of the Pdelay_Resp message > t3 = sum of > 1) The nanoseconds field of the responseOriginTimestamp, > 2) The seconds field of the responseOriginTimestamp, multiplied by > 10^9 , and > 3) The correction field, divided by 2^16, of the > Pdelay_Resp_Follow_Up message > r = current value of neighborRateRatio > > In short, the difference is that the 1588 specification asks the > implementation to sum the correction fields whereas the 802.1AS > specification asks the implementation to take their difference. The 802.1AS > specification seems to almost go as far as saying that the peer delay > correction fields can be ignored altogether (see the NOTE in table 11-6 on > p.199 of 802.1AS-2020), and I am aware of a few implementations that do > ignore it without apparent issue. I am interested in making the linuxptp > project compatible with MOTU switches based on the KSZ9567 switch IC, but > before submitting any patches I wanted to explain the motivation and see if > this is something that the project would be open to considering. > > -- > Dylan Robinson > Software Engineer > MOTU > ___ > 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] Is intel i350 ptp driver broken?
Hi,
For fixes of Intel drivers in the Linux kernel, you should approach the
Intel network group of the Linux kernel.
You can look in
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/MAINTAINERS
.
For "INTEL ETHERNET DRIVERS".
Or perhaps they are here in this mailing list.
Erez
On Fri, 26 May 2023 at 16:53, egg car wrote:
> Dear Richard,
>
> Ah yes I have figured out that the problem is not ts2phc, it should be
> fixed in igb_extts() at igb_main.c
>
> if (hw->mac
> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/mac>.type == e1000_82580
> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/e1000_82580> ||
>> hw->mac
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/mac>.type == e1000_i354
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/e1000_i354> ||
>> hw->mac
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/mac>.type == e1000_i350
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/e1000_i350>) {
>> s64 <https://elixir.bootlin.com/linux/v5.19.17/C/ident/s64> ns
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/ns> = rd32
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/rd32>(auxstmpl);
>>
>> ns <https://elixir.bootlin.com/linux/v5.19.17/C/ident/ns> +=
>> ((s64 <https://elixir.bootlin.com/linux/v5.19.17/C/ident/s64>)(rd32
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/rd32>(auxstmph) & 0xFF))
>> << 32;
>> ts <https://elixir.bootlin.com/linux/v5.19.17/C/ident/ts> =
>> ns_to_timespec64
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/ns_to_timespec64>(ns
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/ns>);
>> } else {
>> ts
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/ts>.tv_nsec
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/tv_nsec> = rd32
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/rd32>(auxstmpl);
>> ts
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/ts>.tv_sec
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/tv_sec> = rd32
>> <https://elixir.bootlin.com/linux/v5.19.17/C/ident/rd32>(auxstmph);
>> }
>>
>> here the driver does treat the AUXSTMPH resolution and valid bits in the
> right way, but forgot to convert the raw circle counter value to
> valid time stamp value.
>
> I'll test the patch next week
>
> Thanks for your attention
>
> Richard Cochran 于2023年5月26日周五 22:09写道：
>
>> On Fri, May 26, 2023 at 03:02:43PM +0800, egg car wrote:
>>
>> > It's a bit complicated to use, I see why they use 'struct timecounter'
>> > instead of hardware PHC
>> > counter, and in this case all the timestamp regs cannot be used
>> directly.
>> > Needs more time to find out how to fix this, either the driver or
>> 'ts2phc'
>> > program.
>>
>> Don't try to "fix" ts2phc. That won't make the device driver work any
>> better.
>>
>> Thanks,
>> Richard
>>
>>
>> ___
> 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] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
Thanks for the reply.
Please add the explanation to the commit and to the structure.
Personally, I do not have an opinion, yet I did not participate in the IEEE
1558 committee.
Erez
On Tue, 16 May 2023 at 23:43, Kishen Maloor wrote:
> On 5/16/23 3:56 AM, Erez wrote:
> > On Tue, 16 May 2023 at 00:29, Kishen Maloor
> wrote:
> >
> >> In a setup with multiple gPTP domains, the Common Mean Link Delay
> Service
> >> (CMLDS) (IEEE 1588/16.6.3) performs link delay measurements in a single
> >> domain and must (somehow) convey those to other domains. IEEE 1588 does
> not
> >> specify this interface and flags it as an implementation
> >> detail (IEEE 1588/16.6.1). Accordningly, this change introduces a new
> >> TLV to convey link delay measurements by the CMLDS over the management
> >> interface.
> >>
> >> In addition to the parameters suggested in IEEE 1588/16.6.3.2,
> >> the TLV also conveys the latest 'up measurements' (req and rx
> timestamps)
> >> recorded in the CMLDS. These values collectively aid other gPTP domains
> to
> >> complete their delay/offset computations via the COMMON_P2P
> >> delay mechanism.
> >>
> >> Updated 'pmc' to support the new MID, MID_CMLDS_INFO_NP.
> >>
> >> Co-authored-by: Andrew Zaborowski
> >> Signed-off-by: Kishen Maloor
> >> ---
> >> clock.c| 1 -
> >> msg.h | 2 ++
> >> pmc.c | 13 +
> >> pmc_common.c | 1 +
> >> port.c | 22 ++
> >> port_private.h | 2 ++
> >> tlv.c | 18 ++
> >> tlv.h | 11 +++
> >> 8 files changed, 69 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/clock.c b/clock.c
> >> index fe08d48ed8f8..c74a6baa9f61 100644
> >> --- a/clock.c
> >> +++ b/clock.c
> >> @@ -47,7 +47,6 @@
> >> #include "util.h"
> >>
> >> #define N_CLOCK_PFD (N_POLLFD + 1) /* one extra per port, for the fault
> >> timer */
> >> -#define POW2_41 ((double)(1ULL << 41))
> >>
> >> struct interface {
> >> STAILQ_ENTRY(interface) list;
> >> diff --git a/msg.h b/msg.h
> >> index cbd09e75a2aa..db12e249f89f 100644
> >> --- a/msg.h
> >> +++ b/msg.h
> >> @@ -69,6 +69,8 @@
> >> #define SIGNAL_NO_CHANGE -128
> >> #define SIGNAL_SET_INITIAL 126
> >>
> >> +#define POW2_41 ((double)(1ULL << 41))
> >> +
> >> enum timestamp_type {
> >> TS_SOFTWARE,
> >> TS_HARDWARE,
> >> diff --git a/pmc.c b/pmc.c
> >> index 00e691f0c244..cac06fb5b41d 100644
> >> --- a/pmc.c
> >> +++ b/pmc.c
> >> @@ -169,6 +169,7 @@ static void pmc_show(struct ptp_message *msg, FILE
> *fp)
> >> struct subscribe_events_np *sen;
> >> struct port_properties_np *ppn;
> >> struct port_hwclock_np *phn;
> >> + struct cmlds_info_np *cmlds;
> >> struct timePropertiesDS *tp;
> >> struct management_tlv *mgt;
> >> struct time_status_np *tsn;
> >> @@ -651,6 +652,18 @@ static void pmc_show(struct ptp_message *msg, FILE
> >> *fp)
> >> fprintf(fp, "LOG_MIN_PDELAY_REQ_INTERVAL "
> >> IFMT "logMinPdelayReqInterval %hhd", mtd->val);
> >> break;
> >> + case MID_CMLDS_INFO_NP:
> >> + cmlds = (struct cmlds_info_np *) mgt->data;
> >> + fprintf(fp, "CMLDS INFO "
> >> + IFMT "serviceMeasurementValid %i"
> >> + IFMT "meanLinkDelay %" PRId64
> >> + IFMT "scaledNeighborRateRatio %" PRId32
> >> + IFMT "egress_ts %" PRId64
> >> + IFMT "rx_ts %" PRId64,
> >> + cmlds->serviceMeasurementValid,
> >> cmlds->meanLinkDelay,
> >> + cmlds->scaledNeighborRateRatio,
> >> + cmlds->egress_ts, cmlds->rx_ts);
> >> + break;
> >> }
> >> out:
> >> fprintf(fp, "\n");
> >> diff --git a/pmc_common.c b/pmc_common.c
> >> index 9e251c43e95b..d7a6114dcd62 100644
> >> --- a/pmc_common.c
> >> +++ b/pmc_common.c
> >>
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Tue, 16 May 2023 at 00:29, Kishen Maloor wrote:
> In a setup with multiple gPTP domains, the Common Mean Link Delay Service
> (CMLDS) (IEEE 1588/16.6.3) performs link delay measurements in a single
> domain and must (somehow) convey those to other domains. IEEE 1588 does not
> specify this interface and flags it as an implementation
> detail (IEEE 1588/16.6.1). Accordningly, this change introduces a new
> TLV to convey link delay measurements by the CMLDS over the management
> interface.
>
> In addition to the parameters suggested in IEEE 1588/16.6.3.2,
> the TLV also conveys the latest 'up measurements' (req and rx timestamps)
> recorded in the CMLDS. These values collectively aid other gPTP domains to
> complete their delay/offset computations via the COMMON_P2P
> delay mechanism.
>
> Updated 'pmc' to support the new MID, MID_CMLDS_INFO_NP.
>
> Co-authored-by: Andrew Zaborowski
> Signed-off-by: Kishen Maloor
> ---
> clock.c| 1 -
> msg.h | 2 ++
> pmc.c | 13 +
> pmc_common.c | 1 +
> port.c | 22 ++
> port_private.h | 2 ++
> tlv.c | 18 ++
> tlv.h | 11 +++
> 8 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/clock.c b/clock.c
> index fe08d48ed8f8..c74a6baa9f61 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -47,7 +47,6 @@
> #include "util.h"
>
> #define N_CLOCK_PFD (N_POLLFD + 1) /* one extra per port, for the fault
> timer */
> -#define POW2_41 ((double)(1ULL << 41))
>
> struct interface {
> STAILQ_ENTRY(interface) list;
> diff --git a/msg.h b/msg.h
> index cbd09e75a2aa..db12e249f89f 100644
> --- a/msg.h
> +++ b/msg.h
> @@ -69,6 +69,8 @@
> #define SIGNAL_NO_CHANGE -128
> #define SIGNAL_SET_INITIAL 126
>
> +#define POW2_41 ((double)(1ULL << 41))
> +
> enum timestamp_type {
> TS_SOFTWARE,
> TS_HARDWARE,
> diff --git a/pmc.c b/pmc.c
> index 00e691f0c244..cac06fb5b41d 100644
> --- a/pmc.c
> +++ b/pmc.c
> @@ -169,6 +169,7 @@ static void pmc_show(struct ptp_message *msg, FILE *fp)
> struct subscribe_events_np *sen;
> struct port_properties_np *ppn;
> struct port_hwclock_np *phn;
> + struct cmlds_info_np *cmlds;
> struct timePropertiesDS *tp;
> struct management_tlv *mgt;
> struct time_status_np *tsn;
> @@ -651,6 +652,18 @@ static void pmc_show(struct ptp_message *msg, FILE
> *fp)
> fprintf(fp, "LOG_MIN_PDELAY_REQ_INTERVAL "
> IFMT "logMinPdelayReqInterval %hhd", mtd->val);
> break;
> + case MID_CMLDS_INFO_NP:
> + cmlds = (struct cmlds_info_np *) mgt->data;
> + fprintf(fp, "CMLDS INFO "
> + IFMT "serviceMeasurementValid %i"
> + IFMT "meanLinkDelay %" PRId64
> + IFMT "scaledNeighborRateRatio %" PRId32
> + IFMT "egress_ts %" PRId64
> + IFMT "rx_ts %" PRId64,
> + cmlds->serviceMeasurementValid,
> cmlds->meanLinkDelay,
> + cmlds->scaledNeighborRateRatio,
> + cmlds->egress_ts, cmlds->rx_ts);
> + break;
> }
> out:
> fprintf(fp, "\n");
> diff --git a/pmc_common.c b/pmc_common.c
> index 9e251c43e95b..d7a6114dcd62 100644
> --- a/pmc_common.c
> +++ b/pmc_common.c
> @@ -156,6 +156,7 @@ struct management_id idtab[] = {
> { "UNICAST_MASTER_TABLE_NP", MID_UNICAST_MASTER_TABLE_NP,
> do_get_action },
> { "PORT_HWCLOCK_NP", MID_PORT_HWCLOCK_NP, do_get_action },
> { "POWER_PROFILE_SETTINGS_NP", MID_POWER_PROFILE_SETTINGS_NP,
> do_set_action },
> + { "CMLDS_INFO_NP", MID_CMLDS_INFO_NP, do_get_action },
> };
>
> static void do_get_action(struct pmc *pmc, int action, int index, char
> *str)
> diff --git a/port.c b/port.c
> index 8b2eb04a855a..d467a69e519a 100644
> --- a/port.c
> +++ b/port.c
> @@ -887,6 +887,7 @@ static int port_management_fill_response(struct port
> *target,
> struct clock_description *desc;
> struct port_properties_np *ppn;
> struct port_hwclock_np *phn;
> + struct cmlds_info_np *cmlds;
> struct management_tlv *tlv;
> struct port_stats_np *psn;
> struct foreign_clock *fc;
> @@ -1129,6 +1130,27 @@ static int port_management_fill_response(struct
> port *target,
> memcpy(pwr, >pwr, sizeof(*pwr));
> datalen = sizeof(*pwr);
> break;
> + case MID_CMLDS_INFO_NP:
> + cmlds = (struct cmlds_info_np *)tlv->data;
> + /* IEEE1588-2019 16.6.3.2 h) 1) && nrate.ratio_valid
> because
> +* we have no extra field to convey that separately.
> +*/
> + cmlds->serviceMeasurementValid =
> + target->peer_portid_valid && !target->pdr_missing
> &&
> +
Re: [Linuxptp-devel] [PATCH] sk: Reset timestamping mode on exit, use locks
On Tue, 9 May 2023 at 20:38, Richard Cochran wrote: > On Tue, May 09, 2023 at 02:02:05PM +0200, Andrew Zaborowski wrote: > > Per https://www.kernel.org/doc/Documentation/networking/timestamping.txt > > section 3: > > "User space is responsible to ensure that multiple processes don't > interfere > > with each other and that the settings are reset." > > > > Add locking for the interface's HW timestamping mode to ensure that in a > > setup with multiple ptp4l sessions sharing interfaces the sessions don't > > overwrite each other's timestamping mode and that there is one session > > responsible for resetting the mode on exit. > > We already have a way to implement "sessions don't overwrite each > other's timestamping mode and that there is one session responsible > for resetting the mode on exit." > >hwts_filter > Select the hardware time stamp filter setting mode. > Possible > values are normal, check, full. Normal mode set the > filters as > needed. Check mode only check but do not set. Full mode > set > the receive filter to mark all packets with hardware time > stamp, > so all applications can get them. The default is normal. > > How do you use that? > > 1. Set mode globally using hwstamp_ctl > 2. Start ptp4l with --hwts_filter=check > 3. done. > +1 > > Thanks, > Richard > > > ___ > 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] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
Did blame.
commit afeabf3c90edf6699d7e0d058593835ec258be46
Author: Hangbin Liu
Date: Wed May 25 14:46:16 2022 +0800
ptp4l: add VLAN over bond support
Perhaps Hangbin Liu can assist?
Erez
On Tue, 2 May 2023 at 00:08, Erez wrote:
>
>
> On Mon, 1 May 2023 at 18:30, Martin Pecka wrote:
>
>>
>> This code in hwts_init is wrong:
>>
>> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
>> /* Fall back without flag if user run new build on old kernel */
>> if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL)
>> init_ifreq(, , device);
>>
>> As `man ioctl` says:
>>
>> RETURN VALUE
>>Usually, on success zero is returned. A few ioctl() requests use
>> the
>>return value as an output parameter and return a nonnegative value
>> on
>>success. On error, -1 is returned, and errno is set appropriately.
>>
>> So I think what you meant to write is this:
>>
>> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
>> err = ioctl(fd, SIOCGHWTSTAMP, );
>> if (err < 0) {
>> /* Fall back without flag if user run new build on old kernel */
>> if (errno == EINVAL) {
>> init_ifreq(, , device);
>> } else {
>> pr_err("ioctl SIOCGHWTSTAMP failed: %m");
>> return err;
>> }
>> }
>>
>>
>> Agree. Applying this fix reveals the real error - EOPNOTSUPP.
>>
>> @Martin would that also fix your issue?
>>
>> No. Getting the real error code, I went after the source of EOPNOTSUPP,
>> and...
>>
>> $ sudo hwstamp_ctl -i eth0
>> Device driver does not have support for non-destructive SIOCGHWTSTAMP.
>>
>> This is it! The nvidia eqos driver does not support SIOCGHWTSTAMP (but it
>> does support SIOCSHWTSTAMP). Evidence can be found in
>> https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.7.3/nvidia/drivers/net/ethernet/nvidia/eqos/drv.c#L3979
>> (function eqos_ioctl).
>>
>> According to
>> https://www.kernel.org/doc/Documentation/networking/timestamping.txt,
>> section 3.1:
>>
>> A driver which supports hardware time stamping must support the
>> SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
>> the actual values as described in the section on SIOCSHWTSTAMP. It
>> should also support SIOCGHWTSTAMP.
>>
>> The support for SIOCGHWTSTAMP is optional.
>>
>> So it seems to me wrong to test for the bonded PHC support using this
>> ioctl, which is only optional.
>>
>> To add importance to this issue, I've found out it not only affects the
>> pretty old Jetson TX2 I used for the test, but all Jetson models up to the
>> newest AGX Orin (included). Meaning no Jetson can run ptp4l from master
>> branch now. I really wonder I'm the first one complaining...
>>
>> Regarding possible solutions I can think of:
>>
>> 1. Check errno not only for EINVAL, but also for EOPNOTSUPP. This would
>> solve the issue for me (and Jetsons in general), but would probably leave
>> some users with bonded PHCs whose drivers do not support SIOCGHWTSTAMP
>> without the possibility to use the bonded PHC.
>>
>
> On a second review.
> I think you have a point.
>
> This get ioctl (SIOCGHWTSTAMP) was added for VLAN over bond support.
>
> On normal run, the get ioctl is only used with HWTS_FILTER_CHECK.
> So the user can switch to HWTS_FILTER_FULL or HWTS_FILTER_NORMAL and skip
> the get ioctl.
>
> But the get ioctl with bonded PHC index, can not be skipped.
>
>
>> 2. Find another way to test for the bonded PHC feature.
>>
> Perhaps a flag?
>
> Erez
>
>
>> Martin
>>
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Mon, 1 May 2023 at 18:30, Martin Pecka wrote:
>
> This code in hwts_init is wrong:
>
> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
> /* Fall back without flag if user run new build on old kernel */
> if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL)
> init_ifreq(, , device);
>
> As `man ioctl` says:
>
> RETURN VALUE
>Usually, on success zero is returned. A few ioctl() requests use the
>return value as an output parameter and return a nonnegative value on
>success. On error, -1 is returned, and errno is set appropriately.
>
> So I think what you meant to write is this:
>
> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
> err = ioctl(fd, SIOCGHWTSTAMP, );
> if (err < 0) {
> /* Fall back without flag if user run new build on old kernel */
> if (errno == EINVAL) {
> init_ifreq(, , device);
> } else {
> pr_err("ioctl SIOCGHWTSTAMP failed: %m");
> return err;
> }
> }
>
>
> Agree. Applying this fix reveals the real error - EOPNOTSUPP.
>
> @Martin would that also fix your issue?
>
> No. Getting the real error code, I went after the source of EOPNOTSUPP,
> and...
>
> $ sudo hwstamp_ctl -i eth0
> Device driver does not have support for non-destructive SIOCGHWTSTAMP.
>
> This is it! The nvidia eqos driver does not support SIOCGHWTSTAMP (but it
> does support SIOCSHWTSTAMP). Evidence can be found in
> https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.7.3/nvidia/drivers/net/ethernet/nvidia/eqos/drv.c#L3979
> (function eqos_ioctl).
>
> According to
> https://www.kernel.org/doc/Documentation/networking/timestamping.txt,
> section 3.1:
>
> A driver which supports hardware time stamping must support the
> SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
> the actual values as described in the section on SIOCSHWTSTAMP. It
> should also support SIOCGHWTSTAMP.
>
> The support for SIOCGHWTSTAMP is optional.
>
> So it seems to me wrong to test for the bonded PHC support using this
> ioctl, which is only optional.
>
> To add importance to this issue, I've found out it not only affects the
> pretty old Jetson TX2 I used for the test, but all Jetson models up to the
> newest AGX Orin (included). Meaning no Jetson can run ptp4l from master
> branch now. I really wonder I'm the first one complaining...
>
> Regarding possible solutions I can think of:
>
> 1. Check errno not only for EINVAL, but also for EOPNOTSUPP. This would
> solve the issue for me (and Jetsons in general), but would probably leave
> some users with bonded PHCs whose drivers do not support SIOCGHWTSTAMP
> without the possibility to use the bonded PHC.
>
On a second review.
I think you have a point.
This get ioctl (SIOCGHWTSTAMP) was added for VLAN over bond support.
On normal run, the get ioctl is only used with HWTS_FILTER_CHECK.
So the user can switch to HWTS_FILTER_FULL or HWTS_FILTER_NORMAL and skip
the get ioctl.
But the get ioctl with bonded PHC index, can not be skipped.
> 2. Find another way to test for the bonded PHC feature.
>
Perhaps a flag?
Erez
> Martin
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Sun, 30 Apr 2023 at 23:26, Richard Cochran
wrote:
> On Thu, Mar 30, 2023 at 11:16:44AM +0800, Hangbin Liu wrote:
> > Richard, what do you think?
>
> This code in hwts_init is wrong:
>
> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
> /* Fall back without flag if user run new build on old kernel */
> if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL)
> init_ifreq(, , device);
>
> As `man ioctl` says:
>
> RETURN VALUE
>Usually, on success zero is returned. A few ioctl() requests use
> the
>return value as an output parameter and return a nonnegative
> value on
>success. On error, -1 is returned, and errno is set appropriately.
>
> So I think what you meant to write is this:
>
> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
> err = ioctl(fd, SIOCGHWTSTAMP, );
> if (err < 0) {
> /* Fall back without flag if user run new build on old
> kernel */
> if (errno == EINVAL) {
> init_ifreq(, , device);
> } else {
> pr_err("ioctl SIOCGHWTSTAMP failed: %m");
> return err;
> }
> }
>
> @Martin would that also fix your issue?
>
I support.
Erez
>
> Thanks,
> Richard
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Help : linuxptp power profile
On Mon, 24 Apr 2023 at 07:48, Shubham Gupta wrote: > Hello All, > > I am currently working on ptp power profile and have a few queries. If > anyone can help me with the below queries will be highly appreciated. > > My use case is to run linuxptp as a slave in my device and also run > linuxptp as a master in another device. > > 1. As of now what is the plan for releasing 4.0 with the support of power > profile C37_238? > I understand Richard wants to release version 4. There are some bug fixes left there. The power profile patch is already merged in master. > 2. What are the settings we need to do to run linuxptp as a slave and as a > master in the power profile? > See the new options in Richard commit: https://github.com/richardcochran/linuxptp/commit/7059a05a3fb2182e851217c8872cf47126ec4c4c And the new POWER_PROFILE_SETTINGS_NP management TLV (you can query and set by using the pmc tool). > 3. Are power profile messages mandatorily required to carry IEEE 802.1Q > VLAN tags? > I do not remember seeing dependence of that kind. But you can read IEEE C37 238 of 2011 or 2017. Or simply try yourself. As I did not try using it myself, I can not answer for sure. Erez > > Thanks and regards, > Shubham > ___ > 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 v5 1/2] pmc_agent: Add option to run callback for signaling messages
On Wed, 26 Apr 2023 at 11:55, Maciek Machnikowski
wrote:
> On 4/21/2023 6:46 PM, Erez wrote:
> >
> >
> > On Fri, 21 Apr 2023 at 17:27, Maciek Machnikowski
> > mailto:mac...@machnikowski.net>> wrote:
> >
> > On 4/21/2023 1:25 PM, Erez wrote:
> > >
> > >
> > > On Thu, 20 Apr 2023 at 19:01, Maciek Machnikowski
> > > mailto:mac...@machnikowski.net>
> > <mailto:mac...@machnikowski.net <mailto:mac...@machnikowski.net>>>
> > wrote:
> > >
> > > Add option to run callback that when the PMC agent receives
> > > signaling messages.
> > >
> > > Signed-off-by: Maciek Machnikowski > <mailto:mac...@machnikowski.net>
> > > <mailto:mac...@machnikowski.net mac...@machnikowski.net>>>
> > > ---
> > > pmc_agent.c | 21 +++--
> > > pmc_agent.h | 7 +++
> > > 2 files changed, 26 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/pmc_agent.c b/pmc_agent.c
> > > index 62d1a86..ef4e1bb 100644
> > > --- a/pmc_agent.c
> > > +++ b/pmc_agent.c
> > > @@ -42,6 +42,7 @@ struct pmc_agent {
> > > bool dds_valid;
> > > int leap;
> > > int pmc_ds_requested;
> > > + bool signaling_cb_ena;
> > > bool stay_subscribed;
> > > int sync_offset;
> > > int utc_offset_traceable;
> > > @@ -127,6 +128,7 @@ static int run_pmc(struct pmc_agent *node,
> int
> > > timeout, int ds_id,
> > > #define N_FD 1
> > > struct pollfd pollfd[N_FD];
> > > int cnt, res;
> > > + bool skip_cb;
> > >
> > > while (1) {
> > > pollfd[0].fd = pmc_get_transport_fd(node->pmc);
> > > @@ -178,9 +180,18 @@ static int run_pmc(struct pmc_agent
> > *node, int
> > > timeout, int ds_id,
> > > node->pmc_ds_requested = 0;
> > > return RUN_PMC_NODEV;
> > > }
> > > - if (res <= 0 ||
> > > +
> > > + /* Skip callback if message is not management
> */
> > > + skip_cb = (res <= 0) ? true : false;
> > > +
> > > + /* Run the callback on signaling messages if
> > > configured */
> > > + if (node->signaling_cb_ena && (msg_type(*msg)
> ==
> > > SIGNALING)) {
> > >
> > >
> > > I would add res == 0, to save time here.
> > >
> > > You can have
> > >if (res < 0) {
> > >skip_cb = false;
> > >} else if(res == 0) {
> > > if (node->signaling_cb_ena && (msg_type(*msg) ==
> > > SIGNALING)) {
> > >skip_cb = true;
> > > } else {
> > > skip_cb = false;
> > > }
> > > } else {
> > >skip_cb = true;
> > > }
> > >
> > > This code saves you from checking 'node->signaling_cb_ena' if res
> > is not 0.
> > > 'res' is a local variable, 'node->signaling_cb_ena' is referred
> > through> a pointer, so its fetch time is much bigger.
> >
> > This is not true. It compiles to a single ASM line even without any
> > optimizations enabled:
> >
> >
> > This looks like arm64. There are other CPUs beside ARM.
> > And in assembler it is hard to "see" how long it takes to load
> > 'signaling_cb_ena' from node unless it is in the memory cache.
>
> It's similar on x86.
> /* Run the callback on signaling messages if configured */
> if (res == 0 && node->signaling_cb_ena &&
> 475: 83 7d f4 00 cmpl $0x0,-0xc(%rbp)
> 479: 75 24 jne49f
> >47b: 48 8b 45 d8 mov-0x28(%rbp),%rax
> >47f: 0f b6 40 30 movzbl 0x30(%rax),%eax
> >483: 84 c
Re: [Linuxptp-devel] [PATCH 1/6] Add doubly attached clock support
On Tue, 25 Apr 2023 at 13:40, Wurm, Stephan
wrote:
> Am Montag, dem 24.04.2023 um 14:59 -0700 schrieb Richard Cochran:
>
> On Mon, Apr 24, 2023 at 10:45:56AM +0200, Stephan Wurm wrote:
>
> @@ -210,6 +219,40 @@ enum port_state ptp_fsm(enum port_state state, enum
> fsm_event event, int mdiff)
>
>
> + case PS_PASSIVE_SLAVE:
> + switch (event) {
> + case EV_DESIGNATED_DISABLED:
> + next = PS_DISABLED;
> + break;
> + case EV_FAULT_DETECTED:
> + next = PS_FAULTY;
> + break;
> + case EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES:
> + next = PS_MASTER;
> + break;
> + case EV_SYNCHRONIZATION_FAULT:
> + next = PS_LISTENING;
> + break;
> + case EV_RS_MASTER:
> + next = PS_PRE_MASTER;
> + break;
> + case EV_RS_GRAND_MASTER:
> + next = PS_GRAND_MASTER;
> + break;
> + case EV_RS_PASSIVE:
> + next = PS_PASSIVE;
> + break;
> + case EV_RS_SLAVE:
> + next = PS_SLAVE;
> + break;
>
>
> You can't just add random states into the ieee 1588 state machine.
>
> It was not my intention, to add any random states, but I understand this
> conflicts with the IEEE 1588 standard.
>
The port state is defined in IEEE 1588, any new state needs to be defined
by IEEE 1588.
It is not open for other standards or enterprise/private use.
It is not about "conflict" today, but on potential conflict in the future
as these values are defined solely by IEEE 1588.
Internal states are as suggested, internal. We have a 'grand master' port
state that maps to IEEE 1588 master publicly.
>
> The port state PASSIVE_SLAVE is required for the core feature of
> doubly-attached clocks as described by specification IEC 62439-2:2016
> Appendix A, which is an industrial standard accounting for high precision
> and high availability needs. It explicitly extends the IEEE 1588 state
> machine.
> Other standards in power automation are referencing this redundancy
> mechanism, e.g. the Power Profile v2 (IEEE C37.238-2017) or the Power
> Utility Profile (IEC 61850-9-3:2016).
>
> A doubly-attached clock in this context allows for redundant connection
> of a clock to a grandmaster clock via two independent interface ports.
> Provided, the same grandmaster is evaluated as best clock at both
> interfaces, one port synchronizes as SLAVE, while the other port
> remains passive (PASSIVE_SLAVE).
> Now the passive port can instantly step in, whenever the active port
> loses its synchronization (FAULTY).
>
> Do you see any chance to add this extension to linuxptp?
> Maybe only on demand, e.g. at compile time or activateable with a
> separate configuration option?
>
As far as I know. We do not like or use any compilation flags for features.
We only use compilation flags for dependencies of outer headers like
kernels.
We control features by configuration only on run time.
The Linuxptp is first an IEEE 1588 PTP project.
It does not mean we do not like enhancements or using ITU or IEC.
But at bottom line, your code must be IEEE 1588 compliant in any
configuration you choose.
Erez
>
>
> Thanks,
> Richard
>
>
> Best regards
> Stephan
> ___
> 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/6] Add doubly attached clock support
On Tue, 25 Apr 2023 at 10:16, Wurm, Stephan
wrote:
> Am Montag, dem 24.04.2023 um 12:39 +0200 schrieb Erez:
>
>
>
>
>
> On Mon, 24 Apr 2023 at 11:08, Stephan Wurm
> wrote:
>
> Standard IEC 21439-3:2016 Appendix A extends the PTPv2 standard by the
> definition of doubly attached clocks (DAC) via redundant ports (either
> connected by HSR or PRP). Therefore, the state machine is extended by
> state PASSIVE_SLAVE and transition PSLAVE.
>
> In order to take advantage of the DAC feature, two interfaces need to
> be configured as redundant port by explicitly selecting the respective
> other interface via the `paired_interface` configuration option.
>
> The new state is reported as PASSIVE via the management interface,
> remaining compatible with the PTPv2 standard.
>
> Signed-off-by: Stephan Wurm
> ---
> bmc.c | 10
> clock.c | 4
> config.c | 1 +
> e2e_tc.c | 1 +
> fsm.c | 71
> +++
> fsm.h | 2 ++
> p2p_tc.c | 2 ++
> pmc.c | 4 ++--
> port.c| 44 +++---
> port.h| 47
> port_private.h| 4
> port_signaling.c | 1 +
> tc.c | 2 ++
> unicast_service.c | 1 +
> util.c| 4 +++-
> 15 files changed, 177 insertions(+), 21 deletions(-)
>
> diff --git a/bmc.c b/bmc.c
> index ebc0789..1e1d83f 100644
> --- a/bmc.c
> +++ b/bmc.c
> @@ -130,12 +130,14 @@ enum port_state bmc_state_decision(struct clock *c,
> struct port *r,
>int (*compare)(struct dataset *a,
> struct dataset *b))
> {
> struct dataset *clock_ds, *clock_best, *port_best;
> + struct port *paired_port;
> enum port_state ps;
>
> clock_ds = clock_default_ds(c);
> clock_best = clock_best_foreign(c);
> port_best = port_best_foreign(r);
> ps = port_state(r);
> + paired_port = port_paired_port(r);
>
> /*
> * This scenario is particularly important in the
> designated_slave_fsm
> @@ -167,6 +169,14 @@ enum port_state bmc_state_decision(struct clock *c,
> struct port *r,
> return PS_SLAVE; /*S1*/
> }
>
> + /*
> +* This scenario handles the PASSIVE_SLAVE transition according to
> +* IEC 62439-3 standard in case of a doubly attached clock.
> +*/
> + if (paired_port && (clock_best_port(c) == paired_port)) {
> + return PS_PASSIVE_SLAVE;
> + }
> +
> if (compare(clock_best, port_best) == A_BETTER_TOPO) {
> return PS_PASSIVE; /*P2*/
> } else {
> diff --git a/clock.c b/clock.c
> index 75d7c40..d52e826 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -1009,6 +1009,7 @@ static int clock_add_port(struct clock *c, const
> char *phc_device,
> return -1;
> }
> LIST_FOREACH(piter, >ports, list) {
> + port_pair(piter, p);
> lastp = piter;
> }
> if (lastp) {
> @@ -2235,6 +2236,9 @@ static void handle_state_decision_event(struct clock
> *c)
> clock_update_slave(c);
> event = EV_RS_SLAVE;
> break;
> + case PS_PASSIVE_SLAVE:
> + event = EV_RS_PSLAVE;
> + break;
> default:
> event = EV_FAULT_DETECTED;
> break;
> diff --git a/config.c b/config.c
> index cb4421f..28beb3b 100644
> --- a/config.c
> +++ b/config.c
> @@ -298,6 +298,7 @@ struct config_item config_tab[] = {
> GLOB_ITEM_INT("offsetScaledLogVariance", 0x, 0, UINT16_MAX),
> PORT_ITEM_INT("operLogPdelayReqInterval", 0, INT8_MIN, INT8_MAX),
> PORT_ITEM_INT("operLogSyncInterval", 0, INT8_MIN, INT8_MAX),
> + PORT_ITEM_STR("paired_interface", ""),
> PORT_ITEM_INT("path_trace_enabled", 0, 0, 1),
> PORT_ITEM_INT("phc_index", -1, -1, INT_MAX),
> GLOB_ITEM_DBL("pi_integral_const", 0.0, 0.0, DBL_MAX),
> diff --git a/e2e_tc.c b/e2e_tc.c
> index 2f8e821..94099eb 100644
> --- a/e2e_tc.c
> +++ b/e2e_tc.c
> @@ -69,6 +69,7 @@ void e2e_dispatch(struct port *p, enum fsm_event event,
> int mdiff)
> flush_delay_req(p);
> /* fall through */
> case PS_SLAVE:
> + case PS_PASSIVE_SLAVE:
> port_set_announce_tmo
Re: [Linuxptp-devel] [PATCH 3/6] Add profile identification according to IEC 62439-3:2016 standard
On Tue, 25 Apr 2023 at 09:16, Wurm, Stephan
wrote:
> Am Montag, dem 24.04.2023 um 12:46 +0200 schrieb Erez:
>
>
>
> On Mon, 24 Apr 2023 at 11:07, Stephan Wurm
> wrote:
>
> Set profile identification according to IEC 62439-3:2016 Appendix B,
> when dataset comparison is set to iec62439-3.
> This also distinguishes between single-attached (SAC) and doubly-
> attached (DAC) clocks.
>
>
> DAC usually stands for digital analog converter.
> https://en.wikipedia.org/wiki/Digital-to-analog_converter
> Perhaps you or IEC have a better acronym? Like DbAC? or CA2 and CA1?
>
> Erez
>
>
> I know, the acronym is not perfect. But I took both SAC (single-attached
> clock)
> and DAC (doubly-attached clock) from the IEC 62439-3 specification I
> wanted to
> implement.
>
OK, so please use IEC DAC, or IEC62439 DAC also in the code and titles.
Also in the variable/constands name as well as the comments.
Please do not use DAC without IEC.
Some of us use DAC for other purposes a lot.
Erez
>
> Stephan
>
>
> Signed-off-by: Stephan Wurm
> ---
> bmc.h| 1 +
> config.c | 1 +
> port.c | 25 -
> 3 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/bmc.h b/bmc.h
> index 2901cda..17e4934 100644
> --- a/bmc.h
> +++ b/bmc.h
> @@ -32,6 +32,7 @@
> enum {
> DS_CMP_IEEE1588,
> DS_CMP_G8275,
> + DS_CMP_IEC62439_3,
> };
>
> /**
> diff --git a/config.c b/config.c
> index 28beb3b..f2da24f 100644
> --- a/config.c
> +++ b/config.c
> @@ -160,6 +160,7 @@ static struct config_enum clock_type_enu[] = {
> static struct config_enum dataset_comp_enu[] = {
> { "ieee1588", DS_CMP_IEEE1588 },
> { "G.8275.x", DS_CMP_G8275},
> + { "iec62439-3", DS_CMP_IEC62439_3 },
> { NULL, 0 },
> };
>
> diff --git a/port.c b/port.c
> index c70e5b4..edf76da 100644
> --- a/port.c
> +++ b/port.c
> @@ -873,6 +873,8 @@ static const Octet profile_id_drr[] = {0x00, 0x1B,
> 0x19, 0x00, 0x01, 0x00};
> static const Octet profile_id_p2p[] = {0x00, 0x1B, 0x19, 0x00, 0x02,
> 0x00};
> static const Octet profile_id_8275_1[] = {0x00, 0x19, 0xA7, 0x01, 0x02,
> 0x03};
> static const Octet profile_id_8275_2[] = {0x00, 0x19, 0xA7, 0x02, 0x01,
> 0x02};
> +static const Octet profile_id_62439_3_SAC[] = {0x00, 0x0C, 0xCD, 0x00,
> 0x01, 0x00};
> +static const Octet profile_id_62439_3_DAC[] = {0x00, 0x0C, 0xCD, 0x00,
> 0x01, 0x30};
>
> static int port_management_fill_response(struct port *target,
> struct ptp_message *rsp, int id)
> @@ -893,8 +895,10 @@ static int port_management_fill_response(struct port
> *target,
> struct port_ds_np *pdsnp;
> struct tlv_extra *extra;
> struct PortIdentity pid;
> + const Octet *profile_id;
> const char *ts_label;
> struct portDS *pds;
> + struct config *cfg;
> uint16_t u16;
> uint8_t *buf;
> int datalen;
> @@ -967,20 +971,31 @@ static int port_management_fill_response(struct port
> *target,
> buf += sizeof(struct PTPText) +
> cd->userDescription->length;
>
> if (target->delayMechanism == DM_P2P) {
> - memcpy(buf, profile_id_p2p, PROFILE_ID_LEN);
> + cfg = clock_config(target->clock);
> + if (config_get_int(cfg, NULL,
> "dataset_comparison") ==
> + DS_CMP_IEC62439_3) {
> + if (target->paired_port) {
> + profile_id =
> profile_id_62439_3_DAC;
> + } else {
> + profile_id =
> profile_id_62439_3_SAC;
> + }
> + } else {
> + profile_id = profile_id_p2p;
> + }
> } else {
> - struct config *cfg = clock_config(target->clock);
> + cfg = clock_config(target->clock);
> if (config_get_int(cfg, NULL,
> "dataset_comparison") ==
> DS_CMP_G8275) {
> if (transport_type(target->trp) ==
> TRANS_IEEE_802_3) {
> - memcpy(buf, profile_id_8275_1,
> PROFILE_ID_LEN);
> + profile_id = profile_id_8275_1;
> } else {
> - memcpy(buf, profile_id_8275_2,
&g
Re: [Linuxptp-devel] [PATCH 4/6] ptp4l: Add doubly attached clock support
On Mon, 24 Apr 2023 at 11:07, Stephan Wurm wrote:
> Allow ORDINARY_CLOCK (OC) as doubly attached clock according to IEC
> 62439-3:2016 standard.
>
> Signed-off-by: Stephan Wurm
> ---
> ptp4l.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/ptp4l.c b/ptp4l.c
> index c61175b..8eb0720 100644
> --- a/ptp4l.c
> +++ b/ptp4l.c
> @@ -23,6 +23,7 @@
> #include
> #include
>
> +#include "bmc.h"
> #include "clock.h"
> #include "config.h"
> #include "ntpshm.h"
> @@ -73,6 +74,7 @@ int main(int argc, char *argv[])
> char *config = NULL, *req_phc = NULL, *progname;
> enum clock_type type = CLOCK_TYPE_ORDINARY;
> int c, err = -1, index, print_level;
> + bool dac = false;
>
perhaps 'iec_dac', so we know it is not a "digital analog clock/convertor"?
> struct clock *clock = NULL;
> struct option *opts;
> struct config *cfg;
> @@ -203,10 +205,18 @@ int main(int argc, char *argv[])
> goto out;
> }
>
> + if (config_get_int(cfg, NULL, "dataset_comparison") ==
> DS_CMP_IEC62439_3) {
> + dac = true;
> + }
> +
> type = config_get_int(cfg, NULL, "clock_type");
> switch (type) {
> case CLOCK_TYPE_ORDINARY:
> - if (cfg->n_interfaces > 1) {
> + if ((!dac && cfg->n_interfaces > 1) ||
> + /* The IEC 62439-3 standard allows doubly attached
> ordinary
> +* clocks
> +*/
> + (dac && cfg->n_interfaces > 2)) {
> type = CLOCK_TYPE_BOUNDARY;
> }
> break;
>
> --
> 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 3/6] Add profile identification according to IEC 62439-3:2016 standard
On Mon, 24 Apr 2023 at 11:07, Stephan Wurm wrote:
> Set profile identification according to IEC 62439-3:2016 Appendix B,
> when dataset comparison is set to iec62439-3.
> This also distinguishes between single-attached (SAC) and doubly-
> attached (DAC) clocks.
>
DAC usually stands for digital analog converter.
https://en.wikipedia.org/wiki/Digital-to-analog_converter
Perhaps you or IEC have a better acronym? Like DbAC? or CA2 and CA1?
Erez
> Signed-off-by: Stephan Wurm
> ---
> bmc.h| 1 +
> config.c | 1 +
> port.c | 25 -
> 3 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/bmc.h b/bmc.h
> index 2901cda..17e4934 100644
> --- a/bmc.h
> +++ b/bmc.h
> @@ -32,6 +32,7 @@
> enum {
> DS_CMP_IEEE1588,
> DS_CMP_G8275,
> + DS_CMP_IEC62439_3,
> };
>
> /**
> diff --git a/config.c b/config.c
> index 28beb3b..f2da24f 100644
> --- a/config.c
> +++ b/config.c
> @@ -160,6 +160,7 @@ static struct config_enum clock_type_enu[] = {
> static struct config_enum dataset_comp_enu[] = {
> { "ieee1588", DS_CMP_IEEE1588 },
> { "G.8275.x", DS_CMP_G8275},
> + { "iec62439-3", DS_CMP_IEC62439_3 },
> { NULL, 0 },
> };
>
> diff --git a/port.c b/port.c
> index c70e5b4..edf76da 100644
> --- a/port.c
> +++ b/port.c
> @@ -873,6 +873,8 @@ static const Octet profile_id_drr[] = {0x00, 0x1B,
> 0x19, 0x00, 0x01, 0x00};
> static const Octet profile_id_p2p[] = {0x00, 0x1B, 0x19, 0x00, 0x02,
> 0x00};
> static const Octet profile_id_8275_1[] = {0x00, 0x19, 0xA7, 0x01, 0x02,
> 0x03};
> static const Octet profile_id_8275_2[] = {0x00, 0x19, 0xA7, 0x02, 0x01,
> 0x02};
> +static const Octet profile_id_62439_3_SAC[] = {0x00, 0x0C, 0xCD, 0x00,
> 0x01, 0x00};
> +static const Octet profile_id_62439_3_DAC[] = {0x00, 0x0C, 0xCD, 0x00,
> 0x01, 0x30};
>
> static int port_management_fill_response(struct port *target,
> struct ptp_message *rsp, int id)
> @@ -893,8 +895,10 @@ static int port_management_fill_response(struct port
> *target,
> struct port_ds_np *pdsnp;
> struct tlv_extra *extra;
> struct PortIdentity pid;
> + const Octet *profile_id;
> const char *ts_label;
> struct portDS *pds;
> + struct config *cfg;
> uint16_t u16;
> uint8_t *buf;
> int datalen;
> @@ -967,20 +971,31 @@ static int port_management_fill_response(struct port
> *target,
> buf += sizeof(struct PTPText) +
> cd->userDescription->length;
>
> if (target->delayMechanism == DM_P2P) {
> - memcpy(buf, profile_id_p2p, PROFILE_ID_LEN);
> + cfg = clock_config(target->clock);
> + if (config_get_int(cfg, NULL,
> "dataset_comparison") ==
> + DS_CMP_IEC62439_3) {
> + if (target->paired_port) {
> + profile_id =
> profile_id_62439_3_DAC;
> + } else {
> + profile_id =
> profile_id_62439_3_SAC;
> + }
> + } else {
> + profile_id = profile_id_p2p;
> + }
> } else {
> - struct config *cfg = clock_config(target->clock);
> + cfg = clock_config(target->clock);
> if (config_get_int(cfg, NULL,
> "dataset_comparison") ==
> DS_CMP_G8275) {
> if (transport_type(target->trp) ==
> TRANS_IEEE_802_3) {
> - memcpy(buf, profile_id_8275_1,
> PROFILE_ID_LEN);
> + profile_id = profile_id_8275_1;
> } else {
> - memcpy(buf, profile_id_8275_2,
> PROFILE_ID_LEN);
> + profile_id = profile_id_8275_2;
> }
> } else {
> - memcpy(buf, profile_id_drr,
> PROFILE_ID_LEN);
> + profile_id = profile_id_drr;
> }
> }
> + memcpy(buf, profile_id, PROFILE_ID_LEN);
> buf += PROFILE_ID_LEN;
> datalen = buf - tlv->data;
> break;
>
> --
> 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 1/6] Add doubly attached clock support
On Mon, 24 Apr 2023 at 11:08, Stephan Wurm wrote:
> Standard IEC 21439-3:2016 Appendix A extends the PTPv2 standard by the
> definition of doubly attached clocks (DAC) via redundant ports (either
> connected by HSR or PRP). Therefore, the state machine is extended by
> state PASSIVE_SLAVE and transition PSLAVE.
>
> In order to take advantage of the DAC feature, two interfaces need to
> be configured as redundant port by explicitly selecting the respective
> other interface via the `paired_interface` configuration option.
>
> The new state is reported as PASSIVE via the management interface,
> remaining compatible with the PTPv2 standard.
>
> Signed-off-by: Stephan Wurm
> ---
> bmc.c | 10
> clock.c | 4
> config.c | 1 +
> e2e_tc.c | 1 +
> fsm.c | 71
> +++
> fsm.h | 2 ++
> p2p_tc.c | 2 ++
> pmc.c | 4 ++--
> port.c| 44 +++---
> port.h| 47
> port_private.h| 4
> port_signaling.c | 1 +
> tc.c | 2 ++
> unicast_service.c | 1 +
> util.c| 4 +++-
> 15 files changed, 177 insertions(+), 21 deletions(-)
>
> diff --git a/bmc.c b/bmc.c
> index ebc0789..1e1d83f 100644
> --- a/bmc.c
> +++ b/bmc.c
> @@ -130,12 +130,14 @@ enum port_state bmc_state_decision(struct clock *c,
> struct port *r,
>int (*compare)(struct dataset *a,
> struct dataset *b))
> {
> struct dataset *clock_ds, *clock_best, *port_best;
> + struct port *paired_port;
> enum port_state ps;
>
> clock_ds = clock_default_ds(c);
> clock_best = clock_best_foreign(c);
> port_best = port_best_foreign(r);
> ps = port_state(r);
> + paired_port = port_paired_port(r);
>
> /*
> * This scenario is particularly important in the
> designated_slave_fsm
> @@ -167,6 +169,14 @@ enum port_state bmc_state_decision(struct clock *c,
> struct port *r,
> return PS_SLAVE; /*S1*/
> }
>
> + /*
> +* This scenario handles the PASSIVE_SLAVE transition according to
> +* IEC 62439-3 standard in case of a doubly attached clock.
> +*/
> + if (paired_port && (clock_best_port(c) == paired_port)) {
> + return PS_PASSIVE_SLAVE;
> + }
> +
> if (compare(clock_best, port_best) == A_BETTER_TOPO) {
> return PS_PASSIVE; /*P2*/
> } else {
> diff --git a/clock.c b/clock.c
> index 75d7c40..d52e826 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -1009,6 +1009,7 @@ static int clock_add_port(struct clock *c, const
> char *phc_device,
> return -1;
> }
> LIST_FOREACH(piter, >ports, list) {
> + port_pair(piter, p);
> lastp = piter;
> }
> if (lastp) {
> @@ -2235,6 +2236,9 @@ static void handle_state_decision_event(struct clock
> *c)
> clock_update_slave(c);
> event = EV_RS_SLAVE;
> break;
> + case PS_PASSIVE_SLAVE:
> + event = EV_RS_PSLAVE;
> + break;
> default:
> event = EV_FAULT_DETECTED;
> break;
> diff --git a/config.c b/config.c
> index cb4421f..28beb3b 100644
> --- a/config.c
> +++ b/config.c
> @@ -298,6 +298,7 @@ struct config_item config_tab[] = {
> GLOB_ITEM_INT("offsetScaledLogVariance", 0x, 0, UINT16_MAX),
> PORT_ITEM_INT("operLogPdelayReqInterval", 0, INT8_MIN, INT8_MAX),
> PORT_ITEM_INT("operLogSyncInterval", 0, INT8_MIN, INT8_MAX),
> + PORT_ITEM_STR("paired_interface", ""),
> PORT_ITEM_INT("path_trace_enabled", 0, 0, 1),
> PORT_ITEM_INT("phc_index", -1, -1, INT_MAX),
> GLOB_ITEM_DBL("pi_integral_const", 0.0, 0.0, DBL_MAX),
> diff --git a/e2e_tc.c b/e2e_tc.c
> index 2f8e821..94099eb 100644
> --- a/e2e_tc.c
> +++ b/e2e_tc.c
> @@ -69,6 +69,7 @@ void e2e_dispatch(struct port *p, enum fsm_event event,
> int mdiff)
> flush_delay_req(p);
> /* fall through */
> case PS_SLAVE:
> + case PS_PASSIVE_SLAVE:
> port_set_announce_tmo(p);
> break;
> };
> diff --git a/fsm.c b/fsm.c
> index ce6efad..9679fea 100644
> --- a/fsm.c
> +++ b/fsm.c
> @@ -80,6 +80,9 @@ enum port_state ptp_fsm(enum port_state state, enum
> fsm_event event, int mdiff)
> case EV_RS_PASSIVE:
> next = PS_PASSIVE;
> break;
> + case EV_RS_PSLAVE:
> + next = PS_PASSIVE_SLAVE;
> + break;
> default:
> break;
> }
> @@ -102,6 +105,9 @@ enum port_state
Re: [Linuxptp-devel] [PATCH v2 1/2] pmc_agent: Add option to run callback for signaling messages
On Fri, 7 Apr 2023 at 17:15, Maciek Machnikowski
wrote:
> Add option to run callback that when the PMC agent receives signaling
> messages.
>
> Signed-off-by: Maciek Machnikowski
> ---
> pmc_agent.c | 19 ++-
> pmc_agent.h | 7 +++
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/pmc_agent.c b/pmc_agent.c
> index 62d1a86..7ffcec8 100644
> --- a/pmc_agent.c
> +++ b/pmc_agent.c
> @@ -42,6 +42,7 @@ struct pmc_agent {
> bool dds_valid;
> int leap;
> int pmc_ds_requested;
> + bool signaling_cb_ena;
> bool stay_subscribed;
> int sync_offset;
> int utc_offset_traceable;
> @@ -127,6 +128,7 @@ static int run_pmc(struct pmc_agent *node, int
> timeout, int ds_id,
> #define N_FD 1
> struct pollfd pollfd[N_FD];
> int cnt, res;
> + bool skip_cb;
>
> while (1) {
> pollfd[0].fd = pmc_get_transport_fd(node->pmc);
> @@ -178,7 +180,16 @@ static int run_pmc(struct pmc_agent *node, int
> timeout, int ds_id,
> node->pmc_ds_requested = 0;
> return RUN_PMC_NODEV;
> }
> - if (res <= 0 ||
> +
> + /* Skip callback if message is not management */
> + skip_cb = (res <= 0) ? true : false;
> +
> + /* Run the callback on signaling messages if configured */
> + if (node->signaling_cb_ena && (msg_type(*msg) ==
> SIGNALING)) {
> + skip_cb = false;
> + }
> +
> + if (skip_cb ||
> node->recv_subscribed(node->recv_context, *msg, ds_id)
> ||
> management_tlv_id(*msg) != ds_id) {
> msg_put(*msg);
> @@ -430,3 +441,9 @@ bool pmc_agent_utc_offset_traceable(struct pmc_agent
> *agent)
> {
> return agent->utc_offset_traceable;
> }
>
I think I have it:
+ /* Run the callback on signaling messages if configured */
+ if (res == 0 && node->signaling_cb_ena && (msg_type(*msg)
== SIGNALING)) {
+ res=2;
+ }
- management_tlv_id(*msg) != ds_id) {
+ res == 1 && management_tlv_id(*msg) != ds_id) {
Erez :-)
> +
> +void pmc_agent_enable_signaling_cb(struct pmc_agent *agent, bool enable)
> +{
> + agent->signaling_cb_ena = enable;
> +}
> +
> diff --git a/pmc_agent.h b/pmc_agent.h
> index 2fb1cc8..9ae37f7 100644
> --- a/pmc_agent.h
> +++ b/pmc_agent.h
> @@ -170,4 +170,11 @@ int pmc_agent_update(struct pmc_agent *agent);
> */
> bool pmc_agent_utc_offset_traceable(struct pmc_agent *agent);
>
> +/**
> + * Enables or disables callback on signaling messages
> + * @param agent Pointer to a PMC instance obtained via @ref
> pmc_agent_create().
> + * @param enable - if set to true, callback will be called on signaling
> msgs
> + */
> +void pmc_agent_enable_signaling_cb(struct pmc_agent *agent, bool enable);
> +
> #endif
> --
> 2.30.2
>
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 1/2] pmc_agent: Add option to run callback for signaling messages
On Sat, 8 Apr 2023 at 17:29, Erez wrote:
>
>
> On Fri, 7 Apr 2023 at 17:15, Maciek Machnikowski
> wrote:
>
>> Add option to run callback that when the PMC agent receives signaling
>> messages.
>>
>
> I support you!
>
>
>>
>> Signed-off-by: Maciek Machnikowski
>> ---
>> pmc_agent.c | 19 ++-
>> pmc_agent.h | 7 +++
>> 2 files changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/pmc_agent.c b/pmc_agent.c
>> index 62d1a86..7ffcec8 100644
>> --- a/pmc_agent.c
>> +++ b/pmc_agent.c
>> @@ -42,6 +42,7 @@ struct pmc_agent {
>> bool dds_valid;
>> int leap;
>> int pmc_ds_requested;
>> + bool signaling_cb_ena;
>> bool stay_subscribed;
>> int sync_offset;
>> int utc_offset_traceable;
>> @@ -127,6 +128,7 @@ static int run_pmc(struct pmc_agent *node, int
>> timeout, int ds_id,
>> #define N_FD 1
>> struct pollfd pollfd[N_FD];
>> int cnt, res;
>> + bool skip_cb;
>>
>> while (1) {
>> pollfd[0].fd = pmc_get_transport_fd(node->pmc);
>> @@ -178,7 +180,16 @@ static int run_pmc(struct pmc_agent *node, int
>> timeout, int ds_id,
>> node->pmc_ds_requested = 0;
>> return RUN_PMC_NODEV;
>> }
>> - if (res <= 0 ||
>> +
>> + /* Skip callback if message is not management */
>> + skip_cb = (res <= 0) ? true : false;
>> +
>> + /* Run the callback on signaling messages if configured */
>> + if (node->signaling_cb_ena && (msg_type(*msg) ==
>> SIGNALING)) {
>> + skip_cb = false;
>> + }
>> +
>>
>
> You can do:
>if (res == 0 && node->signaling_cb_ena && (msg_type(*msg)
> == SIGNALING)) {
>
if(node->recv_subscribed(node->recv_context, *msg,
> ds_id) {
> msg_put(*msg);
> *msg = NULL;
> continue;
> }
>}
>else if (node->recv_subscribed(node->recv_context, *msg,
> ds_id) ||
> management_tlv_id(*msg) != ds_id) {
> msg_put(*msg);
> *msg = NULL;
> continue;
>}
>
>
My code is wrong, but you should call "management_tlv_id(*msg)" only if the
message is a management.
> + if (skip_cb ||
>> node->recv_subscribed(node->recv_context, *msg,
>> ds_id) ||
>> management_tlv_id(*msg) != ds_id) {
>>
>
> This condition: "management_tlv_id(*msg) != ds_id" seems irrelevant to
> signaling messages.
>
>
>> msg_put(*msg);
>> @@ -430,3 +441,9 @@ bool pmc_agent_utc_offset_traceable(struct pmc_agent
>> *agent)
>> {
>> return agent->utc_offset_traceable;
>> }
>> +
>> +void pmc_agent_enable_signaling_cb(struct pmc_agent *agent, bool enable)
>> +{
>> + agent->signaling_cb_ena = enable;
>> +}
>> +
>> diff --git a/pmc_agent.h b/pmc_agent.h
>> index 2fb1cc8..9ae37f7 100644
>> --- a/pmc_agent.h
>> +++ b/pmc_agent.h
>> @@ -170,4 +170,11 @@ int pmc_agent_update(struct pmc_agent *agent);
>> */
>> bool pmc_agent_utc_offset_traceable(struct pmc_agent *agent);
>>
>> +/**
>> + * Enables or disables callback on signaling messages
>> + * @param agent Pointer to a PMC instance obtained via @ref
>> pmc_agent_create().
>> + * @param enable - if set to true, callback will be called on signaling
>> msgs
>> + */
>> +void pmc_agent_enable_signaling_cb(struct pmc_agent *agent, bool enable);
>>
>
> I like the name!
>
>
>> +
>> #endif
>> --
>> 2.30.2
>>
>>
> Great work
> Erez
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 1/2] pmc_agent: Add option to run callback for signaling messages
On Fri, 7 Apr 2023 at 17:15, Maciek Machnikowski
wrote:
> Add option to run callback that when the PMC agent receives signaling
> messages.
>
I support you!
>
> Signed-off-by: Maciek Machnikowski
> ---
> pmc_agent.c | 19 ++-
> pmc_agent.h | 7 +++
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/pmc_agent.c b/pmc_agent.c
> index 62d1a86..7ffcec8 100644
> --- a/pmc_agent.c
> +++ b/pmc_agent.c
> @@ -42,6 +42,7 @@ struct pmc_agent {
> bool dds_valid;
> int leap;
> int pmc_ds_requested;
> + bool signaling_cb_ena;
> bool stay_subscribed;
> int sync_offset;
> int utc_offset_traceable;
> @@ -127,6 +128,7 @@ static int run_pmc(struct pmc_agent *node, int
> timeout, int ds_id,
> #define N_FD 1
> struct pollfd pollfd[N_FD];
> int cnt, res;
> + bool skip_cb;
>
> while (1) {
> pollfd[0].fd = pmc_get_transport_fd(node->pmc);
> @@ -178,7 +180,16 @@ static int run_pmc(struct pmc_agent *node, int
> timeout, int ds_id,
> node->pmc_ds_requested = 0;
> return RUN_PMC_NODEV;
> }
> - if (res <= 0 ||
> +
> + /* Skip callback if message is not management */
> + skip_cb = (res <= 0) ? true : false;
> +
> + /* Run the callback on signaling messages if configured */
> + if (node->signaling_cb_ena && (msg_type(*msg) ==
> SIGNALING)) {
> + skip_cb = false;
> + }
> +
>
You can do:
if (res == 0 && node->signaling_cb_ena && (msg_type(*msg) ==
SIGNALING)) {
if(node->recv_subscribed(node->recv_context, *msg,
ds_id) {
msg_put(*msg);
*msg = NULL;
continue;
}
}
else if (node->recv_subscribed(node->recv_context, *msg,
ds_id) ||
management_tlv_id(*msg) != ds_id) {
msg_put(*msg);
*msg = NULL;
continue;
}
+ if (skip_cb ||
> node->recv_subscribed(node->recv_context, *msg, ds_id)
> ||
> management_tlv_id(*msg) != ds_id) {
>
This condition: "management_tlv_id(*msg) != ds_id" seems irrelevant to
signaling messages.
> msg_put(*msg);
> @@ -430,3 +441,9 @@ bool pmc_agent_utc_offset_traceable(struct pmc_agent
> *agent)
> {
> return agent->utc_offset_traceable;
> }
> +
> +void pmc_agent_enable_signaling_cb(struct pmc_agent *agent, bool enable)
> +{
> + agent->signaling_cb_ena = enable;
> +}
> +
> diff --git a/pmc_agent.h b/pmc_agent.h
> index 2fb1cc8..9ae37f7 100644
> --- a/pmc_agent.h
> +++ b/pmc_agent.h
> @@ -170,4 +170,11 @@ int pmc_agent_update(struct pmc_agent *agent);
> */
> bool pmc_agent_utc_offset_traceable(struct pmc_agent *agent);
>
> +/**
> + * Enables or disables callback on signaling messages
> + * @param agent Pointer to a PMC instance obtained via @ref
> pmc_agent_create().
> + * @param enable - if set to true, callback will be called on signaling
> msgs
> + */
> +void pmc_agent_enable_signaling_cb(struct pmc_agent *agent, bool enable);
>
I like the name!
> +
> #endif
> --
> 2.30.2
>
>
Great work
Erez
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v1 1/2] pmc_agent: Add callback for signaling messages
On Fri, 31 Mar 2023 at 13:35, Maciek Machnikowski
wrote:
> Add callback that will act on signaling messages.
>
Adding a second callback seems like an unnecessary overhead.
All you need is a simple boolean flag for adding signalling using the same
callback to receive both management and signaling messages.
In https://github.com/erezgeva/libptpmgmt/, I added an option to filter
signalling messages by their ID.
Erez
>
> Signed-off-by: Maciek Machnikowski
> ---
> phc2sys.c | 4 ++--
> pmc_agent.c | 17 -
> pmc_agent.h | 7 +--
> ts2phc.c| 2 +-
> 4 files changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/phc2sys.c b/phc2sys.c
> index 19e8012..16fd335 100644
> --- a/phc2sys.c
> +++ b/phc2sys.c
> @@ -1329,7 +1329,7 @@ int main(int argc, char *argv[])
>
> if (autocfg) {
> if (init_pmc_node(cfg, priv.agent, uds_local,
> - phc2sys_recv_subscribed, ))
> + phc2sys_recv_subscribed, , NULL,
> NULL))
> goto end;
> if (auto_init_ports(, rt) < 0)
> goto end;
> @@ -1346,7 +1346,7 @@ int main(int argc, char *argv[])
>
> if (wait_sync) {
> if (init_pmc_node(cfg, priv.agent, uds_local,
> - phc2sys_recv_subscribed, ))
> + phc2sys_recv_subscribed, , NULL,
> NULL))
> goto end;
>
> while (is_running()) {
> diff --git a/pmc_agent.c b/pmc_agent.c
> index 62d1a86..b9e3371 100644
> --- a/pmc_agent.c
> +++ b/pmc_agent.c
> @@ -49,6 +49,10 @@ struct pmc_agent {
> /* Callback on message reception */
> pmc_node_recv_subscribed_t *recv_subscribed;
> void *recv_context;
> +
> + /* Callback on signaling message reception */
> + pmc_node_recv_subscribed_t *recv_signaling;
> + void *signaling_context;
> };
>
> static void send_subscription(struct pmc_agent *node)
> @@ -178,6 +182,12 @@ static int run_pmc(struct pmc_agent *node, int
> timeout, int ds_id,
> node->pmc_ds_requested = 0;
> return RUN_PMC_NODEV;
> }
> +
> + if (msg_type(*msg) == SIGNALING && node->recv_signaling) {
> + node->recv_signaling(node->signaling_context, *msg,
> +ds_id);
> + }
> +
> if (res <= 0 ||
> node->recv_subscribed(node->recv_context, *msg, ds_id)
> ||
> management_tlv_id(*msg) != ds_id) {
> @@ -230,7 +240,9 @@ int run_pmc_wait_sync(struct pmc_agent *node, int
> timeout)
> }
>
> int init_pmc_node(struct config *cfg, struct pmc_agent *node, const char
> *uds,
> - pmc_node_recv_subscribed_t *recv_subscribed, void
> *context)
> + pmc_node_recv_subscribed_t *recv_subscribed, void
> *context,
> + pmc_node_recv_subscribed_t *signaling_subscribed,
> + void *signaling_context)
> {
> node->pmc = pmc_create(cfg, TRANS_UDS, uds, 0,
>config_get_int(cfg, NULL, "domainNumber"),
> @@ -242,6 +254,9 @@ int init_pmc_node(struct config *cfg, struct pmc_agent
> *node, const char *uds,
> node->recv_subscribed = recv_subscribed;
> node->recv_context = context;
>
> + node->recv_signaling = signaling_subscribed;
> + node->signaling_context = signaling_context;
> +
> return 0;
> }
>
> diff --git a/pmc_agent.h b/pmc_agent.h
> index 2fb1cc8..8a418ef 100644
> --- a/pmc_agent.h
> +++ b/pmc_agent.h
> @@ -32,8 +32,11 @@ struct pmc_agent;
> typedef int pmc_node_recv_subscribed_t(void *context, struct ptp_message
> *msg,
>int excluded);
>
> -int init_pmc_node(struct config *cfg, struct pmc_agent *agent, const char
> *uds,
> - pmc_node_recv_subscribed_t *recv_subscribed, void
> *context);
> +int init_pmc_node(struct config *cfg, struct pmc_agent *node, const char
> *uds,
> + pmc_node_recv_subscribed_t *recv_subscribed, void
> *context,
> + pmc_node_recv_subscribed_t *signaling_subscribed,
> + void *signaling_context);
> +
> int run_pmc_wait_sync(struct pmc_agent *agent, int timeout);
>
> /**
> diff --git a/ts2phc.c b/ts2phc.c
> index 4393059..b83ba3a 100644
> --- a/ts2phc.c
> +++ b/ts2phc.c
> @@ -668,7 +668,7 @@ int main(int argc, char *argv[])
>
> if (autoc
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Thu, 30 Mar 2023 at 03:03, Martin Pecka wrote: > > > The kernel is 1 year and 3 month old, it should work. > > You mean this device: https://developer.nvidia.com/embedded/jetson-tx2 > Yes. NVidia Jetson TX2. > > > > > > The device's NIC uses eqos driver and reports all the timestamping > > capabilities required for ptp4l: > > > > > > I do not find any 'eqos' driver in kernel 4.9.299. > > It is probably a private driver. Please ask your manufacturer for a > > full source code of the kernel. > > As it is a GPL 2 software, he should. > It can be found here: > > https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.7.3/nvidia/drivers/net/ethernet/nvidia/eqos/ethtool.c#L276 > . It seems to be a driver written directly by NVidia for their custom > NIC contained in the SoC. > > linuxptp version 4 is not published yet, I assume you use the last > > master version, which you build yourself. > I am compiling master branch myself. > > Do you use VLANs or bonds? > No. > > > > ptp4l[1045.420]: driver rejected most general HWTSTAMP filter > > ptp4l[1045.421]: ioctl SIOCSHWTSTAMP failed: Numerical result out > > of range > > > > > > I remember we did some upgrades regarding very old kernels, > > yet Linux 4.9 should work. > > However as the 'eqos' driver is private, the problem might be there. > > I have a suspicion regarding the code in sk.c: > > ```c++ > cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX; > /* Fall back without flag if user run new build on old kernel */ > if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL) > init_ifreq(, , device); > ``` > > The eqos driver returns EINVAL if any flag is set in the ioctl handler: > > https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.7.3/nvidia/drivers/net/ethernet/nvidia/eqos/drv.c#L3760 > . > > However, the ioctl call has result -1, which is not -EINVAL, but -EPERM. > There is no EPERM in the ioctl handler code. So I'm not sure what > mechanism kicks in that either doesn't even let the ioctl bubble to the > driver, or that changes the return code. The consequence is that the > fallback code is not called and thus the following ioctls try to first > get PTP_V2_EVENT timestamping with the bond flag (timestamping mode is > supported, but bonding is not), and then tries the rx_filter2, which is > in this case PTP_V2_L2_EVENT (which is not supported by the driver). > > Anyways, the fix for me would be checking the ioctl result also for > -EPERM instead of just -EINVAL. Or, would there be any downside to just > testing if the ioctl result is negative? I've tested the code with this > fix and it works for me. I have no idea about how it could or could not > influence bonds. > $ errno EINVAL EINVAL 22 Invalid argument $ errno EPERM EPERM 1 Operation not permitted The EINVAL error in the driver means that the configuration sent with the ioctl is not accepted by the driver. The configuration should match the capabilities you fetch with "ethtool -T eth0", as you mentioned. This EPERM error does not exist in the driver ioctl callback for a good reason. It is returned by the kernel network layer. Looking at kernel net source code https://elixir.bootlin.com/linux/v4.9.299/source/net For example in core/dev_ioctl.c It is usually returned for: ```c++ if (!capable(CAP_NET_ADMIN)) return -EPERM; ``` Or with network namespace ```c++ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) return -EPERM; ``` I do not think we want to check this error in sk.c. Unless the error was generated by something more reasonable. Erez > > Thanks for your help, Erez. > > Martin > > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix power profile config option range to UINT32_MAX
On Wed, 29 Mar 2023 at 20:36, Jacob Keller wrote:
> The power profile configuration options added in commit 7059a05a3fb2
> ("Introduce the power profile.") specify their maximum range as INT_MAX.
> The values are stored in UInteger32 values, and the default 0x is
> outside the range of a 32-bit integer. Because of this, on platforms which
> have 32-bit integers, ptp4l is unable to read the default configuration:
>
Just thinking.
Why not move to unsigned 64 bits?
It can solve future limitations.
I would also change the int to signed 64,
but I can understand it may require too many changes in the code.
Erez
>
> 0x is an out of range value for option
> power_profile.2011.grandmasterTimeInaccuracy at line 44
> failed to parse configuration file configs/default.cfg
> These values are unsigned and stored as fixed width values of 32 bits.
> Correct the configuration specification to allow the true maximum of an
> unsigned 32 bit integer.
>
> Signed-off-by: Jacob Keller
> ---
> I'm not sure if there is a simpler or better way to fix this. We could just
> update the range of CFG_TYPE_INT to be long (or long long) instead, which
> would give it a range big enough to cover all our current values...
>
> config.c | 54 +++---
> config.h | 3 +++
> port.c | 6 +++---
> 3 files changed, 57 insertions(+), 6 deletions(-)
>
> diff --git a/config.c b/config.c
> index cb4421f572c7..baf8352538ea 100644
> --- a/config.c
> +++ b/config.c
> @@ -51,6 +51,7 @@ enum config_section {
>
> enum config_type {
> CFG_TYPE_INT,
> + CFG_TYPE_UINT,
> CFG_TYPE_DOUBLE,
> CFG_TYPE_ENUM,
> CFG_TYPE_STRING,
> @@ -63,6 +64,7 @@ struct config_enum {
>
> typedef union {
> int i;
> + unsigned int u;
> double d;
> char *s;
> } any_t;
> @@ -109,6 +111,14 @@ struct config_item {
> .min.i = _min, \
> .max.i = _max, \
> }
> +#define CONFIG_ITEM_UINT(_label, _port, _default, _min, _max) {\
> + .label = _label, \
> + .type = CFG_TYPE_UINT,\
> + .flags = _port ? CFG_ITEM_PORT : 0,\
> + .val.u = _default, \
> + .min.u = _min, \
> + .max.u = _max, \
> +}
> #define CONFIG_ITEM_STRING(_label, _port, _default) { \
> .label = _label, \
> .type = CFG_TYPE_STRING, \
> @@ -125,6 +135,9 @@ struct config_item {
> #define GLOB_ITEM_INT(label, _default, min, max) \
> CONFIG_ITEM_INT(label, 0, _default, min, max)
>
> +#define GLOB_ITEM_UINT(label, _default, min, max) \
> + CONFIG_ITEM_UINT(label, 0, _default, min, max)
> +
> #define GLOB_ITEM_STR(label, _default) \
> CONFIG_ITEM_STRING(label, 0, _default)
>
> @@ -137,6 +150,9 @@ struct config_item {
> #define PORT_ITEM_INT(label, _default, min, max) \
> CONFIG_ITEM_INT(label, 1, _default, min, max)
>
> +#define PORT_ITEM_UINT(label, _default, min, max) \
> + CONFIG_ITEM_UINT(label, 1, _default, min, max)
> +
> #define PORT_ITEM_STR(label, _default) \
> CONFIG_ITEM_STRING(label, 1, _default)
>
> @@ -309,9 +325,9 @@ struct config_item config_tab[] = {
> GLOB_ITEM_DBL("pi_proportional_norm_max", 0.7, DBL_MIN, 1.0),
> GLOB_ITEM_DBL("pi_proportional_scale", 0.0, 0.0, DBL_MAX),
> PORT_ITEM_ENU("power_profile.version", IEEE_C37_238_VERSION_NONE,
> ieee_c37_238_enu),
> - PORT_ITEM_INT("power_profile.2011.grandmasterTimeInaccuracy",
> 0x, 0, INT_MAX),
> - PORT_ITEM_INT("power_profile.2011.networkTimeInaccuracy", 0, 0,
> INT_MAX),
> - PORT_ITEM_INT("power_profile.2017.totalTimeInaccuracy",
> 0x, 0, INT_MAX),
> + PORT_ITEM_UINT("power_profile.2011.grandmasterTimeInaccuracy",
> 0x, 0, UINT32_MAX),
> + PORT_ITEM_UINT("power_profile.2011.networkTimeInaccuracy", 0, 0,
> UINT32_MAX),
> + PORT_ITEM_UINT("power_profile.2017.totalTimeInaccuracy",
> 0x, 0, UINT32_MAX),
> PORT_ITEM_INT("power_profile.grandmasterID", 0, 0, 0x),
> GLOB_ITEM_INT("priority1", 128, 0, UINT8_MAX),
> GLOB_ITEM_INT("priority2", 128, 0, UINT8_MAX),
> @@ -559,6 +575,7 @@ static enum parser_result parse_item(struct config
> *cfg,
> enum parser_result r;
&
Re: [Linuxptp-devel] [PATCH 6/6] Use periodic timer for TX SYNC timeout.
Sorry I forgot another hint.
Please use the 'git format-patch' with the patch seria iteration flag '-v
'.
So we can differentiate the mails as newer :-)
This will change the subject to something like "Subject: [PATCH *v2* 0/6]
...."
Erez
On Wed, 29 Mar 2023 at 17:17, Erez wrote:
> You add a nice cover letter and good explanations on your patches.
> Now we wait for other developers' feedback.
>
> Just one last hint.
> We usually check the patch format with the kernel check patch tool.
> https://docs.kernel.org/dev-tools/checkpatch.html
> But you can do that after you get more feedbacks :-)
>
> Well done
>Erez
>
>
> On Wed, 29 Mar 2023 at 15:24, Luigi Mantellini
> wrote:
>
>> In order to obtain a precise TX SYNC frequency we need to use a periodic
>> timer facility instead to reconfigure the timer on every expiration.
>>
>> The solution consists to configure the it_interval field of the
>> itimerspec structure (see timerfd_create(2) man page) only when the port
>> goes into Master role and avoiding to call timerfd_settime() on timer
>> expiration.
>> ---
>> port.c | 15 ---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/port.c b/port.c
>> index 29b6870..3c7df6b 100644
>> --- a/port.c
>> +++ b/port.c
>> @@ -231,7 +231,7 @@ struct fdarray *port_fda(struct port *port)
>> return >fda;
>> }
>>
>> -int set_tmo_log(int fd, unsigned int scale, int log_seconds)
>> +static int set_tmo_log_periodic(int fd, unsigned int scale, int
>> log_seconds, bool periodic)
>> {
>> struct itimerspec tmo = {
>> {0, 0}, {0, 0}
>> @@ -255,9 +255,19 @@ int set_tmo_log(int fd, unsigned int scale, int
>> log_seconds)
>> } else
>> tmo.it_value.tv_sec = scale * (1 << log_seconds);
>>
>> + if (periodic) {;
>> + tmo.it_interval.tv_nsec = tmo.it_value.tv_nsec;
>> + tmo.it_interval.tv_sec = tmo.it_value.tv_sec;
>> + }
>> +
>> return timerfd_settime(fd, 0, , NULL);
>> }
>>
>> +int set_tmo_log(int fd, unsigned int scale, int log_seconds)
>> +{
>> + return set_tmo_log_periodic(fd, scale, log_seconds, false);
>> +}
>> +
>> int set_tmo_lin(int fd, int seconds)
>> {
>> struct itimerspec tmo = {
>> @@ -1297,7 +1307,7 @@ int port_set_sync_rx_tmo(struct port *p)
>>
>> static int port_set_sync_tx_tmo(struct port *p)
>> {
>> - return set_tmo_log(p->fda.fd[FD_SYNC_TX_TIMER], 1,
>> p->logSyncInterval);
>> + return set_tmo_log_periodic(p->fda.fd[FD_SYNC_TX_TIMER], 1,
>> p->logSyncInterval, true);
>> }
>>
>> void port_show_transition(struct port *p, enum port_state next,
>> @@ -2936,7 +2946,6 @@ static enum fsm_event bc_event(struct port *p, int
>> fd_index)
>> case FD_SYNC_TX_TIMER:
>> pr_debug("%s: master sync timeout", p->log_name);
>> timerfd_flush(p, fd, "master sync timeout");
>> - port_set_sync_tx_tmo(p);
>> p->service_stats.master_sync_timeout++;
>> return port_tx_sync(p, NULL, p->seqnum.sync++) ?
>> EV_FAULT_DETECTED : EV_NONE;
>> --
>> 2.40.0
>>
>>
>>
>> ___
>> 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 6/6] Use periodic timer for TX SYNC timeout.
You add a nice cover letter and good explanations on your patches.
Now we wait for other developers' feedback.
Just one last hint.
We usually check the patch format with the kernel check patch tool.
https://docs.kernel.org/dev-tools/checkpatch.html
But you can do that after you get more feedbacks :-)
Well done
Erez
On Wed, 29 Mar 2023 at 15:24, Luigi Mantellini
wrote:
> In order to obtain a precise TX SYNC frequency we need to use a periodic
> timer facility instead to reconfigure the timer on every expiration.
>
> The solution consists to configure the it_interval field of the
> itimerspec structure (see timerfd_create(2) man page) only when the port
> goes into Master role and avoiding to call timerfd_settime() on timer
> expiration.
> ---
> port.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/port.c b/port.c
> index 29b6870..3c7df6b 100644
> --- a/port.c
> +++ b/port.c
> @@ -231,7 +231,7 @@ struct fdarray *port_fda(struct port *port)
> return >fda;
> }
>
> -int set_tmo_log(int fd, unsigned int scale, int log_seconds)
> +static int set_tmo_log_periodic(int fd, unsigned int scale, int
> log_seconds, bool periodic)
> {
> struct itimerspec tmo = {
> {0, 0}, {0, 0}
> @@ -255,9 +255,19 @@ int set_tmo_log(int fd, unsigned int scale, int
> log_seconds)
> } else
> tmo.it_value.tv_sec = scale * (1 << log_seconds);
>
> + if (periodic) {;
> + tmo.it_interval.tv_nsec = tmo.it_value.tv_nsec;
> + tmo.it_interval.tv_sec = tmo.it_value.tv_sec;
> + }
> +
> return timerfd_settime(fd, 0, , NULL);
> }
>
> +int set_tmo_log(int fd, unsigned int scale, int log_seconds)
> +{
> + return set_tmo_log_periodic(fd, scale, log_seconds, false);
> +}
> +
> int set_tmo_lin(int fd, int seconds)
> {
> struct itimerspec tmo = {
> @@ -1297,7 +1307,7 @@ int port_set_sync_rx_tmo(struct port *p)
>
> static int port_set_sync_tx_tmo(struct port *p)
> {
> - return set_tmo_log(p->fda.fd[FD_SYNC_TX_TIMER], 1,
> p->logSyncInterval);
> + return set_tmo_log_periodic(p->fda.fd[FD_SYNC_TX_TIMER], 1,
> p->logSyncInterval, true);
> }
>
> void port_show_transition(struct port *p, enum port_state next,
> @@ -2936,7 +2946,6 @@ static enum fsm_event bc_event(struct port *p, int
> fd_index)
> case FD_SYNC_TX_TIMER:
> pr_debug("%s: master sync timeout", p->log_name);
> timerfd_flush(p, fd, "master sync timeout");
> - port_set_sync_tx_tmo(p);
> p->service_stats.master_sync_timeout++;
> return port_tx_sync(p, NULL, p->seqnum.sync++) ?
> EV_FAULT_DETECTED : EV_NONE;
> --
> 2.40.0
>
>
>
> ___
> 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] Use periodic timer for TX SYNC timeout
On Wed, 29 Mar 2023 at 14:37, Luigi 'Comio' Mantellini < luigi.mantell...@gmail.com> wrote: > Hi Erez, > > sorry, I usually use pull requests. > Me too :-) But using patch seria is cool too. > > > Il giorno mer 29 mar 2023 alle ore 14:29 Erez ha > scritto: > >> >> >> On Wed, 29 Mar 2023 at 11:28, Luigi Mantellini < >> luigi.mantell...@gmail.com> wrote: >> >>> The actual ptp4l implementation rearms timers on timeut. This doesn't >>> permit to have a precise TX SYNC >> >> >> Did you misspell "timeout"? >> > > yes > > >> >> >>> message scheduling. >>> The following patchset uses non blocking timers and only for TX SYNC >>> timer a periodic timer is used. >>> In addition, a periodic timer requires to read (and flush) the file >>> descriptor and a new timerfd_flush() function has been introduced for this. >>> >>> >> Cool :-) >> This explanation is coherent. >> >> We usually add a cover letter, using 'git format-patch' with the >> '--cover-letter' options. >> And please add a short explanation on the issue you solve to each patch >> (relevant to each patch). >> And if the solution is not trivial, a short explanation on the solution >> as well. >> >> I will provide it soon. Can you give a look at the code also? I tested > with a custom ethernet device and I cannot test with common hw (like intel > nic). > We have some Intel engineers, they will probably do. And also Miroslav Lichvar from Red hat that also provides a simulator, you can use for testing. Erez > Thanks, > > luigi > > Thanks >> Erez >> >> >>> e2e_tc.c | 28 +--- >>> fd.h | 4 ++-- >>> p2p_tc.c | 28 +--- >>> port.c | 102 >>> -- >>> port.h | 10 ++ >>> raw.c| 4 ++-- >>> udp.c| 4 ++-- >>> udp6.c | 4 ++-- >>> 8 files changed, 132 insertions(+), 52 deletions(-) >>> >>> [PATCH 1/6] Use constant FD_EVENT and FD_GENERAL instead numeric >>> [PATCH 2/6] Rearrange the fdarray in order to serve timers before >>> [PATCH 3/6] Flush timer fd after expiration >>> [PATCH 4/6] Split announce/sync_rx timer rearm on expiration fd >>> [PATCH 5/6] Use Non-blocking timer file descriptors >>> [PATCH 6/6] Use periodic timer for TX SYNC timeout >>> >>> >>> >>> ___ >>> Linuxptp-devel mailing list >>> Linuxptp-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel >>> >> > > -- > *Luigi 'Comio' Mantellini* > My Professional Profile <http://www.linkedin.com/in/comio> > > *"UNIX is very simple, it just needs a genius to understand its > simplicity." [cit.]* > > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Use periodic timer for TX SYNC timeout
On Wed, 29 Mar 2023 at 11:28, Luigi Mantellini wrote: > The actual ptp4l implementation rearms timers on timeut. This doesn't > permit to have a precise TX SYNC Did you misspell "timeout"? > message scheduling. > The following patchset uses non blocking timers and only for TX SYNC timer > a periodic timer is used. > In addition, a periodic timer requires to read (and flush) the file > descriptor and a new timerfd_flush() function has been introduced for this. > > Cool :-) This explanation is coherent. We usually add a cover letter, using 'git format-patch' with the '--cover-letter' options. And please add a short explanation on the issue you solve to each patch (relevant to each patch). And if the solution is not trivial, a short explanation on the solution as well. Thanks Erez > e2e_tc.c | 28 +--- > fd.h | 4 ++-- > p2p_tc.c | 28 +--- > port.c | 102 > -- > port.h | 10 ++ > raw.c| 4 ++-- > udp.c| 4 ++-- > udp6.c | 4 ++-- > 8 files changed, 132 insertions(+), 52 deletions(-) > > [PATCH 1/6] Use constant FD_EVENT and FD_GENERAL instead numeric > [PATCH 2/6] Rearrange the fdarray in order to serve timers before > [PATCH 3/6] Flush timer fd after expiration > [PATCH 4/6] Split announce/sync_rx timer rearm on expiration fd > [PATCH 5/6] Use Non-blocking timer file descriptors > [PATCH 6/6] Use periodic timer for TX SYNC timeout > > > > ___ > 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] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Wed, 29 Mar 2023 at 11:27, Martin Pecka wrote: > Hello, > > I'm using linuxptp from master branch on a Jetson TX2 device, where > unfortunately only kernel 4.9.299 is available from the manufacturer. > commit 224d99f50f25ec3234b99556c0076a7130e230c6 (tag: v4.9.299) Author: Greg Kroah-Hartman Date: Sat Jan 29 10:15:58 2022 +0100 Linux 4.9.299 The kernel is 1 year and 3 month old, it should work. You mean this device: https://developer.nvidia.com/embedded/jetson-tx2 > > The device's NIC uses eqos driver and reports all the timestamping > capabilities required for ptp4l: > I do not find any 'eqos' driver in kernel 4.9.299. It is probably a private driver. Please ask your manufacturer for a full source code of the kernel. As it is a GPL 2 software, he should. > > $ ethtool -T eth0 > Time stamping parameters for eth0: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) > hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 0 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on(HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req(HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) > ptpv2-l4-delay-req(HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) > ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) > ptpv2-l2-delay-req(HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > > After updating to v4.0, I've noticed ptp4l cannot run with hardware > timestamping: > linuxptp version 4 is not published yet, I assume you use the last master version, which you build yourself. > > $ sudo ptp4l -H -i eth0 -f /etc/linuxptp/automotive-slave.cfg -m -l6 > ptp4l[1045.377]: selected /dev/ptp0 as PTP clock > ptp4l[1045.420]: driver rejected most general HWTSTAMP filter > ptp4l[1045.421]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range > ptp4l[1045.456]: port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) > > With the older version I used before (something after v3.1), it worked > flawlessly. > I remember we did some upgrades regarding very old kernels, yet Linux 4.9 should work. However as the 'eqos' driver is private, the problem might be there. > > Using git bisect, I've concluded that commit afeabf3 "ptp4l: add VLAN > over bond support" is the bad one. > > If I comment out this part in sk.c, I get HW timestamping working again > (line 67 onwards on current master): > Could be, then find the bug, please :-) Do you use VLANs or bonds? As the linuxptp should work the same without them. > > init_ifreq(, , device); > > //cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX; > /* Fall back without flag if user run new build on old kernel */ > //if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL) > // init_ifreq(, , device); > > What would be the best way to fix this properly? > If linuxptp has a bug, we should fix it. If the bug is in the 'eqos' driver, then the fix should be there. :-) Richard, do you think we should wait with commit afeabf3 "ptp4l: add VLAN over bond support"? Erez > Thanks, > > Martin > > ___ > 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] Add option to bind raw and UDP sockets to interface
On Tue, 14 Mar 2023 at 20:27, Richard Cochran wrote: > On Tue, Mar 14, 2023 at 12:38:06PM +0200, Kamil Zaripov wrote: > > Can you explain the problems you see with timestamping in the interface > on top of a bridge? > > When a MAC joins a bridge, the MAC is no longer avaiable as a network > interface. This is how the bridge thing is implemented in Linux. > There are also other options for creating bridges, i.e. like using the dsa driver. But the overall result is the same. With the dsa, you can only access the "host interface" not the external ports. Erez > Thanks, > Richard > > > ___ > 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] Add option to bind raw and UDP sockets to interface
On Mon, 13 Mar 2023 at 12:12, Kamil Zaripov wrote: > > > On 12 Mar 2023, at 14:18, Erez wrote: > > Sounds cool, but requires multiple clocks on the network interface. > Hardware or logic using a single hardware clock. > I do know that some do work on this. > Both in kernel and on application level. > > If we talk about ptp4l I think that two processes that synchronise their > access to the timestamping capabilities can run simultaneously on the same > “physical” network interface. And this patch designed change only ptp4l > process behaviour. It it affects other tools I need to fix it. > > Usually VLAN in Linux are deployed by adding a network interface for the > VLAN. > How is this patch feat to the Linux deployment of VLANs. > Nor do I see how this patch integrates with using multiple clocks. > > Please enlighten us. > > Erez > > > Actually I do not understand this question. Can you rephrase it? > As Richard explains. We use Linux VLAN. For example see "Create the VLAN device" https://wiki.archlinux.org/title/VLAN The vlan interface should point to the PHC associated with the network interface. The only problem is what happens if on top of a single network interface, you have several PTP networks, using VLANs. I do not refer to a bridge, but to an end device of several VLANs in which each VLANs use a separate PTP network. For this case you need multiple PHC. I assume you do not plan that yet. But once we do, we will need support to select a network interface and a PHP. But till then the Linux VLAN interface should be sufficient. Do you have other plans? As for Bridge. I am content with Richard replys. ptp4l is used as a PTP end device only. That could also explain why Richard did not like the virtual ports idea, as it might require the ptp4l to work as a virtual bridge :-) Erez > > Regards, > Zaripov Kamil. > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Set controlField to zero in message headers
On Tue, 28 Feb 2023 at 01:49, Andrew Zaborowski
wrote:
> From: Christopher S M Hall
>
> IEEE1588-2019 and 802.1AS-2020 both require the field to be 0 in
> transmitted messages except when the "version 1 hardware option" is set
> (IEEE1588-2019 C.4.2) and only with IPv4. Since ptp4l isn't padding
> the UDP messages to 124 bytes as required for compatibility with the
> "V.1 Hardware" implementations, assume that we're not dealing with such
> hardware, do not implement the option as defined in C.4.2.
>
Make sense.
Why not clean it all?
There are more places that assign the controlField.
$ git grep -l 'header.control\s*='
nsm.c
pmc_common.c
port_signaling.c
tc.c
> Since the default behaviour changes, in principle this could break
>
May break when using non Linuxptp, as far as I understand, linuxptp only
sets the field, but never checks the value.
Anyhow we do not support PTP version 1 hardware,
so perhaps it is better to break faster :-)
Erez
things. It is similar to 2a2532d66121 ("Bump to IEEE 1588-2019 version")
> however, where ptp4l switches the version field to the IEEE1588-2019
> value.
>
> Signed-off-by: Andrew Zaborowski
> ---
> The original patch added a per-port v1_hw_support option that would
> force the previous controlField values but it wasn't implementing the
> rest of the C.4.2 logic so with no indication that there's a use case
> for such partial support and no mention in the specification, I dropped
> it.
>
> port.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/port.c b/port.c
> index 3453716..76f817c 100644
> --- a/port.c
> +++ b/port.c
> @@ -1544,7 +1544,6 @@ static int port_pdelay_request(struct port *p)
> msg->header.correction = -p->asymmetry;
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = p->seqnum.delayreq++;
> - msg->header.control= CTL_OTHER;
> msg->header.logMessageInterval = port_is_ieee8021as(p) ?
> p->logPdelayReqInterval : 0x7f;
>
> @@ -1608,7 +1607,6 @@ int port_delay_request(struct port *p)
> msg->header.correction = -p->asymmetry;
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = p->seqnum.delayreq++;
> - msg->header.control= CTL_DELAY_REQ;
> msg->header.logMessageInterval = 0x7f;
>
> if (p->hybrid_e2e) {
> @@ -1660,7 +1658,6 @@ int port_tx_announce(struct port *p, struct address
> *dst, uint16_t sequence_id)
> msg->header.domainNumber = clock_domain_number(p->clock);
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = sequence_id;
> - msg->header.control= CTL_OTHER;
> msg->header.logMessageInterval = p->logAnnounceInterval;
>
> msg->header.flagField[1] = tp.flags;
> @@ -1743,7 +1740,6 @@ int port_tx_sync(struct port *p, struct address
> *dst, uint16_t sequence_id)
> msg->header.domainNumber = clock_domain_number(p->clock);
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = sequence_id;
> - msg->header.control= CTL_SYNC;
> msg->header.logMessageInterval = p->logSyncInterval;
>
> if (p->timestamping != TS_ONESTEP && p->timestamping !=
> TS_P2P1STEP) {
> @@ -1779,7 +1775,6 @@ int port_tx_sync(struct port *p, struct address
> *dst, uint16_t sequence_id)
> fup->header.domainNumber = clock_domain_number(p->clock);
> fup->header.sourcePortIdentity = p->portIdentity;
> fup->header.sequenceId = sequence_id;
> - fup->header.control= CTL_FOLLOW_UP;
> fup->header.logMessageInterval = p->logSyncInterval;
>
> fup->follow_up.preciseOriginTimestamp =
> tmv_to_Timestamp(msg->hwts.ts);
> @@ -2130,7 +2125,6 @@ static int process_delay_req(struct port *p, struct
> ptp_message *m)
> msg->header.correction = m->header.correction;
> msg->header.sourcePortIdentity = p->portIdentity;
> msg->header.sequenceId = m->header.sequenceId;
> - msg->header.control= CTL_DELAY_RESP;
> msg->header.logMessageInterval = p->logMinDelayReqInterval;
>
> msg->delay_resp.receiveTimestamp = tmv_to_Timestamp(m->hwts.ts);
> @@ -2321,7 +2315,6 @@ int process_pdelay_req(struct port *p, struct
> ptp_message *m)
> rsp->header.domainNumber = m->header.domainN
[Linuxptp-devel] The new application 'tz2alt' is missed in .gitignore
Hi Richard, You forgot to add 'tz2alt' to .gitignore. Erez ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Code freeze for 4.0 release
On Wed, 22 Feb 2023 at 16:07, Richard Cochran wrote: > Dear Devs, > > I'll be releasing 4.0 in the next day or two. I won't be taking any > Great :-) Will your power profile patch be included? It looks like it passed the review. Erez > new stuff until after the release. If you have any last minute > critical bug fixes, please let me know ASAP. > > Thanks, > Richard > > > ___ > 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 v4 11/11] Introduce a time zone helper program.
On Mon, 13 Feb 2023 at 10:32, Miroslav Lichvar wrote:
> On Sat, Feb 11, 2023 at 07:51:27AM -0800, Richard Cochran wrote:
> > On Wed, Feb 01, 2023 at 04:52:15PM +0100, Miroslav Lichvar wrote:
> >
> > > > + if (next) {
> > > > + atop.jumpSeconds = next->local_tai_offset -
> tz->local_tai_offset;
> > > > + atop.timeOfNextJump.seconds_lsb = next->timestamp;
> > > > + }
> > >
> > > Is this intentionally not setting the _msb field, ignoring distant
> future?
> >
> > Yes, it is intentional. The LSB is 32 bits of seconds, so the range is
> >
> > (/ (/ (/ 4294967295 3600) 24) 365) = 136 years
> >
> > It is hard for me to understand why a time zone should change more
> > that one year in the future from a given date?
>
> Isn't timeOfNextJump an absolute time, i.e. will it not overflow 136
> years after the epoch?
>
>From IEEE 1558-2019
"16.3.3.7 timeOfNextJump (UInteger48)
The value of timeOfNextJump shall be the value of the seconds portion of
the PTP Instance Time of the transmitting PTP Instance at the time that the
next discontinuity will occur.
The discontinuity occurs at the start of the second indicated by the value
of timeOfNextJump.
NOTE—If the alternate timescale implements a leap second correction
(e.g., if the alternate timescale is a local timescale at the time of a
leap second,
or if the option of this subclause is being used to compute UTC time at
the time of a leap second),
timeOfNextJump is the time when = TAI – UTC changes.
This time is specified by the IERS (see 7.2.4 and IERS Bulletin C).
..."
I agree with Miroslav.
POSIX also address the issue regarding the 'time_t' type:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html
"Implementations in which *time_t* is a 32-bit signed integer (many
historical implementations) fail in the year 2038.
POSIX.1-2017 does not address this problem.
However, the use of the *time_t* type is mandated in order to ease the
eventual fix."
"In a future version of this volume of POSIX.1-2017, *time_t* is likely to
be required to be capable of representing times far in the future.
Whether this will be mandated as a 64-bit type or a requirement that a
specific date in the future be representable (for example, 1 AD) is not
yet determined.
Systems purchased after the approval of this volume of POSIX.1-2017 should
be evaluated to determine whether their lifetime will extend past 2038."
Seems that instead of 'BUG 2000', we will have 'Bug 2038' :-)
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 v4 06/11] Prepare clock based storage of up to four time zones.
On Sat, 2023-01-28 at 14:43 -0800, Richard Cochran wrote:
> Signed-off-by: Richard Cochran
> ---
> clock.c | 19 ---
> tz.h | 26 ++
> 2 files changed, 42 insertions(+), 3 deletions(-)
> create mode 100644 tz.h
>
> diff --git a/clock.c b/clock.c
> index 134c7c3..767599b 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -42,6 +42,7 @@
> #include "rtnl.h"
> #include "tlv.h"
> #include "tsproc.h"
> +#include "tz.h"
> #include "uds.h"
> #include "util.h"
>
> @@ -79,6 +80,15 @@ struct clock_subscriber {
> time_t expiration;
> };
>
> +struct time_zone {
> + bool enabled;
> + int32_t current_offset;
> + int32_t jump_seconds;
> + uint16_t next_jump_msb;
> + uint32_t next_jump_lsb;
> + struct static_ptp_text display_name;
> +};
> +
> struct clock {
> enum clock_type type;
> struct config *config;
> @@ -137,6 +147,7 @@ struct clock {
> struct monitor *slave_event_monitor;
> int step_window_counter;
> int step_window;
> + struct time_zone tz[MAX_TIME_ZONES];
> };
>
> struct clock the_clock;
> @@ -894,19 +905,17 @@ int clock_required_modes(struct clock *c)
> struct clock *clock_create(enum clock_type type, struct config
> *config,
> const char *phc_device)
> {
> + int conf_phc_index, i, max_adj = 0, phc_index, required_modes
> = 0, sfl, sw_ts;
> enum servo_type servo = config_get_int(config, NULL,
> "clock_servo");
> char ts_label[IF_NAMESIZE], phc[32], *tmp;
> enum timestamp_type timestamping;
> - int phc_index, conf_phc_index, required_modes = 0;
> struct clock *c = _clock;
> - int max_adj = 0, sw_ts;
> const char *uds_ifname;
> double fadj = 0.0;
> struct port *p;
> unsigned char oui[OUI_LEN];
> struct interface *iface;
> struct timespec ts;
> - int sfl;
>
> clock_gettime(CLOCK_REALTIME, );
> srandom(ts.tv_sec ^ ts.tv_nsec);
> @@ -1201,6 +1210,10 @@ struct clock *clock_create(enum clock_type
> type, struct config *config,
> c->dad.pds.observedParentClockPhaseChangeRate =
> 0x7fff;
> c->dad.ptl = c->ptl;
>
> + for (i = 0; i < MAX_TIME_ZONES; i++) {
> + c->tz[i].display_name.max_symbols =
> MAX_TZ_DISPLAY_NAME;
> + }
> +
> clock_sync_interval(c, 0);
>
> LIST_INIT(>subscribers);
> diff --git a/tz.h b/tz.h
> new file mode 100644
> index 000..986f976
> --- /dev/null
> +++ b/tz.h
> @@ -0,0 +1,26 @@
> +/**
> + * @file tz.h
> + * @brief Implements time zone constants.
> + * @note Copyright (C) 2021 Richard Cochran <
> richardcoch...@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as published
> by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> along
> + * with this program; if not, write to the Free Software Foundation,
> Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
Perhaps we can use SPDX, like the Linux kernel do?
https://www.kernel.org/doc/html/latest/process/license-rules.html
https://spdx.dev/
> +#ifndef HAVE_TZ_H
> +#define HAVE_TZ_H
> +
> +#define MAX_TZ_DISPLAY_NAME10
> +#define MAX_TIME_ZONES 4
> +
> +#endif
Erez
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v4 05/11] tlv: Encode and decode alternate time offset indicator TLVs.
On Sat, 2023-01-28 at 14:43 -0800, Richard Cochran wrote:
> Signed-off-by: Richard Cochran
> ---
> tlv.c | 58
> ++
> tlv.h | 26 ++
> 2 files changed, 84 insertions(+)
>
> diff --git a/tlv.c b/tlv.c
> index 2e421ed..212414f 100644
> --- a/tlv.c
> +++ b/tlv.c
> @@ -77,6 +77,22 @@ static uint16_t flip16(void *p)
> return v;
> }
>
> +static void host2net32_unaligned(void *p)
> +{
> + int32_t v;
> + memcpy(, p, sizeof(v));
> + v = htonl(v);
> + memcpy(p, , sizeof(v));
> +}
> +
> +static void net2host32_unaligned(void *p)
> +{
> + int32_t v;
> + memcpy(, p, sizeof(v));
> + v = ntohl(v);
> + memcpy(p, , sizeof(v));
> +}
> +
> static int64_t host2net64_unaligned(void *p)
> {
> int64_t v;
> @@ -111,6 +127,43 @@ static bool tlv_array_invalid(struct TLV *tlv,
> size_t base_size, size_t item_siz
> return (tlv->length == expected_length) ? false : true;
> }
>
> +static int alttime_offset_post_recv(struct tlv_extra *extra)
> +{
> + struct TLV *tlv = extra->tlv;
> + struct alternate_time_offset_indicator_tlv *atoi =
> + (struct alternate_time_offset_indicator_tlv *) tlv;
> +
> + if (tlv->length < sizeof(struct
> alternate_time_offset_indicator_tlv) +
> + atoi->displayName.length - sizeof(struct TLV)) {
> + return -EBADMSG;
> + }
> +
> + NTOHS(atoi->type);
> + NTOHS(atoi->length);
> + /* Message alignment broken by design. */
> + net2host32_unaligned(>currentOffset);
> + net2host32_unaligned(>jumpSeconds);
> + flip16(>timeOfNextJump.seconds_msb);
> + net2host32_unaligned(>timeOfNextJump.seconds_lsb);
> +
> + return 0;
> +}
> +
> +static void alttime_offset_pre_send(struct tlv_extra *extra)
> +{
> + struct alternate_time_offset_indicator_tlv *atoi;
> +
> + atoi = (struct alternate_time_offset_indicator_tlv *) extra-
> >tlv;
> +
> + HTONS(atoi->type);
> + HTONS(atoi->length);
> + /* Message alignment broken by design. */
> + host2net32_unaligned(>currentOffset);
> + host2net32_unaligned(>jumpSeconds);
> + flip16(>timeOfNextJump.seconds_msb);
> + host2net32_unaligned(>timeOfNextJump.seconds_lsb);
> +}
> +
> static int mgt_post_recv(struct management_tlv *m, uint16_t
> data_len,
> struct tlv_extra *extra)
> {
> @@ -1035,6 +1088,8 @@ int tlv_post_recv(struct tlv_extra *extra)
> }
> break;
> case TLV_ALTERNATE_TIME_OFFSET_INDICATOR:
> + result = alttime_offset_post_recv(extra);
> + break;
> case TLV_AUTHENTICATION_2008:
> case TLV_AUTHENTICATION_CHALLENGE:
> case TLV_SECURITY_ASSOCIATION_UPDATE:
> @@ -1098,7 +1153,10 @@ void tlv_pre_send(struct TLV *tlv, struct
> tlv_extra *extra)
> unicast_negotiation_pre_send(tlv);
> break;
> case TLV_PATH_TRACE:
> + break;
> case TLV_ALTERNATE_TIME_OFFSET_INDICATOR:
> + alttime_offset_pre_send(extra);
> + break;
> case TLV_AUTHENTICATION_2008:
> case TLV_AUTHENTICATION_CHALLENGE:
> case TLV_SECURITY_ASSOCIATION_UPDATE:
> diff --git a/tlv.h b/tlv.h
> index 3dbce4f..a1a7dbc 100644
> --- a/tlv.h
> +++ b/tlv.h
> @@ -175,6 +175,32 @@ struct grant_unicast_xmit_tlv {
> uint8_t flags;
> } PACKED;
>
> +struct alternate_time_offset_indicator_tlv {
> + Enumeration16 type;
> + UInteger16 length;
> + UInteger8 keyField;
> + /* Message alignment broken by design. */
> + Integer32 currentOffset;
> + Integer32 jumpSeconds;
> + struct {
> + uint16_t seconds_msb; /* 16 bits + */
> + uint32_t seconds_lsb; /* 32 bits = 48 bits*/
> + } PACKED timeOfNextJump;
> + struct PTPText displayName;
> +} PACKED;
> +
> +struct alternate_time_offset_properties {
> + UInteger8 keyField;
> + /* Message alignment broken by design. */
> + Integer32 currentOffset;
> + Integer32 jumpSeconds;
> + struct {
> + uint16_t seconds_msb; /* 16 bits + */
> + uint32_t seconds_lsb; /* 32 bits = 48 bits*/
> + } PACKED timeOfNextJump;
> + uint8_t pad;
> +} PACKED;
> +
> struct management_tlv {
> E
Re: [Linuxptp-devel] [PATCH v3 1/4] [Interface Rate TLV] function to support get interface speed via ethtool
On Thu, 29 Dec 2022 at 08:02, Devasish Dey
wrote:
> Hi Erez,
>
>
>> > + goto failed;
>> > + }
>>
>> I think it is better to merge this ioctl and the socket creation with
>> sk_get_ts_info().
>> No reason for duplication.
>> You can use a static function or inline one.
>
> The existing code seems to be more readable. One socket creation during
> link events and init time is not much heavy operation.
>
Code duplication is usually lighter, this is not an excuse to do so.
Readable is a lame excuse for laziness and bad coding, please avoid.
I respect your opinion anyhow.
Using shared code helps in avoiding duplicate bugs.
And when we improve code, we only need to do so once :-)
>
> > + /* clear data and ensure it is not marked valid */
>> > + memset(if_info, 0, sizeof(struct sk_if_info));
>> > + return -1;
>>
>> You need to close the socket!
>
> The close call is in place. The code structure has been kept similar
> to sk_get_ts_info. We want to follow the same
>
Yes, the same function structure in sk_get_ts_info().
That is why you should use common code, to avoid similar bugs in both
functions.
Also, we may want to use more functions like that in the future, or perhaps
using a new ioctl in the future..
This is why we try to avoid code duplications. (of more than 3 lines of
code :-)
> coding guidelines.
>
> Moreover, the bit period calculation has been updated with the new patch
> and will get called during initialization and whenever there is a link
> event.
>
Very good, as you submit a new version of the patch, we do try to catch up
and review them.
>
> Thanks,
> Devasish.
>
>
Erez
>
> On Wed, 14 Dec 2022 at 09:04, Richard Cochran
> wrote:
>
>> On Tue, Dec 13, 2022 at 10:39:59AM +0530, Devasish Dey wrote:
>>
>> > > +struct sk_if_info {
>> > > + bool valid;
>> > It is better not to use bool in a structure, as the size is usually
>> > int, i.e. 64 bits to hold 1 bit.
>>
>> Because we don't have huge arrays of these structs, the size isn't
>> critical IMO.
>>
>> > [Devasish]: Earlier we had it as an integer. We can update it to
>> uint8_t as
>> > well. But Richard suggested updating it to Boolean.
>> > So, leaving this to Richard.
>>
>> I think 'bool' is fine here.
>>
>> Thanks,
>> Richard
>>
> ___
> 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 v4 2/4] [Interface Rate TLV] adding speed field information for interface
On Thu, 29 Dec 2022 at 07:52, SyncMonk Technologies
wrote:
> Get the interface speed related information using ethtool and
> convert interface speed to bit rate in attoseconds per bit.
>
> v4: adding interface bit period in iface_if_info. This bit period
> is updated during init time and whenever there are port events
> like link up and down and speed updates.
>
> Signed-off-by: Greg Armstrong
> Signed-off-by: Leon Goldin
> Signed-off-by: Devasish Dey
> Signed-off-by: Vipin Sharma
> ---
> clock.c | 6 --
> interface.c | 12
> interface.h | 14 ++
> port.c | 5 +
> sk.c| 2 ++
> sk.h| 2 ++
> 6 files changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/clock.c b/clock.c
> index 134c7c3..94da41b 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -1005,11 +1005,13 @@ struct clock *clock_create(enum clock_type type,
> struct config *config,
> memset(ts_label, 0, sizeof(ts_label));
> if (!rtnl_get_ts_device(interface_name(iface), ts_label))
> interface_set_label(iface, ts_label);
> + /* Interface speed information */
> + interface_get_ifinfo(iface);
> interface_get_tsinfo(iface);
> if (interface_tsinfo_valid(iface) &&
> - !interface_tsmodes_supported(iface, required_modes)) {
> + !interface_tsmodes_supported(iface,
> required_modes)) {
>
Do you use Linux kernel alignment?
Why is that line shift?
> pr_err("interface '%s' does not support requested
> timestamping mode",
> - interface_name(iface));
> + interface_name(iface));
> return NULL;
> }
> }
> diff --git a/interface.c b/interface.c
> index 6c2630c..8524719 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -12,6 +12,7 @@ struct interface {
> char name[MAX_IFNAME_SIZE + 1];
> char ts_label[MAX_IFNAME_SIZE + 1];
> struct sk_ts_info ts_info;
> + struct sk_if_info if_info;
> int vclock;
> };
>
> @@ -40,11 +41,22 @@ int interface_get_tsinfo(struct interface *iface)
> return sk_get_ts_info(iface->ts_label, >ts_info);
> }
>
> +int interface_get_ifinfo(struct interface *iface)
> +{
> + return sk_get_if_info(iface->ts_label, >if_info);
> +}
> +
> const char *interface_label(struct interface *iface)
> {
> return iface->ts_label;
> }
>
> +bool interface_ifinfo_valid(struct interface *iface)
> +{
> + return iface->if_info.valid ? true : false;
>
Boolean does not need to be translated to boolean.
You can simply "valid != 0", depending on 'valid' value.
Another one popular in Linux kernel is "!!valid".
> +}
> +
> +
> const char *interface_name(struct interface *iface)
> {
> return iface->name;
> diff --git a/interface.h b/interface.h
> index 5fc7836..5289a7f 100644
> --- a/interface.h
> +++ b/interface.h
> @@ -40,6 +40,13 @@ void interface_destroy(struct interface *iface);
> */
> int interface_get_tsinfo(struct interface *iface);
>
> +/**
> + * Populate the time stamping information of a given interface.
> + * @param iface The interface of interest.
> + * @return zero on success, negative on failure.
> + */
> +int interface_get_ifinfo(struct interface *iface);
> +
> /**
> * Obtain the time stamping label of a network interface. This can be
> * different from the name of the interface when bonding is in effect.
> @@ -77,6 +84,13 @@ void interface_set_label(struct interface *iface, const
> char *label);
> */
> bool interface_tsinfo_valid(struct interface *iface);
>
> +/**
> + * Tests whether an interface's interface information is valid or not.
> + * @param iface The interface of interest.
> + * @return True if the interface information is valid, false
> otherwise.
> + */
> +bool interface_ifinfo_valid(struct interface *iface);
> +
> /**
> * Tests whether an interface supports a set of given time stamping modes.
> * @param iface The interface of interest.
> diff --git a/port.c b/port.c
> index 6baf5c8..2a96c40 100644
> --- a/port.c
> +++ b/port.c
> @@ -2741,6 +2741,11 @@ void port_link_status(void *ctx, int linkup, int
> ts_index)
> p->link_status = link_state;
> } else {
> p->link_status = link_state | LINK_STATE_CHANGED;
> + /* Update Interface speed information on Link up*/
> + if (linkup) {
> + interface_get_ifinfo(p->iface);
> + }
> +
> pr_notice("%s: link %s", p->log_name, linkup ? "up" :
> "down");
> }
>
> diff --git a/sk.c b/sk.c
> index 1c14ca3..2e4ef2c 100644
> --- a/sk.c
> +++ b/sk.c
> @@ -267,6 +267,8 @@ int sk_get_if_info(const char *name, struct sk_if_info
> *if_info)
> if_info->valid = 1;
>
Perhaps using "valid = true" and "valid =
Re: [Linuxptp-devel] [PATCH] raw: Use BPF filter based on tcpdump syntax.
On Thu, 22 Dec 2022 at 18:41, Sebastian Andrzej Siewior <
bige...@linutronix.de> wrote:
> Replace the hand written BPF code with something that has been created
>
We love tcpdump and use its output as reference.
But we prefer using opcodes, we can understand and NOT numbers generated by
tcpdump, as we are human, not machines.
> by tcpdump based on a filter rule. This has the advantage that it can be
> extended/ modified based text syntax and is safer to extend in regard to
> jump labels.
> The generated asm/ BFP code is longer by one opcode because the "and"
>
You are welcome to improve the filter, simply translate the tcpdump numbers
back to opcodes, add new opcodes if you miss them.
If the result filter is shorter then we are happy and open for
improvements. :-)
> operation from VLAN and non-VLAN comparison is not optimized/ merged as
> it is the case in the hand-written code.
>
We are happy for better filters and optimization improvements.
> Also provide two structs/ filters which either filter for the generic or
> event PTP packet instead of accessing the struct directly and changing
> the jump opcode.
>
> The result is less readable if it comes to offsets. If this is an issue
> than it could be optimized with some kind of pre-processor.
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> contain.h | 2 ++
> ether.h | 2 --
> raw.c | 104 ++
> 3 files changed, 76 insertions(+), 32 deletions(-)
>
> diff --git a/contain.h b/contain.h
> index e0090bca7dffa..a611a9f640945 100644
> --- a/contain.h
> +++ b/contain.h
> @@ -30,4 +30,6 @@
> (type *)( (char *)__mptr - offsetof(type, member) );\
> })
>
> +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>
We already have this macro in pmc_common.c.
Perhaps, we should share it a cross?
> +
> #endif
> diff --git a/ether.h b/ether.h
> index 8ec96691468b6..276eec44997db 100644
> --- a/ether.h
> +++ b/ether.h
> @@ -48,6 +48,4 @@ struct vlan_hdr {
> uint16_t type;
> } __attribute__((packed));
>
>
Please use this macro, it would be nice if you add a note.
"This is the offset of the ethernet type in the ethernet header".
> -#define OFF_ETYPE (2 * sizeof(eth_addr))
> -
> #endif
> diff --git a/raw.c b/raw.c
> index b9abe7a4f7c96..a76fab67242d3 100644
> --- a/raw.c
> +++ b/raw.c
> @@ -55,50 +55,94 @@ struct raw {
> int vlan;
> };
>
> No need to remove, just add a short explanation on each opcode :-)
> -#define OP_AND (BPF_ALU | BPF_AND | BPF_K)
> -#define OP_JEQ (BPF_JMP | BPF_JEQ | BPF_K)
> -#define OP_JUN (BPF_JMP | BPF_JA)
> -#define OP_LDB (BPF_LD | BPF_B | BPF_ABS)
> -#define OP_LDH (BPF_LD | BPF_H | BPF_ABS)
> -#define OP_RETK (BPF_RET | BPF_K)
> -
> #define PTP_GEN_BIT 0x08 /* indicates general message, if set in message
> type */
>
> -#define N_RAW_FILTER12
> -#define RAW_FILTER_TEST 9
>
This was ugly, no real reason to use :-)
> -
> #define PRP_MIN_PACKET_LEN 70
> #define PRP_TRAILER_LEN 6
>
> -static struct sock_filter raw_filter[N_RAW_FILTER] = {
> - {OP_LDH, 0, 0, OFF_ETYPE },
> - {OP_JEQ, 0, 4, ETH_P_8021Q }, /*f goto non-vlan block*/
> - {OP_LDH, 0, 0, OFF_ETYPE + 4},
> - {OP_JEQ, 0, 7, ETH_P_1588 }, /*f goto reject*/
> - {OP_LDB, 0, 0, ETH_HLEN + VLAN_HLEN },
> - {OP_JUN, 0, 0, 2}, /*goto test general bit*/
> - {OP_JEQ, 0, 4, ETH_P_1588 }, /*f goto reject*/
> - {OP_LDB, 0, 0, ETH_HLEN},
> - {OP_AND, 0, 0, PTP_GEN_BIT }, /*test general bit*/
> - {OP_JEQ, 0, 1, 0 }, /*0,1=accept event; 1,0=accept
> general*/
> - {OP_RETK, 0, 0, 1500}, /*accept*/
> - {OP_RETK, 0, 0, 0 }, /*reject*/
> +/*
> + * tcpdump -d \
> + * ' (ether[12:2] == 0x8100 and ether[12 + 4 :2] == 0x88F7 and
> ether[14+4 :1] & 0x8 == 0x8) '\
> + * 'or (ether[12:2] == 0x88F7 and
> ether[14 :1] & 0x8 == 0x8) '
> + *
> + * (000) ldh [12]
> + * (001) jeq #0x8100 jt 2jf 7
> + * (002) ldh [16]
> + * (003) jeq #0x88f7 jt 4jf 12
> + * (004) ldb [18]
> + * (005) and #0x8
> + * (006) jeq #0x8 jt 11 jf 12
> + * (007) jeq #0x88f7 jt 8jf 12
> + * (008) ldb [14]
> + * (009) and #0x8
> + * (010) jeq #0x8 jt 11 jf 12
> + * (011) ret #262144
> + * (012) ret #0
> +*/
> +static struct sock_filter raw_filter_vlan_norm_general[] = {
>
Please leave the opcodes here, it makes code more easy to read.
Yes, in addition to 'tcpdump -d', more readable is better :-)
> + { 0x28, 0, 0, 0x000c },
> + { 0x15, 0, 5, 0x8100 },
> + { 0x28, 0, 0, 0x0010 },
> + { 0x15, 0, 8, 0x88f7 },
> + { 0x30, 0, 0, 0x0012 },
> + { 0x54, 0, 0, 0x0008 },
> + { 0x15, 4, 5, 0x0008 },
> + { 0x15, 0, 4, 0x88f7 },
> + { 0x30, 0, 0,
Re: [Linuxptp-devel] [PATCH v3 4/4] [Interface Rate TLV] adding delay asymmetry calculation
On Tue, 2022-12-13 at 10:56 +0530, Devasish Dey wrote:
> + /* Megabits per secon converted to attoseconds per bit. */
> + return 1ULL/ iface->if_info.speed;
Performing division in running is not a very good idea.
It is better to perform the division when updating the speed and store
it in if_info.
I agree with Miroslav, calculation is better, I did not suggest using hard
coded values, so not need to defend.
I simply suggest to move the calculation to where you set "if_info.speed".
So instead of calculate it every cycle, we only calculate when speed is changed.
Division is expensive (unless it is a left shift).
I usually compare new speed with old speed before calculate, if the speed is
the same, so is the bit time :-)
Are you sure we need attoseconds (10^-18), we usually uses nanoseconds
(10^-9). I would except a better resolution, but that much?
Please explain your choosing.
> +}
[Devasish]: The initial changes were with hardcoded values for the speed to
avoid the calculation.
Miroslav suggested this way to have clean code.
Yes the calculation is based on attoseconds and not nanoseconds This is as per
standard G.8275.2
From G.8275.2 (06/2021)
The linuxptp is mainly implement IEEE.
That does not means we can not support or use ITU standards,
but if you do, please add a comment with reference.
This applies as well as to choosing attoseconds.
"
interfaceBitPeriod (Uinteger64)
The period of 1-bit of the transmitting PTP timestamp interface, excluding line
encoding.
The value is encoded as an unsigned integer in units of attoseconds (10–18 s)
to accommodate interface bit periods less than 1 ns."
Thanks,
Devasish.
On Fri, 9 Dec 2022 at 18:08, Geva, Erez
mailto:erez.geva@siemens.com>> wrote:
On Wed, 2022-12-07 at 17:34 +0530, SyncMonk Technologies wrote:
> Delay asymmetry calculation based on the PTP port interface speed of
> master obtained from TLV and the slave interface rate obtained by
> ethtool.
>
> v3: updating network/host byte order handling.
> v1: initial commit
>
> Signed-off-by: Greg Armstrong
> mailto:greg.armstrong...@renesas.com>>
> Signed-off-by: Leon Goldin
> mailto:leon.goldin...@renesas.com>>
> Signed-off-by: Devasish Dey
> mailto:devasish@syncmonk.net>>
> Signed-off-by: Vipin Sharma
> mailto:vipin.sha...@syncmonk.net>>
> ---
> interface.c | 10 ++
> interface.h | 7 +++
> port_private.h| 1 +
> port_signaling.c | 39 ---
> ptp4l.8 | 7 +++
> tlv.c | 29 +
> unicast_service.c | 32
> 7 files changed, 122 insertions(+), 3 deletions(-)
>
> diff --git a/interface.c b/interface.c
> index 3157e8c..02d530e 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -94,3 +94,13 @@ int interface_get_vclock(struct interface *iface)
> {
> return iface->vclock;
> }
> +
> +uint64_t interface_bitperiod(struct interface *iface)
> +{
> + if (!iface->if_info.valid)
> + return 0;
> +
> + /* Megabits per secon converted to attoseconds per bit. */
> + return 1ULL/ iface->if_info.speed;
Performing division in running is not a very good idea.
It is better to perform the division when updating the speed and store
it in if_info.
Are you sure we need attoseconds (10^-18), we usually uses nanoseconds
(10^-9). I would except a better resolution, but that much?
Please explain your choosing.
> +}
> +
> diff --git a/interface.h b/interface.h
> index f4b9545..7c9a6bd 100644
> --- a/interface.h
> +++ b/interface.h
> @@ -113,4 +113,11 @@ void interface_set_vclock(struct interface
> *iface, int vclock);
> */
> int interface_get_vclock(struct interface *iface);
>
> +/**
> + * Obtains the interface bit period based on the speed.
Perhaps: "Obtains bit period based on interface speed."
> + * @param iface The interface of interest.
We must be interesting "Pointer to the interface" can be suffiecnt :-)
> + * @return if valid speed return interface bitperiod in atto
> seconds.
No need to make the return complicated, make it simple
"return interface bit period in attoseconds".
We know functions handle errors.
> + */
> +uint64_t interface_bitperiod(struct interface *iface);
> +
> #endif
> diff --git a/port_private.h b/port_private.h
> index d6487eb..6ad4af8 100644
> --- a/port_private.h
> +++ b/port_private.h
> @@ -146,6 +146,7 @@ struct port {
> UInteger8 delay_response_counter;
> UInteger8 delay_response_timeout;
> booliface_rate_tlv;
> + Integer64 portAsymmetry;
> s
Re: [Linuxptp-devel] [PATCH v3 1/4] [Interface Rate TLV] function to support get interface speed via ethtool
On Tue, 2022-12-13 at 10:39 +0530, Devasish Dey wrote:
> + goto failed;
> + }
I think it is better to merge this ioctl and the socket creation with
sk_get_ts_info().
No reason for duplication.
You can use a static function or inline one.
> +
> + if (ecmd.req.link_mode_masks_nwords >= 0 ||
> + ecmd.req.cmd != ETHTOOL_GLINKSETTINGS) {
> + return 1;
> + }
[Devasish]: This can be done.
> + /* clear data and ensure it is not marked valid */
> + memset(if_info, 0, sizeof(struct sk_if_info));
> + return -1;
You need to close the socket!
[Devasish]: Noted. Will be updated in the next patch.
> +struct sk_if_info {
> + bool valid;
It is better not to use bool in a structure, as the size is usually
int, i.e. 64 bits to hold 1 bit.
[Devasish]: Earlier we had it as an integer. We can update it to uint8_t as
well. But Richard suggested updating it to Boolean.
So, leaving this to Richard.
Good point, we can define a Boolean type using uint8_t for structures use.
But we can leave this decision to Richard.
> + int speed;
What are the units here?
Old systems use 32 bits, if you measure in bits per second, the maximum
is 4 GB.
It is better to use uint64_t and use 1 mbps as units.
[Devasish]: It is the same as the speed in ethtool_link_settings which is a
uint32_t variable and it is in Mbps.
Will change it to uint32_t and update the comments.
We do not have to follow the kernel ioctl type for speed, they tend to change
them from time to time.
Probably, someone in the past choose 'int' as he did not predict future speed
will pass 31 bits (int is signed).
And also the use of uintNN_t was not so common than.
But as sk.c is our internal layer, it can translate from kernel units and types
to our application units and types.
You do provide internal structure and do not use the kernel one :-)
So if in the future the kernel will use a new ioctl for speed as int will be
too small, we can retain out internal interface.
This is my opinion, but you can defer.
Thanks,
Devasish.
Erez
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 4/4] [Interface Rate TLV] adding delay asymmetry calculation
On Tue, 2022-12-13 at 17:27 +0100, Erez Geva wrote: On Tue, 2022-12-13 at 10:56 +0530, Devasish Dey wrote: > + /* Megabits per secon converted to attoseconds per bit. */ > + return 1ULL/ iface->if_info.speed; Performing division in running is not a very good idea. It is better to perform the division when updating the speed and store it in if_info. I agree with Miroslav, calculation is better, I did not suggest using hard coded values, so not need to defend. I simply suggest to move the calculation to where you set "if_info.speed". So instead of calculate it every cycle, we only calculate when speed is changed. Division is expensive (unless it is a left shift). I usually compare new speed with old speed before calculate, if the speed is the same, so is the bit time :-) Are you sure we need attoseconds (10^-18), we usually uses nanoseconds (10^-9). I would except a better resolution, but that much? Please explain your choosing. > +} [Devasish]: The initial changes were with hardcoded values for the speed to avoid the calculation. Miroslav suggested this way to have clean code. Yes the calculation is based on attoseconds and not nanoseconds This is as per standard G.8275.2 From G.8275.2 (06/2021) The linuxptp is mainly implement IEEE. That does not means we can not support or use ITU standards, but if you do, please add a comment with reference. This applies as well as to choosing attoseconds. This comment is also valid for the 'Uinteger64' type, as it is not currently used by IEEE, please add a comment it is used for ITU standard parameters. If future IEEE will use the Uinteger64 too, we can remove the comment. " interfaceBitPeriod (Uinteger64) The period of 1-bit of the transmitting PTP timestamp interface, excluding line encoding. The value is encoded as an unsigned integer in units of attoseconds (10–18 s) to accommodate interface bit periods less than 1 ns." Thanks, Devasish. Erez ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 1/4] [Interface Rate TLV] function to support get interface speed via ethtool
On Tue, 2022-12-13 at 17:39 +0100, Erez Geva wrote:
On Tue, 2022-12-13 at 10:39 +0530, Devasish Dey wrote:
> + goto failed;
> + }
I think it is better to merge this ioctl and the socket creation with
sk_get_ts_info().
No reason for duplication.
You can use a static function or inline one.
> +
> + if (ecmd.req.link_mode_masks_nwords >= 0 ||
> + ecmd.req.cmd != ETHTOOL_GLINKSETTINGS) {
> + return 1;
> + }
[Devasish]: This can be done.
> + /* clear data and ensure it is not marked valid */
> + memset(if_info, 0, sizeof(struct sk_if_info));
> + return -1;
You need to close the socket!
[Devasish]: Noted. Will be updated in the next patch.
> +struct sk_if_info {
> + bool valid;
It is better not to use bool in a structure, as the size is usually
int, i.e. 64 bits to hold 1 bit.
[Devasish]: Earlier we had it as an integer. We can update it to uint8_t as
well. But Richard suggested updating it to Boolean.
So, leaving this to Richard.
Good point, we can define a Boolean type using uint8_t for structures use.
But we can leave this decision to Richard.
> + int speed;
What are the units here?
Old systems use 32 bits, if you measure in bits per second, the maximum
is 4 GB.
It is better to use uint64_t and use 1 mbps as units.
[Devasish]: It is the same as the speed in ethtool_link_settings which is a
uint32_t variable and it is in Mbps.
Will change it to uint32_t and update the comments.
We do not have to follow the kernel ioctl type for speed, they tend to change
them from time to time.
Probably, someone in the past choose 'int' as he did not predict future speed
will pass 31 bits (int is signed).
And also the use of uintNN_t was not so common than.
But as sk.c is our internal layer, it can translate from kernel units and types
to our application units and types.
You do provide internal structure and do not use the kernel one :-)
So if in the future the kernel will use a new ioctl for speed as int will be
too small, we can retain out internal interface.
This is my opinion, but you can defer.
Sorry, I miss reading your answer properly, please disregard this part.
Erez
Thanks,
Devasish.
Erez
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 4/4] [Interface Rate TLV] adding delay asymmetry calculation
m->interfaceBitPeriod = host2net64(m-
> >interfaceBitPeriod);
> + m->numberOfBitsBeforeTimestamp = htons(m-
> >numberOfBitsBeforeTimestamp);
> + m->numberOfBitsAfterTimestamp = htons(m-
> >numberOfBitsAfterTimestamp);
> + break;
> + }
> }
> }
>
> diff --git a/unicast_service.c b/unicast_service.c
> index 3154894..1078041 100644
> --- a/unicast_service.c
> +++ b/unicast_service.c
> @@ -84,6 +84,30 @@ static int attach_grant(struct ptp_message *msg,
> return 0;
> }
>
> +static int attach_interface_rate(struct ptp_message *msg,
> + uint64_t iface_bit_period,
> + uint16_t no_of_bits_before_ts,
> + uint16_t no_of_bits_after_ts)
> +{
> + struct msg_interface_rate_tlv *mir;
> + struct tlv_extra *extra;
> +
> + extra = msg_tlv_append(msg, sizeof(*mir));
> + if (!extra) {
> + return -1;
> + }
> + mir = (struct msg_interface_rate_tlv *) extra->tlv;
> + mir->type = TLV_ORGANIZATION_EXTENSION;
> + mir->length = sizeof(*mir) - sizeof(mir->type) - sizeof(mir-
> >length);
> + memcpy(mir->id, itu_t_id, sizeof(itu_t_id));
> + mir->subtype[2] = 2;
> + mir->interfaceBitPeriod = iface_bit_period;
> + mir->numberOfBitsBeforeTimestamp = no_of_bits_before_ts;
> + mir->numberOfBitsAfterTimestamp = no_of_bits_after_ts;
> +
> + return 0;
> +}
> +
> static int compare_timeout(void *ain, void *bin)
> {
> struct unicast_service_interval *a, *b;
> @@ -256,6 +280,14 @@ static int unicast_service_reply(struct port *p,
> struct ptp_message *dst,
> if (err) {
> goto out;
> }
> + if (p->iface_rate_tlv && duration > 0 &&
> interface_ifinfo_valid(p->iface)) {
> + err = attach_interface_rate(msg,
> + interface_bitperiod(p->iface), 64,
> 720);
> + if (err) {
> + goto out;
> + }
> + }
> +
> err = port_prepare_and_send(p, msg, TRANS_GENERAL);
> if (err) {
> pr_err("%s: signaling message failed", p->log_name);
Erez
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 3/4] [Interface Rate TLV] organization TLV support for interface rate
On Wed, 2022-12-07 at 17:34 +0530, SyncMonk Technologies wrote:
> adding interface rate TLV as defined by ITU-T G.8275.2 Annex D to
> enable master to communicate PTP port interface rate to slave.
>
> Signed-off-by: Greg Armstrong
> Signed-off-by: Leon Goldin
> Signed-off-by: Devasish Dey
> Signed-off-by: Vipin Sharma
> ---
> config.c | 1 +
> pdt.h | 1 +
> port.c | 1 +
> port_private.h | 1 +
> tlv.c | 1 +
> tlv.h | 14 ++
> 6 files changed, 19 insertions(+)
>
> diff --git a/config.c b/config.c
> index 08e3346..2fa95fc 100644
> --- a/config.c
> +++ b/config.c
> @@ -267,6 +267,7 @@ struct config_item config_tab[] = {
> PORT_ITEM_INT("inhibit_delay_req", 0, 0, 1),
> PORT_ITEM_INT("inhibit_multicast_service", 0, 0, 1),
> GLOB_ITEM_INT("initial_delay", 0, 0, INT_MAX),
> + PORT_ITEM_INT("interface_rate_tlv", 0, 0, 1),
> GLOB_ITEM_INT("kernel_leap", 1, 0, 1),
> GLOB_ITEM_STR("leapfile", NULL),
> PORT_ITEM_INT("logAnnounceInterval", 1, INT8_MIN, INT8_MAX),
> diff --git a/pdt.h b/pdt.h
> index e46b218..1ad23d4 100644
> --- a/pdt.h
> +++ b/pdt.h
> @@ -39,6 +39,7 @@ typedef uint16_t UInteger16;
> typedef int32_t Integer32;
> typedef uint32_t UInteger32;
> typedef int64_t Integer64;
> +typedef uint64_t UInteger64;
IEEE 1588-2019 only define Integer64, but not UInteger64.
Not sure why, but probably there is no UInteger64 in IEEE standard.
Are you using UInteger64 for a standard parameter/variables?
> typedef uint8_t Octet;
>
> #endif
> diff --git a/port.c b/port.c
> index 7fd50dd..85cfa4a 100644
> --- a/port.c
> +++ b/port.c
> @@ -1854,6 +1854,7 @@ int port_initialize(struct port *p)
> p->neighborPropDelayThresh = config_get_int(cfg, p->name,
> "neighborPropDelayThresh");
> p->min_neighbor_prop_delay = config_get_int(cfg, p->name,
> "min_neighbor_prop_delay");
> p->delay_response_timeout = config_get_int(cfg, p->name,
> "delay_response_timeout");
> + p->iface_rate_tlv = config_get_int(cfg, p->name,
> "interface_rate_tlv");
>
> if (config_get_int(cfg, p->name, "asCapable") ==
> AS_CAPABLE_TRUE) {
> p->asCapable = ALWAYS_CAPABLE;
> diff --git a/port_private.h b/port_private.h
> index d27dceb..d6487eb 100644
> --- a/port_private.h
> +++ b/port_private.h
> @@ -145,6 +145,7 @@ struct port {
> UInteger8 versionNumber; /* UInteger4 */
> UInteger8 delay_response_counter;
> UInteger8 delay_response_timeout;
> + bool iface_rate_tlv;
Again, using bool in structure is unwise.
Better use uint8_t and not UInteger8, so we now it is not standard type
and with a comment saying it holds a boolean value.
> struct PortStats stats;
> struct PortServiceStats service_stats;
> /* foreignMasterDS */
> diff --git a/tlv.c b/tlv.c
> index 1c13460..35bee4f 100644
> --- a/tlv.c
> +++ b/tlv.c
> @@ -35,6 +35,7 @@
> (tlv->length < sizeof(struct type) - sizeof(struct TLV))
>
> uint8_t ieee8021_id[3] = { IEEE_802_1_COMMITTEE };
> +uint8_t itu_t_id[3] = { ITU_T_COMMITTEE };
>
> static TAILQ_HEAD(tlv_pool, tlv_extra) tlv_pool =
> TAILQ_HEAD_INITIALIZER(tlv_pool);
> diff --git a/tlv.h b/tlv.h
> index 8966696..ec22e2f 100644
> --- a/tlv.h
> +++ b/tlv.h
> @@ -395,6 +395,20 @@ struct tlv_extra {
> };
> };
>
> +/* Organizationally Unique Identifiers */
> +#define ITU_T_COMMITTEE 0x00, 0x19, 0xA7
> +extern uint8_t itu_t_id[3];
> +
> +struct msg_interface_rate_tlv {
> + Enumeration16 type;
> + UInteger16 length;
> + Octet id[3];
> + Octet subtype[3];
> + UInteger64 interfaceBitPeriod;
> + UInteger16 numberOfBitsBeforeTimestamp;
> + UInteger16 numberOfBitsAfterTimestamp;
> +} PACKED;
> +
> /**
> * Allocates a new tlv_extra structure.
> * @return Pointer to a new structure on success or NULL otherwise.
Erez
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v3 1/4] [Interface Rate TLV] function to support get interface speed via ethtool
On Wed, 2022-12-07 at 17:34 +0530, SyncMonk Technologies wrote:
> When master and slave instance interacting with each other operating
> at different interface speed, delay assymetry needs to be compensated
> as described in G.8271 appendix V.
>
> In this patch we are adding changes to get the interface speed using
> ethtool.
>
> v1: initial commit.
> v2: updating comments and data types.
> v3: updating Boolean data type to bool from
> ---
> sk.c | 71
>
> sk.h | 19
> 2 files changed, 90 insertions(+)
>
> diff --git a/sk.c b/sk.c
> index d27abff..1d1a656 100644
> --- a/sk.c
> +++ b/sk.c
> @@ -205,6 +205,77 @@ failed:
> return -1;
> }
>
> +int sk_get_if_info(const char *name, struct sk_if_info *if_info)
> +{
> +#ifdef ETHTOOL_GLINKSETTINGS
> + struct ifreq ifr;
> + int fd, err;
> +
> + struct {
> + struct ethtool_link_settings req;
> + /*
> + * link_mode_data consists of supported[],
> advertising[],
> + * lp_advertising[] with size up to 127 each.
> + * The actual size is provided by the kernel.
> + */
> + __u32 link_mode_data[3 * 127];
> + } ecmd;
> +
> + memset(, 0, sizeof(ifr));
> + memset(, 0, sizeof(ecmd));
> +
> + fd = socket(AF_INET, SOCK_DGRAM, 0);
> + if (fd < 0) {
> + goto failed;
> + }
> +
> + ecmd.req.cmd = ETHTOOL_GLINKSETTINGS;
> +
> + strncpy(ifr.ifr_name, name, IFNAMSIZ - 1);
> + ifr.ifr_data = (char *)
> +
> + /* Handshake with kernel to determine number of words for
> link
> + * mode bitmaps. When requested number of bitmap words is not
> + * the one expected by kernel, the latter returns the integer
> + * opposite of what it is expecting. We request length 0
> below
> + * (aka. invalid bitmap length) to get this info.
> + */
> + err = ioctl(fd, SIOCETHTOOL, );
> + if (err < 0) {
> + pr_err("ioctl SIOCETHTOOL failed: %m");
> + close(fd);
> + goto failed;
> + }
I think it is better to merge this ioctl and the socket creation with
sk_get_ts_info().
No reason for duplication.
You can use a static function or inline one.
> +
> + if (ecmd.req.link_mode_masks_nwords >= 0 ||
> + ecmd.req.cmd != ETHTOOL_GLINKSETTINGS) {
> + return 1;
> + }
> + ecmd.req.link_mode_masks_nwords = -
> ecmd.req.link_mode_masks_nwords;
> +
> + err = ioctl(fd, SIOCETHTOOL, );
> + if (err < 0) {
> + pr_err("ioctl SIOCETHTOOL failed: %m");
> + close(fd);
> + goto failed;
> + }
> +
> + close(fd);
> +
> + /* copy the necessary data to sk_info */
> + memset(if_info, 0, sizeof(struct sk_if_info));
> + if_info->valid = 1;
> + if_info->speed = ecmd.req.speed;
> +
> + return 0;
> +failed:
> +#endif
> + /* clear data and ensure it is not marked valid */
> + memset(if_info, 0, sizeof(struct sk_if_info));
> + return -1;
You need to close the socket!
> +}
> +
> +
> static int sk_interface_guidaddr(const char *name, unsigned char
> *guid)
> {
> char file_name[64], buf[64], addr[8];
> diff --git a/sk.h b/sk.h
> index 486dbc4..4cee3d7 100644
> --- a/sk.h
> +++ b/sk.h
> @@ -20,6 +20,7 @@
> #ifndef HAVE_SK_H
> #define HAVE_SK_H
>
> +#include
> #include "address.h"
> #include "transport.h"
>
> @@ -49,6 +50,16 @@ struct sk_ts_info {
> unsigned int rx_filters;
> };
>
> +/**
> + * Contains interface information returned by theGLINKSETTINGS
> ioctl.
> + * @valid: set to non-zero when the info struct contains
> valid data.
> + * @speed: interface speed.
> + */
> +struct sk_if_info {
> + bool valid;
It is better not to use bool in a structure, as the size is usually
int, i.e. 64 bits to hold 1 bit.
> + int speed;
What are the units here?
Old systems use 32 bits, if you measure in bits per second, the maximum
is 4 GB.
It is better to use uint64_t and use 1 mbps as units.
> +};
> +
> /**
> * Obtains a socket suitable for use with sk_interface_index().
> * @return An open socket on success, -1 otherwise.
> @@ -78,6 +89,14 @@ int sk_general_init(int fd);
> */
> int sk_get_ts_info(const char *name, struct sk_ts_info *sk_info);
>
> +/**
> + * Obtain suppor
Re: [Linuxptp-devel] [PATCH 1/1] clock: Fix stale clock parent pid usage after best master change
On Mon, 2022-12-05 at 12:52 -0500, vincent.cheng...@renesas.com wrote:
> On Mon, Dec 05, 2022 at 02:44:07AM EST, Geva, Erez wrote:
> > On Fri, 2022-12-02 at 15:33 -0500,
> > vincent.cheng...@renesas.com wrote:
> > > From: Vincent Cheng
> > >
> > > In handle_state_decision_event(), the update of the clock's
> > > parent
> > > pid after
> > > best master change is non-deterministic. It depends on the port
> > > processing
> > > order and bmc_state_decision() results.
> > >
> > > +static void clock_update_parent_identity(struct clock *c)
> > > +{
> > > + struct parentDS *pds = >dad.pds;
> > > +
> > > + if (c->best) {
> > > + pds->parentPortIdentity = c->best-
> > > >dataset.sender;
> > > + } else {
> > > + pds->parentPortIdentity.clockIdentity = c-
> > > > dds.clockIdentity;
> > > + pds->parentPortIdentity.portNumber = 0;
> >
> > Why is the port 0?
> > It make sense that defaultDS do not have port as we work in the
> > context
> > of the clock.
> > Is it make sense to use port ID here?
>
> I would like to say it is port 0 because I consulted 1588-2019.pdf
> and found the
> requirement in "Table 30 - Updates for state decision code M1 and
> M2".
>
> parentDS.clockIdentity member set to the value of
> defaultDS.clockIdentity field.
> parentDS.parentPortIdentity.portNumber member is 0
>
> However, realistically speaking, I copied the logic from
> clock_update_grandmaster()
> and clock_update_slave() first and then looked it up afterwards.
Make sense, please live a comment on the value assignment :-)
Something like ~ "follow IEEE table 30 updates for M1".
No need for a long one, just a short reference.
Erez
>
> >
> >
> > > + }
> > > +}
> > > +
> > > static int clock_utc_correct(struct clock *c, tmv_t ingress)
> > > {
> > > struct timespec offset;
> > > @@ -2015,6 +2027,8 @@ static void
> > > handle_state_decision_event(struct
> > > clock *c)
> > > c->best = best;
> > > c->best_id = best_id;
> > >
> > > + clock_update_parent_identity(c);
> > > +
> > > LIST_FOREACH(piter, >ports, list) {
> > > enum port_state ps;
> > > enum fsm_event event;
> >
> >
> > P.S.
> > All patches should be on top of master, no need to comment on
> > obvious.
>
> Ok, will leave out commit next time if it's not needed. Thanks.
>
> Vincent
--
Erez Geva
Siemens AG
www.siemens.com
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] phc_ctl: use PTP_CLOCK_GETCAPS2 ioctl if available
On Wed, 2022-12-07 at 06:59 -0800, Richard Cochran wrote: > On Thu, Nov 17, 2022 at 02:15:23PM -0800, Jacob Keller wrote: > > On 11/17/2022 1:34 PM, Geva, Erez wrote: > > > > The problem is the fallback works only on build. > > > But if the build system is newer than the running system, the > > > fallback > > > will fail, as you will use the PTP_CLOCK_GETCAPS2 which does not > > > exist > > > on the running old system. > > > > > > > Fair. We likely have the same problem with some of the other "2" > > ioctls, > > since they're handled in a similar way. I think we do the Right(TM) > > thing > > for the sysoff.c where we probe the kernel at run-time. This could > > be done > > here but is probably not really worth it considering that > > PTP_CLOCK_GETCAPS > > functions the same way as PTP_CLOCK_GETCAPS2 for all kernels I > > checked... So > > I guess this is somewhat less likely. > > Jacob, do you want to have phc_ctl fall back to PTP_CLOCK_GETCAPS at > run time if PTP_CLOCK_GETCAPS2 fails? We can use run-time fallback. But personalty, I do not think it worth it. Using PTP_CLOCK_GETCAPS2 is only done for one new field in a debug tool. We can simply wait till PTP_CLOCK_GETCAPS become obsolete or we have a new PTP_CLOCK_GETCAPS3 to handle. > > > I'm not sure if our other PTP ioctls are checked properly like this > > at run > > time... > > Maybe, but only because of sloppiness. Better to support older > kernels at run time, as this is more user friendly. > > Working on embedded systems over the years, I've have often been that > user, and, believe me, it is super annoying when the latest greatest > App isn't backwards compatible. My view too :-) > > Thanks, > Richard Erez ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 1/1] clock: Fix stale clock parent pid usage after best master change
On Fri, 2022-12-02 at 15:33 -0500, vincent.cheng...@renesas.com wrote:
> From: Vincent Cheng
>
> In handle_state_decision_event(), the update of the clock's parent
> pid after
> best master change is non-deterministic. It depends on the port
> processing
> order and bmc_state_decision() results.
>
> Subsequent call to unicast_client_state_changed() via port_dispatch()
> may use
> stale parent pid and place UC FSM in wrong state.
>
>
> Signed-off-by: Vincent Cheng
> ---
> clock.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/clock.c b/clock.c
> index 8177e77..55ca8d3 100644
> --- a/clock.c
> +++ b/clock.c
> @@ -709,6 +709,18 @@ static void clock_update_slave(struct clock *c)
> clock_update_time_properties(c, tds);
> }
>
> +static void clock_update_parent_identity(struct clock *c)
> +{
> + struct parentDS *pds = >dad.pds;
> +
> + if (c->best) {
> + pds->parentPortIdentity = c->best->dataset.sender;
> + } else {
> + pds->parentPortIdentity.clockIdentity = c-
> >dds.clockIdentity;
> + pds->parentPortIdentity.portNumber = 0;
Why is the port 0?
It make sense that defaultDS do not have port as we work in the context
of the clock.
Is it make sense to use port ID here?
> + }
> +}
> +
> static int clock_utc_correct(struct clock *c, tmv_t ingress)
> {
> struct timespec offset;
> @@ -2015,6 +2027,8 @@ static void handle_state_decision_event(struct
> clock *c)
> c->best = best;
> c->best_id = best_id;
>
> + clock_update_parent_identity(c);
> +
> LIST_FOREACH(piter, >ports, list) {
> enum port_state ps;
> enum fsm_event event;
P.S.
All patches should be on top of master, no need to comment on obvious.
The rest of the explantation is perfect :-)
Erez
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] phc_ctl: use PTP_CLOCK_GETCAPS2 ioctl if available
On Thu, 2022-11-17 at 18:27 +, Keller, Jacob E wrote:
>
>
> > -Original Message-
> > From: Geva, Erez
> > Sent: Thursday, November 17, 2022 9:13 AM
> > To: Keller, Jacob E ; linuxptp-
> > de...@lists.sourceforge.net
> > Subject: Re: [Linuxptp-devel] [PATCH 2/2] phc_ctl: use
> > PTP_CLOCK_GETCAPS2
> > ioctl if available
> >
> > On Tue, 2022-11-15 at 16:43 -0800, Jacob Keller wrote:
> > > The PTP_CLOCK_GETCAPS2 ioctl is provided by kernel as a
> > > replacement
> > > for the
> > > original PTP_CLOCK_GETCAPS ioctl. This was done in order to
> > > provide
> > > ioctls
> > > which guarantee reserved fields are properly initialized. In
> > > practice
> > > the
> > > PTP_CLOCK_GETCAPS2 and PTP_CLOCK_GETCAPS both behave identically
> > > since
> >
> > Exactly, that is why I send a patch to add the new 'adjust_phase'
> > in
> > do_caps(), without changing the ioctl itself :-)
> >
> >
>
> The reason PTP_CLOCK_GETCAPS2 was created was around the same time as
> the other ioctls were fixed to properly a) validate reserved fields
> and b) ensure that all reported reserved fields were zeroed.
>
> Functionally its 100% identical to PTP_CLOCK_GETCAPS because this
> ioctl already did the right thing.
>
> The reason I propose switching to PTP_CLOCK_GETCAPS2 over
> PTP_CLOCK_GETCAPS is because it reduces cognitive burden to REMEMBER
> that the old PTP_CLOCK_GETCAPS is ok. All I remembered was "the non-2
> ioctls might be broken and not receive new features".
>
> > > PTP_CLOCK_GETCAPS always zeroed the caps structure. However, it
> > > is
> > > good
> > > practice to use the newer version consistently.
> >
> > But, it can also breaks when using the new linuxptp version build
> > on
> > new machine, but used with old kernel.
> > It may be reasonable in few years, when these old kernels becomes
> > obsolete.
>
> This uses a fallback to PTP_CLOCK_GETCAPS if PTP_CLOCK_GETCAPS2 is
> not found.
The problem is the fallback works only on build.
But if the build system is newer than the running system, the fallback
will fail, as you will use the PTP_CLOCK_GETCAPS2 which does not exist
on the running old system.
If I may, this is the classic gap, Hardware companies fail to
understand.
Erez
>
> > But since the new PTP_CLOCK_GETCAPS2 was introduce in 2019, I think
> > we
> > should wait with it.
> > As not everyone build linuxptp, most users use pre-build.
> >
> >
> > >
> > > Signed-off-by: Jacob Keller
> > > ---
> > > Technically this is identical in current kernels, both ioctls
> > > return
> > > exactly
> > > the same conent.. I still think its better to use the '2'
> > > variants in
> > > principle that developer doesn't have to remember "is this
> > > variant ok
> > > to get
> > > all the new features going forward?"
> >
> > There are more 12 bytes in the reserve.
> > I guess once we pass them, we would need a non-backward flag, but
> > till
> > then, I think we can keep using the PTP_CLOCK_GETCAPS flag, and
> > leave
> > the new flags in do_caps().
> >
>
> The only motiviation for this patch is consistency in using the "2"
> style ioctls across ptp4l, because it makes it less likely someone
> will use the non-2 version of an ioctl that actually does have
> behavioral differences in the future.
>
> Thanks,
> Jake
>
> > Erez
> >
> > >
> > > missing.h | 7 +++
> > > phc_ctl.c | 2 +-
> > > 2 files changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/missing.h b/missing.h
> > > index 79a87d425993..41427d3a38b2 100644
> > > --- a/missing.h
> > > +++ b/missing.h
> > > @@ -98,6 +98,13 @@ enum {
> > > #define PTP_PEROUT_REQUEST2 PTP_PEROUT_REQUEST
> > > #endif
> > >
> > > +#ifdef PTP_CLOCK_GETCAPS2
> > > +#define PTP_CLOCK_GETCAPS_REQUEST_FAILED "PTP_CLOCK_GETCAPS2
> > failed:
> > > %m"
> > > +#else
> > > +#define PTP_CLOCK_GETCAPS_REQUEST_FAILED "PTP_CLOCK_GETCAPS
> > > failed:
> > > %m"
> > > +#define PTP_CLOCK_GETCAPS2 PTP_CLOCK_GETCAPS
> > > +#endif
> > > +
> > > #if LINUX_VERSION_CODE < KERNEL_VERSION(5,8,0)
> > >
> > > /* from upcoming Linux kernel version 5.8 */
> > > diff --git a/phc_ctl.c b/phc_ctl.c
> > > index 6a5c2f43d7c9..17a615f8aae6 100644
> > > --- a/phc_ctl.c
> > > +++ b/phc_ctl.c
> > > @@ -288,7 +288,7 @@ static int do_caps(clockid_t clkid, int cmdc,
> > > char *cmdv[])
> > > return 0;
> > > }
> > >
> > > - if (ioctl(CLOCKID_TO_FD(clkid), PTP_CLOCK_GETCAPS,
> > > )) {
> > > + if (ioctl(CLOCKID_TO_FD(clkid), PTP_CLOCK_GETCAPS2,
> > > )) {
> > > pr_err("get capabilities failed: %s",
> > > strerror(errno));
> > > return -1;
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] bmc: Fix PortId comparison
On Mon, 2022-11-14 at 14:25 +0100, Luigi Mantellini wrote:
> The PortId is defined as a couple of ClockId (an 8-bytes opaque) and
> the PortNumber (UInterger16).
> In order to correctly handle the PortId endianess, the comparison has
> been split in the ClockIds comparison (using memcmp) and PortNumber
> comparison.
You code do not solve any endianess issue.
The clock ID is byte stream.
And port number is 16 bits, it require converting from network order to
host order, which you do not need here. Becuase port ID are already in
the same endian here.
As struct PortIdentity is defined as "PACKED", it should not have any
pad that may cause the memory compare to fail. Of having different
values in the pad.
So memcmp and your "portid_cmp" should give the same result.
I would suggest to replace the memcmp and "portid_cmp" with existing
pid_eq(const struct PortIdentity *a, const struct PortIdentity *b)
And debug and find the real reason you have the bug.
And than send a real bug fix :-)
Erez
> ---
> bmc.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/bmc.c b/bmc.c
> index 6ac7aa0..ebc0789 100644
> --- a/bmc.c
> +++ b/bmc.c
> @@ -21,6 +21,17 @@
> #include "bmc.h"
> #include "ds.h"
>
> +static int portid_cmp(struct PortIdentity *a, struct PortIdentity
> *b)
> +{
> + int diff = memcmp(>clockIdentity, >clockIdentity,
> sizeof(a->clockIdentity));
> +
> + if (diff == 0) {
> + diff = a->portNumber - b->portNumber;
> + }
> +
> + return diff;
> +}
> +
> int dscmp2(struct dataset *a, struct dataset *b)
> {
> int diff;
> @@ -35,7 +46,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> * standard, since there is nothing we can do about it
> anyway.
> */
> if (A < B) {
> - diff = memcmp(>receiver, >sender, sizeof(b-
> >receiver));
> + diff = portid_cmp(>receiver, >sender);
> if (diff < 0)
> return A_BETTER;
> if (diff > 0)
> @@ -44,7 +55,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> return 0;
> }
> if (A > B) {
> - diff = memcmp(>receiver, >sender, sizeof(a-
> >receiver));
> + diff = portid_cmp(>receiver, >sender);
> if (diff < 0)
> return B_BETTER;
> if (diff > 0)
> @@ -53,7 +64,7 @@ int dscmp2(struct dataset *a, struct dataset *b)
> return 0;
> }
>
> - diff = memcmp(>sender, >sender, sizeof(a->sender));
> + diff = portid_cmp(>sender, >sender);
> if (diff < 0)
> return A_BETTER_TOPO;
> if (diff > 0)
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] remove C99 style loop variable declarations
On Thu, 2022-11-17 at 08:02 +, Magnus Armholt via Linuxptp-devel wrote: > Nothing to complain about the patch, thanks for looking after the > code base! > > > LinuxPTP source still prefers to keep with the GNU C89 convention > > of > > variables being at the top of the function. Newer versions of GCC > > have > > begun defaulting to a newer C standard, which explains how these > > slipped in. > > Note that directly enforcing "-std=c89" does not work because we > > rely on > > some GNU extensions of C89. > > Has there been any discussion about this topic? If it is hard to > verify the code, then these > mistakes will keep on slipping in. Is there a script or ReadMe > somewhere, listing the needed > compiler flags to be used in order to use the "correct" C89? > > C89 is now > 30y old, any plans when to move to a more modern > version? It is the standard, not the compiler. As it may, that I might prefer differently. It does make sense to use old standard with new compilers. New compilers and new libc support old standards. No reason to update standard for them. The standard is more for developers convenient. And in case we want to use new functionality added in new standard. > > Linux is from time to time dropping support for old things, Linux uses and relys on GNU extensions. As much as I appropriate Linux and Linus, their approach is not the holly grill. Richard may differ. I do not object to use a newer standard or stay with the old one, as long as we are coherent. > so although being a project that try to support as many devices as > possible, it is possible As the newest compilers support old standard. And new compilers can compile to very old devices. I do not see any connection between old devices and old standard. They are not a reason to select standard. As long as you can update linuxptp, you can probably update the libc. If you can't, than no reason to update linuxptp either. > to move to more modern versions, if it is announced in time and in > accordance with a plan. > > BR, > Magnus Armholt > > > > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cerez.geva.ext%40siemens.com%7C8b9983f7486248beb86308dac8771ed9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638042711193699884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Kq2Tj%2FHyfp5x5fj8qFsLcuoUozMtBY9ZiLS%2FtT9mnv0%3Dreserved=0 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 1/2] phc_ctl: explicitly check for adjust_phase definition
On Tue, 2022-11-15 at 16:43 -0800, Jacob Keller wrote:
> The PTP_CLOCK_GETCAPS ioctl call in phc_ctl has a conditional check
> for
> whether to report the caps.adjust_phase bit. This is always set for
> both
> PTP_CLOCK_GETCAPS and PTP_CLOCK_GETCAPS2, and was always zero before
> the
> bit was moved from being reserved to indicate the adjust_phase.
>
> In some sense if we lack PTP_CLOCK_GETCAPS2 we know the kernel won't
> report
> adjust_phase, but in reality such kernel versions did not have
> adjust_phase at all.
>
> There's no reason to make this check against PTP_CLOCK_GETCAPS2.
> Instead,
> scan the ptp_clock.h header file and check if we have adjust_phase
> support.
> Use this new flag instead of PTP_CLOCK_GETCAPS2.
>
> Signed-off-by: Jacob Keller
> ---
> Checking against PTP_CLOCK_GETCAPS2 is wrong because this is not when
> the
> adjust_phase was actually introduced. A direct check against whats in
> the
> header is more accurate.
This make sense.
Thanks for the correction :-)
>
> incdefs.sh | 5 +
> phc_ctl.c | 2 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/incdefs.sh b/incdefs.sh
> index 21333e5109e9..a9e94f777f6b 100755
> --- a/incdefs.sh
> +++ b/incdefs.sh
> @@ -63,6 +63,7 @@ kernel_flags()
> {
> prefix=""
> tstamp=/usr/include/linux/net_tstamp.h
> + ptp_clock=/usr/include/linux/ptp_clock.h
Is that catch if using kernel headers?
The location in the current kernel is
/include/uapi/linux/ptp_clock.h
I see you add in the same way, perhaps we need to update the script?
>
> if [ "x$KBUILD_OUTPUT" != "x" ]; then
> # With KBUILD_OUTPUT set, we are building against
> @@ -90,6 +91,10 @@ kernel_flags()
> if grep -q SOF_TIMESTAMPING_BIND_PHC ${prefix}${tstamp}; then
> printf " -DHAVE_VCLOCKS"
> fi
> +
> + if grep -q adjust_phase ${prefix}${ptp_clock}; then
> + printf " -DHAVE_PTP_CAPS_ADJUST_PHASE"
> + fi
> }
>
> flags="$(user_flags)$(kernel_flags)"
> diff --git a/phc_ctl.c b/phc_ctl.c
> index 92e597c40a23..6a5c2f43d7c9 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -311,7 +311,7 @@ static int do_caps(clockid_t clkid, int cmdc,
> char *cmdv[])
> caps.n_pins,
> caps.pps ? "has" : "doesn't have",
> caps.cross_timestamping ? "has" : "doesn't have",
> - #ifdef PTP_CLOCK_GETCAPS2
> + #ifdef HAVE_PTP_CAPS_ADJUST_PHASE
> caps.adjust_phase ? "has" : "doesn't have"
> #else
> "no information regarding"
Erez
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 0/1] Configurable VLAN tags for Ethernet
On Thu, 2022-11-17 at 13:43 +0200, Magnus Armholt wrote: > Add possibility to configure VLAN tags for ethernet. > > We mainly use PTP in slave mode so this has been developed > primarly for the sync request. > The raw_send function is used by a lot of functionality, so input > on what we could have missed (especially from master point of view) > is appreciated. The idea is nice. I personally in favour of more options of using VLANs. If you add an option for using VLAN out of band (instead of using Linux VLANs interfaces), it should be complete. i.e. you should implement the receive side. You can filter the received packets using a kernel BPF filter, to filter only the wanted VLAN id and PTP packets. Erez > > Mika Paulamäki (1): > Add configurable VLAN tags for Ethernet > > config.c | 3 +++ > raw.c | 47 +++ > 2 files changed, 42 insertions(+), 8 deletions(-) > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 2/2] phc_ctl: use PTP_CLOCK_GETCAPS2 ioctl if available
On Tue, 2022-11-15 at 16:43 -0800, Jacob Keller wrote:
> The PTP_CLOCK_GETCAPS2 ioctl is provided by kernel as a replacement
> for the
> original PTP_CLOCK_GETCAPS ioctl. This was done in order to provide
> ioctls
> which guarantee reserved fields are properly initialized. In practice
> the
> PTP_CLOCK_GETCAPS2 and PTP_CLOCK_GETCAPS both behave identically
> since
Exactly, that is why I send a patch to add the new 'adjust_phase' in
do_caps(), without changing the ioctl itself :-)
> PTP_CLOCK_GETCAPS always zeroed the caps structure. However, it is
> good
> practice to use the newer version consistently.
But, it can also breaks when using the new linuxptp version build on
new machine, but used with old kernel.
It may be reasonable in few years, when these old kernels becomes
obsolete.
But since the new PTP_CLOCK_GETCAPS2 was introduce in 2019, I think we
should wait with it.
As not everyone build linuxptp, most users use pre-build.
>
> Signed-off-by: Jacob Keller
> ---
> Technically this is identical in current kernels, both ioctls return
> exactly
> the same conent.. I still think its better to use the '2' variants in
> principle that developer doesn't have to remember "is this variant ok
> to get
> all the new features going forward?"
There are more 12 bytes in the reserve.
I guess once we pass them, we would need a non-backward flag, but till
then, I think we can keep using the PTP_CLOCK_GETCAPS flag, and leave
the new flags in do_caps().
Erez
>
> missing.h | 7 +++
> phc_ctl.c | 2 +-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/missing.h b/missing.h
> index 79a87d425993..41427d3a38b2 100644
> --- a/missing.h
> +++ b/missing.h
> @@ -98,6 +98,13 @@ enum {
> #define PTP_PEROUT_REQUEST2 PTP_PEROUT_REQUEST
> #endif
>
> +#ifdef PTP_CLOCK_GETCAPS2
> +#define PTP_CLOCK_GETCAPS_REQUEST_FAILED "PTP_CLOCK_GETCAPS2 failed:
> %m"
> +#else
> +#define PTP_CLOCK_GETCAPS_REQUEST_FAILED "PTP_CLOCK_GETCAPS failed:
> %m"
> +#define PTP_CLOCK_GETCAPS2 PTP_CLOCK_GETCAPS
> +#endif
> +
> #if LINUX_VERSION_CODE < KERNEL_VERSION(5,8,0)
>
> /* from upcoming Linux kernel version 5.8 */
> diff --git a/phc_ctl.c b/phc_ctl.c
> index 6a5c2f43d7c9..17a615f8aae6 100644
> --- a/phc_ctl.c
> +++ b/phc_ctl.c
> @@ -288,7 +288,7 @@ static int do_caps(clockid_t clkid, int cmdc,
> char *cmdv[])
> return 0;
> }
>
> - if (ioctl(CLOCKID_TO_FD(clkid), PTP_CLOCK_GETCAPS, )) {
> + if (ioctl(CLOCKID_TO_FD(clkid), PTP_CLOCK_GETCAPS2, )) {
> pr_err("get capabilities failed: %s",
> strerror(errno));
> return -1;
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH 0/5] *** Add support for configurable data set members in ptp4l ***
Hi, Personally I am in favour of more management messages. But: We did not add the option to set masterOnly and slaveOnly, as the ptp4l do not support setting them in run time. A restart is needed for these flags, making the set useless. If you do manage to change the masterOnly and slaveOnly on run-time, we would be very glad, but please verify, before patching. We did not forget to write the set, we did read the standard As for domain number, in addition to support, change on run time. There is the carpet effect, as the management protocol relay on domain number to communicate with the ptp4l. Changing on run time might cause us to loos the management communication with the ptp4l itself, in case we are unaware someone else might change the domain number, the management interface is insecure. So, perhaps it is better to leave the set disabled in any case. As for announceReceiptTimeout, not sure why we did not add set, perhaps the same run time issue, worth testing. As for maxStepsRemoved, in general It look a good idea, though I wonder, why did IEEE did not define a standard management TLV for it? We need to test it in run-time before we add a management set, the get you can add in any case. Erez -Original Message- From: izunna.otiji...@renesas.com Sent: Wednesday, 2 November 2022 22:33 To: linuxptp-devel@lists.sourceforge.net Subject: [Linuxptp-devel] [PATCH 0/5] *** Add support for configurable data set members in ptp4l *** From: Izunna Otiji *** The IEEE 1588 standard describes a SET action for the PTP management message, however, ptp4l is missing the implementation of some of these SET actions. This patch adds the SET action for the following configurable dataset members, as needed by the ITU-T Telecom Profiles (G.8265.1, G.8275.1, G.8275.2): defaultDS.domainNumber (managementId DOMAIN) defaultDS.slaveOnly (managementId SLAVE_ONLY) defaultDS.maxStepsRemoved (*new* managementId MAX_STEPS_REMOVED_NP (0xC00A)) portDS.announceReceiptTimeout (managementId ANNOUNCE_RECEIPT_TIMEOUT) portDS.masterOnly (managementId MASTER_ONLY) *** Izunna Otiji (5): ptp4l: Add SET for defaultDS.domainNumber ptp4l: Add SET for defaultDS.slaveOnly ptp4l: Add SET for portDS.announceReceiptTimeout ptp4l: Add SET for portDS.masterOnly ptp4l: Add SET for defaultDS.maxStepsRemoved clock.c | 26 ++ pmc.c| 5 + pmc_common.c | 15 +++ port.c | 11 +++ tlv.h| 1 + 5 files changed, 54 insertions(+), 4 deletions(-) -- 2.37.2 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cerez.geva.ext%40siemens.com%7Ca4ddbe4285454cb2efc508dabd1a27de%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638030217279130687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=z9H3UuewDspsHkb8iIquQl0gjGrM3VNPbcgeVoRmH%2Bo%3Dreserved=0 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] phc_ctl: add pin_cfg command to display pin functions
Already have it in https://github.com/erezgeva/libptpmgmt/blob/master/src/ptp.h Erez -Original Message- From: Miroslav Lichvar Sent: Thursday, 27 October 2022 17:00 To: Jacob Keller Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] phc_ctl: add pin_cfg command to display pin functions On Thu, Oct 27, 2022 at 03:32:48AM -0700, Jacob Keller wrote: > Add a new function to phc_ctl to display the devices pin configuration > data. First, obtain the device capabilities to determine the number of > pins. Then, for each pin, print the name, function, and channel > information. Nice feature. In a quick test, it printed the state correctly after setting it with "testptp -L". Do you plan to add also pin_set? -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cerez.geva.ext%40siemens.com%7C251d114a1038480f9d8c08dab82c36a2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638024797280276161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Mmcyv9SWoG8j5HkvEwD%2F7wADQXidByNzHOAdNqX36wc%3Dreserved=0 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Inclusion of a virtual PTP port on a PTP clock
On Mon, 17 Oct 2022 at 16:46, Vipin Sharma wrote: > Hi Richard, > We really appreciate the work and time you have spent on our commits and > the community work you are doing for LinuxPTP and other timesync features. > > "I read Annex B and Appendix III of T-REC-G.8275-202010, and I claim > > that linuxptp already implements this functionality, even though there is >> no "virtual port" explicitly modeled." > > > I see that you have said that this functionality is already present and > it's against the design practice for having the same thing in two different > ways. We have the opinion that LinuxPTP doesn't support the Virtual Port > mechanism to address the specification. > > If you talk about BMCA in ts2phc or phc2sys that actually doesn't make any > sense. Since the virtual port should participate in the ptp4l BMCA, it > should select the best port among them, including the virtual port. > This is actually in the right approach as ts2phc acts as a PTP node and > sends announce and sync messages to the BMCA in PTP4L instance. There is a > possibility of N numbers of Ports which can become master and TS2PHC or > PHC2SYS won't be aware of it so keeping BMCA in the one place is the right > approach. > > I saw a similar complaint with the sys2phc, as it can not change the direction of the synchronization if the port is master instead of client. I do think you have a point. But I think Richard is not interested in new naming of virtual ports and moving the ts2phc into ptp4l. I think he looks for fewer changes that would be able to support your deployment, but without merging the ts2phc into ptp4l. Perhaps you are right and we should merge ts2phc and sys2phc into ptp4l and let the system clock or any non PTP clock behave as a virtual port. But I think you should start by explicitly explaining in simple, what you think is missing in the current ts2phc and sys2phc to fulfill your needs, but without moving to a robust ptp4l with "virtual ports". Or convince us, why do you think the new "virtual port" is better? Erez > We do agree that currently the reverse direction message from PTP4L to > TS2PHC is not implemented and TS2PHC doesn't stops synchronizing using the > 1PPS in case External PTP Node become master, but this can be easily > implemented with help of Virtual Ports, we can send the management message > to accomplish this task very easily using Virtual Port. This can be an open > item for discussion. > > The SyncMonk team would be happy to host a meeting at everyone's > convenient time and day. Please note we are based in Bangalore, INDIA but > can work in any timezone to solve the open items. > > Thanks and Regards, > Vipin Sharma > > CEO and Founder > > SyncMonk Technologies Pvt Limited > > https://www.linkedin.com/in/vipinsss > > https://www.linkedin.com/company/syncmonk > +91-9844419796 > vipin.sha...@syncmonk.net > www.syncmonk.net > Bangalore-560035 > > > On Sat, 15 Oct, 2022, 10:28 am Richard Cochran, > wrote: > >> On Sat, Oct 08, 2022 at 04:05:17PM -0700, Richard Cochran wrote: >> > >> > So I really don't see any reason for merging the Virtual Port patch >> > series. It merely adds a second way to accomplish existing >> > functionality, but having two ways of doing the same thing violated >> > best software design practice. >> >> Having said that, I'm not *totally* against the idea of adding a >> Virtual Port that participates in the BCMA explicitly. >> >> As I said in another thread, it would be nice to have the system clock >> (think phc2sys) and/or the GPS clock (think ts2phc) act like first >> class PTP nodes, generating and consuming Announce messages, >> maintaining the relevant data sets, and running the BCMA explicitly. >> >> However, the patch series presented by SyncMonk doesn't follow through >> in that respect. >> >> Thanks, >> Richard >> >> >> ___ >> 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 mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Add source only option to phc2sys autoconfiguration
On Wed, 12 Oct 2022 at 13:48, Jakub Raczynski <
j.raczyn...@elpromaelectronics.com> wrote:
> Current implementation of flag "-a -rr" for phc2sys selects CLOCK_REALTIME
> for
> both directions of PTP synchronization. This may be impractical for Network
>
Not really sure what you are talking about, it can be used to "synchro‐
nize the system clock to a PTP hardware clock (PHC)".
Which means it updated the PHC and only read the CLOCK_REALTIME.
Why do you need to "protect" the CLOCK_REALTIME further?
> Time Servers which use alternative sources of synchronization, that usually
> have clock adjusted by ntpd/chrony.
> For gPTP Grandmaster in Time Servers the most optimal solution would be to
>
What do you mean by "gPTP"?
Do you mean Generalized Precision Time Protocol (gPTP, IEEE 8201.AS)?
There is a project that uses the gPTP name: https://github.com/Avnu/gptp
> use CLOCK_REALTIME to synchronize phc when in Master state and stopping
> synchronization when in Slave state. This would allow to combine
> internal Time Server sources (using ntpd/chrony) with phc as Master/Slave.
>
> Implementation of two-way gPTP synchronization requires two phc2sys
> instances:
> - one synchronizing CLOCK_REALTIME->phc when in Master (phc2sys -a -rr),
> - second synchronizing phc->ntpshm when in Slave state (phc2sys -a -r -E
> ntpshm).
>
Looks like a great idea, why is it related to "double" read-only of the
system clock?
Seems you want a flag that toggle the phc2sys based on the ptp4l state,
whether it is source (master) or it is a client (slave).
I think that a condition flag like that is better than using a 3 x 'r',
which is quite confusing.
I think something like:
1. Normal mode, Sys clock => PHC or PHC => Sys clock
2. PHC only, Sys clock => PHC if ptp4l is master (source)
3. both, Sys clock => PHC if ptp4l is source (maste) or PHC => Sys clock
if ptp4l is client (slave)
> The problem is that current implementation of autoconfiguration in gPTP
> will
>
synchronize phc from CLOCK_REALTIME when in Slave state.
>
Then fix gPTP.
>
> To address this issue, the additional (triple) '-r' flag was implemented.
> When using '-a -rrr' CLOCK_REALTIME will be used as "source only".
> This is probably better solution than usage of separate program detecting
> current portState of PTP.
>
I do not understand how this solves the problem.
As phc2sys does communicate with ptp4l, it can probe the portState and you
do not need an additional program for that.
Although in most cases we want to make the decision, who is the
master/grandmaster of our PTP domain,
As PTP does work with "priorities", it means that in practice, any PTP
entity with a higher value may become the master. So a feature like that in
phc2sys does make sense :-)
Erez
>
> Signed-off-by: Jakub Raczynski
> ---
> phc2sys.8 | 5 -
> phc2sys.c | 22 --
> 2 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/phc2sys.8 b/phc2sys.8
> index 963df83..3858c22 100644
> --- a/phc2sys.8
> +++ b/phc2sys.8
> @@ -75,7 +75,10 @@ to also synchronize the system clock (CLOCK_REALTIME).
> By default, the
> system clock is not considered as a possible time source. If you want the
> system clock to be eligible to become a time source, specify the
> .B \-r
> -option twice.
> +option twice. Specify
> +.B \-r
> +thrice to use CLOCK_REALTIME as source only and do not synchronize it to
> +other sources.
> .TP
> .BI \-f " config"
> Read configuration from the specified file. No configuration file is read
> by
> diff --git a/phc2sys.c b/phc2sys.c
> index 2c8e905..ab0376a 100644
> --- a/phc2sys.c
> +++ b/phc2sys.c
> @@ -72,6 +72,7 @@ struct clock {
> int sysoff_method;
> int is_utc;
> int dest_only;
> + int src_only;
> int state;
> int new_state;
> int sync_offset;
> @@ -468,12 +469,16 @@ static void reconfigure(struct phc2sys_private *priv)
> src = rt;
> rt->state = PS_SLAVE;
> } else if (rt) {
> - if (rt->state != PS_MASTER) {
> + if (rt->state != PS_MASTER && !rt->src_only) {
> rt->state = PS_MASTER;
> clock_reinit(priv, rt, rt->state);
> }
> LIST_INSERT_HEAD(>dst_clocks, rt, dst_list);
> pr_info("selecting %s for synchronization", rt->device);
> + if (rt && rt->src_only && rt->state != PS_MASTER) {
> + pr_info("clock %s selected as source only, not
> sync
Re: [Linuxptp-devel] [PATCH] Fixed time of generic ts2phc master
Hi, I think we should put a comment there. It does looks buzzard to see ' ts->tv_nsec = ntx.time.tv_usec'. Though this is how 'ADJ_NANO' works Erez -Original Message- From: Miroslav Lichvar Sent: Monday, 26 September 2022 10:57 To: j.raczynski Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Fixed time of generic ts2phc master On Mon, Sep 26, 2022 at 09:53:34AM +0200, j.raczynski wrote: > Fixed incorrect conversion of units from [us] to [ns] when polling PPS > time from generic master in ts2phc program. > --- a/ts2phc_generic_pps_source.c > +++ b/ts2phc_generic_pps_source.c > @@ -42,7 +42,7 @@ static int ts2phc_generic_pps_source_getppstime(struct > ts2phc_pps_source *src, > return -1; > } > ts->tv_sec = ntx.time.tv_sec + ntx.tai; > - ts->tv_nsec = ntx.time.tv_usec; > + ts->tv_nsec = ntx.time.tv_usec * 1000; There is ADJ_NANO passed to the adjtimex call few lines above this, so it should be in nanoseconds, even though it says tv_usec. Did you see a bug, or was this just a review? -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=05%7C01%7Cerez.geva.ext%40siemens.com%7C8613f4fd91564ec8914908da9f9d4e7f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637997795218339465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5yiVNbmFsS555g6rs4q1KmRfQI5yNq3XhoeAjWCl2Lc%3Dreserved=0 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
