[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171115121648.jjbs4jdpjoyhkbqo@sirena.org.uk>
Date: Wed, 15 Nov 2017 12:16:48 +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 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.
> 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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists