From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752724AbcBXL2v (ORCPT ); Wed, 24 Feb 2016 06:28:51 -0500 Received: from mail.skyhub.de ([78.46.96.112]:45222 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750931AbcBXL2t (ORCPT ); Wed, 24 Feb 2016 06:28:49 -0500 Date: Wed, 24 Feb 2016 12:28:47 +0100 From: Borislav Petkov To: Aravind Gopalakrishnan Cc: tony.luck@intel.com, hpa@zytor.com, mingo@redhat.com, tglx@linutronix.de, dougthompson@xmission.com, mchehab@osg.samsung.com, x86@kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, ashok.raj@intel.com, gong.chen@linux.intel.com, len.brown@intel.com, peterz@infradead.org, ak@linux.intel.com, alexander.shishkin@linux.intel.com Subject: Re: [PATCH 1/4] EDAC, MCE, AMD: Enable error decoding of Scalable MCA errors Message-ID: <20160224112846.GA3888@pd.tnic> References: <1455659111-32074-1-git-send-email-Aravind.Gopalakrishnan@amd.com> <1455659111-32074-2-git-send-email-Aravind.Gopalakrishnan@amd.com> <20160223123744.GC3673@pd.tnic> <56CCE23D.6080802@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56CCE23D.6080802@amd.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 23, 2016 at 04:50:37PM -0600, Aravind Gopalakrishnan wrote: > Sorry about that. Looks like this pair is not defined in spelling.txt. So, > might be worth adding there as well? Oh geez, we have a spelling.txt! I think we can declare the kernel as done and go do something else with our lives... > It's the block for programming FUSE registers. Oh, that's what it is. So maybe "fuses block" or "fuses" or ... just the capitalized "FUSE" is kinda misleading. > How about "Unable to gather IP block that threw the error. Therefore cannot > decode errors further.\n" Or simply "Invalid IP block specified, error information is unreliable." and still continue decoding. It might still be recognizable from the signature, methinks. > If for some reason the CPUID bit is not set, then we should not assume the > processor supports the features right? Is that even remotely possible? If yes, then we should keep the warning, otherwise it is useless. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.