linux-kernel - Re: [PATCH 3/4] ARM: sched_clock: Add support for >32 bit sched

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]

Message-ID: <517558CE.7090602@codeaurora.org>
Date:	Mon, 22 Apr 2013 08:35:42 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Will Deacon <will.deacon@....com>
CC:	Rob Herring <robherring2@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Russell King <linux@....linux.org.uk>,
	"arm@...nel.org" <arm@...nel.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	John Stultz <john.stultz@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 3/4] ARM: sched_clock: Add support for >32 bit sched_clock

On 04/22/13 03:48, Will Deacon wrote:
> Hi Stephen,
>
> On Sat, Apr 20, 2013 at 01:29:05AM +0100, Stephen Boyd wrote:
>> The arm architected system counter has at least 56 bits of
>> useable bits. Add support to ARM's sched_clock implementation for
>> counters with more than 32 bits so we can avoid the complexity of
>> dealing with wraparound on these devices while benefiting from
>> the irqtime accounting and suspend/resume handling that the ARM
>> sched_clock code already has.
>>
>> Signed-off-by: Stephen Boyd <sboyd@...eaurora.org>
>> ---
>>
>> Maybe we need a union for the epoch_ns usage?
>>
>>  arch/arm/include/asm/sched_clock.h |   2 +
>>  arch/arm/kernel/sched_clock.c      | 101 +++++++++++++++++++++++++++----------
>>  2 files changed, 77 insertions(+), 26 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
>> index 3d520dd..7fcd2ee 100644
>> --- a/arch/arm/include/asm/sched_clock.h
>> +++ b/arch/arm/include/asm/sched_clock.h
>> @@ -13,4 +13,6 @@ extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
>>  
>>  extern unsigned long long (*sched_clock_func)(void);
>>  
>> +extern void setup_sched_clock_64(u64 (*read)(void), int bits,
>> +				 unsigned long rate);
> Curious, but why do we need two setup_sched_clock functions, where the bits
> are passed as a parameter? Can't we just do the right thing if the clock
> claims to be more than 32 bits wide (and get rid of the BUG_ONs at the same
> time)?

This is to avoid having to change a bunch of code that is using
setup_sched_clock() already where their read function returns a u32
instead of a u64. I suppose we could make the 64 bit version fall back
to the 32 bit version if the bits aren't large enough and provide some
sort of u32 wrapper function around the u64 callback. It may also be
useful if we can determine that the timer wraps too quickly even when
there are more than 32 bits.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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