[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170815155000.d57hwki5jbixjuj6@pd.tnic>
Date: Tue, 15 Aug 2017 17:50:00 +0200
From: Borislav Petkov <bp@...en8.de>
To: "Kani, Toshimitsu" <toshi.kani@....com>
Cc: "rjw@...ysocki.net" <rjw@...ysocki.net>,
"lenb@...nel.org" <lenb@...nel.org>,
"mchehab@...nel.org" <mchehab@...nel.org>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()
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?
> 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.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists