netdev - Re: [PATCH 4/7] ptp: switch to use gpiolib

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] [day] [month] [year] [list]

Message-ID: <m3r4csr5d7.fsf@intrepid.localdomain>
Date:	Fri, 13 Sep 2013 19:36:20 +0200
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	"linux-gpio\@vger.kernel.org" <linux-gpio@...r.kernel.org>,
	Imre Kaloz <kaloz@...nwrt.org>,
	Alexandre Courbot <acourbot@...dia.com>,
	"linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"netdev\@vger.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 4/7] ptp: switch to use gpiolib

Richard Cochran <richardcochran@...il.com> writes:

> I was really talking about the IXP465 with its PTP function. The Intel
> devel board had a silicon bug making the PTP function useless. But
> even if the bug got fixed, still the PTP function was very limiting.
>
> I never got any feedback about the IXP465 PTP stuff, and so I doubt
> whether anyone is really using the Linux PTP driver on the IXP465, but
> you never know.

Ah, OK.
I have just checked, Intel's spec update says IXP46x steppings A1 and A2
are fixed. PTP on 46x-A0 is broken.
42x and 43x don't support PTP.

OTOH there is interesting stuff there:
Problem: The A-0 and A-1 stepping of the Intel® IXP45X/IXP46X Product Line of Network
         Processors can enter a condition whereby the system locks up when certain
         combinations of memory accesses occur nearly simultaneously.

         After more extensive investigation, it has been identified that the lockup condition can
         be caused by near-simultaneous accesses to 1 or 2 cache lines. The accesses to the
         cache lines must be performed by the Intel XScale processor, South AHB, and/or North
         AHB for the lockup to happen.

Hmmm...
-- 
Krzysztof Halasa
--
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