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: <717976963.391348.1737617030636.JavaMail.zimbra@couthit.local>
Date: Thu, 23 Jan 2025 12:53:50 +0530 (IST)
From: Basharath Hussain Khaja <basharath@...thit.com>
To: richardcochran <richardcochran@...il.com>
Cc: basharath <basharath@...thit.com>, danishanwar <danishanwar@...com>, 
	rogerq <rogerq@...nel.org>, andrew+netdev <andrew+netdev@...n.ch>, 
	davem <davem@...emloft.net>, edumazet <edumazet@...gle.com>, 
	kuba <kuba@...nel.org>, pabeni <pabeni@...hat.com>, 
	Rob Herring <robh@...nel.org>, krzk+dt <krzk+dt@...nel.org>, 
	conor+dt <conor+dt@...nel.org>, nm <nm@...com>, 
	ssantosh <ssantosh@...nel.org>, tony <tony@...mide.com>, 
	parvathi <parvathi@...thit.com>, schnelle <schnelle@...ux.ibm.com>, 
	rdunlap <rdunlap@...radead.org>, diogo ivo <diogo.ivo@...mens.com>, 
	m-karicheri2 <m-karicheri2@...com>, horms <horms@...nel.org>, 
	jacob e keller <jacob.e.keller@...el.com>, 
	m-malladi <m-malladi@...com>, 
	javier carrasco cruz <javier.carrasco.cruz@...il.com>, 
	afd <afd@...com>, s-anna <s-anna@...com>, 
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, 
	netdev <netdev@...r.kernel.org>, 
	devicetree <devicetree@...r.kernel.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>, 
	linux-omap <linux-omap@...r.kernel.org>, 
	pratheesh <pratheesh@...com>, prajith <prajith@...com>, 
	vigneshr <vigneshr@...com>, praneeth <praneeth@...com>, 
	srk <srk@...com>, rogerq <rogerq@...com>, 
	krishna <krishna@...thit.com>, pmohan <pmohan@...thit.com>, 
	mohan <mohan@...thit.com>
Subject: Re: [RFC PATCH 06/10] net: ti: prueth: Adds HW timestamping support
 for PTP using PRU-ICSS IEP module

> On Fri, Jan 10, 2025 at 11:29:02AM +0530, Basharath Hussain Khaja wrote:
> 
>> @@ -189,12 +190,37 @@ static void icssm_emac_get_regs(struct net_device *ndev,
>>  	regs->version = PRUETH_REG_DUMP_GET_VER(prueth);
>>  }
>>  
>> +static int icssm_emac_get_ts_info(struct net_device *ndev,
>> +				  struct kernel_ethtool_ts_info *info)
>> +{
>> +	struct prueth_emac *emac = netdev_priv(ndev);
>> +
>> +	if ((PRUETH_IS_EMAC(emac->prueth) && !emac->emac_ptp_tx_irq))
>> +		return ethtool_op_get_ts_info(ndev, info);
>> +
>> +	info->so_timestamping =
>> +		SOF_TIMESTAMPING_TX_HARDWARE |
>> +		SOF_TIMESTAMPING_TX_SOFTWARE |
> 
> The driver advertises software Transmit time stamping, but where is
> the call to skb_tx_timestamp() ?
> 
> I didn't see it in Patch #4.
> 

Yes. This module always uses IEP HW time stamping for better precision. 
We will clean this in the next version.

>> +		SOF_TIMESTAMPING_RX_HARDWARE |
>> +		SOF_TIMESTAMPING_RX_SOFTWARE |
>> +		SOF_TIMESTAMPING_SOFTWARE |
>> +		SOF_TIMESTAMPING_RAW_HARDWARE;
>> +
>> +	info->phc_index = icss_iep_get_ptp_clock_idx(emac->prueth->iep);
>> +	info->tx_types = BIT(HWTSTAMP_TX_OFF) | BIT(HWTSTAMP_TX_ON);
>> +	info->rx_filters = BIT(HWTSTAMP_FILTER_NONE) |
>> +				BIT(HWTSTAMP_FILTER_PTP_V2_EVENT);
>> +
>> +	return 0;
>> +}
> 
>> @@ -442,6 +482,173 @@ static void icssm_emac_adjust_link(struct net_device
>> *ndev)
>>  	spin_unlock_irqrestore(&emac->lock, flags);
>>  }
>>  
>> +static u8 icssm_prueth_ptp_ts_event_type(struct sk_buff *skb, u8 *ptp_msgtype)
>> +{
>> +	unsigned int ptp_class = ptp_classify_raw(skb);
>> +	struct ptp_header *hdr;
>> +	u8 msgtype, event_type;
>> +
>> +	if (ptp_class == PTP_CLASS_NONE)
>> +		return PRUETH_PTP_TS_EVENTS;
>> +
>> +	hdr = ptp_parse_header(skb, ptp_class);
>> +	if (!hdr)
>> +		return PRUETH_PTP_TS_EVENTS;
>> +
>> +	msgtype = ptp_get_msgtype(hdr, ptp_class);
>> +	/* Treat E2E Delay Req/Resp messages sane as P2P peer delay req/resp
> 
> s/sane/in the same way/
> 

This was a typo, We will address this in the next version. Firmware running in PRU 
treats E2E Delay Req/Resp messages same as P2P peer delay req/resp.

>> +	 * in driver here since firmware stores timestamps in the same memory
>> +	 * location for either (since they cannot operate simultaneously
>> +	 * anyway)
>> +	 */
>> +	switch (msgtype) {
>> +	case PTP_MSGTYPE_SYNC:
>> +		event_type = PRUETH_PTP_SYNC;
>> +		break;
>> +	case PTP_MSGTYPE_DELAY_REQ:
>> +	case PTP_MSGTYPE_PDELAY_REQ:
>> +		event_type = PRUETH_PTP_DLY_REQ;
>> +		break;
>> +	/* TODO: Check why PTP_MSGTYPE_DELAY_RESP needs timestamp
>> +	 * and need for it.
>> +	 */
>> +	case 0x9:
> 
> Delay response messages are PTP "general" messages and not event
> messages, and as such they do not require time stamps.
> 
currently firmware sends back timestamp even for E2E Delay_response message 
though this is a general message. To service that txts request we added this
here. We will revisit again and clean this in the subsequent versions.

Thanks & Best Regards,
Basharath

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ