linux-kernel - Re: [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection

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: <CAL_Jsq+NLfzLnEPxXQyyE2hg9wYeBtOyT307+oTUUdTKXmUUuQ@mail.gmail.com>
Date:   Tue, 19 Dec 2017 17:20:14 -0600
From:   Rob Herring <robh+dt@...nel.org>
To:     Grygorii Strashko <grygorii.strashko@...com>
Cc:     Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection

On Fri, Dec 15, 2017 at 7:57 PM, Grygorii Strashko
<grygorii.strashko@...com> wrote:
>
>
> On 12/13/2017 12:53 PM, Alexandre Belloni wrote:
>> The clocksource and clockevent timer are probed early in the boot process.
>> At that time it is difficult for linux to know whether a particular timer
>> can be used as the clocksource or the clockevent or by another driver,
>> especially when they are all identical or have similar features.
>>
>> Until now, multiple strategies have been used to solve that:
>>   - use Kconfig option as MXC_USE_EPIT or ATMEL_TCB_CLKSRC_BLOCK
>>   - use a kernel parameter as the "clocksource" early_param in mach-omap2
>>   - registering the first seen timer as a clockevent and the second one as
>>   a clocksource as in rk_timer_init or dw_apb_timer_init
>>
>> Add a linux,clocksource and a linux,clockevent node in chosen with a timer
>> property pointing to the timer to use. Other properties, like the targeted
>> precision may be added later.
>>
>> Signed-off-by: Alexandre Belloni <alexandre.belloni@...e-electrons.com>
>> ---
>>   Documentation/devicetree/bindings/chosen.txt | 20 ++++++++++++++++++++
>>   1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
>> index e3b13ea7d2ae..c7ee3ecb5276 100644
>> --- a/Documentation/devicetree/bindings/chosen.txt
>> +++ b/Documentation/devicetree/bindings/chosen.txt
>> @@ -120,3 +120,23 @@ e.g.
>>   While this property does not represent a real hardware, the address
>>   and the size are expressed in #address-cells and #size-cells,
>>   respectively, of the root node.
>> +
>> +linux,clocksource and linux,clockevent
>> +--------------------------------------
>> +
>> +Those nodes have a timer property. This property is a phandle to the timer to be
>> +chosen as the clocksource or clockevent. This is only useful when the platform
>> +has multiple identical timers and it is not possible to let linux make the
>> +correct choice.
>> +
>> +/ {
>> +     chosen {
>> +             linux,clocksource {
>> +                     timer = <&timer0>;
>> +             };
>> +
>> +             linux,clockevent {
>> +                     timer = <&timer1>;
>> +             };
>> +     };
>> +};
>>
>
> It'd be nice if smth. like this will actually happen, as on some OMAP
> platforms can be up to 3-4 alternatives for each clocksource/clockevent and
> different combination need to be selected depending on SoC and platform
> (and sometime - use case) which is pain in multi-platform environment now.

Can we have some concrete examples with why the current selection
logic is broken.

For use-cases, if a board maker can't make that decision, then I think
those should be kernel command-line options (if boot time) or sysfs
controlled.

> But more important note from my side is clocksource and clockevent selections seems
> not enough :( There are also sched clock (sched_clock_register()) and delay_timer
>  (register_current_timer_delay() at least on ARM).
> Both above can't be unregistered (at least last time I've checked).

Sounds like an OS problem...

Rob