[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171115133305.vh6cszha753spc2j@sirena.org.uk>
Date: Wed, 15 Nov 2017 13:33:05 +0000
From: Mark Brown <broonie@...nel.org>
To: Takashi Iwai <tiwai@...e.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Vinod Koul <vinod.koul@...el.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
alsa-devel@...a-project.org
Subject: Re: [GIT PULL] sound updates for 4.15-rc1
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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists