Re: [Linuxptp-devel] [PATCH] Add support for DELAY_REQ and SYNC packets rx_filter

2023-11-14 Thread Erez
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 Featu

Re: [Linuxptp-devel] [PATCH] Add support for DELAY_REQ and SYNC packets rx_filter

2023-11-14 Thread IlorDash
Honestly, I don't know, is it necessary to dynamically switch RX filters, If the device supports EVENT RX filters, because with EVENT RX filters it can handle all PTP messages. Maybe you could suggest appropriate behaviour for utility in that case? Yes, I agree that it can be added as a new enum t

[Linuxptp-devel] [PATCH] print: Support log level in message tag.

2023-11-14 Thread Miroslav Lichvar
If the string specified by the message_tag option contains "{level}", replace it with the log level of the message as a number. This allows users to filter printed log messages by their level. Signed-off-by: Miroslav Lichvar --- phc2sys.8 | 4 +++- print.c | 27 ++- p

Re: [Linuxptp-devel] [PATCH] Add support for DELAY_REQ and SYNC packets rx_filter

2023-11-14 Thread Miroslav Lichvar
On Mon, Nov 13, 2023 at 08:47:48PM +0300, IlorDash wrote: > I assumed, if these filters are defined in Kernel, they might be used in > 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_

[Linuxptp-devel] [PATCH v2 2/4] pmc_agent: Make update interval configurable.

2023-11-14 Thread Miroslav Lichvar
Add a new parameter to pmc_agent_subscribe() to specify the maximum expected interval between pmc_agent_update() calls to avoid gaps in the subscription coverage when phc2sys is configured with an update rate smaller than 1 per minute. Define a minimum update interval of 10 seconds (corresponding

[Linuxptp-devel] [PATCH v2 3/4] phc2sys: Better indicate domain with realtime clock.

2023-11-14 Thread Miroslav Lichvar
Add a new field to the domain struct to mark the domain which contains the system realtime clock instead of relying on the fact that the domain doesn't have a subscribed pmc agent. Signed-off-by: Miroslav Lichvar --- phc2sys.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff -

[Linuxptp-devel] [PATCH v2 4/4] phc2sys: Stop synchronization when ptp4l stops responding.

2023-11-14 Thread Miroslav Lichvar
phc2sys in the automatic mode waits for ptp4l on start, but doesn't care if it stopped providing state notifications and responding to UTC offset requests, e.g. if it stopped, crashed, freezed, or its socket was removed by a misconfigured ptp4l instance. To better handle broken communication with

[Linuxptp-devel] [PATCH v2 0/4] Handle unresponsive ptp4l in phc2sys

2023-11-14 Thread Miroslav Lichvar
v2: - changed pmc_agent_subscribe() to accept update interval instead of subscription duration to simplify the code and keep constants in one place - reordered and merged patches to better follow the previous change - improved coding style per suggestions This series improves the automatic mode

[Linuxptp-devel] [PATCH v2 1/4] pmc_agent: Add function to check if still subscribed.

2023-11-14 Thread Miroslav Lichvar
Add function to compare the current time with the time of the last successful pmc update to determine if ptp4l is still responding. Signed-off-by: Miroslav Lichvar --- pmc_agent.c | 15 +++ pmc_agent.h | 8 2 files changed, 23 insertions(+) diff --git a/pmc_agent.c b/pmc_a

Re: [Linuxptp-devel] [PATCH 5/5] phc2sys: Stop synchronization when ptp4l stops responding.

2023-11-14 Thread Miroslav Lichvar
On Thu, Nov 09, 2023 at 10:54:31PM -0800, 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, > > -

[Linuxptp-devel] [PATCH 0/2] Implement gPTP-Capable TLV Signaling message for per-domain asCapable

2023-11-14 Thread Chwee-Lin Choong
This commit implements the gPTP-capable TLV signaling messages, essential for determining if a PTP domain is asCapable (or neighborGptpCapable) in a multi-PTP domain system with Command Mean Link Delay Service (CMLDS) enabled. The first patch establishes the transmission and reception mechanisms

[Linuxptp-devel] [PATCH 1/2] port: Implement gPTP-capable TLV signaling message processing

2023-11-14 Thread Chwee-Lin Choong
From: Ganesh Venkatesan Implementation of the transmission and reception of gPTP-capable TLV signaling messages is crucial for determining per-domain asCapable when Command Mean Link Delay Service (CMLDS) is enabled, as mandated by the IEEE802.1AS-2020 standard. For transmission, each active PTP

[Linuxptp-devel] [PATCH 2/2] port: Implement asCapableAcrossDomains and neighborGptpCapable

2023-11-14 Thread Chwee-Lin Choong
This commit implements asCapableAcrossDomains and neighborGptpCapable, as specified in IEEE 802.1AS-2020 Section 11.2.2. In scenario with multiple PTP domains, a domain is asCapable only when both asCapableAcrossDomains and neighborGptpCapable are TRUE. The determination of asCapableAcrossDomains