linux-kernel - Re: [GIT PULL] sound updates for 6.17-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wgO0Rx2LcYT4f75Xs46orbJ4JxO2jbAFQnVKDYAjV5HeQ@mail.gmail.com>
Date: Wed, 30 Jul 2025 09:50:00 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: Mark Brown <broonie@...nel.org>, Liam Girdwood <lgirdwood@...il.com>, 
	Linux Sound Mailing List <linux-sound@...r.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] sound updates for 6.17-rc1

On Tue, 29 Jul 2025 at 22:51, Takashi Iwai <tiwai@...e.de> wrote:
>
> It's a dilemma of the default kconfig enablement.  In general we want
> to keep the default disabled for leaf drivers.

You misunderstand.

The problem is that you threw away all the old config data in the name
of "reorganizing".

And no, the answer is *not* "make everything enabled by default".  If
somebody has a working configuration for their setup, new subdrivers
shouldn't be enabled by "make oldconfig", because clearly those new
drivers aren't relevant.

So no - not "default y".

If you change the names of config variables or re-organize things some
other way - you need to accept the old configuration name as the
default.

And even then it's an absolute *nightmare* for any bisection, because
losing configuration ends up being very easy when going back and forth
if the person testing doesn't realize.

And yes, dealing with this makes name changes and Kconfig
reorganization more complex. And if that makes people go "that's too
complicated", then DON'T DO IT THEN.

Breaking peoples existing setup is bad. This is not quite a
regression, but it's a huge inconvenience.

My laptop is back to working - it turns out I only needed the addition
of SND_HDA_CODEC_HDMI_INTEL in addition to figuring out which realtek
codec got lost in this shuffle.

And *that* case should have been handled by making the newly split up
HDMI config variables be "default y". Because my *old* setup worked
because I had SND_HDA_CODEC_HDMI enabled, and that enabled everything.

The new setup didn't work, because I still had SND_HDA_CODEC_HDMI
enabled, but the newly introduced sub-config variables weren't enabled
by "make oldconfig".

So that

  config SND_HDA_CODEC_HDMI_INTEL
         tristate "Intel HDMI/DisplayPort HD-audio codec support"
         select SND_HDA_CODEC_HDMI

is wrong, because it *should* have been done something like

        depends on SND_HDA_CODEC_HDMI
        default y
        select SND_HDA_CODEC_HDMI_COMMON

so that *if* people have SND_HDA_CODEC_HDMI from their old config, the
new "oh, that old name used to select everything, so now we obviously
need to make it 'default y' in the new world order".

And the "select SND_HDA_CODEC_HDMI" doesn't work in that setup, so
what you need to have is a different name for the "I want to select
the common support that the intel HDMI code needs".

End result: don't re-organize Kconfig stuff unless you are willing to
deal with this kind of detail. Because as it was done, it was BADLY
done.

               Linus