linux-kernel - Re: [PATCH v2] clocksource/drivers/tango

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56157CB9.7010105@free.fr>
Date:	Wed, 7 Oct 2015 22:12:41 +0200
From:	Mason <slash.tmp@...e.fr>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>
Cc:	Marc Gonzalez <marc_gonzalez@...madesigns.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] clocksource/drivers/tango_xtal: Add new timer for
 Tango SoCs

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/