netdev - Re: [PATCH] net:cpsw: Pass unhandled ioctl's on to generic phy ioctl

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]

Date:	Wed, 5 Feb 2014 08:12:51 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	Sørensen, Stefan 
	<Stefan.Sorensen@...ctralink.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"mugunthanvnm@...com" <mugunthanvnm@...com>
Subject: Re: [PATCH] net:cpsw: Pass unhandled ioctl's on to generic phy ioctl

On Tue, Feb 04, 2014 at 09:51:59PM +0000, Ben Hutchings wrote:
> 
> Right.  If all versions of CPSW include hardware timestamping then
> bother with PHY timestamping at all?  And why make CONFIG_TI_CPTS
> configurable?

On the one hand, PHY time stamping is more accurate and offers
synchronization performance that is measurably better than MAC time
stamping. On the other hand, when using a MAC the CPU usually has much
more direct access to the clock (for example, direct register access
or PCIe, versus MDIO).

I once worked on a project in which it was planned to have both kinds
of hardware in the design, in order to keep our options open in the
face of fluid requirements. So I think you can expect to see such
combinations in the wild, especially in the embedded area.

We cannot reasonably support both types in the kernel at the same
time, and so it makes sense to have compile time options in MAC
drivers to disable time stamping.

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