From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756335AbdABQOH (ORCPT ); Mon, 2 Jan 2017 11:14:07 -0500 Received: from mail-wj0-f193.google.com ([209.85.210.193]:32884 "EHLO mail-wj0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755748AbdABQOF (ORCPT ); Mon, 2 Jan 2017 11:14:05 -0500 Date: Mon, 2 Jan 2017 17:13:59 +0100 From: Richard Cochran To: Nicolas Ferre Cc: Rafal Ozieblo , Andrei Pistirica , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "davem@davemloft.net" , "harinikatakamlinux@gmail.com" , "harini.katakam@xilinx.com" , "punnaia@xilinx.com" , "michals@xilinx.com" , "anirudh@xilinx.com" , "boris.brezillon@free-electrons.com" , "alexandre.belloni@free-electrons.com" , "tbultel@pixelsurmer.com" Subject: Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM. Message-ID: <20170102161359.GD3609@localhost.localdomain> References: <1481720175-12703-1-git-send-email-andrei.pistirica@microchip.com> <20170102113155.GA16373@localhost.localdomain> <0717c63b-2e29-9ad1-7f01-39817980933f@atmel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0717c63b-2e29-9ad1-7f01-39817980933f@atmel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 02, 2017 at 03:47:07PM +0100, Nicolas Ferre wrote: > Le 02/01/2017 à 12:31, Richard Cochran a écrit : > > This Cadence IP core is a complete disaster. > > Well, it evolved and propose several options to different SoC > integrators. This is not something unusual... > I suspect as well that some other network adapters have the same > weakness concerning PTP timestamp in single register as the early > revisions of this IP. It appears that this core can neither latch the time on read or write, or even latch time stamps. I have worked with many different PTP HW implementations, even early ones like on the ixp4xx, and it is no exaggeration to say that this one is uniquely broken. > I suspect that Rafal tend to jump too quickly to the latest IP revisions > and add more options to this series: let's not try to pour too much > things into this code right now. Why can't you check the IP version in the driver? And is it really true that the registers don't latch the time stamps, as Rafal said? If so, then we cannot accept the non-descriptor driver version, since it cannot possibly work correctly. Thanks, Richard