Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3159106ybb; Mon, 13 Apr 2020 01:53:50 -0700 (PDT) X-Google-Smtp-Source: APiQypJV391XDbfpzJpf2CyIARiED6AbpiiWiI76HCLYdDadmjQHOXLbxqfIcKUmjy0HDfxsTUAX X-Received: by 2002:a05:6402:1bc7:: with SMTP id ch7mr6569019edb.224.1586768029998; Mon, 13 Apr 2020 01:53:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586768029; cv=none; d=google.com; s=arc-20160816; b=zKJ6w6++h3FalVJoUvuyjzYO0EAd02jvGysblDNI8jtGLHT8isdFoQK9KEyUVoXoLM 6RU7q8Jky6eTm/jad8TEDbRg1Q+RE77wfE67DtfHLCx5moEj0rpvf4dci+6z/3OKjlqH 0NZxUguvTYiUJdl9Iy/MwT9Ip7KudOOVseIjpePooaToBklGTyABPDaD/iQVZodRbWKk uT/2ETfbXqqy4o/Sd7ef96pQ0BiGoVa6Do1TdwglU7MajU00cLMoXvZcow8bxvleWmpV 0TQNNihX0NPKkmpEKbgTn7GgXYdWUvpFiFDhdWXeKDMA8I/Xs4XeZ6MBd4V6IoktqpNb qyIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hOqxL66FbwiBOL3LXXwgTnGg5mLB+6JiHF9fkHXdoqk=; b=l82UdBNfwwFeEpliYzgq7Kwnz/Te9gQ1eBFyhGv7KrGEAJ46WZX6dpRs+se+WaNDhh gOcTuRPxWuTUWKs95PuWSwLkeajmKHAEyG9LQ5QeGO43QbllR4MwYpA32ZhTqb+dXN0o xJHaOLum20bbMuRh8FTZkBR+HJymjCK3J8LBSPh8oBEyX8mxOb82GRDn46+vXi9LPO1O mhKQmeDHD6x3TWNOFBBYw4MxvTPEfnaASb0YHy+5Io/0brHWUhFgELtMxeOn2n5ss3Ym oO6EXIqHaZgnTNT6F5qJbJjN/YzroEDxTfgAg5O2xV19QyfBshxPXbqRgazoElt2yXGT NLIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eHdueZ7z; spf=pass (google.com: best guess record for 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x25si1178331ejs.434.2020.04.13.01.53.26; Mon, 13 Apr 2020 01:53:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for 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=@gmail.com header.s=20161025 header.b=eHdueZ7z; spf=pass (google.com: best guess record for 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728620AbgDMDsM (ORCPT + 99 others); Sun, 12 Apr 2020 23:48:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.18]:53424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727513AbgDMDsM (ORCPT ); Sun, 12 Apr 2020 23:48:12 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6942EC0A3BE0; Sun, 12 Apr 2020 20:48:12 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id a201so8397209wme.1; Sun, 12 Apr 2020 20:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hOqxL66FbwiBOL3LXXwgTnGg5mLB+6JiHF9fkHXdoqk=; b=eHdueZ7zFdz+7TXQqL4OoHrQ7V9wb5fcGX8I25YHfG809MzEvvbGSoSEdNSX6H8zFH AVWDCCjYr2GRJ9+p6jm1Jk21Rn/hhBauiTSnYYja62zzwXa70l5vRnwzdhmoW9lsKS9y lSRxHU3ZOlx+o/uyXS8yQIKfE82mXM1P93rEnr0hvLmMGgdzFU3tMIXuE0QAHHaEKxV2 2J1EkElbvYGA+i4IQz8XdaTRhUJwZkAgokdfL/qFq2Uskqo9jrHOMEemtxLMI3Q9YJxS fUKT6k/BYYehjZ2hK61znbKtb5T9pFyX6LoVj/Ad2s8qFsDMWeqlIgbKKSX6krRUTXnY RtlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hOqxL66FbwiBOL3LXXwgTnGg5mLB+6JiHF9fkHXdoqk=; b=BNBHDkg5v7s0iuc7Yy2qFuN0CWqcAbgqQ15/pAx5aYNKbgw+i26juI9LBxuXx/uEgG PV2M8BMPu2FoyNCnHicklLCEHyf2B9NJni2yeejeWy2dRiWCEb5MjtRaTbbowEWwQAQf jfVBkQrBVeNf9UvgufcR2thZIibodpikB1lB8VsxUMxuV9ktlf/RXPGJpImF7DlhRtem OwHmfK8V7zQUy1RJlvPQ3ZeS/gglBN1oSC9jAwlvbmieB2KTdvoR8xZ+/uRfUeb3kmmW xOLK7KYvzd9m0hMbtJFtAl4SKa2h9ZbBql7WYNinISx39lpq/jPSuBArSIzwCfnCFIb5 h+6g== X-Gm-Message-State: AGi0PuYG2EDA1kW42ATirET9bDO2CjQ3Q/8ukFFR5srW/QHn0Crmk3sh xpcgWPFMkMNuMA58ux8Hh3cjRPRTLLk1Lg0SXyg= X-Received: by 2002:a1c:3b0a:: with SMTP id i10mr16241410wma.26.1586749691152; Sun, 12 Apr 2020 20:48:11 -0700 (PDT) MIME-Version: 1.0 References: <20200408160044.2550437-1-arnd@arndb.de> <158657204622.199533.16589832598336244320@swboyd.mtv.corp.google.com> In-Reply-To: <158657204622.199533.16589832598336244320@swboyd.mtv.corp.google.com> From: Chunyan Zhang Date: Mon, 13 Apr 2020 11:47:35 +0800 Message-ID: Subject: Re: [PATCH] [RFC] clk: sprd: fix compile-testing To: Stephen Boyd Cc: Sandeep Patil , Arnd Bergmann , Catalin Marinas , Will Deacon , Michael Turquette , Chunyan Zhang , Greg Kroah-Hartman , Linux ARM , LKML , linux-clk , Orson Zhai , Android Kernel Team Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 11 Apr 2020 at 10:27, Stephen Boyd wrote: > > Quoting Chunyan Zhang (2020-04-09 20:45:16) > > We see this broken because I shouldn't leave clk Makefile a tristate > > compile [1] after changing ARCH_SPRD to be tristate. > > > > If we will make ARCH_SPRD tristate-able in the future and you all > > aggree that, I would like to do it now, and pay more attention to > > Makefiles and dependencies. > > > > I can also make a change like below: > > > > diff --git a/drivers/clk/sprd/Kconfig b/drivers/clk/sprd/Kconfig > > index e18c80fbe804..9f7d9d8899a5 100644 > > --- a/drivers/clk/sprd/Kconfig > > +++ b/drivers/clk/sprd/Kconfig > > @@ -2,6 +2,7 @@ > > config SPRD_COMMON_CLK > > tristate "Clock support for Spreadtrum SoCs" > > depends on ARCH_SPRD || COMPILE_TEST > > + depends on m || ARCH_SPRD != m > > default ARCH_SPRD > > select REGMAP_MMIO > > > > Arnd, Stephen, Sandeep, what do you think? Does that make sense? > > Sorry, doesn't make any sense to me. The ARCH_FOO configs for various > platforms are intended to be used to limit the configuration space of > various other Kconfig symbols for the code that only matters to those > platforms. The usage of depends and default is correct here already. The > ARCH_FOO configs should always be bool. Any code bloat problems seen by > config symbols enabling because they're 'default ARCH_FOO' can be > resolved by explicitly disabling those configs. Ok - alright, please feel free to merge Arnd's patch then. Thanks, Chunyan