| 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
| ||
|
Date: Tue, 22 Mar 2016 15:29:46 +0100 From: Neil Armstrong <narmstrong@...libre.com> To: Robin Murphy <robin.murphy@....com>, Rob Herring <robh@...nel.org> Cc: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Daniel Lezcano <daniel.lezcano@...aro.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Sudeep Holla <sudeep.holla@....com>, Russell King <rmk+kernel@....linux.org.uk>, Thomas Gleixner <tglx@...utronix.de>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH v2 02/18] dt-bindings: timer: sp804: add timer-width property On 03/22/2016 01:02 PM, Robin Murphy wrote: > Hi Neil, >>>> >>>> Humm, same as integrator timers perhaps? >>> >>> Having had a quick look, what the Integrator/AP manual describes certainly smells like the same basic block as the "AMBA Timer" - 16 bit counters and the same control register layout - albeit in a mutant triple-timer version with a bigger offset between each register set. Integrator/CP, on the other hand, looks much more SP804-like. >>> >>> Robin. >>> >> >> Hi, >> >> I will switch to oxsemi,ox810se-rps-timer since it need a specific register width that will be handled by the driver. > > By "needs a specific register width" do you mean the OxSemi implementation will give a bus error on a 32-bit access and requires 16-bit accessors? If so, I'd expect to see patch 1 changing readl()s to readw()s at least somewhere. Otherwise, if it's merely that the clocksource API needs to know the upper 16 bits of a word it reads are undefined, then since that's the standard behaviour I'd be inclined to add it to the driver as a canonical "arm,amba-timer" implementation, then have your implementation-specific compatible on top of that just in case. No actually the bus access is 32bit but the counter is 24bit wide instead of 16bit, so the clocksource won't work and the system time will furiously drift. It's not the case of the clockevent since the delay fits in 24 bits. It also seems is ignores the 32BIT config bit, so it seems based on the initial 16bit only reference design. How do you think I should implement this ? Neil > Robin. > >> >> Thanks, >> Neil >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@...ts.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> >
Powered by blists - more mailing lists