linux-kernel - Re: [RFC 13/13] m68k: mac: convert to generic clockevent

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]

Message-ID: <alpine.LNX.2.23.453.2010091900150.12@nippy.intranet>
Date:   Sat, 10 Oct 2020 09:21:38 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Arnd Bergmann <arnd@...db.de>
cc:     linux-kernel@...r.kernel.org, Russell King <linux@...linux.org.uk>,
        Tony Luck <tony.luck@...el.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Greg Ungerer <gerg@...ux-m68k.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Philip Blundell <philb@....org>,
        Joshua Thompson <funaho@...ai.org>,
        Sam Creasey <sammy@...my.net>,
        "James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
        Helge Deller <deller@....de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-ia64@...r.kernel.org, linux-parisc@...r.kernel.org,
        linux-m68k@...ts.linux-m68k.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC 13/13] m68k: mac: convert to generic clockevent

Hi Arnd,

Perhaps patch 13 does not belong in this series (?).

All m68k platforms will need conversion before the TODO can be removed 
from Documentation/features/time/clockevents/arch-support.txt.

On m68k, HZ is fixed at 100. Without addressing that, would there be any 
benefit from adopting GENERIC_CLOCKEVENTS as per this RFC patch?

On Thu, 8 Oct 2020, Arnd Bergmann wrote:

> Now that the infrastructure allows kernels to have both legacy timer 
> ticks and clockevent drivers in the same image, start by moving one 
> platform to generic clockevents.
> 
> As qemu only supports the q800 platform among the classic m68k, use that 
> as an example.
> 

Correct VIA emulation is suprisingly difficult, so this kind of work 
should be tested on real hardware.

I say that because when I did the clocksource conversion for m68k I ran 
into a bug in QEMU (since fixed) and also because I once worked on some of 
the bugs in the emulated VIA device used in MAME/MESS.

> I also tried adding oneshot mode, which was successful but broke the 
> clocksource. It's probably not hard to make it work properly, but this 
> is where I've stopped.
> 

I'm not so sure that one timer is able to support both a clocksource 
driver and a clockevent driver. In some cases we may have to drop the 
clocksource driver (i.e. fall back on the jiffies clocksource).

Anyway, even on Macs with only one VIA chip we still have two timers. So I 
think we should try to use Timer 1 as a freerunning clocksource and Timer 
2 as a oneshot clock event. This may result in better accuracy and simpler 
code. This may require some experimentation though.

> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> I have never tried implementing a clockevent or clocksource
> driver in the past, so this is really just an experiment and
> I expect I got something wrong.
> 

Writing clockevent drivers is new to me too. I'm still trying to discover 
what the implications might be if the only available clockevent device 
offers oneshot mode or periodic mode but not both.