linux-kernel - Re: [RFC PATCH 07/13] m68k: amiga: Convert to clocksource API

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.21.1811122007531.351@nippy.intranet>
Date:   Mon, 12 Nov 2018 20:21:02 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
cc:     Arnd Bergmann <arnd@...db.de>,
        Stephen N Chivers <schivers@....com.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 07/13] m68k: amiga: Convert to clocksource API

On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Mon, Nov 12, 2018 at 5:46 AM Finn Thain <fthain@...egraphics.com.au> wrote:
> > Add a platform clocksource by adapting the existing arch_gettimeoffset
> > implementation.
> >
> > Signed-off-by: Finn Thain <fthain@...egraphics.com.au>
> 
> Thanks for your patch!
> 

Thanks for your review.

> > --- a/arch/m68k/amiga/config.c
> > +++ b/arch/m68k/amiga/config.c
> > @@ -17,6 +17,7 @@
> >  #include <linux/mm.h>
> >  #include <linux/seq_file.h>
> >  #include <linux/tty.h>
> > +#include <linux/clocksource.h>
> >  #include <linux/console.h>
> >  #include <linux/rtc.h>
> >  #include <linux/init.h>
> > @@ -461,7 +462,30 @@ void __init config_amiga(void)
> >                 *(unsigned char *)ZTWO_VADDR(0xde0002) |= 0x80;
> >  }
> >
> > +static u64 amiga_read_clk(struct clocksource *cs);
> > +
> > +static struct clocksource amiga_clk = {
> > +       .name   = "ciab",
> > +       .rating = 250,
> > +       .read   = amiga_read_clk,
> > +       .mask   = CLOCKSOURCE_MASK(32),
> > +       .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
> > +};
> > +
> >  static unsigned short jiffy_ticks;
> > +static u32 clk_total;
> 
> Shouldn't clk_total be u64?
> 

Well, it was intentionally u32, and amiga_clk.mask was intentionally 
CLOCKSOURCE_MASK(32)...

> > +
> > +static irqreturn_t ciab_timer_handler(int irq, void *data)
> > +{
> > +       irq_handler_t timer_routine = data;
> > +       unsigned long flags;
> > +
> > +       local_irq_save(flags);
> > +       clk_total += jiffy_ticks;
> > +       local_irq_restore(flags);
> > +
> > +       return timer_routine(irq, data);
> > +}
> 
> [...]
> 
> > -static u32 amiga_gettimeoffset(void)
> > +static u64 amiga_read_clk(struct clocksource *cs)
> >  {
> >         unsigned long flags;
> >         unsigned short hi, lo, hi2;
> > @@ -512,14 +537,13 @@ static u32 amiga_gettimeoffset(void)
> >         if (ticks > jiffy_ticks / 2)
> >                 /* check for pending interrupt */
> >                 if (cia_set_irq(&ciab_base, 0) & CIA_ICR_TA)
> > -                       offset = 10000;
> > +                       offset = jiffy_ticks;
> >
> >         local_irq_restore(flags);
> >
> >         ticks = jiffy_ticks - ticks;
> > -       ticks = (10000 * ticks) / jiffy_ticks;
> >
> > -       return (ticks + offset) * 1000;
> > +       return clk_total + ticks + offset;
> 
> ... to return a full 64-bit value here?
> 

It's certainly possible. Is it better? It sounds like a question about the 
cost of wrap-around in the clocksource core vs. the cost of 64-bit 
additions in the arch code.

Looking at __clocksource_update_freq_scale() there are some consequences 
to choosing a 32-bit mask --

                 * For clocksources which have a mask > 32-bit
                 * we need to limit the max sleep time to have a good
                 * conversion precision.

I don't know the answer, sorry.

-- 

> Gr{oetje,eeting}s,
> 
>                         Geert
> 
>