From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933232AbbJINqy (ORCPT ); Fri, 9 Oct 2015 09:46:54 -0400 Received: from mail1.bemta7.messagelabs.com ([216.82.254.100]:49270 "EHLO mail1.bemta7.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933108AbbJINqv (ORCPT ); Fri, 9 Oct 2015 09:46:51 -0400 X-Env-Sender: Marc_Gonzalez@sigmadesigns.com X-Msg-Ref: server-15.tower-96.messagelabs.com!1444398404!15578009!1 X-Originating-IP: [195.215.56.170] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Subject: Re: [PATCH v3] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs To: Daniel Lezcano , Thomas Gleixner CC: Mason , LKML References: <5613E45C.5020208@sigmadesigns.com> <5614549F.2070002@linaro.org> <5614D66A.1060402@sigmadesigns.com> <56150369.2050609@sigmadesigns.com> <561510BF.7050207@linaro.org> <56151B5B.90404@sigmadesigns.com> <56154268.5060700@linaro.org> <56157CB9.7010105@free.fr> <5617AF82.4000606@sigmadesigns.com> <5617C028.3040709@linaro.org> From: Marc Gonzalez Message-ID: <5617C52F.9040309@sigmadesigns.com> Date: Fri, 9 Oct 2015 15:46:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 MIME-Version: 1.0 In-Reply-To: <5617C028.3040709@linaro.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.27.0.114] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/10/2015 15:24, Daniel Lezcano wrote: > On 10/09/2015 02:13 PM, Marc Gonzalez wrote: >> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. >> Use it for clocksource, sched_clock, and delay_timer. >> >> Signed-off-by: Marc Gonzalez >> --- >> I have a nagging feeling that the QUIT_IF macro will get this patch NAKed ;-) >> My rationale: error-handling tends to take the focus away from the normal >> path, and put it on the error path. Hiding the details away in a macro >> helps to keep the error-handling noise to a minimum. > > It is a right feeling :) > > The Linux kernel code follows the same path all across the different > sub-systems. So it is not a problem to write: if (err) ..., people is > used to read such code and by introducing this macro, that makes the > code less readable for them. > > Moreover, the way you wrote the macro is strongly discouraged in the > CodingStyle document because there is a 'return' inside. New patch coming right up. On a tangential subject, it would seem that platforms with verbose logs at init might benefit from marking as __initconst strings used in __init functions. I discussed this some time ago: https://lkml.org/lkml/2015/3/25/688 which pointed to an earlier discussion: https://lkml.org/lkml/2014/8/21/255 https://lkml.org/lkml/2014/6/22/149 Regards.