Signed-off-by: Jürgen Appel
---
makefile | 5 ++--
ts2phc.c | 16 ++--
ts2phc_extpps_pps_source.c | 51 ++
ts2phc_extpps_pps_source.h | 15 +++
ts2phc_pps_source.c| 4 +++
ts2phc_pps_source.h
Signed-off-by: Jürgen Appel
---
servo.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/servo.c b/servo.c
index daaa41c..ea171cd 100644
--- a/servo.c
+++ b/servo.c
@@ -103,8 +103,12 @@ static int check_offset_threshold(struct servo *s,
int64_t offset)
long lon
Signed-off-by: Jürgen Appel
---
1pps2phc.service | 42 ++
config.c | 1 +
servo.c | 4
ts2phc.c | 45 -
ts2phc.h | 2 ++
5 files changed, 93 insertions(+), 1 deletion(-)
c
Fix error handling: timeout=1500ms, sign of EINTR, cnt==0.
Signed-off-by: Jürgen Appel
---
ts2phc_pps_sink.c | 66 +++
1 file changed, 49 insertions(+), 17 deletions(-)
diff --git a/ts2phc_pps_sink.c b/ts2phc_pps_sink.c
index d25bc89..1e86849 100644
-
From: Vincent Cheng
In case of broken network there may be an absolute absence of delay packets.
In this scenario ptp4l log messages do not indicate anything is wrong because
the delay response timer is only activate for LOCKED servo state.
This patch expands the delay_response_timeout feature t
From: Vincent Cheng
Sending delay requests prior to getting a delay response grant will incur
unnecessary
delay_response_timeout errors if the remote master only responds to delay
requests
when a delay reponse request was granted.
Signed-off-by: Vincent Cheng
---
port.c | 4 +++-
1 file chan
From: Vincent Cheng
The original intent of the delay_response_timeout submission was to kick servo
out of LOCKED state if a valid delay response was not received within the
configurable delay response timeout duration. In case of broken network there
may be an absolute absence of delay packets
From: Vincent Cheng
Signed-off-by: Vincent Cheng
---
unicast_client.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/unicast_client.c b/unicast_client.c
index 1d84183..e635db1 100644
--- a/unicast_client.c
+++ b/unicast_client.c
@@ -500,6 +500,7 @@ void unicast_client_grant(struct port *p,
From: Vincent Cheng
Signed-off-by: Vincent Cheng
---
unicast_client.c | 20
unicast_client.h | 8
2 files changed, 28 insertions(+)
diff --git a/unicast_client.c b/unicast_client.c
index 0843554..ef7fc5c 100644
--- a/unicast_client.c
+++ b/unicast_client.c
@@ -64
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 lev
An unallocated pmc_agent may be dereferenced in the pmc_agent_destroy
called by the ts2phc_cleanup().
Check if the agent was allocated before releasing it.
v2: Fixed coding standard
Signed-off-by: Maciek Machnikowski
---
ts2phc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
On Mon, Mar 13, 2023 at 12:25:28PM +0200, Kamil Zaripov wrote:
>
> > On 13 Mar 2023, at 03:56, Richard Cochran wrote:
> >
> > We don't support PTP on top of bridge interfaces, because the kernel
> > does not support that, and it would be difficult to add.
>
> Ok, but actually it is possible to
On Mon, Mar 13, 2023 at 03:07:27PM +0100, Maciek Machnikowski wrote:
> An unallocated pmc_agent may be dereferenced in the pmc_agent_destroy
> called by the ts2phc_cleanup().
> Check if the agent was allocated before releasing it.
>
> Signed-off-by: Maciek Machnikowski
> ---
> ts2phc.c | 3 ++-
>
An unallocated pmc_agent may be dereferenced in the pmc_agent_destroy
called by the ts2phc_cleanup().
Check if the agent was allocated before releasing it.
Signed-off-by: Maciek Machnikowski
---
ts2phc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ts2phc.c b/ts2phc.c
in
> 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 process
> On 13 Mar 2023, at 03:56, Richard Cochran wrote:
>
> We don't support PTP on top of bridge interfaces, because the kernel
> does not support that, and it would be difficult to add.
Ok, but actually it is possible to do it using this patch and it works pretty
good in my case (two VLAN’s on to
16 matches
Mail list logo