Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping layers to user space.

Jacob Keller
2023-05-17T22:13:17Z

On 4/6/2023 6:46 PM, Jakub Kicinski wrote:
> On Thu, 6 Apr 2023 19:33:05 +0200 Köry Maincent wrote:
>> +/* TSLIST_GET */
>> +static int tslist_prepare_data(const struct ethnl_req_info *req_base,
>> + struct ethnl_reply_data *reply_base,
>> + struct genl_info *info)
>> +{
>> + struct ts_reply_data *data = TS_REPDATA(reply_base);
>> + struct net_device *dev = reply_base->dev;
>> + const struct ethtool_ops *ops = dev->ethtool_ops;
>> + int ret;
>> +
>> + ret = ethnl_ops_begin(dev);
>> + if (ret < 0)
>> + return ret;
>> +
>> + data->ts = 0;
>> + if (phy_has_tsinfo(dev->phydev))
>> + data->ts = SOF_PHY_TIMESTAMPING;
>> + if (ops->get_ts_info)
>> + data->ts |= SOF_MAC_TIMESTAMPING;
>
> We can't make that assumption, that info must come from the driver.
>
> Also don't we need some way to identify the device / phc from which
> the timestamp at the given layer will come?

For example, ice hardware captures timestamp data in its internal PHY
well after the MAC layer finishes, but it doesn't expose the PHY to the
host at all..

From a timing perspective it matters that its PHY, but from an
implementation perspective there's not much difference since we don't
support MAC timestamping at all (and the PHY isn't accessible through
phylink...)

Perhaps that doesn't fit the use cace here though where the issue is
with supporting both MAC and PHY but no way to configure that