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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 6C3A3C4338F for ; Mon, 16 Aug 2021 14:47:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1315B601FA for ; Mon, 16 Aug 2021 14:47:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1315B601FA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 8DBB98D0002; Mon, 16 Aug 2021 10:47:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 864E18D0001; Mon, 16 Aug 2021 10:47:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 72CBD8D0002; Mon, 16 Aug 2021 10:47:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 56A318D0001 for ; Mon, 16 Aug 2021 10:47:26 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E2A521A4C1 for ; Mon, 16 Aug 2021 14:47:25 +0000 (UTC) X-FDA: 78481222050.38.9C370DE Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf14.hostedemail.com (Postfix) with ESMTP id 799C6600F2DE for ; Mon, 16 Aug 2021 14:47:25 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E15726D; Mon, 16 Aug 2021 07:47:24 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9E34F3F66F; Mon, 16 Aug 2021 07:47:23 -0700 (PDT) Date: Mon, 16 Aug 2021 15:47:21 +0100 From: Cristian Marussi To: Arnd Bergmann Cc: kbuild test robot , igor.skalkin@opensynergy.com, kbuild-all@lists.01.org, Linux-MM , Sudeep Holla , peter.hilber@opensynergy.com Subject: Re: [PATCH] firmware: arm_scmi: Fix virtio transport Kconfig dependency Message-ID: <20210816144721.GA6592@e120937-lin> References: <20210816141609.41751-1-cristian.marussi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of cristian.marussi@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=cristian.marussi@arm.com; dmarc=pass (policy=none) header.from=arm.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 799C6600F2DE X-Stat-Signature: jdqy6pi5kmw4dpueg1s9wxj3ft5y44fq X-HE-Tag: 1629125245-708312 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Aug 16, 2021 at 04:30:10PM +0200, Arnd Bergmann wrote: > On Mon, Aug 16, 2021 at 4:16 PM Cristian Marussi > wrote: > > > > ARM_SCMI_TRANSPORT_VIRTIO is a 'bool' Kconfig used to include support for > > the SCMI virtio transport inside the core SCMI stack; a bare transport > > dependency attached here to this option, though, cannot be properly > > propagated to the parent ARM_SCMI_PROTOCOL option and, as a result, it is > > currently possible to configure a Kernel where SCMI core is builtin > > and includes support for virtio while VirtIO core is =m. > > This allowed combination breaks linking: > > > > ARM_SCMI_PROTOCOL=y > > ARM_SCMI_TRANSPORT_VIRTIO=y > > VIRTIO=m > > > > Bind the dependency in ARM_SCMI_TRANSPORT_VIRTIO to the chosen kind of > > compilation of ARM_SCMI_PROTOCOL. > > > > Reported-by: kernel test robot > > Suggested-by: Arnd Bergmann > > Signed-off-by: Cristian Marussi > Hi, > The description looks good > > Acked-by: Arnd Bergmann > > > @@ -68,7 +68,7 @@ config ARM_SCMI_TRANSPORT_SMC > > > > config ARM_SCMI_TRANSPORT_VIRTIO > > bool "SCMI transport based on VirtIO" > > - depends on VIRTIO > > + depends on VIRTIO=y || VIRTIO=ARM_SCMI_PROTOCOL > > select ARM_SCMI_HAVE_TRANSPORT > > select ARM_SCMI_HAVE_MSG > > Looking at this again, I noticed that this still needs the explicit > 'depends on VIRTIO' line you removed, otherwise the prompt > pops up when both VIRTIO and ARM_SCMI_PROTOCOL > are disabled. I checked this (VIRTIO=n with ARM_SCMI_PROTOCOL=n) and ARM_SCMI_TRANSPORT_VIRTIO menu does not popup because the whole menuconfig section under ARM_SCMI_PROTOCOL is already guarded by: if ARM_SCMI_PROTOCOL config ARM_SCMI_TRANSPORT_VIRTIO ... endif ...if this was what you meant. Thanks, Cristian From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4182346613493036567==" MIME-Version: 1.0 From: Cristian Marussi To: kbuild-all@lists.01.org Subject: Re: [PATCH] firmware: arm_scmi: Fix virtio transport Kconfig dependency Date: Mon, 16 Aug 2021 15:47:21 +0100 Message-ID: <20210816144721.GA6592@e120937-lin> In-Reply-To: List-Id: --===============4182346613493036567== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Aug 16, 2021 at 04:30:10PM +0200, Arnd Bergmann wrote: > On Mon, Aug 16, 2021 at 4:16 PM Cristian Marussi > wrote: > > > > ARM_SCMI_TRANSPORT_VIRTIO is a 'bool' Kconfig used to include support f= or > > the SCMI virtio transport inside the core SCMI stack; a bare transport > > dependency attached here to this option, though, cannot be properly > > propagated to the parent ARM_SCMI_PROTOCOL option and, as a result, it = is > > currently possible to configure a Kernel where SCMI core is builtin > > and includes support for virtio while VirtIO core is =3Dm. > > This allowed combination breaks linking: > > > > ARM_SCMI_PROTOCOL=3Dy > > ARM_SCMI_TRANSPORT_VIRTIO=3Dy > > VIRTIO=3Dm > > > > Bind the dependency in ARM_SCMI_TRANSPORT_VIRTIO to the chosen kind of > > compilation of ARM_SCMI_PROTOCOL. > > > > Reported-by: kernel test robot > > Suggested-by: Arnd Bergmann > > Signed-off-by: Cristian Marussi > = Hi, > The description looks good > = > Acked-by: Arnd Bergmann > = > > @@ -68,7 +68,7 @@ config ARM_SCMI_TRANSPORT_SMC > > > > config ARM_SCMI_TRANSPORT_VIRTIO > > bool "SCMI transport based on VirtIO" > > - depends on VIRTIO > > + depends on VIRTIO=3Dy || VIRTIO=3DARM_SCMI_PROTOCOL > > select ARM_SCMI_HAVE_TRANSPORT > > select ARM_SCMI_HAVE_MSG > = > Looking at this again, I noticed that this still needs the explicit > 'depends on VIRTIO' line you removed, otherwise the prompt > pops up when both VIRTIO and ARM_SCMI_PROTOCOL > are disabled. I checked this (VIRTIO=3Dn with ARM_SCMI_PROTOCOL=3Dn) and ARM_SCMI_TRANSPORT_VIRTIO menu does not popup because the whole menuconfig section under ARM_SCMI_PROTOCOL is already guarded by: if ARM_SCMI_PROTOCOL config ARM_SCMI_TRANSPORT_VIRTIO ... endif ...if this was what you meant. Thanks, Cristian --===============4182346613493036567==--