From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756991AbbJHNPJ (ORCPT ); Thu, 8 Oct 2015 09:15:09 -0400 Received: from smtpfb2-g21.free.fr ([212.27.42.10]:50751 "EHLO smtpfb2-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753028AbbJHNPG (ORCPT ); Thu, 8 Oct 2015 09:15:06 -0400 Subject: Re: [PATCH v2] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs To: Daniel Lezcano , Thomas Gleixner Cc: Marc Gonzalez , 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> From: Mason Message-ID: <56157CB9.7010105@free.fr> Date: Wed, 7 Oct 2015 22:12:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 MIME-Version: 1.0 In-Reply-To: <56154268.5060700@linaro.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/10/2015 18:03, Daniel Lezcano wrote: > On 10/07/2015 03:17 PM, Marc Gonzalez wrote: > >> I'm also confused that you've replaced panic() with pr_err/return. >> AFAIU, if I don't have a clocksource/sched_clock, the system is dead >> in the water. Might as well stop there, and wait for the operator to >> fix whatever needs fixing. (Several clksrc drivers do this.) > > Hmm, yeah that's true but also we have platforms with different > clocksources, so we don't want to panic if the next clocksource will > succeed. That's the logic behind not doing panic. There is some legacy > code still using panic but that should be fixed. There's so much legacy code lying around that it's really hard to tell what the current best practices are :-( > I don't know if your platform can fall under this category, but it would > be a good practice to pr_err or pr_warn instead of panic in order to be > consistent with the current direction in the recent drivers. I think the system falls back to using the "jiffies clock" when it doesn't find anything better? However, on my system, the clockevent device is running at cpuclk/2, so once I add cpufreq DFS into the mix, I don't think the "jiffies" clock is a very good clocksource. Anyway, updated patch is on the way. Regards.