linux-kernel - Re: [PATCH 1/2] clocksource: sp804: Add support for OX810SE 24bit timer width

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:	Mon, 25 Apr 2016 16:48:24 +0200
From:	Neil Armstrong <narmstrong@...libre.com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	rmk+kernel@....linux.org.uk, sudeep.holla@....com
Subject: Re: [PATCH 1/2] clocksource: sp804: Add support for OX810SE 24bit
 timer width

On 04/22/2016 09:53 AM, Thomas Gleixner wrote:
> On Fri, 22 Apr 2016, Daniel Lezcano wrote:
> 
>> On Fri, Apr 01, 2016 at 04:22:38PM +0200, Neil Armstrong wrote:
>>> In order to support the Dual-Timer on the Oxford Semiconductor OX810SE SoC,
>>> implement variable counter width, keeping 32bit as default width.
>>> Add new compatible string oxsemi,ox810se-rps-timer in order to select
>>> the 24bit counter width.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@...libre.com>
>>> ---
>>>  drivers/clocksource/timer-sp804.c | 107 ++++++++++++++++++++++++--------------
>>>  include/clocksource/timer-sp804.h |  42 ++++++++++++---
>>>  2 files changed, 102 insertions(+), 47 deletions(-)
>>
>> I will take those patches but this driver really deserves a cleanup.
> 
> If it deserves a cleanup, then this should happen _BEFORE_ we add new
> functionality to it.
> 
> Thanks,
> 
> 	tglx
> 

Hi Thomas, Daniel,

Sure this driver should have a cleanup, but it still depends on old legacy vexpress calls.

The reason I submitted a change and a small cleanup over this driver is because the high
similarities of the HW and avoiding adding a brand new driver cloning much of its
functionalities.

I propose to study an eventual cleanup, but could this change be submitted for 4.7 since
it's part of a base platform support serie ?

Thanks,
Neil