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

[Takashi Iwai <tiwai@suse.de>]

On Wed, 15 Nov 2017 14:33:05 +0100,
Mark Brown wrote:
> 
> On Wed, Nov 15, 2017 at 02:16:41PM +0100, Takashi Iwai wrote:
> > Mark Brown wrote:
> 
> > > 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
> 
> Right, just finding what you need to enable to enable a given option.
> 
> > representations would be suitable, and the usual solution is the
> > firmer, to expose *only* individual machine drivers as selectable.
> 
> It's definitely the most conservative thing to do, unless someone has a
> strong reason to do something else I'd probably go that way.
> 
> > (Or, at most, we can have kconfig entries just filtering in addition.)
> 
> Yes, that'd not be quite so bad but it's still adding to the set of
> things you have to grind through to find the option you want.

Right, but these filters are usually with default=y, so at the first
invocation, it can go easy.  The filter config is useful basically for
someone who feel annoyed by too many options appearing, then they can
turn this off explicitly.


Takashi