Re: [PATCH v5 net-next 1/7] ptp: Add ioctls for PHC timestamps with quality attributes

On Wed, 2026-07-29 at 00:16 +0000, Arthur Kiyanovski wrote:
>  
> >      if (ptp->info->gettimexattrs64)
> >          err = ptp->info->gettimexattrs64(ptp->info, &ts, &sts, &att);
> >      else if (ptp->info->gettimex64)
> >          err = ptp->info->gettimex64(ptp->info, &ts, &sts);
> >      else
> >          return -EOPNOTSUPP;
> > 
> > A userspace that respects the capability bits would refuse to call the
> > new ioctl on drivers that would in fact serve it via the fallback. Is
> > the fallback intended, and if so, should the caps advertise it? The
> > commit message does not describe this behavior.
> > 
> 
> The fallback is intentional. I'll widen the caps in v6 so they advertise it
> (gettimexattrs64 || gettimex64, getcrosststampattrs || getcrosststamp) and
> document the behavior in the commit message. Thanks.

FWIW I kind of hate this pattern. I understand it's how PTP does
things, so I'm not suggesting you change it now, but these are all
*kernel* functions not userspace API, so why not just add the new
argument to the existing function rather than adding a new function?

In the linux-phc rework it basically all collapses down to *one*
function that's needed to read a clock, with a bunch of optional
arguments. (Which I guess means that in a very short period of time,
I'll stop caring how awful it is in the PTP code...)