From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 29 May 2017 12:55:33 +0200 (CEST) Received: from mail-wm0-x233.google.com ([IPv6:2a00:1450:400c:c09::233]:37971 "EHLO mail-wm0-x233.google.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23992127AbdE2KzUrz02O (ORCPT ); Mon, 29 May 2017 12:55:20 +0200 Received: by mail-wm0-x233.google.com with SMTP id e127so55053192wmg.1 for ; Mon, 29 May 2017 03:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=m9XVm+COXROdP9Ihxwg8bv8eA2bFTUaT8sLKK0Xq8go=; b=D2QjEgPrrNpSECAYbCxBP78UjoLM9WdHReKNQj+KiDmekZtZmEvoVLStPTlNeBHFP7 rzsXs7gSyU24FSRzpXzrCCf4XNpn7KI4RMcrlbrhsECWF5MXAerfd+1Z09qBz4OXnBWa 55mwYUlAbCYXLEOAvxvhiMuHwlW5FxwDTwVxY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=m9XVm+COXROdP9Ihxwg8bv8eA2bFTUaT8sLKK0Xq8go=; b=Xca+vcL9/p6Rxle9Ne6FOSS+To5wJr54GC02GGOFnO0zQnwl1EswkzxlyO7Ic1zGKE 4eB5AM7JMDoG4td7FX7J8alqz6gARiqelFa3lYFrJiUN+8jmUf1mujeUGqJxRJIrmkYp 9WYpvJS5w6gHMncE1E7dfgcHp5BIzRJLATPNip80EwYFziLFtBPPxON2DN+LfdQn0OkL yPqVw1yN1I+mcAU2Ohp98VoYQ11hHWnvI1KcrD5dvQN7enn7y0X4CSfJmBfiDRd774km gi1HVCMlFeqM+Q6KixLiSAJ6sHbeFKlsTTSjuNP5FHmHGR29r2CoejD+VE5YLVUEDox5 B7tA== X-Gm-Message-State: AODbwcBxO3BPYiLFsFcYirPRgRJ90mBRSB/rO6ezabF4sMXCQ9c1742x FT4N5jxXz9NJ+7mZ X-Received: by 10.28.128.202 with SMTP id b193mr10536955wmd.53.1496055315269; Mon, 29 May 2017 03:55:15 -0700 (PDT) Received: from mai ([2a01:e35:879a:6cd0:3e97:eff:fe5b:1402]) by smtp.gmail.com with ESMTPSA id z32sm9626169wrc.12.2017.05.29.03.55.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 03:55:14 -0700 (PDT) Date: Mon, 29 May 2017 12:55:09 +0200 From: Daniel Lezcano To: Arnd Bergmann Cc: Thomas Gleixner , Linux ARM , Linux Kernel Mailing List , Russell King , Michal Simek , John Crispin , Ralf Baechle , Ley Foon Tan , Vineet Gupta , Mark Rutland , Marc Zyngier , Patrice Chotard , Maxime Coquelin , Alexandre Torgue , Florian Fainelli , Ray Jui , Scott Branden , "maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE..." , Stephen Warren , Lee Jones , Eric Anholt , =?iso-8859-1?Q?S=F6ren?= Brinkmann , Linus Walleij , Alexander Shiyan , Kukjin Kim , Krzysztof Kozlowski , Javier Martinez Canillas , Yoshinori Sato , Carlo Caione , Kevin Hilman , Liviu Dudau , Sudeep Holla , Lorenzo Pieralisi , Matthias Brugger , Heiko Stuebner , Maxime Ripard , Chen-Yu Tsai , Marc Gonzalez , Thierry Reding , Alexandre Courbot , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Joachim Eastwood , Vladimir Zapolskiy , Sylvain Lemieux , Barry Song , Baruch Siach , Santosh Shilimkar , Neil Armstrong , Tony Prisk , John Stultz , Stephen Boyd , Anna-Maria Gleixner , Richard Cochran , Ingo Molnar , Noam Camus , "open list:RALINK MIPS ARCHITECTURE" , "moderated list:NIOS2 ARCHITECTURE" , "open list:SYNOPSYS ARC ARCHITECTURE" , "open list:ARM/STI ARCHITECTURE" , "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" , "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" , "moderated list:H8/300 ARCHITECTURE" , "open list:ARM/Amlogic Meson SoC support" , "moderated list:ARM/Mediatek SoC support" , "open list:ARM/Rockchip SoC support" , "open list:TEGRA ARCHITECTURE SUPPORT" , "moderated list:ARM/OXNAS platform support" Subject: Re: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE Message-ID: <20170529105509.GC2192@mai> References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org> <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org> <20170529084809.GA2192@mai> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 58065 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: daniel.lezcano@linaro.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On Mon, May 29, 2017 at 11:57:25AM +0200, Arnd Bergmann wrote: > On Mon, May 29, 2017 at 10:48 AM, Daniel Lezcano > wrote: > > On Mon, May 29, 2017 at 10:41:52AM +0200, Arnd Bergmann wrote: > >> On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano > >> wrote: > >> > The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the > >> > clocksource at early stage. However, this macro is also used to initialize > >> > the clockevent if any, or the clockevent only. > >> > > >> > It was originally suggested to declare another macro to initialize a > >> > clockevent, so in order to separate the two entities even they belong to the > >> > same IP. This was not accepted because of the impact on the DT where splitting > >> > a clocksource/clockevent definition does not make sense as it is a Linux > >> > concept not a hardware description. > >> > > >> > On the other side, the clocksource has not interrupt declared while the > >> > clockevent has, so it is easy from the driver to know if the description is > >> > for a clockevent or a clocksource, IOW it could be implemented at the driver > >> > level. > >> > > >> > So instead of dealing with a named clocksource macro, let's use a more generic > >> > one: TIMER_OF_DECLARE. > >> > > >> > The patch has not functional changes. > >> > > >> > Signed-off-by: Daniel Lezcano > >> > >> Could you either leave the old name as an alias for one release, or introduce > >> the new name as an alias now for 4.13? > >> > >> I think that that would make it easier to merge new drivers. Otherwise this > >> looks good to me, > > > > > > New drivers should go through my tree, so I can catch them with the old macro > > name and do the change. > > Sure, they should, and it's quite likely that you won't even need the fallback, > I've just seen too many cases where a similar assumption turned out wrong, > that I'd just pick the safer option just in case whenever I do an API change. > > Things that could go wrong include: > > - A platform maintainer wants to add a new platform and has a for-next > branch that gets merged into linux-next, with parts of it going through > different maintainers, and now they have to choose between a branch > that doesn't build without the timer branch, or one that break for-next > unless Stephen applies a fixup > > - Some architecture maintainer didn't get the memo and adds an instance of > CLOCKSOUCE_OF_DECLARE in architecture specific code without asking > having the patch reviewed first > > - A platform has a branch with complex cross-tree dependencies and > it need to get merged in an unconventional way. > > - You make a mistake and accidentally merge one driver for an unusual > architecture that escapes your test matrix. > > While those all are unlikely to happen in a particular merge window, they do > happen occasionally and tend to cause a lot of pain. Hmm, that sounds scary :) There is no guarantee, when removing the alias, none of the above happens, right? If the timer branch is in linux-next, that could be caugth before any of the above happens, no? I'm not against adding an alias, just checking out if it is worth to. -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog