Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp2550436pxu; Fri, 9 Oct 2020 22:41:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyrj2vSesidwDrUsGRSWraIGmgdZ6Bf2mUijTQUow85pdy2ZLtSVMnIsQ+D5fbUWZ6cNvWq X-Received: by 2002:a50:d64f:: with SMTP id c15mr2880513edj.248.1602308518649; Fri, 09 Oct 2020 22:41:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602308518; cv=none; d=google.com; s=arc-20160816; b=QtJZmTSSRvnSs//CnkpUKd3FAAXrgQs9YvJi2vB18nQSMWivXLFVS9UcxgvBT0HTd4 3HHCSXSQWOikkK6TRlxZYQ+kcZEe0XoCvWcxq4IYc9WeOTXRH6mhObaBeRyjwj9TNyfR dx8cT32kZ6gnDXCxbRXhE422kdcnmWX0AJWKT7bLIb1mgYQXk12s6Dbn2gHjNhcriEPS 8FO71mF6fopRsn9MY3kXIN0UI2qZkJfRhLNYNYmlDatx7oIeeGWMbxHpZs7JXR8EJOfn VFd8j9n0nHpq4NLJ+5TNNwtgFjsaBKXVMOPYOKFmfdSPZVI4gCOpfAyXRFJAWiWXqftn NTxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date; bh=QEl7wZP3gtjt5D2Teviwsf79ZquhkkACnPHsFbBHxko=; b=ijPpKy8vJkKp9yKq9s9yJHvU+JPwIldcYMNnDHOOKUztMSZmaiZcizFC0VlDmAzSB/ pT3PdfH1e9YejhUKz5a+ymltiaYoHMT//OMLJuu7GMpjaZO2IkI7NKOqgHPu/CKjVS06 yZLXkrMMiovgSLRk/d0EiQovDcOiocHEdN+Vro30ZovNyK9v/IkkGNTcPBJY6yLZICnU L7Eu5HGNuYdSBDRpHwQhAvkoNIdJ4SVjrQdJCvTRkiEj9t6FOqlvIbQ8NeUkFvnr//5+ as4q9uy9zr/yBhoVM+5haFGhOr4iyLYV55x2IUs5iyHQeyHG0I0u57D5grqTu/JYeBsw hPlQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bc8si7250248edb.79.2020.10.09.22.41.33; Fri, 09 Oct 2020 22:41:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391034AbgJIWTA (ORCPT + 99 others); Fri, 9 Oct 2020 18:19:00 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:39224 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731594AbgJIWS6 (ORCPT ); Fri, 9 Oct 2020 18:18:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id DF3BA29EC3; Fri, 9 Oct 2020 18:18:51 -0400 (EDT) Date: Sat, 10 Oct 2020 09:18:53 +1100 (AEDT) From: Finn Thain To: Arnd Bergmann cc: linux-kernel@vger.kernel.org, Russell King , Tony Luck , Fenghua Yu , Greg Ungerer , Geert Uytterhoeven , Philip Blundell , Joshua Thompson , Sam Creasey , "James E.J. Bottomley" , Helge Deller , Thomas Gleixner , Daniel Lezcano , John Stultz , Stephen Boyd , Linus Walleij , linux-ia64@vger.kernel.org, linux-parisc@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 01/13] timekeeping: add CONFIG_LEGACY_TIMER_TICK In-Reply-To: <20201008154651.1901126-2-arnd@arndb.de> Message-ID: References: <20201008154651.1901126-1-arnd@arndb.de> <20201008154651.1901126-2-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On Thu, 8 Oct 2020, Arnd Bergmann wrote: > All platforms that currently do not use generic clockevents roughly call > the same set of functions in their timer interrupts: xtime_update(), > update_process_times() and profile_tick(), sometimes in a different > sequence. > > Add a helper function that performs all three of them, to make the > callers more uniform and simplify the interface. > > Signed-off-by: Arnd Bergmann > --- > include/linux/timekeeping.h | 1 + > kernel/time/Kconfig | 7 +++++++ > kernel/time/Makefile | 1 + > kernel/time/tick-legacy.c | 19 +++++++++++++++++++ > 4 files changed, 28 insertions(+) > create mode 100644 kernel/time/tick-legacy.c > > diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h > index 7f7e4a3f4394..3670cb1670ff 100644 > --- a/include/linux/timekeeping.h > +++ b/include/linux/timekeeping.h > @@ -12,6 +12,7 @@ extern int timekeeping_suspended; > /* Architecture timer tick functions: */ > extern void update_process_times(int user); > extern void xtime_update(unsigned long ticks); > +extern void legacy_timer_tick(unsigned long ticks); > > /* > * Get and set timeofday > diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig > index a09b1d61df6a..f2b0cfeade47 100644 > --- a/kernel/time/Kconfig > +++ b/kernel/time/Kconfig > @@ -61,6 +61,13 @@ config POSIX_CPU_TIMERS_TASK_WORK > bool > default y if POSIX_TIMERS && HAVE_POSIX_CPU_TIMERS_TASK_WORK > > +config LEGACY_TIMER_TICK > + bool > + help > + The legacy timer tick helper is used by platforms that > + lack support for the generic clockevent framework. > + New platforms should use generic clockevents instead. > + > if GENERIC_CLOCKEVENTS > menu "Timers subsystem" > > diff --git a/kernel/time/Makefile b/kernel/time/Makefile > index c8f00168afe8..1fb1c1ef6a19 100644 > --- a/kernel/time/Makefile > +++ b/kernel/time/Makefile > @@ -16,6 +16,7 @@ ifeq ($(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST),y) > endif > obj-$(CONFIG_GENERIC_SCHED_CLOCK) += sched_clock.o > obj-$(CONFIG_TICK_ONESHOT) += tick-oneshot.o tick-sched.o > +obj-$(CONFIG_LEGACY_TIMER_TICK) += tick-legacy.o > obj-$(CONFIG_HAVE_GENERIC_VDSO) += vsyscall.o > obj-$(CONFIG_DEBUG_FS) += timekeeping_debug.o > obj-$(CONFIG_TEST_UDELAY) += test_udelay.o > diff --git a/kernel/time/tick-legacy.c b/kernel/time/tick-legacy.c > new file mode 100644 > index 000000000000..73c5a0af4743 > --- /dev/null > +++ b/kernel/time/tick-legacy.c > @@ -0,0 +1,19 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Timer tick function for architectures that lack generic clockevents, > + * consolidated here from m68k/ia64/parisc/arm. > + */ > + > +#include > +#include > +#include > + > +#include "tick-internal.h" > + > +void legacy_timer_tick(unsigned long ticks) > +{ > + if (ticks) > + xtime_update(ticks); > + update_process_times(user_mode(get_irq_regs())); > + profile_tick(CPU_PROFILING); > +} > It's good to see this code refactored in this way because, as well as de-duplication, it reveals the logic that's common to the relevant platforms and may shed some light on the need for that logic. Yet it's not clear to me that the clockevents framework is able to replace that logic on all of the affected hardware. I suppose it remains to be seen. I hate to quibble about naming, but you seem to be using "legacy" here to mean "deprecated" (?) Is it a good idea to prepend such adjectives to symbol names? IMO, the term "legacy" is redundant in this context. That term covers a large portion of kernel code, a large number of hardware features in current silicon, a large portion of the userspace ABI, a large number of production Linux systems, probably all "Unix" systems, etc. As a corollary, cutting edge ("non-legacy") code is often kept out of open source projects by the owners of the intellectual property rights.