Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp151728ybt; Tue, 23 Jun 2020 17:58:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDnKN1JQjYcVtef/udwBOeHiHERrj0ftA8LKNrvjqxE8EVlL8SW+pkHL3wiGBc8bFXK+We X-Received: by 2002:a17:906:50b:: with SMTP id j11mr4610290eja.127.1592960331393; Tue, 23 Jun 2020 17:58:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592960331; cv=none; d=google.com; s=arc-20160816; b=O35ByBUDaZuJDbjd3HYFNV/gOyJkiV8AHt3+8DrPOWQlAlRDAU97z4UE40x0WtpG0K w5tD3Q/z/nQ8snfQFqwXjWLPuLkhS30gw+NCzhLfsMfPEo5uWZS0gdkLj/mx+nlneG6f 13W47flRq5yNNQOw3hHGArL/xEKhWsiw7zqw8XeI1NfMpuNfXL6WPmXwmzexKQQrxn6H fEonCDb0SF19ReIwbdR+uZ7zHe2w84P0h3ZtMNlrfbInZz2/1GrWbSOWI4oVivkQUWPa 08pLqDNKgATLP3hNrVTHoniEs7UH7IA1iPbOdoX7R/CpEzq7ydLEipTvgu0CIDYwWD0y wbRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:date:to:cc:from :subject:references:in-reply-to:content-transfer-encoding :mime-version:dkim-signature; bh=qeVQIyFu06RVQnFbEMpvM+EP5YFW4HfglLbS6BMK4xE=; b=G0490csxafrI6W6D5jp+m7kFkmSc4Y5iFVxXY/q1fIEfEt/0tpQUmBJyFAXoTKSsGK j3w4SE2C4o9s9fMGijZo+aUvS0a6AFRxRLZ83kw8xQUQV2xqAG8VdVbPT68mktn84fJu fu7iIgFgljLuX8hVVk6VxJC9Fj4D9IadUMbJhhwnz/+44Wes9rMbuGv4sKA4B/q3Ns/k v9HwGSyPbNFBmP6y4q8K/ChbtM5hhLTzxx684Vsx57uQh8UBjUrEc3S9YlcDFZUcoZBF 9npVMHWViFMAFxexz9/TjeUzDPTQJY0GbZJJOCx9w6Ctp16qjrQuK3yC1XFLrnRHYjYF UQ3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="Ex/rw0Q2"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id la26si4740569ejb.587.2020.06.23.17.58.26; Tue, 23 Jun 2020 17:58:51 -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; dkim=pass header.i=@kernel.org header.s=default header.b="Ex/rw0Q2"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388045AbgFXA5x (ORCPT + 99 others); Tue, 23 Jun 2020 20:57:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:55434 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387586AbgFXA5x (ORCPT ); Tue, 23 Jun 2020 20:57:53 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 02FFD20C09; Wed, 24 Jun 2020 00:57:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592960272; bh=AIcBjg5EduAc2hzc+ZZu4+NrFWBrKK0dKtZ4TiZI8hk=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Ex/rw0Q2yGMJJ5Y1Mb0WjrwmRbTpPIUqWA18wpXyjDd1XLi9vRJJ1RXY662WE/6se VajoedT+VunLFcfmjeGvY5QuUCQiV9JcIeXOpfOhXeM4ha4A8ZedfIoP8Hf/vp2ZWI 96rwsceBn9b6QQuXvSTxtwM5blaJD4NO4J6mEQUA= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <1591687933-19495-1-git-send-email-Anson.Huang@nxp.com> <1591687933-19495-4-git-send-email-Anson.Huang@nxp.com> <159262367025.62212.11651547971712516448@swboyd.mtv.corp.google.com> <159290125202.62212.13172213909023205615@swboyd.mtv.corp.google.com> Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module From: Stephen Boyd Cc: dl-linux-imx To: Abel Vesa , Aisheng Dong , Andy Duan , Anson Huang , Daniel Baluta , Leonard Crestez , Peng Fan , Stefan Agner , allison@lohutok.net, arnd@arndb.de, festevam@gmail.com, gregkh@linuxfoundation.org, info@metux.net, kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux@armlinux.org.uk, mturquette@baylibre.com, oleksandr.suvorov@toradex.com, s.hauer@pengutronix.de, sfr@canb.auug.org.au, shawnguo@kernel.org, tglx@linutronix.de, yuehaibing@huawei.com Date: Tue, 23 Jun 2020 17:57:51 -0700 Message-ID: <159296027133.62212.18074403520585879907@swboyd.mtv.corp.google.com> User-Agent: alot/0.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Aisheng Dong (2020-06-23 02:00:47) > > From: Stephen Boyd > > Sent: Tuesday, June 23, 2020 4:34 PM > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver= as > > module > >=20 > > Quoting Aisheng Dong (2020-06-22 20:42:19) > > > > From: Stephen Boyd > > > > Sent: Saturday, June 20, 2020 11:28 AM > > > > Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock > > > > driver as module > > > > > > > > Quoting Aisheng Dong (2020-06-17 18:58:51) > > > > > > From: Anson Huang > > > > > > > > +obj-$(CONFIG_MXC_CLK_SCU) +=3D mxc-clk-scu.o > > > > > > > > > > > > > > Like i.MX pinctrl, I'm not sure if it's really necessary to > > > > > > > build core libraries as modules. Probably the simplest way is > > > > > > > only building platform drivers part as module. And leave those > > > > > > > core libraries > > > > built in kernel. > > > > > > > This may make the code a bit cleaner. > > > > > > > > > > > > > > > > > > > Will discuss this with Linaro guys about it, previous > > > > > > requirement I received is all SoC specific modules need to be b= uilt as > > module. > > > > > > > > > > > > > > > > Okay. AFAIK it's not conflict. > > > > > You still make drivers into modules. > > > > > Only difference is for those common libraries part, we don't > > > > > convert them into module Which is less meaningless. > > > > > > > > > > > > > What is the benefit of making the core part of the SoC driver not a= module? > > > > > > Usually we could try to build it as module if it's not hard. > > > > > > One question is sometimes those core part are shared with some platfo= rms > > which can't built as module. > > > For i.MX case, it's mainly patch 4: > > > [V2,4/9] clk: imx: Support building i.MX common clock driver as module > > > > > > > > > Those libraries are also used by i.MX6&7 which can't build as module. > > > So we need an extra workaround patch to forcely 'select' it under > > > arch/arm/mach-imx/Kconfig [V2,2/9] ARM: imx: Select MXC_CLK for > > > ARCH_MXC > > > Then the users can't configure it as module in order to not break bui= ld. > > > > > > If build-in those common libraries, the implementation could be a bit= easier > > and cleaner. > > > So I'm not sure if we still have to build them as module. > > > How would you suggest for such case? > >=20 > > Stop using 'select MXC_CLK' when requiring the core library code? > > Instead, make it a 'depends' and then that will make depending modules = (i.e. the > > SoC files) that want to be builtin force the core module to be builtin = too. Other > > modular configs that depend on the core will still be modular. > >=20 >=20 > It seems not work. > Patch 4 already changes it to depend on ARCH_MXC which can only be 'Y'. > [V2,4/9] clk: imx: Support building i.MX common clock driver as module > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig > index ded0643..678113b 100644 > --- a/drivers/clk/imx/Kconfig > +++ b/drivers/clk/imx/Kconfig > @@ -1,8 +1,8 @@=20 > # SPDX-License-Identifier: GPL-2.0 > # common clock support for NXP i.MX SoC family. > config MXC_CLK > - bool > - def_bool ARCH_MXC > + tristate "IMX clock" > + depends on ARCH_MXC >=20 > But user can still set MXC_CLK to be m, either via make menuconfig or def= config. Isn't that what we want? Why does ARCH_MXC being enabled mandate that it is builtin? Is some architecture level code calling into the clk driver?