From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel.lezcano@linaro.org (Daniel Lezcano) Date: Mon, 29 May 2017 12:55:09 +0200 Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE In-Reply-To: References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org> <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org> <20170529084809.GA2192@mai> Message-ID: <20170529105509.GC2192@mai> To: linus-amlogic@lists.infradead.org List-Id: linus-amlogic.lists.infradead.org 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Lezcano Subject: Re: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE Date: Mon, 29 May 2017 12:55:09 +0200 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-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+glpam-linux-mediatek=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Arnd Bergmann Cc: Mark Rutland , "open list:RALINK MIPS ARCHITECTURE" , Baruch Siach , Heiko Stuebner , Neil Armstrong , Linus Walleij , Santosh Shilimkar , Liviu Dudau , "moderated list:ARM/OXNAS platform support" , Patrice Chotard , Eric Anholt , Thierry Reding , Ingo Molnar , "open list:ARM/STI ARCHITECTURE" , Alexandre Courbot , "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" , Florian Fainelli , "moderated list:H8/300 ARCHITECTURE" , Alexander Shiyan List-Id: linux-mediatek@lists.infradead.org T24gTW9uLCBNYXkgMjksIDIwMTcgYXQgMTE6NTc6MjVBTSArMDIwMCwgQXJuZCBCZXJnbWFubiB3 cm90ZToKPiBPbiBNb24sIE1heSAyOSwgMjAxNyBhdCAxMDo0OCBBTSwgRGFuaWVsIExlemNhbm8K PiA8ZGFuaWVsLmxlemNhbm9AbGluYXJvLm9yZz4gd3JvdGU6Cj4gPiBPbiBNb24sIE1heSAyOSwg MjAxNyBhdCAxMDo0MTo1MkFNICswMjAwLCBBcm5kIEJlcmdtYW5uIHdyb3RlOgo+ID4+IE9uIFNh dCwgTWF5IDI3LCAyMDE3IGF0IDExOjU4IEFNLCBEYW5pZWwgTGV6Y2Fubwo+ID4+IDxkYW5pZWwu bGV6Y2Fub0BsaW5hcm8ub3JnPiB3cm90ZToKPiA+PiA+IFRoZSBDTE9DS1NPVUNFX09GX0RFQ0xB UkUgbWFjcm8gaXMgdXNlZCB3aWRlbHkgZm9yIHRoZSB0aW1lcnMgdG8gZGVjbGFyZSB0aGUKPiA+ PiA+IGNsb2Nrc291cmNlIGF0IGVhcmx5IHN0YWdlLiBIb3dldmVyLCB0aGlzIG1hY3JvIGlzIGFs c28gdXNlZCB0byBpbml0aWFsaXplCj4gPj4gPiB0aGUgY2xvY2tldmVudCBpZiBhbnksIG9yIHRo ZSBjbG9ja2V2ZW50IG9ubHkuCj4gPj4gPgo+ID4+ID4gSXQgd2FzIG9yaWdpbmFsbHkgc3VnZ2Vz dGVkIHRvIGRlY2xhcmUgYW5vdGhlciBtYWNybyB0byBpbml0aWFsaXplIGEKPiA+PiA+IGNsb2Nr ZXZlbnQsIHNvIGluIG9yZGVyIHRvIHNlcGFyYXRlIHRoZSB0d28gZW50aXRpZXMgZXZlbiB0aGV5 IGJlbG9uZyB0byB0aGUKPiA+PiA+IHNhbWUgSVAuIFRoaXMgd2FzIG5vdCBhY2NlcHRlZCBiZWNh dXNlIG9mIHRoZSBpbXBhY3Qgb24gdGhlIERUIHdoZXJlIHNwbGl0dGluZwo+ID4+ID4gYSBjbG9j a3NvdXJjZS9jbG9ja2V2ZW50IGRlZmluaXRpb24gZG9lcyBub3QgbWFrZSBzZW5zZSBhcyBpdCBp cyBhIExpbnV4Cj4gPj4gPiBjb25jZXB0IG5vdCBhIGhhcmR3YXJlIGRlc2NyaXB0aW9uLgo+ID4+ ID4KPiA+PiA+IE9uIHRoZSBvdGhlciBzaWRlLCB0aGUgY2xvY2tzb3VyY2UgaGFzIG5vdCBpbnRl cnJ1cHQgZGVjbGFyZWQgd2hpbGUgdGhlCj4gPj4gPiBjbG9ja2V2ZW50IGhhcywgc28gaXQgaXMg ZWFzeSBmcm9tIHRoZSBkcml2ZXIgdG8ga25vdyBpZiB0aGUgZGVzY3JpcHRpb24gaXMKPiA+PiA+ IGZvciBhIGNsb2NrZXZlbnQgb3IgYSBjbG9ja3NvdXJjZSwgSU9XIGl0IGNvdWxkIGJlIGltcGxl bWVudGVkIGF0IHRoZSBkcml2ZXIKPiA+PiA+IGxldmVsLgo+ID4+ID4KPiA+PiA+IFNvIGluc3Rl YWQgb2YgZGVhbGluZyB3aXRoIGEgbmFtZWQgY2xvY2tzb3VyY2UgbWFjcm8sIGxldCdzIHVzZSBh IG1vcmUgZ2VuZXJpYwo+ID4+ID4gb25lOiBUSU1FUl9PRl9ERUNMQVJFLgo+ID4+ID4KPiA+PiA+ IFRoZSBwYXRjaCBoYXMgbm90IGZ1bmN0aW9uYWwgY2hhbmdlcy4KPiA+PiA+Cj4gPj4gPiBTaWdu ZWQtb2ZmLWJ5OiBEYW5pZWwgTGV6Y2FubyA8ZGFuaWVsLmxlemNhbm9AbGluYXJvLm9yZz4KPiA+ Pgo+ID4+IENvdWxkIHlvdSBlaXRoZXIgbGVhdmUgdGhlIG9sZCBuYW1lIGFzIGFuIGFsaWFzIGZv ciBvbmUgcmVsZWFzZSwgb3IgaW50cm9kdWNlCj4gPj4gdGhlIG5ldyBuYW1lIGFzIGFuIGFsaWFz IG5vdyBmb3IgNC4xMz8KPiA+Pgo+ID4+IEkgdGhpbmsgdGhhdCB0aGF0IHdvdWxkIG1ha2UgaXQg ZWFzaWVyIHRvIG1lcmdlIG5ldyBkcml2ZXJzLiBPdGhlcndpc2UgdGhpcwo+ID4+IGxvb2tzIGdv b2QgdG8gbWUsCj4gPgo+ID4KPiA+IE5ldyBkcml2ZXJzIHNob3VsZCBnbyB0aHJvdWdoIG15IHRy ZWUsIHNvIEkgY2FuIGNhdGNoIHRoZW0gd2l0aCB0aGUgb2xkIG1hY3JvCj4gPiBuYW1lIGFuZCBk byB0aGUgY2hhbmdlLgo+IAo+IFN1cmUsIHRoZXkgc2hvdWxkLCBhbmQgaXQncyBxdWl0ZSBsaWtl bHkgdGhhdCB5b3Ugd29uJ3QgZXZlbiBuZWVkIHRoZSBmYWxsYmFjaywKPiBJJ3ZlIGp1c3Qgc2Vl biB0b28gbWFueSBjYXNlcyB3aGVyZSBhIHNpbWlsYXIgYXNzdW1wdGlvbiB0dXJuZWQgb3V0IHdy b25nLAo+IHRoYXQgSSdkIGp1c3QgcGljayB0aGUgc2FmZXIgb3B0aW9uIGp1c3QgaW4gY2FzZSB3 aGVuZXZlciBJIGRvIGFuIEFQSSBjaGFuZ2UuCj4gCj4gVGhpbmdzIHRoYXQgY291bGQgZ28gd3Jv bmcgaW5jbHVkZToKPiAKPiAtIEEgcGxhdGZvcm0gbWFpbnRhaW5lciB3YW50cyB0byBhZGQgYSBu ZXcgcGxhdGZvcm0gYW5kIGhhcyBhIGZvci1uZXh0Cj4gICBicmFuY2ggdGhhdCBnZXRzIG1lcmdl ZCBpbnRvIGxpbnV4LW5leHQsIHdpdGggcGFydHMgb2YgaXQgZ29pbmcgdGhyb3VnaAo+ICAgZGlm ZmVyZW50IG1haW50YWluZXJzLCBhbmQgbm93IHRoZXkgaGF2ZSB0byBjaG9vc2UgYmV0d2VlbiBh IGJyYW5jaAo+ICAgdGhhdCBkb2Vzbid0IGJ1aWxkIHdpdGhvdXQgdGhlIHRpbWVyIGJyYW5jaCwg b3Igb25lIHRoYXQgYnJlYWsgZm9yLW5leHQKPiAgIHVubGVzcyBTdGVwaGVuIGFwcGxpZXMgYSBm aXh1cAo+IAo+IC0gU29tZSBhcmNoaXRlY3R1cmUgbWFpbnRhaW5lciBkaWRuJ3QgZ2V0IHRoZSBt ZW1vIGFuZCBhZGRzIGFuIGluc3RhbmNlIG9mCj4gICBDTE9DS1NPVUNFX09GX0RFQ0xBUkUgaW4g YXJjaGl0ZWN0dXJlIHNwZWNpZmljIGNvZGUgd2l0aG91dCBhc2tpbmcKPiAgIGhhdmluZyB0aGUg cGF0Y2ggcmV2aWV3ZWQgZmlyc3QKPiAKPiAtIEEgcGxhdGZvcm0gaGFzIGEgYnJhbmNoIHdpdGgg Y29tcGxleCBjcm9zcy10cmVlIGRlcGVuZGVuY2llcyBhbmQKPiAgIGl0IG5lZWQgdG8gZ2V0IG1l cmdlZCBpbiBhbiB1bmNvbnZlbnRpb25hbCB3YXkuCj4gCj4gLSBZb3UgbWFrZSBhIG1pc3Rha2Ug YW5kIGFjY2lkZW50YWxseSBtZXJnZSBvbmUgZHJpdmVyIGZvciBhbiB1bnVzdWFsCj4gICBhcmNo aXRlY3R1cmUgdGhhdCBlc2NhcGVzIHlvdXIgdGVzdCBtYXRyaXguCj4gCj4gV2hpbGUgdGhvc2Ug YWxsIGFyZSB1bmxpa2VseSB0byBoYXBwZW4gaW4gYSBwYXJ0aWN1bGFyIG1lcmdlIHdpbmRvdywg dGhleSBkbwo+IGhhcHBlbiBvY2Nhc2lvbmFsbHkgYW5kIHRlbmQgdG8gY2F1c2UgYSBsb3Qgb2Yg cGFpbi4KCkhtbSwgdGhhdCBzb3VuZHMgc2NhcnkgOikKClRoZXJlIGlzIG5vIGd1YXJhbnRlZSwg d2hlbiByZW1vdmluZyB0aGUgYWxpYXMsIG5vbmUgb2YgdGhlIGFib3ZlIGhhcHBlbnMsCnJpZ2h0 PwoKSWYgdGhlIHRpbWVyIGJyYW5jaCBpcyBpbiBsaW51eC1uZXh0LCB0aGF0IGNvdWxkIGJlIGNh dWd0aCBiZWZvcmUgYW55IG9mIHRoZQphYm92ZSBoYXBwZW5zLCBubz8KCkknbSBub3QgYWdhaW5z dCBhZGRpbmcgYW4gYWxpYXMsIGp1c3QgY2hlY2tpbmcgb3V0IGlmIGl0IGlzIHdvcnRoIHRvLgoK LS0gCgogPGh0dHA6Ly93d3cubGluYXJvLm9yZy8+IExpbmFyby5vcmcg4pSCIE9wZW4gc291cmNl IHNvZnR3YXJlIGZvciBBUk0gU29DcwoKRm9sbG93IExpbmFybzogIDxodHRwOi8vd3d3LmZhY2Vi b29rLmNvbS9wYWdlcy9MaW5hcm8+IEZhY2Vib29rIHwKPGh0dHA6Ly90d2l0dGVyLmNvbS8jIS9s aW5hcm9vcmc+IFR3aXR0ZXIgfAo8aHR0cDovL3d3dy5saW5hcm8ub3JnL2xpbmFyby1ibG9nLz4g QmxvZwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTGlu dXgtbWVkaWF0ZWsgbWFpbGluZyBsaXN0CkxpbnV4LW1lZGlhdGVrQGxpc3RzLmluZnJhZGVhZC5v cmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1tZWRp YXRlawo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel.lezcano@linaro.org (Daniel Lezcano) Date: Mon, 29 May 2017 12:55:09 +0200 Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE In-Reply-To: References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org> <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org> <20170529084809.GA2192@mai> List-ID: Message-ID: <20170529105509.GC2192@mai> To: linux-snps-arc@lists.infradead.org On Mon, May 29, 2017@11:57:25AM +0200, Arnd Bergmann wrote: > On Mon, May 29, 2017 at 10:48 AM, Daniel Lezcano > wrote: > > On Mon, May 29, 2017@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