From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753388AbcASM3x (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 Jan 2016 07:29:53 -0500
Received: from unicorn.mansr.com ([81.2.72.234]:46721 "EHLO unicorn.mansr.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752161AbcASM3w convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 Jan 2016 07:29:52 -0500
From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@suse.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Michal Marek <mmarek@suse.cz>,
        Markus Trippelsdorf <markus@trippelsdorf.de>,
        Thomas Voegtle <tv@lio96.de>, linux-kernel@vger.kernel.org,
        x86-ml <x86@kernel.org>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Thomas Gleixner <tglx@linutronix.de>, Jiri Olsa <jolsa@redhat.com>,
        Arnaldo Carvalho de Melo <acme@infradead.org>,
        =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker <fweisbec@gmail.com>
Subject: Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y
References: <20160108122719.GG14673@pd.tnic> <568FB028.1030706@suse.cz>
	<20160108133725.GH14673@pd.tnic> <568FCC45.1010301@suse.cz>
	<20160111194311.GF4686@pd.tnic> <yw1x4mejx3le.fsf@unicorn.mansr.com>
	<20160111205945.GH4686@pd.tnic> <yw1xziwbvnde.fsf@unicorn.mansr.com>
	<20160111211712.GI4686@pd.tnic> <20160114184350.GB12109@pd.tnic>
	<20160119082022.GB18237@gmail.com>
Date: Tue, 19 Jan 2016 12:29:48 +0000
In-Reply-To: <20160119082022.GB18237@gmail.com> (Ingo Molnar's message of
	"Tue, 19 Jan 2016 09:20:22 +0100")
Message-ID: <yw1xbn8hsqf7.fsf@unicorn.mansr.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Ingo Molnar <mingo@kernel.org> writes:

> So can we do something more intelligent instead, such as modifying the
> Kconfigs in a way that it's not possible to have CONFIG_MICROCODE
> enabled while BLK_DEV_INITRD is disabled?

The problem with *any* approach involving Kconfig is that it still
leaves users free to load microcode whenever they want, even if they're
not supposed to.  Doing so apparently works correctly (almost) every
time (how does it fail if it does?), and no warnings are issued to
suggest it might be a bad idea.  Force-enabling BLK_DEV_INITRD isn't
going to make anyone change their boot scripts.  Many might not even
notice that it got silently enabled. So what purpose does it serve to
play games with the config when it has no actual impact on the usage of
the driver?

I'd also like to get a coherent answer to why microcode update is
preferably done from an initrd as opposed to shortly after mounting a
regular disk.  My systems seem perfectly happy doing the latter.

-- 
Måns Rullgård