Message ID | 20201115170950.304460-2-krzk@kernel.org (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1keLY2-00DVZG-6v; Sun, 15 Nov 2020 17:10:42 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727404AbgKORKC (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Sun, 15 Nov 2020 12:10:02 -0500 Received: from mail.kernel.org ([198.145.29.99]:38524 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726727AbgKORKC (ORCPT <rfc822;linux-media@vger.kernel.org>); Sun, 15 Nov 2020 12:10:02 -0500 Received: from localhost.localdomain (adsl-84-226-167-205.adslplus.ch [84.226.167.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 12A4124198; Sun, 15 Nov 2020 17:09:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605460202; bh=nLQvhMPRPmn8OBYUS7haupcAM25cdbBYOxtHEx0ld1E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U84DhcaoqGc5ScNqf/gUzmoe3lK2x7woUgZ2YR83LVYwL4il15/VjE1A83CrMWzD4 EqboYDLGRo+lHGcZ3VILVGxtMrtg4zqXdQ27FuDOoXg9eoSw7rFg7+xX2HLG+NpCGp Nf5csY7BoO+zqJ+LnWl6v2gXW/c48MlQgjuFwbAk= From: Krzysztof Kozlowski <krzk@kernel.org> To: Maxime Ripard <mripard@kernel.org>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@siol.net>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Sakari Ailus <sakari.ailus@linux.intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, linux-media@vger.kernel.org, devel@driverdev.osuosl.org, alsa-devel@alsa-project.org Cc: Krzysztof Kozlowski <krzk@kernel.org> Subject: [PATCH 1/3] clk: fix redefinition of clk_prepare on MIPS with HAVE_LEGACY_CLK Date: Sun, 15 Nov 2020 18:09:48 +0100 Message-Id: <20201115170950.304460-2-krzk@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20201115170950.304460-1-krzk@kernel.org> References: <20201115170950.304460-1-krzk@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -3.1 (---) X-LSpam-Report: No, score=-3.1 required=5.0 tests=BAYES_00=-1.9,DKIMWL_WL_HIGH=0.001,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DKIM_VALID_EF=-0.1,MAILING_LIST_MULTI=-1 autolearn=ham autolearn_force=no |
Series |
clk/sunxi/media: Fix builds with COMMON_CLK and HAVE_LEGACY_CLK
|
|
Commit Message
Krzysztof Kozlowski
Nov. 15, 2020, 5:09 p.m. UTC
COMMON_CLK even though is a user-selectable symbol, is still selected by
multiple other config options. COMMON_CLK should not be used when
legacy clocks are provided by architecture, so it correctly depends on
!HAVE_LEGACY_CLK.
However it is possible to create a config which selects both COMMON_CLK
(by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (by SOC_RT305X) which leads to
compile errors (MIPS architecture):
drivers/clk/clk.c:855:6: error: redefinition of ‘clk_unprepare’
In file included from drivers/clk/clk.c:9:
include/linux/clk.h:263:20: note: previous definition of ‘clk_unprepare’ was here
The definitions clk_bulk_prepare() (and unprepare) already have proper
surrounding #ifdef so add them also for clk_prepare()/clk_unprepare().
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/clk/clk.c | 4 ++++
1 file changed, 4 insertions(+)
Comments
Quoting Krzysztof Kozlowski (2020-11-15 09:09:48) > COMMON_CLK even though is a user-selectable symbol, is still selected by > multiple other config options. COMMON_CLK should not be used when > legacy clocks are provided by architecture, so it correctly depends on > !HAVE_LEGACY_CLK. > > However it is possible to create a config which selects both COMMON_CLK > (by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (by SOC_RT305X) which leads to Why is SND_SUN8I_CODEC selecting COMMON_CLK? Or really, why is SOC_RT305X selecting HAVE_LEGACY_CLK?
On Tue, Nov 17, 2020 at 11:41:57PM -0800, Stephen Boyd wrote: > Quoting Krzysztof Kozlowski (2020-11-15 09:09:48) > > COMMON_CLK even though is a user-selectable symbol, is still selected by > > multiple other config options. COMMON_CLK should not be used when > > legacy clocks are provided by architecture, so it correctly depends on > > !HAVE_LEGACY_CLK. > > > > However it is possible to create a config which selects both COMMON_CLK > > (by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (by SOC_RT305X) which leads to > > Why is SND_SUN8I_CODEC selecting COMMON_CLK? Or really, why is > SOC_RT305X selecting HAVE_LEGACY_CLK? The SND_SUN8I_CODEC I fixed in following patch (I sent separately v2 of it). The SOC_RT305X select HAVE_LEGACY_CLK? because it is an old, Ralink platform, not converted to Common clock frm. Few clock operations are defined in: arch/mips/ralink/clk.c Best regards, Krzysztof
Quoting Krzysztof Kozlowski (2020-11-17 23:48:12) > On Tue, Nov 17, 2020 at 11:41:57PM -0800, Stephen Boyd wrote: > > Quoting Krzysztof Kozlowski (2020-11-15 09:09:48) > > > COMMON_CLK even though is a user-selectable symbol, is still selected by > > > multiple other config options. COMMON_CLK should not be used when > > > legacy clocks are provided by architecture, so it correctly depends on > > > !HAVE_LEGACY_CLK. > > > > > > However it is possible to create a config which selects both COMMON_CLK > > > (by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (by SOC_RT305X) which leads to > > > > Why is SND_SUN8I_CODEC selecting COMMON_CLK? Or really, why is > > SOC_RT305X selecting HAVE_LEGACY_CLK? > > The SND_SUN8I_CODEC I fixed in following patch (I sent separately v2 of > it). > > The SOC_RT305X select HAVE_LEGACY_CLK? because it is an old, Ralink > platform, not converted to Common clock frm. Few clock operations are > defined in: arch/mips/ralink/clk.c > Ok so this patch isn't necessary then? It seems OK to select HAVE_LEGACY_CLK but not to select COMMON_CLK unless it's architecture code that can't be enabled when the other architecture code is selecting HAVE_LEGACY_CLK.
On Tue, Nov 24, 2020 at 04:11:31PM -0800, Stephen Boyd wrote: > Quoting Krzysztof Kozlowski (2020-11-17 23:48:12) > > On Tue, Nov 17, 2020 at 11:41:57PM -0800, Stephen Boyd wrote: > > > Quoting Krzysztof Kozlowski (2020-11-15 09:09:48) > > > > COMMON_CLK even though is a user-selectable symbol, is still selected by > > > > multiple other config options. COMMON_CLK should not be used when > > > > legacy clocks are provided by architecture, so it correctly depends on > > > > !HAVE_LEGACY_CLK. > > > > > > > > However it is possible to create a config which selects both COMMON_CLK > > > > (by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (by SOC_RT305X) which leads to > > > > > > Why is SND_SUN8I_CODEC selecting COMMON_CLK? Or really, why is > > > SOC_RT305X selecting HAVE_LEGACY_CLK? > > > > The SND_SUN8I_CODEC I fixed in following patch (I sent separately v2 of > > it). > > > > The SOC_RT305X select HAVE_LEGACY_CLK? because it is an old, Ralink > > platform, not converted to Common clock frm. Few clock operations are > > defined in: arch/mips/ralink/clk.c > > > > Ok so this patch isn't necessary then? For this particular build failure - it is not necessary anymore. However there might more of such errors - just not discovered yet. Also, the clock bulk API has such ifdefs so it kind of symmetrical and consistent approach. > It seems OK to select > HAVE_LEGACY_CLK but not to select COMMON_CLK unless it's architecture > code that can't be enabled when the other architecture code is selecting > HAVE_LEGACY_CLK. Best regards, Krzysztof
Quoting Krzysztof Kozlowski (2020-11-25 06:15:05) > On Tue, Nov 24, 2020 at 04:11:31PM -0800, Stephen Boyd wrote: > > > > Ok so this patch isn't necessary then? > > For this particular build failure - it is not necessary anymore. > > However there might more of such errors - just not discovered yet. Also, > the clock bulk API has such ifdefs so it kind of symmetrical and > consistent approach. > Ok. Patches always welcome.
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index f83dac54ed85..f4f68c7c2fb5 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -841,6 +841,7 @@ static void clk_core_unprepare_lock(struct clk_core *core) clk_prepare_unlock(); } +#ifdef CONFIG_HAVE_CLK_PREPARE /** * clk_unprepare - undo preparation of a clock source * @clk: the clk being unprepared @@ -860,6 +861,7 @@ void clk_unprepare(struct clk *clk) clk_core_unprepare_lock(clk->core); } EXPORT_SYMBOL_GPL(clk_unprepare); +#endif static int clk_core_prepare(struct clk_core *core) { @@ -921,6 +923,7 @@ static int clk_core_prepare_lock(struct clk_core *core) return ret; } +#ifdef CONFIG_HAVE_CLK_PREPARE /** * clk_prepare - prepare a clock source * @clk: the clk being prepared @@ -941,6 +944,7 @@ int clk_prepare(struct clk *clk) return clk_core_prepare_lock(clk->core); } EXPORT_SYMBOL_GPL(clk_prepare); +#endif /* CONFIG_HAVE_CLK_PREPARE */ static void clk_core_disable(struct clk_core *core) {