[Linuxptp-devel] [PATCH v2] Increase the default tx_timestamp_timeout to 10

2021-07-08 Thread Jacob Keller
to the socket error queue. (On old kernels around the 3.x era the poll will sleep for the full duration before reporting the timestamp, but this is now quite an old kernel release). Signed-off-by: Jacob Keller --- config.c| 2 +- configs/default.cfg | 2 +- ptp4l.8 | 2 +- 3

[Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5

2021-07-07 Thread Jacob Keller
. In most cases, hardware is only capable of a single outstanding timestamp at a time, so we cannot send another packet anyways until the first one has completed. Signed-off-by: Jacob Keller --- config.c| 2 +- configs/default.cfg | 2 +- ptp4l.8 | 2 +- 3 files changed, 3

Re: [Linuxptp-devel] [PATCH 2/2] Add setting of PTP_TIMESCALE flag

2021-06-14 Thread Jacob Keller
On 6/14/2021 5:03 AM, Miklas, Marcin via Linuxptp-devel wrote: > From: Marcin Miklas > > In gPTP PTP_TIMESCALE flag should be set to 1. It looks like the flags > where not properly set for any of messages used in gPTP. > > Some of the automotive gPTP bridges where rejecting the PDelayReq

Re: [Linuxptp-devel] Recover a faulty master port

2021-06-09 Thread Jacob Keller
On 6/7/2021 1:19 PM, YENDstudio wrote: > Hello, > > I have configure one of my machines as a unicast BC which is > synchronized to the grandmaster clock via the first of it's two ports. > The second port is used to provide sync to another local machine. This > setup works for a few hours after

Re: [Linuxptp-devel] [Linuxptp-users] phc2sys jump into huge value

2021-04-29 Thread Jacob Keller
On 4/29/2021 8:04 AM, ramesh t wrote: > hello Jake, > > Did time profiling using time ticks.  > Under the problem condition, observing clock_gettime of interface > connected to BC is taking more time ticks. This results in phc offset > jumping to 4 digit value momentarily. Also i'm not sure if

Re: [Linuxptp-devel] [PATCH 0/1] Add master only management TLV

2021-04-22 Thread Jacob Keller
On 4/22/2021 8:46 AM, Luigi 'Comio' Mantellini wrote: > Generally speaking and in my opinion should be interesting to have the > following features: >  - asynchronous clock adjust: I2c is a slow bus with unpredictable > access time, especially when you have a lot of devices. this is a true >

Re: [Linuxptp-devel] SyncE support

2021-03-30 Thread Jacob Keller
On 3/22/2021 8:40 AM, Miroslav Lichvar wrote: > FWIW, some onboard NICs supported by the e1000e driver can > "cross-timestamp" using the Always Running Timer (ART), which should > avoid the asymmetry of PCIe. I have not seen any detailed description > of how it actually works. > I'm not sure

Re: [Linuxptp-devel] [PATCH 2/2] Clock Class Threshold Feature addition for PTP4L

2021-02-16 Thread Jacob Keller
On 2/14/2021 9:59 PM, Karthikkumar V wrote: > Implemented code review comments. > This code changes brings in the ability to program the acceptable > clockClass threshold beyond which device will move to holdover/free-run. > Default clockClass threshold is 248. > Example Use-Case > This is

Re: [Linuxptp-devel] [PATCH 1/1] clock: Introduce step_window to free run x seconds after a clock step.

2021-02-01 Thread Jacob Keller
On 2/1/2021 2:55 PM, vincent.cheng...@renesas.com wrote: > From: Vincent Cheng > > When clock stepping is unable to happen instantaneously the subsequent > timestamps after a clock step does not reflect the step result and > undesired clock freq and step adjustments will occur. > > When

Re: [Linuxptp-devel] [PATCH 5/6] clock: Add read-only UDS port for monitoring.

2021-01-26 Thread Jacob Keller
On 1/26/2021 2:00 AM, Miroslav Lichvar wrote: > Add a second UDS port to allow untrusted applications to monitor ptp4l. > On this "read-only" UDS port disable non-GET actions and forwarding. > The path can be configured with the uds_address2 option (default is > /var/run/ptp4lro). > should

Re: [Linuxptp-devel] [PATCH 1/6] port: Don't assume transport from port number.

2021-01-26 Thread Jacob Keller
clock number is zero. Reviewed-by: Jacob Keller > --- > port.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/port.c b/port.c > index 0a93c06..6136153 100644 > --- a/port.c > +++ b/port.c > @@ -3108,23 +3108,25 @@ struct port *port

Re: [Linuxptp-devel] [RFC PATCH] clock: Add read-only UDS port for monitoring.

2021-01-21 Thread Jacob Keller
On 1/21/2021 12:31 AM, Miroslav Lichvar wrote: > On Wed, Jan 20, 2021 at 10:13:25PM +, Keller, Jacob E wrote: >> It makes sense to remove forwarding, but I am not sure I understand the >> justification for removing access to subscriptions.. if the subscription is >> for read only data,

Re: [Linuxptp-devel] [PATCH 2/4] Deprecate the slaveOnly option in favor of clientOnly.

2021-01-14 Thread Jacob Keller
On 1/14/2021 6:15 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran > --- > clock.c | 4 ++-- > config.c | 5 - > port.c | 2 +- > ptp4l.c | 2 +- > timemaster.c | 2 +- > 5 files changed, 9 insertions(+), 6 deletions(-) > > diff --git a/clock.c b/clock.c >

Re: [Linuxptp-devel] [PATCH 1/4] Check for deprecated "long" options on the command line.

2021-01-14 Thread Jacob Keller
On 1/14/2021 6:15 AM, Richard Cochran wrote: > The slaveOnly and masterOnly options will be deprecated in favor of > clientOnly and serverOnly, respectively. However, existing user scripts > may very well make use of these options. Apply the deprecated option > check to the long command line

Re: [Linuxptp-devel] [PATCH v2 0/8] Convert to inclusive terminology, Part I

2021-01-11 Thread Jacob Keller
On 1/11/2021 9:05 AM, Richard Cochran wrote: > On Mon, Jan 11, 2021 at 10:07:41AM +0100, Miroslav Lichvar wrote: >> What will happen with the "grandmaster" term? Does it stay, or should > > No decision yet on that one. > >> it be replaced with something like "Primary time server"? > > That

Re: [Linuxptp-devel] [RFC Patch 2/2] port: Fix link down/up to continue using phc_index set from command line -p option.

2021-01-07 Thread Jacob Keller
On 1/6/2021 11:39 AM, vincent.cheng...@renesas.com wrote: > From: Vincent Cheng > > In the scenario where a port link goes down and up, current code checks > the port's phc_index against the interface's phc_index and if they are > different will set the port phc_index to the interface

Re: [Linuxptp-devel] [RFC Patch 1/2] port: Add phc_from_cmdline to indicate the phc index was from the command line.

2021-01-07 Thread Jacob Keller
On 1/6/2021 11:39 AM, vincent.cheng...@renesas.com wrote: > From: Vincent Cheng > > Signed-off-by: Vincent Cheng > --- > port_private.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/port_private.h b/port_private.h > index fcabaa6..6e40e15 100644 > --- a/port_private.h > +++

Re: [Linuxptp-devel] [PATCH v2 0/8] Convert to inclusive terminology, Part I

2021-01-07 Thread Jacob Keller
On 1/5/2021 6:42 AM, Richard Cochran wrote: > * Changed in v2: > - Use client/server terminology in the phc2sys man page. > - Add missing source/sink conversions in the phc2sys man page. > > > There is an industry wide effort underway to replace historically and > culturally loaded terms

Re: [Linuxptp-devel] [PATCH v2 8/8] ts2phc: Convert usage message to time source/sink terminology.

2021-01-07 Thread Jacob Keller
On 1/5/2021 6:42 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran Reviewed-by: Jacob Keller > --- > ts2phc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ts2phc.c b/ts2phc.c > index 2342858..bc41041 100644 > --- a/ts2phc.c >

Re: [Linuxptp-devel] [PATCH v2 7/8] ptp4l: Convert usage messages to client/server terminology.

2021-01-07 Thread Jacob Keller
On 1/5/2021 6:42 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran Reviewed-by: Jacob Keller > --- > ptp4l.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ptp4l.c b/ptp4l.c > index 84661c5..ccbaa02 100644 > --- a/ptp4l.c &g

Re: [Linuxptp-devel] [PATCH v2 6/8] phc2sys: Convert usage messages to time source/sink terminology.

2021-01-07 Thread Jacob Keller
On 1/5/2021 6:42 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran Reviewed-by: Jacob Keller > --- > phc2sys.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/phc2sys.c b/phc2sys.c > index aafff6c..70155f9 100644 >

Re: [Linuxptp-devel] [PATCH v2 5/8] ts2phc: Convert man page to source/sink terminology.

2021-01-07 Thread Jacob Keller
On 1/5/2021 6:42 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran Reviewed-by: Jacob Keller > --- > ts2phc.8 | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/ts2phc.8 b/ts2phc.8 > index 77f8940..0bd523d 10

Re: [Linuxptp-devel] [PATCH v2 4/8] ptp4l: Convert man page to client/server terminology.

2021-01-07 Thread Jacob Keller
On 1/5/2021 6:42 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran Reviewed-by: Jacob Keller > --- > ptp4l.8 | 80 + > 1 file changed, 41 insertions(+), 39 deletions(-) > > diff --git a/ptp4l.8 b/ptp4l

Re: [Linuxptp-devel] [PATCH v2 3/8] phc2sys: Convert man page to client/server terminology.

2021-01-07 Thread Jacob Keller
On 1/5/2021 6:42 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran Reviewed-by: Jacob Keller > --- > phc2sys.8 | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/phc2sys.8 b/phc2sys.8 > index 7773fd0..99fc937 100

Re: [Linuxptp-devel] [PATCH v2 2/8] phc2sys: Convert man page to source/sink terminology.

2021-01-07 Thread Jacob Keller
On 1/5/2021 6:42 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran > --- Makes sense. I like this direction for the terminology change. Reviewed-by: Jacob Keller > phc2sys.8 | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) >

Re: [Linuxptp-devel] [PATCH v2 1/8] phc2sys: Update man page to reflect the new restriction on the PPS mode.

2021-01-07 Thread Jacob Keller
On 1/5/2021 6:42 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran > --- > phc2sys.8 | 16 > 1 file changed, 4 insertions(+), 12 deletions(-) > > diff --git a/phc2sys.8 b/phc2sys.8 > index b3a3de3..66007eb 100644 > --- a/phc2sys.8 > +++ b/phc2sys.8 > @@ -1,4 +1,4

Re: [Linuxptp-devel] [PATCH 6/6] phc2sys: Replace magical test with a proper test.

2020-11-30 Thread Jacob Keller
de by using a proper test. > > Signed-off-by: Richard Cochran Significant improvement here, it is a bit more clear what's going on here now. Reviewed-by: Jacob Keller Thanks, Jake > --- > phc2sys.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > dif

Re: [Linuxptp-devel] [PATCH 5/6] phc2sys: Expand the validation of the PPS mode.

2020-11-30 Thread Jacob Keller
hran Reviewed-by: Jacob Keller > --- > phc2sys.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/phc2sys.c b/phc2sys.c > index 03347f0..e65bdf5 100644 > --- a/phc2sys.c > +++ b/phc2sys.c > @@ -1253,6 +1253,10 @@ int main(int argc, char *argv[]) >

Re: [Linuxptp-devel] [PATCH 4/6] phc2sys: Validate the PPS mode right away.

2020-11-30 Thread Jacob Keller
n Makes sense. Reviewed-by: Jacob Keller > --- > phc2sys.c | 17 ++--- > 1 file changed, 10 insertions(+), 7 deletions(-) > > diff --git a/phc2sys.c b/phc2sys.c > index f28e9be..03347f0 100644 > --- a/phc2sys.c > +++ b/phc2sys.c > @@ -1245,6

Re: [Linuxptp-devel] [PATCH 3/6] phc2sys: Replace hard coded tests with a readable helper function.

2020-11-30 Thread Jacob Keller
ed-off-by: Richard Cochran Makes sense. Reviewed-by: Jacob Keller > --- > phc2sys.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/phc2sys.c b/phc2sys.c > index e17909f..f28e9be 100644 > --- a/phc2sys.c > +++ b/phc2sys.c > @@ -

Re: [Linuxptp-devel] [PATCH 2/6] phc2sys: Rename PMC agent pointer from node to agent.

2020-11-30 Thread Jacob Keller
On 11/29/2020 7:50 PM, Richard Cochran wrote: > Node is not a very descriptive name. Rename it. > > Signed-off-by: Richard Cochran Reviewed-by: Jacob Keller > --- > phc2sys.c | 48 > 1 file changed, 24 insertion

Re: [Linuxptp-devel] [PATCH 1/6] phc2sys: Don't duplicate the command line arguments.

2020-11-30 Thread Jacob Keller
nts directly. > > Signed-off-by: Richard Cochran Yep, makes sense. Reviewed-by: Jacob Keller > --- > phc2sys.c | 12 > 1 file changed, 4 insertions(+), 8 deletions(-) > > diff --git a/phc2sys.c b/phc2sys.c > index c300984..13cf235 100644 > --- a/phc2sys.c > +

Re: [Linuxptp-devel] [PATCH 4/4] pmc_agent: Simplify the method that gets of the number of local ports.

2020-11-30 Thread Jacob Keller
On 11/28/2020 9:08 AM, Richard Cochran wrote: > The number of ports is already available in the cached default data > set. Use it directly. > > Signed-off-by: Richard Cochran > --- > phc2sys.c | 2 +- > pmc_agent.c | 24 > pmc_agent.h | 11 ++- > 3 files

Re: [Linuxptp-devel] [PATCH 2/4] pmc_agent: Convert the method that queries the port properties.

2020-11-30 Thread Jacob Keller
On 11/28/2020 9:08 AM, Richard Cochran wrote: > Prefix the function with the module name and correct the return code > semantics. > > The active word in the function's name is "query" rather that "get" in > order to distinguish methods that send and receive over the network > from those that

Re: [Linuxptp-devel] [PATCH 1/4] pmc_agent: Convert the method that queries TAI-UTC offset into the canonical form.

2020-11-30 Thread Jacob Keller
t send and receive over the network > from those that merely return a cached value. > > Signed-off-by: Richard Cochran Reviewed-by: Jacob Keller I appreciate the function rename too, it seems a bit more clear. (Plus, if this were a project with many patches in flight, renaming the fun

Re: [Linuxptp-devel] [PATCH 1/7] Introduce error codes for the run_pmc method.

2020-11-11 Thread Jacob Keller
On 11/11/2020 10:50 AM, Richard Cochran wrote: > On Wed, Nov 11, 2020 at 10:35:20AM -0800, Jacob Keller wrote: >> Thoughts on making this an enum instead so that it's even more clear >> from the function signatures that this is not an integer return code? >> The run_pmc

Re: [Linuxptp-devel] [PATCH] Avoid setting clock frequency when free running.

2020-11-11 Thread Jacob Keller
On 11/9/2020 8:14 AM, Richard Cochran wrote: > On Mon, Nov 09, 2020 at 10:12:58AM +0100, Miroslav Lichvar wrote: >> >> Makes sense to me, but maybe it's time to drop the workaround? Looking >> at the git log, it was added in 2013. Are people still using linuxptp >> on kernels older than that? >

Re: [Linuxptp-devel] [PATCH 4/7] pmc_agent: Simplify logic in update method.

2020-11-11 Thread Jacob Keller
Makes sense. Reviewed-by: Jacob Keller > --- > pmc_agent.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/pmc_agent.c b/pmc_agent.c > index 24587b4..47562bc 100644 > --- a/pmc_agent.c > +++ b/pmc_agent.c > @@ -342,14 +342,16 @@

Re: [Linuxptp-devel] [PATCH 3/7] pmc_agent: Simplify the update method.

2020-11-11 Thread Jacob Keller
On 11/10/2020 2:21 PM, Richard Cochran wrote: > The main method that causes the PMC agent to update its status takes a flag > that results in different behavior when push notifications are active. > This patch simplifies the interface by letting the agent remember whether > or not the caller

Re: [Linuxptp-devel] [PATCH 2/7] pmc_agent: Convert the subscribe method into the canonical form.

2020-11-11 Thread Jacob Keller
On 11/10/2020 2:21 PM, Richard Cochran wrote: > This patch renames the function to have the module prefix and corrects the > return code semantics. > > Signed-off-by: Richard Cochran This looks good to me. Reviewed-by: Jacob Keller > --- > phc2sys.c | 4 ++-- &

Re: [Linuxptp-devel] [PATCH 1/7] Introduce error codes for the run_pmc method.

2020-11-11 Thread Jacob Keller
On 11/10/2020 2:21 PM, Richard Cochran wrote: > The run_pmc function is used by several of the PMC agent methods, but it > breaks the pattern of returning zero on success. However, the user facing > PMC agent methods will need to conform to the return code convention used > throughout the

Re: [Linuxptp-devel] [PATCH 0/7] PMC Agent - Part II

2020-11-11 Thread Jacob Keller
On 11/10/2020 2:21 PM, Richard Cochran wrote: > When you start pulling on a thread ... > Indeed! > Looking into the PMC agent code, there are issues that will need > resolution. This series converts the subscribe and update methods > into the canonical form. > > The first patch prepares

Re: [Linuxptp-devel] [PATCH 2/5] pmc_agent: Rename pmc_node to something more descriptive.

2020-11-11 Thread Jacob Keller
On 11/9/2020 3:06 PM, Richard Cochran wrote: > On Tue, Nov 10, 2020 at 12:54:16AM +0200, Vladimir Oltean wrote: >> It will remain named "node" though? > > No, it will change, too. I just want to avoid having too much churn > in a single patch... Part II will finish the job... > > Thanks, >

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

2020-10-27 Thread Jacob Keller
On 10/27/2020 4:26 PM, Richard Cochran wrote: > On Mon, Aug 24, 2020 at 09:41:06AM +0200, Miroslav Lichvar wrote: >> It seems you are set on this terminology. I think it would work for >> me, although in my head I mostly see the packets on the network >> instead of a time signal. Have you

Re: [Linuxptp-devel] [RFC PATCH 01/15] posix_clock_open: derive PHC index from device name if possible

2020-10-02 Thread Jacob Keller
01/15] posix_clock_open: derive PHC >> index from device name if possible >> >> On Wed, Aug 05, 2020 at 04:12:02PM -0700, Jacob Keller wrote: >>> Here, we are making the implicit assumption that all ptp clock devices >>> will always have /dev/ptpX format. I don't th

Re: [Linuxptp-devel] [PATCH 4/8] ts2phc: nmea: Add a configuration option for the current leap seconds file.

2020-09-21 Thread Jacob Keller
On 9/21/2020 11:58 AM, Richard Cochran wrote: > The PTP time scale is TAI, and a PTP GM needs to provide it. However, most > GPS devices only provide UTC time of day information, and they do not, in > general, offer any kind of reliable, standardized leap seconds data. After > all, this

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

2020-08-20 Thread Jacob Keller
On 8/20/2020 2:16 PM, Vladimir Oltean wrote: > On Thu, Aug 20, 2020 at 11:07:09AM -0700, Richard Cochran wrote: >> On Thu, Aug 20, 2020 at 06:45:37PM +0300, Vladimir Oltean wrote: >> >>> What if the terms on which IEEE 1588 settles are not the terms in your >>> mind ("source"/"sink")? >> >>

Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology

2020-08-18 Thread Jacob Keller
On 8/18/2020 1:43 PM, Richard Cochran wrote: > There is an industry wide effort underway to replace historically and > culturally loaded terms like master/slave with neutral alternatives. > The IEEE 1588 committee will most likely amend the standard, but so > far no consensus on the new

Re: [Linuxptp-devel] [RFC PATCH 01/15] posix_clock_open: derive PHC index from device name if possible

2020-08-17 Thread Jacob Keller
[RFC PATCH 01/15] posix_clock_open: derive PHC >> index from device name if possible >> >> On Wed, Aug 05, 2020 at 04:12:02PM -0700, Jacob Keller wrote: >>> Here, we are making the implicit assumption that all ptp clock devices >>> will always have /dev

Re: [Linuxptp-devel] [RFC PATCH 15/15] ts2phc_phc_master: make use of new kernel API for perout waveform

2020-08-05 Thread Jacob Keller
On 8/1/2020 10:46 AM, Vladimir Oltean wrote: > This API was introduced for 2 reasons: > > 1. Some hardware can emit PPS signals but not starting from arbitrary >absolute times, but rather phase-aligned to the beginning of a >second. We _could_ patch ts2phc to always specify a start

Re: [Linuxptp-devel] [RFC PATCH 09/15] ts2phc_slave: print master offset

2020-08-05 Thread Jacob Keller
On 8/1/2020 10:46 AM, Vladimir Oltean wrote: > Make this information more visible by default, since it is the key > output of this program. > > Signed-off-by: Vladimir Oltean Yep. Reviewed-by: Jacob Keller > --- > ts2phc_slave.c | 4 ++-- > 1 file changed, 2 inser

Re: [Linuxptp-devel] [RFC PATCH 08/15] ts2phc: instantiate a pmc node

2020-08-05 Thread Jacob Keller
On 8/1/2020 10:46 AM, Vladimir Oltean wrote: > This introduces the '-a' option in ts2phc, an option inspired from > phc2sys that puts the clocks in "automatic" mode. In this mode, ts2phc > listens, as a PMC, to port state change events from ptp4l, and detects > which port state machine, if any,

Re: [Linuxptp-devel] [RFC PATCH 07/15] ts2phc: instantiate a full clock structure for every PHC master

2020-08-05 Thread Jacob Keller
On 8/1/2020 10:46 AM, Vladimir Oltean wrote: > This is particularly useful when using the "automatic" mode of ts2phc, > and the PPS distribution tree is fixed in hardware (as opposed to port > states). > This refers to work not yet implemented by any of its parent commits. It might make sense

Re: [Linuxptp-devel] [RFC PATCH 07/15] ts2phc: instantiate a full clock structure for every PHC master

2020-08-05 Thread Jacob Keller
On 8/1/2020 10:46 AM, Vladimir Oltean wrote: > This propagates the use of "struct ts2phc_private" all the way into the > master API, in preparation of a new use case that will be supported > soon: some PPS masters (to be precise, the "PHC" kind) instantiate a > struct clock which could be

Re: [Linuxptp-devel] [RFC PATCH 06/15] ts2phc: instantiate a full clock structure for every slave PHC

2020-08-05 Thread Jacob Keller
On 8/1/2020 10:46 AM, Vladimir Oltean wrote: > Slaves in ts2phc are PHC devices that implement the extts kernel API. > They are slaves just in the sense that they timestamp a pulse emitted by > somebody else. > > Currently in ts2phc, PPS slaves are also the only candidates for the > clocks

Re: [Linuxptp-devel] [RFC PATCH 05/15] ts2phc: create a private data structure

2020-08-05 Thread Jacob Keller
ce. Hoever, I think it's a significant improvement on the current state of things, and trying to do this transition piece-meal would be difficult. Avoiding global variables here is definitely an improvement, as it makes it easier to think about who has access to what data. Reviewed-by: Jacob Keller >

Re: [Linuxptp-devel] [RFC PATCH 04/15] pmc_common: fix potential memory leak in run_pmc_events()

2020-08-05 Thread Jacob Keller
The subject says "potential" leak, but in fact it looks like we leaked every single time we succeeded. On 8/1/2020 10:46 AM, Vladimir Oltean wrote: > The convention in all other parts of the code that call run_pmc() is to > free the management PTP message if an error code was returned, or pass >

Re: [Linuxptp-devel] [RFC PATCH 03/15] phc2sys: break out pmc code into pmc_common.c

2020-08-05 Thread Jacob Keller
can be reused by other > modules. Ah, perfect: pmc_node is not too generic, so this is great. I looked this over using git diff with the moved lines coloring options, and the only places where the new code differs is in name change from priv to pmc_node. Makes sense. Reviewed-by: Jacob Kell

Re: [Linuxptp-devel] [RFC PATCH 02/15] phc2sys: rename struct node to struct phc2sys_private

2020-08-05 Thread Jacob Keller
ke node might be too generic. But the change to phc2sys_private seems reasonable. The patch is noisy, but I checked using word-diff and it only changes the name. Reviewed-by: Jacob Keller > > Signed-off-by: Vladimir Oltean > --- > phc2sys.c | 433

Re: [Linuxptp-devel] [RFC PATCH 01/15] posix_clock_open: derive PHC index from device name if possible

2020-08-05 Thread Jacob Keller
On 8/1/2020 10:46 AM, Vladimir Oltean wrote: > Currently the PHC index is retrieved only through an ethtool ioctl if > the PHC is specified as an Ethernet interface. If it's a char device > such as /dev/ptp5, the phc_index will remain unpopulated. Try to infer > it from the char device's path.

[Linuxptp-devel] [PATCH] phc_ctl: display all capability information

2020-08-05 Thread Jacob Keller
The capability command for phc_ctl does not display the number of pins or the cross timestamping support. Add this as output so that the user can see the complete device capabilities. Signed-off-by: Jacob Keller --- phc_ctl.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff

Re: [Linuxptp-devel] Machine Readable Output

2020-07-27 Thread Jacob Keller
On 7/25/2020 7:34 PM, Matthew P. Grosvenor wrote: > >> The messages are standardized and use TLV format so writing your own >> send/receive bits would not be too difficult. Plus, if you don't mind >> GPL you can just simply fork and port pmc into whatever language you >> prefer. > > This is

Re: [Linuxptp-devel] Machine Readable Output

2020-07-22 Thread Jacob Keller
On 7/22/2020 5:07 PM, Richard Cochran wrote: > On Thu, Jul 23, 2020 at 09:57:35AM +1000, Luke Howard wrote: >> Possibly an extension to pmc(8) for emitting JSON would better suit your use >> case, depends on how your application is structured I guess? > > You can pipe the pmc output through a

Re: [Linuxptp-devel] [PATCH] ts2phc_phc_master: specify start time to PPS master as 0.000000000

2020-07-06 Thread Jacob Keller
On 6/26/2020 5:55 AM, Richard Cochran wrote: > On Fri, Jun 26, 2020 at 01:15:11PM +0300, Vladimir Oltean wrote: > >> So, to your point: I didn't see any driver that _rejects_ time in the >> past. If it works, I don't know. If it doesn't work, I would do the >> time fixup at driver level, so in

Re: [Linuxptp-devel] [PATCH] ts2phc_phc_master: specify start time to PPS master as 0.000000000

2020-07-06 Thread Jacob Keller
On 6/26/2020 3:15 AM, Vladimir Oltean wrote: > *Although clock stepping makes that challenging. But I don't know how > many drivers still treat perout correctly after a clock step, and I'm > not even sure what the correct treatment would be. > The way I've seen this done in the past is to

Re: [Linuxptp-devel] [PATCH v2 2/3] clock: dump unexpected packets received on the error queues of sockets

2020-06-18 Thread Jacob Keller
On 6/18/2020 1:17 PM, Vladimir Oltean wrote: > On Thu, 18 Jun 2020 at 23:02, Jacob Keller wrote: >> >> >> >> On 6/18/2020 12:56 PM, Vladimir Oltean wrote: >>>> Could this use the pr facility, so that it honors the printing options >>>> to

Re: [Linuxptp-devel] [PATCH v2 2/3] clock: dump unexpected packets received on the error queues of sockets

2020-06-18 Thread Jacob Keller
On 6/18/2020 12:56 PM, Vladimir Oltean wrote: >> Could this use the pr facility, so that it honors the printing options >> to log to syslog and manages the level? >> >> I'm not sure what I would mark these as: debug because they no longer >> impact the syncing process, or true error because

Re: [Linuxptp-devel] [PATCH v2 2/3] clock: dump unexpected packets received on the error queues of sockets

2020-06-18 Thread Jacob Keller
On 6/15/2020 8:23 AM, Vladimir Oltean wrote: > In the current design of the SO_SELECT_ERR_QUEUE socket option (which is > enabled by sk_timestamping_init on the event fd), it is a bug to only > check revents & POLLIN, but not also POLLERR. > > Normally the error queue events that the

Re: [Linuxptp-devel] [PATCH v2 1/3] ptp4l: call recvmsg() with the MSG_DONTWAIT flag

2020-06-18 Thread Jacob Keller
On 6/15/2020 8:23 AM, Vladimir Oltean wrote: > The application's main event loop (clock_poll) is woken up by poll() and > dispatches the socket receive queue events to the corresponding ports as > needed. > > So it is a bug if poll() wakes up the process for data availability on a > socket's

Re: [Linuxptp-devel] [PATCH 04/11] uds: Convey transmit path errors to the caller.

2020-05-18 Thread Jacob Keller
On 5/18/2020 4:24 PM, Richard Cochran wrote: > On Mon, May 18, 2020 at 04:17:34PM -0700, Jacob Keller wrote: >>> @@ -119,8 +119,8 @@ static int uds_send(struct transport *t, struct fdarray >>> *fda, >>> addr = >address; >>> >>>

Re: [Linuxptp-devel] [RFC PATCH 3/3] phc2pwm: Introduce an utility to sync pwm with PTP clock

2020-05-18 Thread Jacob Keller
On 5/16/2020 11:22 AM, Lokesh Vutla via Linuxptp-devel wrote: > Hi Richard, > > On 16/05/20 10:44 PM, Richard Cochran wrote: >> On Sat, May 16, 2020 at 10:35:33PM +0530, Lokesh Vutla wrote: >>> Hi Richard, >>> >>> On 16/05/20 10:24 PM, Richard Cochran wrote: On Fri, Apr 17, 2020 at

Re: [Linuxptp-devel] [PATCH 11/11] Reject path trace TLVs with excessive elements.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > The current code truncates the size of path trace TLVs which exceed the > expected maximum based on the largest possible message size. However if > another TLV follows, then a gap would appear, that is

Re: [Linuxptp-devel] [PATCH 09/11] port: Export the value of the wildcard port identity.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > Code in other modules will need this special port ID value. This patch > makes it available through the port header file. > > Signed-off-by: Richard Cochran > --- > port.h | 3 +++ >

Re: [Linuxptp-devel] [PATCH 10/11] port: Publish the method for creating signaling messages.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran > --- > port.h | 3 +++ > port_signaling.c | 4 ++-- > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/port.h b/port.h > index

Re: [Linuxptp-devel] [PATCH 07/11] port: Convey targeted forwarding errors to the caller.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > The port_forward_to() method clobbers the specific error code returned > by the transport layer with -1. This patch lets the code preserve the > specific error in question. > > Signed-off-by:

Re: [Linuxptp-devel] [PATCH 08/11] util: Mark port identity comparisons as const.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > The utility function to compare port IDs takes pointers, but it only needs > to read the referenced data. This patch marks the parameters as const, > allowing passing constants in the future. > > Signed-

Re: [Linuxptp-devel] [PATCH 06/11] sk: Convey transmit path errors to the caller.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > The transport layer's functional interface foresees having error codes > percolate back up to the caller. However, up until now, the sk module > simply returned -1 for any error. This patch lets the co

Re: [Linuxptp-devel] [PATCH 05/11] raw: Convey transmit path errors to the caller.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller This one is even easier to tell it is correct. On 5/16/2020 8:03 AM, Richard Cochran wrote: > The transport layer's functional interface foresees having error codes > percolate back up to the caller. However, up until now, the raw module > simply returned -

Re: [Linuxptp-devel] [PATCH 04/11] uds: Convey transmit path errors to the caller.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > The transport layer's functional interface foresees having error codes > percolate back up to the caller. However, up until now, the uds module > simply returned -1 for any error. This patch lets the co

Re: [Linuxptp-devel] [PATCH 02/11] udp: Convey transmit path errors to the caller.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > The transport layer's functional interface foresees having error codes > percolate back up to the caller. However, up until now, the udp module > simply returned -1 for any error. This patch lets the co

Re: [Linuxptp-devel] [PATCH 03/11] udp6: Convey transmit path errors to the caller.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > The transport layer's functional interface foresees having error codes > percolate back up to the caller. However, up until now, the udp6 module > simply returned -1 for any error. This patch lets the co

Re: [Linuxptp-devel] [PATCH 01/11] transport: Correct grammar in the doxygen comments.

2020-05-18 Thread Jacob Keller
Reviewed-by: Jacob Keller On 5/16/2020 8:03 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran > --- > transport.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/transport.h b/transport.h > index 5b8c413..7a7f87b 100644 > -

Re: [Linuxptp-devel] [PATCH V1 1/2] Decouple servo state from automotive profile.

2020-05-18 Thread Jacob Keller
On 5/16/2020 7:42 AM, Richard Cochran wrote: > From: Vincent Cheng > > The logic for the Automotive Profile added a message interval update > mechanism that triggers whenever the servo enters the "stable locked" > state. This SERVO_LOCKED_STABLE state is active when the > configuration

Re: [Linuxptp-devel] [PATCH V1 RFC 0/5] GPS based Grand Master Support

2020-05-01 Thread Jacob Keller
On 5/1/2020 12:05 PM, Richard Cochran wrote: > This series adds support for substantial new features. > > 1. Using a 1-PPS signal from a GPS in order to become a Grand Master >from a high quality, globally traceable time source. > > 2. Using a heterogeneous group of PHC cards wired

Re: [Linuxptp-devel] [PATCH V3 0/6] Clean up in preparation for GrandMaster support.

2020-03-23 Thread Jacob Keller
On 3/21/2020 4:57 AM, Richard Cochran wrote: > I have been preparing Balint Ferencz's ts2phc program for review on > this list. The present series presents a mixture of fixes and new > code in support of the upcoming GrandMaster features. > > Patches 1-3 are random fixes found along the way.

Re: [Linuxptp-devel] PPS generation on BeagleBoneBlack

2020-03-18 Thread Jacob Keller
On 3/16/2020 1:58 PM, Grygorii Strashko via Linuxptp-devel wrote: >> This is the userspace program I have worked on to get the synchronization >> working. Currently the servo part of the tool is in very hacky shape. Before >> cleanup I wanted to get more inputs on where it can be integrated.

Re: [Linuxptp-devel] [PATCH V2 4/6] Add definitions for PTP pin ioctls for backwards kernel compatibility.

2020-03-11 Thread Jacob Keller
On 3/11/2020 11:24 AM, Richard Cochran wrote: > Upcoming functionality will need to configure the input and output pins of > PHC devices. However, this requires fairly recent kernel support. This > patch adds the needed definitions for compiling with older kernel headers. > > In addition,

Re: [Linuxptp-devel] [PATCH V2 2/6] Remove the unfinished SNMP code.

2020-03-11 Thread Jacob Keller
potentially misleading end users about the > scope and completeness of the features. > > Signed-off-by: Richard Cochran Makes sense. It can always be revived. Reviewed-by: Jacob Keller > --- > makefile| 14 > snmp4lptp.8 | 119 -

Re: [Linuxptp-devel] [PATCH V2 1/6] clock: Safely remove event subscribers from list.

2020-03-11 Thread Jacob Keller
priate macro. > > Fixes: 5104e3e56b59 ("Event subscribing") > Signed-off-by: Richard Cochran > Reported-by: Michael Walle Straight forward conversion. Reviewed-by: Jacob Keller > --- > clock.c | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-)

Re: [Linuxptp-devel] [PATCH 5/6] Add PHC methods for querying and configuring the pin functionality.

2020-03-09 Thread Jacob Keller
On 3/9/2020 7:27 AM, Jiri Benc wrote: > On Mon, 9 Mar 2020 07:16:23 -0700, Richard Cochran wrote: >> But maybe that wouldn't be worst thing in the world. There is a trade >> off between maintaining parallel copies of ptp_clock_caps and the >> convenience of compiling the stack just once with the

Re: [Linuxptp-devel] [PATCH RFC 20/30] interface: Introduce a method to test the time stamping information validity.

2020-03-05 Thread Jacob Keller
On 3/4/2020 9:13 AM, Richard Cochran wrote: > On Tue, Feb 18, 2020 at 01:19:09PM -0800, Jacob Keller wrote: >>> +bool interface_tsinfo_valid(struct interface *iface) >>> +{ >>> + return iface->ts_info.valid ? true : false; >>> +} >> >

Re: [Linuxptp-devel] [PATCH RFC 14/30] interface: Introduce a method to set the name.

2020-03-05 Thread Jacob Keller
On 3/4/2020 9:06 AM, Richard Cochran wrote: > On Tue, Feb 18, 2020 at 01:07:52PM -0800, Jacob Keller wrote: >> >> Good, the name is marked as constant. Side note, for those interface_* >> functions that don't modify the interface, does it make sense to mark >> them

Re: [Linuxptp-devel] [PATCH RFC 24/30] interface: Introduce methods to create and destroy instances.

2020-03-05 Thread Jacob Keller
On 3/4/2020 9:19 AM, Richard Cochran wrote: > On Tue, Feb 18, 2020 at 01:25:00PM -0800, Jacob Keller wrote: >> >> I still think it would be good to have the functions guarantee the NULL >> by manually assigning or using one of the string copy implementations >> that

Re: [Linuxptp-devel] [PATCH RFC 28/30] interface: Hide the implementation details.

2020-03-05 Thread Jacob Keller
On 3/4/2020 9:24 AM, Richard Cochran wrote: > On Tue, Feb 18, 2020 at 01:32:01PM -0800, Jacob Keller wrote: >> I'd appreciate if there was some way to ensure we catch the interface >> structure layout changing such that the definitions in clock.c and >> config.c aren't compat

Re: [Linuxptp-devel] More fun with i210 EXTTS: measure some PPS against a reference PPS

2020-03-05 Thread Jacob Keller
On 3/5/2020 8:19 AM, Frantisek Rysanek wrote: > during the initial settling of the PHC frequency / servo loop, > I can see offsets in low units of ns, not aligned in any way. > But: once the PHC settles to offset==0 && ppb==0, > any measured edges captured via EXTTS channel 0 or 1 > will be

Re: [Linuxptp-devel] More fun with i210 EXTTS: measure some PPS against a reference PPS

2020-03-05 Thread Jacob Keller
On 3/5/2020 1:11 AM, Frantisek Rysanek wrote: > And another sideways question is: in the i210 hardware, there's a > register called SYSTIMR, supposedly holding the fraction of a > nanosecond (= sub-nanosecond resolution). And this register is > ignored by the igb driver in Linux - first and

Re: [Linuxptp-devel] [PATCH RFC 07/30] Convert call sites to the proper method for getting interface names.

2020-03-05 Thread Jacob Keller
On 3/4/2020 8:59 AM, Richard Cochran wrote: > On Tue, Feb 18, 2020 at 11:38:43AM -0800, Jacob Keller wrote: >> >> Is there a way to generate the network of how interconnected the various >> object files are? > > The .d files have the includes. I once wrote a sc

Re: [Linuxptp-devel] [PATCH RFC 06/30] interface: Introduce an access method for the name field.

2020-03-05 Thread Jacob Keller
On 3/4/2020 8:56 AM, Richard Cochran wrote: > On Tue, Feb 18, 2020 at 11:33:32AM -0800, Jacob Keller wrote: >> So the interface.o isn't being added to something like $(CONFIG)? > > I like the idea, but I'll leave that as a follow-on task. > > Thanks, > Richard > Y

Re: [Linuxptp-devel] [PATCH RFC 29/30] interface: Silence warning from gcc version 8.

2020-02-18 Thread Jacob Keller
On 2/11/2020 6:04 AM, Richard Cochran wrote: > When compiling with gcc8 and -O2, the clever compiler complains: > >interface.c: In function ‘interface_ensure_tslabel’: >interface.c:38:3: error: ‘strncpy’ output may be truncated copying 108 > bytes from a string of length 108

Re: [Linuxptp-devel] [PATCH RFC 27/30] pmc: Use the proper create/destroy API for network interfaces.

2020-02-18 Thread Jacob Keller
On 2/11/2020 6:04 AM, Richard Cochran wrote: > Signed-off-by: Richard Cochran Reviewed-by: Jacob Keller > --- > pmc_common.c | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/pmc_common.c b/pmc_common.c > index 41

  1   2   >