Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751886AbbKYPVg (ORCPT ); Wed, 25 Nov 2015 10:21:36 -0500 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:60099 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751646AbbKYPVe convert rfc822-to-8bit (ORCPT ); Wed, 25 Nov 2015 10:21:34 -0500 Message-ID: <5655D1F7.2030202@arm.com> Date: Wed, 25 Nov 2015 15:21:27 +0000 From: Vladimir Murzin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Daniel Lezcano , arnd@arndb.de, linux@arm.linux.org.uk, gregkh@linuxfoundation.org, tglx@linutronix.de, u.kleine-koenig@pengutronix.de, afaerber@suse.de, mcoquelin.stm32@gmail.com CC: Mark.Rutland@arm.com, Pawel.Moll@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, jslaby@suse.cz, robh+dt@kernel.org, devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 02/10] clockevents/drivers: add MPS2 Timer driver References: <1448447621-17900-1-git-send-email-vladimir.murzin@arm.com> <1448447621-17900-3-git-send-email-vladimir.murzin@arm.com> <5655BA34.9040207@linaro.org> <5655CADA.1010803@arm.com> <5655CF58.6030507@linaro.org> In-Reply-To: <5655CF58.6030507@linaro.org> X-OriginalArrivalTime: 25 Nov 2015 15:21:27.0956 (UTC) FILETIME=[F4681540:01D12794] X-MC-Unique: 5djdoXTeSFuQbjDlCKnUUg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2727 Lines: 102 On 25/11/15 15:10, Daniel Lezcano wrote: > On 11/25/2015 03:51 PM, Vladimir Murzin wrote: >> Hi Daniel, >> >> Thanks for you review, I agree on all concerns raised and address them >> in the next version. Just some points to confirm below (I left only >> relevant parts). >> >>>> +static irqreturn_t mps2_timer_interrupt(int irq, void *dev_id) >>>> +{ >>>> + struct clockevent_mps2 *ce = dev_id; >>>> + u32 status = readl(ce->reg + TIMER_INT); >>>> + >>>> + if (!status) >>>> + return IRQ_NONE; >>> >>> Why that could happen ? Add a comment. >>> >> >> Sort of defensive programming, I never seen it happens, but just in case >> of spurious interrupts... Do you prefer to get rid of this check or >> >> /* spurious interrupt? */ >> if (!status) >> return IRQ_NONE; >> >> would be fine to you? > > Yes, that would be fine, but if it does never happen, we don't really > need this check. If you prefer to make sure there isn't a spurious > interrupt and considering it shouldn't happen, a pr_info trace may help > to spot this misbehavior. > Good, I'll put pr_warn("spurious interrupt\n") then. >>>> +} >>>> + >>>> +static void __init mps2_timer_init(struct device_node *np) >>>> +{ >>>> + static int clksrc; >>>> + >>>> + if (!clksrc && !mps2_clocksource_init(np)) >>>> + clksrc = 1; >>>> + else >>>> + mps2_clockevents_init(np); >>> >>> That assumes the clocksource is defined before the clockevents in the >>> DT. If it is not the case, the mps2_clocksource_init will fail (and spit >>> errors) and mps2_clockevents_init() won't be called. >>> >> >> Does following (stolen from efm32) look better to you? >> >> static void __init mps2_timer_init(struct device_node *np) >> { >> static int has_clocksource, has_clockevent; >> int ret; >> >> if (!has_clocksource) { >> ret = mps2_clocksource_init(np); >> if (!ret) { >> has_clocksource = 1; >> return; >> } >> } >> >> if (!has_clockevent) { >> ret = mps2_clockevent_init(np); >> if (!ret) { >> has_clockevent = 1; >> return; >> } >> } >> } > > Yes. > > I don't like to have a "CLOCKSOURCE_OF_DECLARE" to initialize a > clockevent but I can't blame you, this is what is done in the other > drivers. Thanks for your time! Vladimir > >>>> +} >>>> + >>>> +CLOCKSOURCE_OF_DECLARE(mps2_timer, "arm,mps2-timer", mps2_timer_init); >>>> >>> >>> >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/