linux-kernel - Re: [PATCH 1/4] clocksource: pass DT node pointer to init functions

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] [day] [month] [year] [list]

Message-ID: <511CF33C.3020402@gmail.com>
Date:	Thu, 14 Feb 2013 08:22:52 -0600
From:	Rob Herring <robherring2@...il.com>
To:	Michal Simek <monstr@...str.eu>
CC:	arm@...nel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Stephen Warren <swarren@...dotorg.org>,
	John Stultz <johnstul@...ibm.com>,
	Josh Cartwright <josh.cartwright@...com>
Subject: Re: [PATCH 1/4] clocksource: pass DT node pointer to init functions

On 02/14/2013 12:45 AM, Michal Simek wrote:
> 2013/2/14 Rob Herring <robherring2@...il.com>:
>> On 02/13/2013 11:33 AM, Michal Simek wrote:
>>> 2013/2/13 Rob Herring <robherring2@...il.com>:
>>>> On 02/13/2013 10:21 AM, Michal Simek wrote:
>>>>> 2013/2/7 Rob Herring <robherring2@...il.com>:
>>>>>> From: Rob Herring <rob.herring@...xeda.com>
>>>>>>


>>> One more thing. Is there any rule which should describe which timer should be
>>> used for clockevent and for clocksource?
>>
>> No. This is a common problem. A simple solution is a "linux,clockevent"
>> property, but I want to avoid that.
> 
> Let me describe it a little bit more. I am going to change current
> mainline implementation
> for zynq timer which uses special compatible string to define
> clocksource and clockevent
> device. I don't think this is right way to go because compatible
> string shouldn't point
> to device usage. Which is exact case you wanted to avoid.
> 
>> Ultimately it is some feature of the
>> h/w that makes you choose. This could be it has an interrupt or not,
>> higher frequency, has timer compare pins, gets power gated, etc. So you
>> should describe enough of the h/w properties to make this decision.
> 
> For different timer type, kernel should decide which timer should be
> used. It should be easy to test
> because I can add some timers to the programmable logic (as is done
> for Microblaze) and check
> how kernel decide which clocksource/clockevent device will use. I
> believe there is any logic around.
> 
> 
> For solution with two instances of the same triple timer counters it
> is impossible
> to specify additional h/w property because all of 6 timers are the same.
> And also adding special parameter to IP goes against rule
> that device-tree should describe hw not Linux usage.
> Maybe enough to save information to driver that clocksource and
> clockevent device is registered
> and do not try to register another timer (and also another timer from
> another instance).

So if you don't care which one is used, then use the first one found and
be done with it. You will have to make your init function just return on
subsequent calls.

> 
> Or maybe it can be done via chosen property or via aliases property where
> timer0 alias is that one who should be used for clocksource and
> clockevent device.
> (for my case alias to one instance of triple timer counter).
> 
> I saw some dtses which have aliases timer.
> 
> How good/bad is this option?

It's best if you can avoid aliases IMO.

> 
> 
>> OMAP
>> is an example doing this with lots of timers with varying integration
>> level differences.
> 
> Can you point me that that omap drivers you are talking about?

arch/arm/mach-omap2/timer.c. They have properties such as always on and
secure mode.

Rob

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