clarify implementation of ethtool's get_ts_info op

This patch adds some clarification about the intended way to implement
both SIOCSHWTSTAMP and ethtool's get_ts_info. The HWTSTAMP API has
several Rx filters which are very specific, as well as more general
filters. The specific filters really only exist to support some broken
hardware which can't fully implement the generic filters. This patch
adds clarification that it is okay to support the specific filters in
SIOCSHWTSTAMP by upscaling them to the generic filters. In addition,
update the header for ethtool_ts_info to specify that drivers ought to
only report the filters they support without upscaling in this manner.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Reviewed-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This commit is contained in:
Jacob Keller 2015-04-22 14:40:30 -07:00 committed by Jeff Kirsher
parent 0d0578815b
commit eff3cddc22
2 changed files with 12 additions and 0 deletions

View File

@ -359,6 +359,13 @@ the requested fine-grained filtering for incoming packets is not
supported, the driver may time stamp more than just the requested types supported, the driver may time stamp more than just the requested types
of packets. of packets.
Drivers are free to use a more permissive configuration than the requested
configuration. It is expected that drivers should only implement directly the
most generic mode that can be supported. For example if the hardware can
support HWTSTAMP_FILTER_V2_EVENT, then it should generally always upscale
HWTSTAMP_FILTER_V2_L2_SYNC_MESSAGE, and so forth, as HWTSTAMP_FILTER_V2_EVENT
is more generic (and more useful to applications).
A driver which supports hardware time stamping shall update the struct A driver which supports hardware time stamping shall update the struct
with the actual, possibly more permissive configuration. If the with the actual, possibly more permissive configuration. If the
requested packets cannot be time stamped, then nothing should be requested packets cannot be time stamped, then nothing should be

View File

@ -1093,6 +1093,11 @@ struct ethtool_sfeatures {
* the 'hwtstamp_tx_types' and 'hwtstamp_rx_filters' enumeration values, * the 'hwtstamp_tx_types' and 'hwtstamp_rx_filters' enumeration values,
* respectively. For example, if the device supports HWTSTAMP_TX_ON, * respectively. For example, if the device supports HWTSTAMP_TX_ON,
* then (1 << HWTSTAMP_TX_ON) in 'tx_types' will be set. * then (1 << HWTSTAMP_TX_ON) in 'tx_types' will be set.
*
* Drivers should only report the filters they actually support without
* upscaling in the SIOCSHWTSTAMP ioctl. If the SIOCSHWSTAMP request for
* HWTSTAMP_FILTER_V1_SYNC is supported by HWTSTAMP_FILTER_V1_EVENT, then the
* driver should only report HWTSTAMP_FILTER_V1_EVENT in this op.
*/ */
struct ethtool_ts_info { struct ethtool_ts_info {
__u32 cmd; __u32 cmd;