From: Jani Nikula <jani.nikula@linux.intel.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Dave Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Masahiro Yamada <masahiroy@kernel.org>,
linux-kbuild <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH 00/11] drm: Restore helper usability
Date: Mon, 22 Apr 2024 20:14:53 +0300 [thread overview]
Message-ID: <87ttjts4j6.fsf@intel.com> (raw)
In-Reply-To: <CAMuHMdXCL-gbKr6mUBPWONtRjz=X0vZQgiS=02WXXSFf67yBww@mail.gmail.com>
On Mon, 22 Apr 2024, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Arnd,
>
> CC kbuild
>
> On Mon, Apr 22, 2024 at 3:55 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> I'm not sure where this misunderstanding comes from, as you
>> seem to be repeating the same incorrect assumption about
>> how select works that Maxime wrote in his changelog. To clarify,
>> this works exactly as one would expect:
>>
>> config HELPER_A
>> tristate
>>
>> config HELPER_B
>> tristate
>> select HELPER_A
>>
>> config DRIVER
>> tristate "Turn on the driver and the helpers it uses"
>> select HELPER_B # this recursively selects HELPER_A
>>
>> Whereas this one is broken:
>>
>> config FEATURE_A
>> tristate "user visible if I2C is enabled"
>> depends on I2C
>>
>> config HELPER_B
>> tristate # hidden
>> select FEATURE_A
>>
>> config DRIVER
>> tristate "This driver is broken if I2C is disabled"
>> select HELPER_B
>
> So the DRIVER section should gain a "depends on I2C" statement.
Why should DRIVER have to care that HELPER_B needs either FEATURE_A or
I2C? It should only have to care about HELPER_B. And if the dependencies
of FEATURE_A or HELPER_B later change, that's their business, not
DRIVER's.
BR,
Jani.
>
> Yamada-san: would it be difficult to modify Kconfig to ignore symbols
> like DRIVER that select other symbols with unmet dependencies?
> Currently it already warns about that.
>
> Handling this implicitly (instead of the current explict "depends
> on") would have the disadvantage though: a user who is not aware of
> the implicit dependency may wonder why DRIVER is invisible in his
> config interface.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-04-22 17:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 10:30 [PATCH 00/11] drm: Restore helper usability Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 01/11] Revert "drm: fix DRM_DISPLAY_DP_HELPER dependencies, part 2" Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 02/11] Revert "drm/display: Select DRM_KMS_HELPER for DP helpers" Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 03/11] Revert "drm/bridge: dw-hdmi: Make DRM_DW_HDMI selectable" Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 04/11] Revert "drm: fix DRM_DISPLAY_DP_HELPER dependencies" Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 05/11] Revert "drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on" Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 06/11] Revert "drm: Switch DRM_DISPLAY_HDCP_HELPER " Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 07/11] Revert "drm: Switch DRM_DISPLAY_DP_HELPER " Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 08/11] Revert "drm: Switch DRM_DISPLAY_DP_AUX_BUS " Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 09/11] Revert "drm: Switch DRM_DISPLAY_HELPER " Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 10/11] Revert "drm: Make drivers depends on DRM_DW_HDMI" Geert Uytterhoeven
2024-04-22 10:30 ` [PATCH 11/11] Revert "drm/display: Make all helpers visible and switch to depends on" Geert Uytterhoeven
2024-04-22 11:50 ` [PATCH 00/11] drm: Restore helper usability Jani Nikula
2024-04-22 12:27 ` Dmitry Baryshkov
2024-04-22 12:30 ` Arnd Bergmann
2024-04-22 13:28 ` Jani Nikula
2024-04-22 13:54 ` Arnd Bergmann
2024-04-22 16:58 ` Geert Uytterhoeven
2024-04-22 17:14 ` Jani Nikula [this message]
2024-04-22 18:02 ` Geert Uytterhoeven
2024-04-22 18:23 ` Arnd Bergmann
2024-04-22 19:42 ` Masahiro Yamada
2024-04-22 20:46 ` Arnd Bergmann
2024-04-22 17:00 ` Jani Nikula
2024-04-22 18:11 ` Geert Uytterhoeven
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=87ttjts4j6.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=arnd@arndb.de \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert+renesas@glider.be \
--cc=geert@linux-m68k.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=masahiroy@kernel.org \
--cc=mripard@kernel.org \
--cc=tzimmermann@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.