linux-kernel - Re: [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI

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]

Date:	Fri, 8 Nov 2013 17:23:31 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Kevin Hilman <khilman@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	SH-Linux <linux-sh@...r.kernel.org>,
	"Simon Horman [Horms]" <horms@...ge.net.au>,
	Olof Johansson <olof@...om.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <john.stultz@...aro.org>
Subject: Re: [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2,
 TMU and STI

On Thu, Nov 7, 2013 at 8:27 PM, Daniel Lezcano
<daniel.lezcano@...aro.org> wrote:
> On 11/06/2013 12:05 PM, Magnus Damm wrote:
>>
>> From: Magnus Damm <damm@...nsource.se>
>>
>> Add Kconfig entries for CMT, MTU2, TMU and STI to
>> drivers/clocksource/Kconfig. This will allow us to
>> get rid of duplicated entires in architecture code
>> such as arch/sh and arch/arm/mach-shmobile.
>>
>> Signed-off-by: Magnus Damm <damm@...nsource.se>
>
>
> Hi Magnus,
>
> we are preventing to have selectable timer from this Kconfig.
>
> You should select the timers from the arch Kconfig option.

Thanks for your reply. In the case of ARM multiplatform this sounds
like a good match, but I wonder what to do in the case of single
platform ARM and the SH architecture. It would be nice to share the
same Kconfig entries for both SH and all ARM variants.

As you can see, in this series the Kconfig is shared between SH and
ARM mach-shmobile. Actually, on those platforms we don't treat the
timers any differently than any other device driver and traditionally
we have been allowing the user to select which timer to use as system
timer via the kernel configuration. What is the reason behind your
suggestion with the arch Kconfig selection? It seems to me that timers
are being treated differently than any other device driver, but I'm
not sure why that is the case.

Changing SH and ARM single/multi to select via the architecture
Kconfig seems like a functional regression for single platforms to me.
It is also not really in line with TWD and architected timers that are
today selectable via the ARM Kconfig. Say that I would like to develop
code for a certain timer on a SoC with multiple timers, how can I make
sure the right timer is used? Perhaps you propose relying on the
clocksource and clockevent ratings?

Cheers,

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