Re: [PATCH net-next v3 1/5] net-timestamp: extend SCM_TIMESTAMPING ancillary data struct

[Willem de Bruijn <willemb@google.com>]

>>> The kernel would simply saw that adjusted HW timestamps are not
>>> supported, the application has to accomodate the possibility of
>>> needing to use one of the other timestamping flavors.
>>
>> Cavium's PTP library already programs the device PTP clock,
>> just not through the standard interface. It appears to map the
>> memory addresses CVMX_MIO_.. directly. In any case, it
>> will gracefully handle the loss of syststamp.
>>
>> I doubt that there are other users of this Octeon interface, but
>> if so, they can reasonably be expected to do the same and
>> rely on the same legacy Octeon PTP clock interface +
>> hwtstamp as alternative. Is that enough justification to remove
>> syststamp without patching the driver to implement
>> ptp_clock_info?
>>
>> Cleanup would be two patches: one to revert the relevant
>> code in the octeon driver (mostly, ptp_to_ktime), and a
>> follow-up to remove the core code now that the last user
>> is gone.
>
> I'm not sure I understand, can users still get hardware timestamps
> from Octeon cards after such a change?  Unless I misunderstand, the
> only thing left available will be software timestamps, right?

They will still receive hardware timestamps in raw format. The
only feature that is deprecated is hardware timestamps
converted to system time format (ptp_to_ktime).

By querying the PTP clock source, users can perform  perform
this conversion to system time themselves. The Octeon driver
does not support the standard PTP clock interface, but does
appear to use its own alternative using shared memory. I'm
not exactly sure how that memory is setup.