linux-kernel - Re: [PATCH v4 21/29] nios2: Time keeping

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 09 Oct 2014 13:57:36 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Ley Foon Tan <lftan@...era.com>, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	lftan.linux@...il.com, cltang@...esourcery.com
Subject: Re: [PATCH v4 21/29] nios2: Time keeping

On Wednesday 08 October 2014 18:19:52 Thomas Gleixner wrote:
> Ok, got it. It does not change the fact that the above function is
> butt ugly and completely non intuitive.

Agreed, it could at least use a comment to explain the logic behind it.

> I also do not agree, that the DT should not tell which of the timers
> should be used as a clockevent device and which one as a
> clocksource. If you have a better suited clockevent device in your
> FPGA, you cannot use a single instance of the timer thingy as it will
> be registered as a clockevent and not as a clocksource. So explicit
> match values for particular hardware instances would be more flexible,
> but I don't have strong feelings about it either.

Right, things can get arbitrarily complicated when this is combined
with other (optional) timer hardware, as we've seen on ARM before.
I think we have discussed the issue for some ARM timers in length
before and not found a good solution.

The clps711x driver has tried to work around this problem by using
aliases, and it has been discussed for other drivers before.

The main problem with encoding the use of the timer blocks in DT
is that it gets really ugly if we ever want to use a third timer
hardware block in the kernel, e.g. to separate the timer wheel
from the hrtimer, if we decide to expose a particular HW
timer to in-kernel or userland interfaces, or if someone wants
to run an OS on the same hardware that uses the timer hardware
in a completely different way.

	Arnd
--
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/