Re: [GIT PULL] sound updates for 4.15-rc1

[Takashi Iwai <tiwai@suse.de>]

On Wed, 15 Nov 2017 13:16:48 +0100,
Mark Brown wrote:
> 
> On Wed, Nov 15, 2017 at 12:58:40PM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
> > > On Wed, Nov 15, 2017 at 08:34:09AM +0100, Takashi Iwai wrote:
> 
> > > Though transitioning back would probably just create more misery.
> > > It's a real shame that ACPI doesn't have standards for the machine
> > > descriptions here like DT does, it'd cut down on the amount of stuff
> > > that needs configuring.
> 
> > True.  Although I don't think ACPI is the center of the mess in this
> > case, but rather too many kconfigs is it.
> 
> It's the source of all the individual board Kconfigs - we can't just
> have an equivalent of the of-graph card - and then the explosion of
> board configs then pushes to have more of the other options user
> selectable to let people make the list more manageable.  

OK, point taken.

> > We should begin with thinking of which entries (and layer) to be
> > selectable, and which not.
> 
> I'd say either just all the individual machines like it was or all the
> SoCs.  If it's the SoCs it prevents people making really tiny configs,
> though I'm not sure who cares.  If it's the machines then you get a lot
> of options but I don't know that this is a problem, it's not like end
> users are routinely configuring their kernel.

It might sound contradicting to my previous statement, but the number
of selections itself isn't a big problem.  The problem is rather that
multiple options have to be selected for reaching to the point to
enable one feature on your machine.  So, I agree that these two
representations would be suitable, and the usual solution is the
firmer, to expose *only* individual machine drivers as selectable.
(Or, at most, we can have kconfig entries just filtering in addition.)


Takashi