Re: [Linuxptp-devel] [PATCH v3 3/3] phc_ctl: add get_pins_cfg command to display pin functions

2023-06-24 Thread Erez
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

2023-06-24 Thread Erez
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