[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.21.1811122002530.351@nippy.intranet>
Date: Mon, 12 Nov 2018 20:06:50 +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>,
Philip Blundell <philb@....org>,
Michael Schmitz <schmitzmic@...il.com>,
Joshua Thompson <funaho@...ai.org>
Subject: Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
> Hi Finn,
>
> Thanks for your patch!
>
> On Mon, Nov 12, 2018 at 5:46 AM Finn Thain <fthain@...egraphics.com.au> wrote:
> > The functions that implement arch_gettimeoffset are re-used by
> > new clocksource drivers in subsequent patches.
>
> Disabling this first affects functionality during bisection, right?
>
It means that all platforms have to use the 'jiffies' clocksource.
At the end of the series, only apollo, q40, sun3 & sun3x continue to use
that clocksource.
> > --- a/arch/m68k/amiga/config.c
> > +++ b/arch/m68k/amiga/config.c
> > @@ -95,8 +95,6 @@ static char amiga_model_name[13] = "Amiga ";
> > static void amiga_sched_init(irq_handler_t handler);
> > static void amiga_get_model(char *model);
> > static void amiga_get_hardware_list(struct seq_file *m);
> > -/* amiga specific timer functions */
> > -static u32 amiga_gettimeoffset(void);
> > extern void amiga_mksound(unsigned int count, unsigned int ticks);
> > static void amiga_reset(void);
> > extern void amiga_init_sound(void);
> > @@ -386,7 +384,6 @@ void __init config_amiga(void)
> > mach_init_IRQ = amiga_init_IRQ;
> > mach_get_model = amiga_get_model;
> > mach_get_hardware_list = amiga_get_hardware_list;
> > - arch_gettimeoffset = amiga_gettimeoffset;
>
> In addition, won't this lead to "function defined statically but not
> called' warnings?
>
I expect so. I haven't compile-tested each step in the series; but I'll do
that before I send v2. Thanks for the reminder.
There are no new warnings at the end of the series.
--
> Gr{oetje,eeting}s,
>
> Geert
>
>
Powered by blists - more mailing lists