From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934569AbdACKsF (ORCPT ); Tue, 3 Jan 2017 05:48:05 -0500 Received: from mail-co1nam03on0044.outbound.protection.outlook.com ([104.47.40.44]:2429 "EHLO NAM03-CO1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752728AbdACKsA (ORCPT ); Tue, 3 Jan 2017 05:48:00 -0500 From: Rafal Ozieblo To: Harini Katakam , Richard Cochran CC: Nicolas Ferre , Andrei Pistirica , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "davem@davemloft.net" , "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. Thread-Topic: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM. Thread-Index: AQHSVfGM/AIZMc0Aj0+XufhsBcqeqqEdbqAQgAeTw4CAACldgIAANoqAgAAYRYCAANfAgIAAUf4w Date: Tue, 3 Jan 2017 10:47:56 +0000 Message-ID: References: <1481720175-12703-1-git-send-email-andrei.pistirica@microchip.com> <20170102113155.GA16373@localhost.localdomain> <0717c63b-2e29-9ad1-7f01-39817980933f@atmel.com> <20170102161359.GD3609@localhost.localdomain> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rafalo@cadence.com; x-originating-ip: [213.131.238.28] x-ms-office365-filtering-correlation-id: 0fd76718-b683-4a9e-2366-08d433c5fa5c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR07MB2513; x-microsoft-exchange-diagnostics: 1;BN3PR07MB2513;7:qwkguQHJ6aTQgkwZRuiHjMboMvzd9KejERQW5j0zWCoGKUnnM1w4KakJIUa6u8f0lPr+mrSSLpogqSY1jp1H200WD7h01C6M4Y0/bySiTPYjArPWlgahsgg2XCL7HC5VFf9QWBShZ713iD8jiZXkVrZ5KnOlAUJGAe6FiQOMGfOXm07/Mo2NLubnNXCDdtUnHOp/vWTNxEBHlLU4InlyYcL5qfkMvrkcsem9a6d+ZZBNm8fQeP7LJPkhohGpRMsEYXJFkB9VWY0+jw8W+tUoNN5rz8Phxp7O8W/nHbiG1T/FKkHO1mMPc7YTeedYZ7iLggZGknHvNtoFgW+NVnSk8kbskz0KqiLvUW9uWMFduVvwbr2TB9cH815LNxUX9CL2etToy7rPSvyTQyUAyipdHFcdzegkrPNuE8NgNcGo23rj2dOa6RaoMrVPOFf5u66yfIPWerYrNkhjrgfQi3ZxsQ==;20:YzShHymVdA9TczCYKEh8mE062WSprd0uKs/m7XWzFMY6bVOjuwB6CZZCeMP+5WKFvXkbe5C+JQcShun4zz74emnHD9z4VFdGUzBVLRHiHNZKNym5j4EY3Wpqa4i0Mhk/1SGvShcN1R/iRw90rnreCI/e+Dv1/oGsYRJ7LQMq0z1OR5TpNWYTEA8Da8laqyNiRuCxPKVQBXRAeOKaxtKV6b77ZioVNnpM8bgVmbgzirA0X1SnjoIBwnU1sY7rM0Vx x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148);SRVR:BN3PR07MB2513;BCL:0;PCL:0;RULEID:;SRVR:BN3PR07MB2513; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(199003)(24454002)(189002)(36092001)(97736004)(54906002)(77096006)(3660700001)(74316002)(86362001)(81156014)(101416001)(6506006)(8936002)(106116001)(76176999)(39060400001)(54356999)(106356001)(105586002)(2900100001)(38730400001)(122556002)(4326007)(50986999)(3280700002)(6436002)(8666007)(8656002)(92566002)(8676002)(229853002)(25786008)(305945005)(5001770100001)(3846002)(33656002)(5660300001)(9686002)(81166006)(2906002)(7416002)(6116002)(55016002)(102836003)(66066001)(189998001)(68736007)(2950100002)(7736002)(93886004)(7696004)(99286003)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:BN3PR07MB2513;H:BN3PR07MB2516.namprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: cadence.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 10:47:56.4595 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d36035c5-6ce6-4662-a3dc-e762e61ae4c9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR07MB2513 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v03Am9Aw005102 >From: Harini Katakam [mailto:harinikatakamlinux@gmail.com] >Sent: 3 stycznia 2017 06:06 >Subject: Re: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM. > >Hi Richard, > >On Mon, Jan 2, 2017 at 9:43 PM, Richard Cochran wrote: >> 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? > >There is an IP revision register but it would be probably be better to rely on "caps" from the compatibility strings - to cover SoC specific implementations. Also, when this extended BD is added (with timestamp), additional words will need to be added statically which will be consistent with Andrei's CONFIG_ checks. We can distinguish IP cores with and without PTP support by reading Design Configuration Register. But to distinguish IP cores with timestamps in buffer descriptors and which support only event registers, we can only check IP version by reading the revision ID register and base on that. I agree with Harini, compatibility strings could be better. But we might end up with many different configuration in the future. We could use only descriptor approach but there are many Atmel's cores on the market which support only event registers.