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  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]
Date:	Tue, 16 Oct 2012 19:14:08 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	"N, Mugunthan V" <mugunthanvnm@...com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	David Miller <davem@...emloft.net>,
	"Chemparathy, Cyril" <cyril@...com>,
	"Govindarajan, Sriramakrishnan" <srk@...com>
Subject: Re: [PATCH V2 0/7] support the cpts found on am335x devices

On Tue, Oct 16, 2012 at 04:33:55PM +0000, N, Mugunthan V wrote:
> I had seen some issues with the patch series.

Please take another look. Excepting the last, none of your points
holds water.
 
> * CPTS will hold only LSB 32 bits of 64 bit Timer and the upper 32 bit
>   time value has to be taken care by the software, but the time stamp
>   which is passed to skb or PTP clock consist of only 32 bit time value

The driver handles this already.

> * CPTS interrupts should be utilized to service Half and Full roll over
>   events as it is non sync events with respect to get/set time and PTP
>   pkt Tx/Rx

Nope, no need for interrupts, since we already have a better way to
handle this.

> * CPTS Time which is obtained from hardware is not actually a nano
>   seconds as the CPTS ref clock is tied to 250MHz for AM335x.

Did you even look at the code in my patch?

> * CPSW register mapping done in this patch series removes the CPSW
>   driver support for previous version found in TI814x

In which Linux version (or commit) did this driver appear?
I never saw it.

> * CPSW Time stamping is done only for port 0 and port 1 is not done

Yes, you are right, and it is strange that the hardware time stamps on
the external ports of the switch, and not at the host port as it
should. Of course it does present us with a problem, since we cannot
reasonably have both ports time stamping at the same time. I propose
simply using a device tree attribute to tell which port to activate.

Thanks,
Richard

--
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