From: Arnd Bergmann <arnd@kernel.org>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: kernel test robot <lkp@intel.com>,
Igor Skalkin <igor.skalkin@opensynergy.com>,
kbuild-all@lists.01.org,
Linux Memory Management List <linux-mm@kvack.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Peter Hilber <peter.hilber@opensynergy.com>
Subject: Re: [linux-next:master 5053/7963] virtio.c:undefined reference to `virtio_check_driver_offered_feature'
Date: Mon, 16 Aug 2021 14:11:19 +0200 [thread overview]
Message-ID: <CAK8P3a0mU3kzUA-MYoWSY_8ot5Gi4qJfo4gqW+JHZWsTZxfSBw@mail.gmail.com> (raw)
In-Reply-To: <20210816102209.GY6592@e120937-lin>
On Mon, Aug 16, 2021 at 12:22 PM Cristian Marussi
<cristian.marussi@arm.com> wrote:
> On Sun, Aug 15, 2021 at 12:54:38PM +0800, kernel test robot wrote:
>
> diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig
> index 7f4d2435503b..daa349615e91 100644
> --- a/drivers/firmware/arm_scmi/Kconfig
> +++ b/drivers/firmware/arm_scmi/Kconfig
> @@ -4,6 +4,7 @@ menu "ARM System Control and Management Interface Protocol"
> config ARM_SCMI_PROTOCOL
> tristate "ARM System Control and Management Interface (SCMI) Message Protocol"
> depends on ARM || ARM64 || COMPILE_TEST
> + select VIRTIO if ARM_SCMI_TRANSPORT_VIRTIO
> help
> ARM System Control and Management Interface (SCMI) protocol is a
> set of operating system-independent software interfaces that are
> @@ -68,7 +69,6 @@ config ARM_SCMI_TRANSPORT_SMC
>
> config ARM_SCMI_TRANSPORT_VIRTIO
> bool "SCMI transport based on VirtIO"
> - depends on VIRTIO
> select ARM_SCMI_HAVE_TRANSPORT
> select ARM_SCMI_HAVE_MSG
> help
Generally speaking it's bad to have both 'select' and 'depends on' for
drivers using
the same subsystem. This can lead to both circular dependencies, and to general
confusion when users are surprised by this.
My recommendation is to stick with 'depends on' in general, as that is usually
what you want. In this case, there are two things you could do that work better
to solve this problem:
a) add 'depends on VIRTIO || !VIRTIO' under ARM_SCMI_PROTOCOL, to prevent
it from being built-in when virtio is a loadable module
b) change the dependency in ARM_SCMI_TRANSPORT_VIRTIO to list the
correct thing, as in 'depends on VIRTIO=y || VIRTIO=ARM_SCMI_PROTOCOL'.
I don't have a strong preference between those two, as neither of them is
perfect: either you and up not seeing the virtio transport option, or you force
ARM_SCMI_PROTOCOL to be non-built-in when virtio is a module even
when the virtio transport is disabled.
Arnd
next prev parent reply other threads:[~2021-08-16 12:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-15 4:54 kernel test robot
2021-08-16 10:22 ` Cristian Marussi
2021-08-16 12:11 ` Arnd Bergmann [this message]
2021-08-16 13:05 ` Cristian Marussi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK8P3a0mU3kzUA-MYoWSY_8ot5Gi4qJfo4gqW+JHZWsTZxfSBw@mail.gmail.com \
--to=arnd@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=igor.skalkin@opensynergy.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=peter.hilber@opensynergy.com \
--cc=sudeep.holla@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox