Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932905AbcLIIuq (ORCPT ); Fri, 9 Dec 2016 03:50:46 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:34945 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932495AbcLIIun (ORCPT ); Fri, 9 Dec 2016 03:50:43 -0500 Date: Fri, 9 Dec 2016 09:50:37 +0100 From: Richard Cochran To: Grygorii Strashko Cc: "David S. Miller" , netdev@vger.kernel.org, Mugunthan V N , Sekhar Nori , linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, Rob Herring , devicetree@vger.kernel.org, Murali Karicheri , Wingman Kwok Subject: Re: [PATCH 3/6] net: ethernet: ti: cpts: add support of cpts HW_TS_PUSH Message-ID: <20161209085037.GA16009@localhost.localdomain> References: <20161128230428.6872-1-grygorii.strashko@ti.com> <20161128230428.6872-4-grygorii.strashko@ti.com> <20161203232130.GA17944@netboy> <58eea45f-b8fe-6892-e784-b41638c62fd8@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58eea45f-b8fe-6892-e784-b41638c62fd8@ti.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 Content-Length: 924 Lines: 29 On Thu, Dec 08, 2016 at 01:04:11PM -0600, Grygorii Strashko wrote: > huh. Seems this is not really good idea, because MISC Irq will be > triggered for *any* CPTS event and there is no way to enable it just for > HW_TS_PUSH. So what? That is not a problem. > So, this doesn't work will with current code for RX/TX timestamping > (which uses polling mode). Why doesn't it work? > + runtime overhead in net RX/TX caused by > triggering more interrupts. This is not relevant. Without HW_TS_PUSH, there is no need for enabling the interrupt simply because we don't need it. Now, with HW_TS_PUSH, we do need it. > May be, overflow check/polling timeout can be made configurable (module parameter). No, it should just work without any user space fiddling. I getting a bit tired of your half-baked implementations of the ancillary clock functions. Either do it right, or just leave it unsupported. Thanks, Richard