Message-ID: <87jz3ptuk0.wl-tiwai@suse.de>
Date: Wed, 30 Jul 2025 20:14:39 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Takashi Iwai <tiwai@...e.de>,
	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 Wed, 30 Jul 2025 19:21:25 +0200,
Linus Torvalds wrote:
> 
> On Wed, 30 Jul 2025 at 09:50, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > 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".
> 
> Ahh. I looked closed - I should have done that earlier. It looks like
> this was just a split, not a rename like I thought earlier.
> 
> But a plain 'default y' is still the wrong thing to do because you do
> *not* want to enable this if people didn't have CODEC_HDMI enabled
> originally. So it would have to be a
> 
>         depends on SND_HDA_CODEC_HDMI
>         default y
> 
> But then you couldn't disable the generic code.
> 
> What *might* work is having both
> 
>         default SND_HDA_CODEC_HDMI
>         select SND_HDA_CODEC_HDMI
> 
> which looks confusing, but should mean that if SND_HDA_CODEC_HDMI was
> selected, the sub-option is on by default
> 
> It looks pretty iffy, honestly, but I _think_ i tworks.

Hm, it's also what I thought of, but rather avoided because it looks
too tricky.

But, if this is acceptable and preferred over default y, I can take
this approach, too.

> I do think that the right model is to keep the old name for the old
> functionality, and have a structure something like
> 
>   config SND_HDA_CODEC_HDMI
>         tristate "Enable all HD-audio HDMI drivers"
>         select SND_HDA_CODEC_HDMI_INTEL
>         select SND_HDA_CODEC_HDMI_...
> 
> And then the new common hdmi code should have a mew and *different*
> Kconfig option name that the sub-drivers select (so
> "SND_HDA_CODEC_HDMI_COMMON" or whatever).
> 
> on't re-use an old name for some new fucntionality, unless you've
> waited at least a full release or two for peoples kernel configs to
> have been refreshed to the new setup.
> 
> With *that* kind of structure, you get
> 
>  - people who didn't use to have this enabled still don't have it
> enabled by default, so "make oldconfig" does the right thing
> 
>  - people who did have  SND_HDA_CODEC_HDMI enabled see no difference:
> they still get all versions
> 
>  - you can now decide to disable SND_HDA_CODEC_HDMI, and then enable
> the sub-drivers individually
> 
> so that would seem to have full functionality, and avoids the
> confusion of having the that combination of "select" and "default".

Yeah, we had another splits in HDMI codecs and this was even more
incompatible with the previous kconfig.  I noticed too late and the
patch set I posted today tries to address it in addition to Realtek
codecs.

So, in the posted patch set (you're on Cc):

- CONFIG_SND_HDA_CODEC_REALTEK and CONFIG_SND_HDA_CODEC_HDMI are the
  top-level config to enable Realtek and HDMI codecs, and those can be
  carried from the previous config as is.

- Kconfigs for the new split drivers CONFIG_SND_HDA_CODEC_ALC* and
  CONFIG_SND_HDA_CODEC_HDMI_* are with default=y, so that they are
  picked up when *_REAKTEK or *_HDMI is chosen from the previous
  kconfig.  User may still disable each item individually.

At least, this will give equivalent functionalities when carrying from
the 6.16 kernel config on the 6.17 kernel.  The rest optimization is
left to users.

I'm fine to change in other way if there can be more reasonable way,
of course.  Let me know what you think.


Thanks!

Takashi

Powered by blists - more mailing lists