[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140724.141528.1823901044834131393.davem@davemloft.net>
Date: Thu, 24 Jul 2014 14:15:28 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: willemb@...gle.com
Cc: netdev@...r.kernel.org, eric.dumazet@...il.com,
richardcochran@...il.com, david.daney@...ium.net,
kreese@...iumnetworks.com
Subject: Re: [PATCH net-next v3 1/5] net-timestamp: extend SCM_TIMESTAMPING
ancillary data struct
From: Willem de Bruijn <willemb@...gle.com>
Date: Thu, 24 Jul 2014 16:48:04 -0400
>> I can't believe we're going to hold onto syststamp just for one
>> odd-ball MIPS ethernet driver. Really?
>>
>> I think putting in whatever work is necessary to convert Octeon over
>> to exposing a proper PTP device is much better than having this
>> syststamp thing rot in our data structures forever.
>
> Implementing ptp_clock_info gettime/settime/adjtime/adjfreq using
> CVMX_MIO_PTP_CLOCK_[CFG|HI|COMP] might be feasible.
>
> That does not address legacy application dependencies on syststamp.
> Even with a PTP device, it is unclear whether anyone would invest time
> to convert their application to use it. The most relevant code I could
> find is cavium ptp-1588v2 on github. That configures SO_TIMESTAMPING
> to generate both raw + sys tstamps and preferentially reads the first.
> If this is the only known octeon timestamping user, then it would be
> just as safe to simply remove syststamp.
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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists