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, 12 Sep 2017 10:10:13 +0100 From: Russell King - ARM Linux <linux@...linux.org.uk> To: Linus Walleij <linus.walleij@...aro.org> Cc: Arnd Bergmann <arnd@...db.de>, Daniel Lezcano <daniel.lezcano@...aro.org>, Thomas Gleixner <tglx@...utronix.de>, Randy Dunlap <rdunlap@...radead.org>, Geert Uytterhoeven <geert@...ux-m68k.org>, "linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>, linux-ia64@...r.kernel.org, Tony Luck <tony.luck@...el.com>, Fenghua Yu <fenghua.yu@...el.com>, Ding Tianhong <dingtianhong@...wei.com>, Mark Rutland <mark.rutland@....com>, Marc Zyngier <marc.zyngier@....com>, Vineet Gupta <vgupta@...opsys.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency On Tue, Sep 12, 2017 at 10:09:51AM +0200, Linus Walleij wrote: > For ARM we now have two subarchs not using generic clockevents: > RISC PC and EBSA110. > > I think Russell stated these two cannot be converted to generic clockevents > because of hardware limitations I guess, no timer interrupt, simply, which > means no clockevents, or unreliable or not granular enough timers. > > IIUC the SA110 does not contain the built-in SoC goodies of the SA1100 > so it needs external timer blocks, and those two machines don't have > good enough timers. That's hardly surprising because SA1100 is a SoC, SA110 is just a CPU, containing no peripherals at all. EBSA110 only has one usable timer, which must be programmed to produce a regular timer tick to the OS: it's no good trying to double up the clocksource and a periodic clockevent onto one counter register - the clock source will see the same timer value +/- interrupt latency, and in any case it won't wrap in a power-of-2 manner. This breaks the assumptions behind the clocksource and timekeeping code, which are that we have a timer that wraps in a power-of-2 manner, and which takes much longer than the desired period to wrap. I think RiscPC may be convertable as there are two timers, and I think the second timer is unused (so could be programmed to the requirements of a clocksource) but is there much reason to bother given the EBSA110? I think there isn't. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Powered by blists - more mailing lists