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 S1751089AbdAQJIb (ORCPT <rfc822;w@1wt.eu>);
        Tue, 17 Jan 2017 04:08:31 -0500
Received: from mail.skyhub.de ([78.46.96.112]:47708 "EHLO mail.skyhub.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750863AbdAQJI2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 17 Jan 2017 04:08:28 -0500
Date: Tue, 17 Jan 2017 10:08:14 +0100
From: Borislav Petkov <bp@alien8.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>, linux-kernel@vger.kernel.org,
        Tony Luck <tony.luck@intel.com>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
        linux-edac@vger.kernel.org
Subject: Re: [PATCH] x86/mce: Fix initialization error warning
Message-ID: <20170117090814.o6ur3d5dbeyqlqds@pd.tnic>
References: <1484603381-15018-1-git-send-email-prarit@redhat.com>
 <20170116215612.f22reezt77nydsp5@pd.tnic>
 <587D43CA.5020609@redhat.com>
 <20170116224316.bhnr4goijsh6h76o@pd.tnic>
 <587D53A3.1010305@redhat.com>
 <20170116233206.4fouuampih5ejvtb@pd.tnic>
 <alpine.DEB.2.20.1701170931100.3495@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1701170931100.3495@nanos>
User-Agent: NeoMutt/20161014 (1.7.1)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jan 17, 2017 at 09:34:18AM +0100, Thomas Gleixner wrote:
> That's one thing, but OTOH we really can avoid the KERN_ERR level print out
> for the case where mce is not available (for whatever reasons: HW / Virt /
> command line ....).
> 
> The simple 2 liner I posted earlier in this thread does it nicely.

Well, I seem to remember at the time of this:

  9c15a24b038f ("x86/mce: Improve mcheck_init_device() error handling")

that I requested to have that error message there so that we *know* when
that function fails instead of trying to decipher "Hey, mcelog doesn't
start here" and wonder why.

But we can kill it just as well, especially as there's patch deprecating
/dev/mcelog floating around. We can reorg error messages in that
function later, if deemed necessary.

So sure.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.