From: Arnd Bergmann <email@example.com>
To: Masahiro Yamada <firstname.lastname@example.org>
Cc: Lee Jones <email@example.com>,
Greg Kroah-Hartman <firstname.lastname@example.org>,
Linux Kernel Mailing List <email@example.com>,
Linux ARM <firstname.lastname@example.org>,
Subject: Re: [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON'
Date: Mon, 26 Feb 2018 13:43:14 +0100 [thread overview]
Message-ID: <CAK8P3a3zMG4wV9SWg78NGmk=BU9yq5paxZvJ=coHCWxVgNhO2w@mail.gmail.com> (raw)
On Mon, Feb 26, 2018 at 12:53 PM, Masahiro Yamada
> 2018-02-26 17:43 GMT+09:00 Arnd Bergmann <email@example.com>:
>> On Sat, Feb 24, 2018 at 3:50 PM, Masahiro Yamada
>> <firstname.lastname@example.org> wrote:
>>> As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
>>> used with care - it forces a lower limit of another symbol, ignoring
>>> the dependency.
>>> MFD_SYSCON depends on HAS_IOMEM, but several drivers with COMPILE_TEST
>>> select it.
>>> This causes unmet dependencies for architecture without HAS_IOMEM.
>>> $ make ARCH=score randconfig
>>> scripts/kconfig/conf --randconfig Kconfig
>>> warning: (HWSPINLOCK_QCOM && AHCI_MTK && STMMAC_PLATFORM && ...)
>>> selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
>>> Use 'depends on' to observe the dependency.
>>> This commit was created by the following command:
>>> $ find drivers -name 'Kconfig*' | xargs sed -i -e \
>>> 's/select MFD_SYSCON$/depends on MFD_SYSCON/'
>>> Then, COMMON_CLK_NXP and S3C2410_WATCHDOG were fixed up manually.
>>> Also, make MFD_SYSCON 'default y' because some defconfig files may
>>> rely on someone select's MFD_SYSCON.
>>> Signed-off-by: Masahiro Yamada <email@example.com>
>>> If you have a better idea to fix 'unmet dependencies',
>>> please suggest.
>> Changing 'select MFD_SYSCON' to 'depends on' will definitely break lots
>> of defconfig configurations, I'd rather not do that.
> Could you explain why?
> I set 'default y' for MFD_SYSCON.
> Would it still break defconfig configurations?
No, you are right, that would not break defconfigs, it would just mean one
useless driver being enabled for many configurations that don't need it.
>> Only score, tile and um have some configurations that select 'NO_IOMEM'.
>> Score is getting removed now, tile might get removed later (we could make
>> PCI mandatory in the meantime to avoid that configuration), and I think for
>> um, we already have a workaround for the NO_IOMEM dependencies
>> (I forget the details).
> I do not think this is a stable solution.
> Or, do you mean to remove NO_IOMEM and HAS_IOMEM completely?
We could either leave it for arch/um only and have that deal with the
issues (which I think we already have), or we could remove the options
next prev parent reply other threads:[~2018-02-26 12:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-24 14:50 [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON' Masahiro Yamada
2018-02-25 12:13 ` Andy Shevchenko
2018-02-26 8:43 ` Arnd Bergmann
2018-02-26 11:53 ` Masahiro Yamada
2018-02-26 12:43 ` Arnd Bergmann [this message]
2018-02-27 0:46 ` Masahiro Yamada
2018-02-27 9:03 ` Arnd Bergmann
2018-02-27 10:22 ` Masahiro Yamada
2018-02-27 13:39 ` Arnd Bergmann
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).