linux-kernel - Re: [PATCH v9 3/6] clocksource: stm32: only use 32 bits timers

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

Date:   Fri, 8 Dec 2017 14:47:58 +0100
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Benjamin Gaignard <benjamin.gaignard@...aro.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Arnd Bergmann <arnd@...db.de>, devicetree@...r.kernel.org,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 3/6] clocksource: stm32: only use 32 bits timers

On 08/12/2017 14:05, Benjamin Gaignard wrote:
> 2017-12-08 13:51 GMT+01:00 Daniel Lezcano <daniel.lezcano@...aro.org>:
>> On 08/12/2017 12:32, Benjamin Gaignard wrote:
>>> From: Benjamin Gaignard <benjamin.gaignard@...aro.org>
>>>
>>> The clock driving counters is at 90MHz so the maximum period
>>> for 16 bis counters is around 728us (2^16 / 90.000.000).
>>> For 32 bits counters this period is close 47 secondes which is
>>> more acceptable.
>>>
>>> When using 16 bits counters the kernel may not be able to boot
>>> because it has a too high overhead compare to the clockevent period.
>>> Downgrading the rating of 16bits counter won't change anything
>>> to this problem so this patch remove 16 bits counters support
>>> and makes sure that they won't be probed anymore.
>>
>> Benjamin,
>>
>> there is an inconsistency in this description and the patchset. This is
>> why it is so confusing to review and understand the purpose.
>>
>> Why are you preventing the clockevents to work with 16bits while the
>> issue is related to the clocksource you introduce in the next patch ?
> 
> No the issue is existing also for clockevent because the max period is
> around 728us so the interrupt will fire each 728us which is really too much.

No, that is because you ripped out in this patch the prescaler which was
1024.

Are you the author of this series ?

-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog