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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5f9a1929-b511-707a-9b56-52cc5f1c40ba@intel.com>
Date: Wed, 17 May 2023 15:13:06 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, Köry Maincent
	<kory.maincent@...tlin.com>
CC: <netdev@...r.kernel.org>, <glipus@...il.com>,
	<maxime.chevallier@...tlin.com>, <vladimir.oltean@....com>,
	<vadim.fedorenko@...ux.dev>, <richardcochran@...il.com>,
	<gerhard@...leder-embedded.com>, <thomas.petazzoni@...tlin.com>,
	<krzysztof.kozlowski+dt@...aro.org>, <robh+dt@...nel.org>,
	<linux@...linux.org.uk>
Subject: Re: [PATCH net-next RFC v4 2/5] net: Expose available time stamping
 layers to user space.



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