From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "tony.luck@intel.com" <tony.luck@intel.com>,
        "bp@alien8.de" <bp@alien8.de>
CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mchehab@kernel.org" <mchehab@kernel.org>,
        "rjw@rjwysocki.net" <rjw@rjwysocki.net>,
        "srinivas.pandruvada@linux.intel.com" 
        <srinivas.pandruvada@linux.intel.com>,
        "lenb@kernel.org" <lenb@kernel.org>,
        "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
        "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Subject: Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac
Thread-Topic: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac
Thread-Index: AQHS/0lGOl4i5ss6QUSn88C0VF1rJqJZF6OAgAAj5gCAANq7AA==
Date: Tue, 18 Jul 2017 21:20:44 +0000
Message-ID: <1500412288.2042.25.camel@hpe.com>
References: <20170717215912.26070-1-toshi.kani@hpe.com>
         <20170717215912.26070-4-toshi.kani@hpe.com>
         <20170718060007.GB8736@nazgul.tnic> <20170718080836.GB8372@nazgul.tnic>
In-Reply-To: <20170718080836.GB8372@nazgul.tnic>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <CB5035F745810242941D2BE9915CB6E3@NAMPRD84.PROD.OUTLOOK.COM>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2017 21:20:44.3205
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0185
X-OriginatorOrg: hpe.com
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nfs id v6ILMU6L001173
Content-Length: 1418
Lines: 32

On Tue, 2017-07-18 at 10:08 +0200, Borislav Petkov wrote:
> On Tue, Jul 18, 2017 at 08:00:07AM +0200, Borislav Petkov wrote:
> > And I think we should try this first: have the firmware disable
> > detection methods so that the platform drivers don't load.
> 
> Btw, in looking at this more, what about the firmware-first thing?
> 
> I.e., the firmware-first detection with apei_osc_setup() at the end
> of ghes_init().
> 
> Can we make ghes_edac loading dependent on that? I mean, that was
> *the* predicate for exactly that - to have the firmware look at the
> errors first. No need for platform whitelisting and so on.

I agree that 'osc_sb_apei_support_acked' should be checked when
enabling ghes_edac.  I do not know the details of existing issues, but
it sounds unlikely that this will address all of them since bugs can be
everywhere.  For instance, ghes_edac relies on DMI/SMBIOS info, unlike
other EDAC drivers, which can be buggy regardless of this _OSC info.

> I'd still decouple ghes_edac loading from ghes_probe() even though
> loading the platform driver should've been done *after* the
> firmware-first detection regardless.
> 
> So what we could do is make ghes_edac a normal module and have the
> relevant x86 EDAC modules query FF mode and if enabled, fail loading.

I agree that making ghes_edac as a normal module is a good thing, but I
do not think it's going to solve this issue.

Thanks,
-Toshi