From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "bp@alien8.de" <bp@alien8.de>
CC: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
        "lenb@kernel.org" <lenb@kernel.org>,
        "mchehab@kernel.org" <mchehab@kernel.org>,
        "tony.luck@intel.com" <tony.luck@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "rjw@rjwysocki.net" <rjw@rjwysocki.net>,
        "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()
Thread-Topic: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()
Thread-Index: AQHTDKTuWyxK/OMe00e0Ovda8CeGBqJzlIKAgAEZcQCAAIyugIAD9yeAgAW2iQCABSfDgIAACkUAgAAEFwCAAAdxAIAACkmAgAAGWwCAAAC7gIAAB8WAgAAEpwCAAAu+AIAACWYAgAAIzwCAATq3AIAABq0AgAAFnYA=
Date: Tue, 15 Aug 2017 16:19:50 +0000
Message-ID: <1502813405.2042.153.camel@hpe.com>
References: <20170814170552.j3lhzvnwlpz75y4g@pd.tnic>
         <1502732561.2042.141.camel@hpe.com>
         <20170814180526.wtfjzgc6uye2qtx6@pd.tnic>
         <1502734083.2042.143.camel@hpe.com>
         <20170814183551.sgk2i7lxpmpyodhv@pd.tnic>
         <1502736750.2042.145.camel@hpe.com>
         <20170814193432.mjldfhfal5ba5dt7@pd.tnic>
         <1502741290.2042.147.camel@hpe.com>
         <20170814203942.6t3mrq3hc324blab@pd.tnic>
         <1502810766.2042.149.camel@hpe.com>
         <20170815155000.d57hwki5jbixjuj6@pd.tnic>
In-Reply-To: <20170815155000.d57hwki5jbixjuj6@pd.tnic>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <33DFDD5BF152414397A3860B5E1D21D8@NAMPRD84.PROD.OUTLOOK.COM>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 16:19:50.2126
 (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 v7FGK4aN000422
Content-Length: 1447
Lines: 36

On Tue, 2017-08-15 at 17:50 +0200, Borislav Petkov wrote:
> On Tue, Aug 15, 2017 at 03:35:51PM +0000, Kani, Toshimitsu wrote:
> > ghes_edac instantiates an mci as a pseudo device representing a
> > GHES error source.  Each error source associates with all DIMMs,
> > and may report errors independently.  As ghes_edac is an GHES
> > error-reporting wrapper to edac, this abstraction makes sense.
> 
> Bullshit.
> 
> An MCI is a memory controller descriptor. That doesn't fit the GHES
> platform devices that get probed. GHES platform device != MCI. How
> many times do I need to say this for it to get through to you?

Right, but it has to be a "pseudo" device for ghes_edac.  There is no
memory controller info available.  A single mci does not make it a real
memory controller, either.

> > I do not see a problem in having counters for each GHES error
> > source.
> 
> And the error counters of that "simulated" mci get incremented
> depending on which pointer gets passed in from GHES? More bullshit.
>
> > This is just statistics info, and ghes_edac does not expect any OS
> > action from the counters.
> 
> So let me know if you don't want to do it and rather would prefer to
> pointlessly debate. I certainly don't want to waste my time debating.

Yes, ghes_edac refactoring like this should be considered a separate
item.  My patchset is aimed to introduce a platform-check to attach
ghes_edac on supported platforms.

Thanks,
-Toshi