On Mon, May 16, 2022 at 11:37:58AM +0200, Miroslav Lichvar wrote: > On Sat, May 14, 2022 at 12:38:31PM -0700, Richard Cochran wrote: > > On Thu, Mar 24, 2022 at 02:19:51PM +0100, Miroslav Lichvar wrote: > > > When probing support for a PTP_SYS_OFFSET ioctl, assume errors other > > > than EOPNOTSUPP and EINVAL are temporary errors (some drivers are known > > > to return with EBUSY or EIO). > > > > If that is the case, then the code should retry only on EBUSY or EIO. > > Ok. My concern was that there might be other (possibly out-of-tree) > drivers using a different error code, which would not be handled > correctly.
I think EBUSY is the only reasonable choice for drivers. Even EIO typically flags an unrecoverable HW fault. But we need not worry about out of tree. That isn't our problem. > > > Try the ioctl up to 100 times before > > > giving up on it to make the detection more reliable. > > > > Why 100? Better to use time based retry method. > > 100 looked to me like a nice round number large enough to avoid false > negatives. I guess even 10 would be plenty, but don't really have any > data to back that up. > > What interval do you suggest? 10 milliseconds? Of real time or > perhaps consumed CPU time (CLOCK_PROCESS_CPUTIME_ID)? I would use monotonic clock (real time not process time). Duration? I don't know... how long do these errors persist? (I haven't seen such errors before) Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
