From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6AC90C433E0 for ; Wed, 24 Jun 2020 22:44:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 34E4D2065D for ; Wed, 24 Jun 2020 22:44:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="lNiyrlYJ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="OBWcVFZP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 34E4D2065D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:Date:To:From:Subject:References: In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YkRDufEDrCCuapn5n2j+fkDdE0gXYIRrvRK8RvlLmTQ=; b=lNiyrlYJHH+mv7bTeTwCHPBTM rhBC1ynEjbv5YAJRKc4Y3M7/jXDhhH7Q9pHhLGLaqRxIhhvSThrLZrKYgvdn8pH2WFg44y4TxUZvG IHg9S7XcX65JmdYrwf8maHV3OkvCpUYBeF98oT33MPxT25H0k+/SOoBKgaWuadtJeQAFAxM7GlhSG KX4j1/1HjfHgGJCj6/QUIpAPPduBw4OFb7uK7DpCiFp0pBAWizKwYfYylx/PRYZIa+CH34hjQVI3x CmL5jH/i+ZYr+St8P7HoHMtGftGuV9lTeqsKF7qIiJuLD2R/i9JS6R8gAcZyuZvMg34DjjrVb0rYc RP9vGvIkw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1joE6h-00046H-Vz; Wed, 24 Jun 2020 22:43:04 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1joE6g-00045f-63 for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 22:43:02 +0000 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 5525B2065D; Wed, 24 Jun 2020 22:43:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593038581; bh=2qOOeWqSin4Sk3mrQE3OE4Gaj5+C3lnfNsT9FLEUq/E=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=OBWcVFZPJiUQ9b5nibHZITiKfn6+sO64TqaXwuDA90blUrv/FDKp3H6wMBuulQUWz 4Q1WxhUQXtHBL8N+ymTa4sHwjQAtVXp89l1zDRjWXmK9hyKAQf5Tp/KEqBh/kPd587 TJzapj4PsMh1XZg10Onm+pWiLhUxEFGacnQZDyzA= MIME-Version: 1.0 In-Reply-To: References: <1591687933-19495-1-git-send-email-Anson.Huang@nxp.com> <159262367025.62212.11651547971712516448@swboyd.mtv.corp.google.com> <159290125202.62212.13172213909023205615@swboyd.mtv.corp.google.com> <159296027133.62212.18074403520585879907@swboyd.mtv.corp.google.com> Subject: RE: [PATCH V2 3/9] clk: imx: Support building SCU clock driver as module From: Stephen Boyd 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: Wed, 24 Jun 2020 15:43:00 -0700 Message-ID: <159303858063.62212.4991053028281879719@swboyd.mtv.corp.google.com> User-Agent: alot/0.9 X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dl-linux-imx Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Quoting Aisheng Dong (2020-06-23 19:59:09) > > > > > - bool > > > > > - def_bool ARCH_MXC > > > > > + tristate "IMX clock" > > > > > + depends on ARCH_MXC > > > > > > > > > > But user can still set MXC_CLK to be m, either via make menuconfig > > > > > or > > > > defconfig. > > > > > > > > Isn't that what we want? > > > > > > No, if user set MXC_CLK to m, the build will break for i.MX6&7. > > > > > > > Why does ARCH_MXC being enabled mandate that it is builtin? Is some > > > > architecture level code calling into the clk driver? > > > > > > > > > It's mainly because there's no Kconfig options for i.MX6 &7 clock drivers. > > > It just reuses ARCH config CONFIG_SOC_XXX which can only be y. > > > e.g. > > > obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o > > > obj-$(CONFIG_SOC_IMX6SL) += clk-imx6sl.o > > > obj-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o > > > obj-$(CONFIG_SOC_VF610) += clk-vf610.o .. > > > > > > If setting MXC_CLK to m, the platform clock drivers will fail to build > > > due to miss to find symbols defined in the common clock library by > > > CONFIG_MXC_CLK. > > > So we have to avoid users to be able to config MXC_CLK to m for i.MX6&7. > > > Only depends on ARCH_MXC mean user still can set it to m. > > > > I think for i.MX6/7, although MXC_CLK is tristate, but it is selected by > > ARCH_MXC which is always "y", so MXC_CLK can ONLY be "y" even it is explicitly > > set to "m" in imx_v6_v7_defconfig file. So that means MXC_CLK can ONLY > > support built-in for i.MX6/7 SoCs, and that is what we want? > > > > Yes, I'm trying to explain to Stephen why we have to select MXC_CLK in ARCH_MXC > And what issues we will met if not select it. > Why aren't there options to enable clk-imx6q and clk-imx6sl in the clk/imx/Kconfig file? Those can be bool or tristate depending on if the SoC drivers use CLK_OF_DECLARE or not and depend on the mxc-clk library and SoC config we have in the makefile today. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel