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 function is static so it

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

2020-11-11 Thread Richard Cochran
On Wed, Nov 11, 2020 at 10:43:40AM -0800, Jacob Keller wrote: > Ok, so now the node/agent tracks the subscriptions automatically. So > someone else needs to call renew_subscription first. Right, actually the user needs to call pmc_agent_subscribe()... > Patch context alone isn't enough to follow

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 1/7] Introduce error codes for the run_pmc method.

2020-11-11 Thread Richard Cochran
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 function is static so it would only affect callers in this file. I considered a

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

2020-11-11 Thread Jacob Keller
On 11/10/2020 2:21 PM, Richard Cochran wrote: > If the pmc pointer is not set, then there is no need to read the time only > to later discard the result. This patch simplifies the flow by returning > early if there is no work to be done. > > Signed-off-by: Richard Cochran Makes sense. Revi

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 sub

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 ++-- > pmc_agent.c | 48 +++

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 stack

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 the

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, > R

Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support

2020-11-11 Thread Richard Cochran
On Wed, Nov 11, 2020 at 02:16:55PM +0100, Luigi 'Comio' Mantellini wrote: > Thanks Richard, > > I will try to better describe my scenario. > On my input-only ITU 8271 interface I receive a Time Event message (with > T1=Time and T2 timestamp and a configurable "cable delay") and at the same > time

Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support

2020-11-11 Thread Luigi 'Comio' Mantellini
Thanks Richard, I will try to better describe my scenario. On my input-only ITU 8271 interface I receive a Time Event message (with T1=Time and T2 timestamp and a configurable "cable delay") and at the same time I receive an Announcement-like message. Ideally, this port should work like any other

Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support

2020-11-11 Thread Richard Cochran
On Wed, Nov 11, 2020 at 10:04:46AM +0100, Luigi 'Comio' Mantellini wrote: > This is an aspect really interesting for me, because in my environment I > haven't true linux interfaces and the serial line discussed above. > Is there an example of "new transport" implementation using your API? Yes, the

Re: [Linuxptp-devel] G.8271 Annex A A.1.3 Serial communication channel support

2020-11-11 Thread Luigi 'Comio' Mantellini
Hi Richard, Reading the project homepage I read the following statement: "Modular design allowing painless addition of new transports and clock servos.". This is an aspect really interesting for me, because in my environment I haven't true linux interfaces and the serial line discussed above. Is