Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp952901ybt; Wed, 24 Jun 2020 15:46:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/q9d3nuQcjPncKpN7N+/hWL6OHCcyaLvuVNy9Fa1irhpmI8jO4TPnU4Rrm7UOxBdaB33C X-Received: by 2002:a17:906:a01:: with SMTP id w1mr27585561ejf.197.1593038762045; Wed, 24 Jun 2020 15:46:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593038762; cv=none; d=google.com; s=arc-20160816; b=bGMpP8U+qNQ4irbsMAR+N2gg62mU4ZiSmztNtwDvqWIuIPlF98mf6uHkMPNy6kGSVf FAvckIl5WuOuMwc/vnXiSmMeBbs4mJaSn4+Qnsy46vr71TcvxXymPh1LC7bYTymvVxF6 SUviA1UUpA/uOGpS8OAaAHwq3Wo+vQ+OTZg86gAqtL9Ms1BiOpJBY4JoHgXl6tfjUjtg B/ukoe3Lr2riw7kDH+iJdJ4fAnt4R9NMfW2LTG7JWm1zea6nvxZXQBdtl8U0+ghM3gPM eQ9QdInXHOHS+1Ud4Tc6ph4MoFMQn921Pbn4A6Cd425OJ8zUnCgrGGoLLThpG+HfoDmm u62Q== 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=jF0RQ9rfpW70kXAdHcf2Ehy4A/Yzo1lxIp0pzLa3QqA=; b=KpftnH/LA22DDr8PXpDJKHU26wrvd0A6MQ4qgrME9R55jqvcTfSROqsNEqrp4I3Tva 0dzNldc/0TT0I+OnAEHkWV/dteViUaGN0Mhh4LYvKRaRTbMjgmTS5w3a8J3IBFzGZUOX DfBWH8qjknHGsZDLxNraV42NHkImCckyva6SbO3T2Im07mBuF5dG6RopY4mKtqkToiTe quMtPAlOKT6COghjEk1e0JaSbVGMZJdreBCZifEdwOBJEbCcxVrNoRpIcdgfHJOylIBw 8Gf1j511R+ahHBh4TkTS6l2MSahttij7OUhrbaJmjS6xFxl6tpXp5dtFTMToBxjoYvye l0ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=OBWcVFZP; 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 rs2si4135304ejb.140.2020.06.24.15.45.38; Wed, 24 Jun 2020 15:46:02 -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=OBWcVFZP; 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 S2389320AbgFXWnC (ORCPT + 99 others); Wed, 24 Jun 2020 18:43:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:39556 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388739AbgFXWnC (ORCPT ); Wed, 24 Jun 2020 18:43:02 -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 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= 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> <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 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: Wed, 24 Jun 2020 15:43:00 -0700 Message-ID: <159303858063.62212.4991053028281879719@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 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 dri= vers. > > > It just reuses ARCH config CONFIG_SOC_XXX which can only be y. > > > e.g. > > > obj-$(CONFIG_SOC_IMX6Q) +=3D clk-imx6q.o > > > obj-$(CONFIG_SOC_IMX6SL) +=3D clk-imx6sl.o > > > obj-$(CONFIG_SOC_IMX7ULP) +=3D clk-imx7ulp.o > > > obj-$(CONFIG_SOC_VF610) +=3D 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. > >=20 > > 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 exp= licitly > > 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? > >=20 >=20 > Yes, I'm trying to explain to Stephen why we have to select MXC_CLK in AR= CH_MXC > And what issues we will met if not select it. >=20 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.