[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170719055838.GF26030@nazgul.tnic>
Date: Wed, 19 Jul 2017 07:58:38 +0200
From: Borislav Petkov <bp@...en8.de>
To: Mauro Carvalho Chehab <mchehab@...pensource.com>
Cc: "Kani, Toshimitsu" <toshi.kani@....com>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mchehab@...nel.org" <mchehab@...nel.org>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
"srinivas.pandruvada@...ux.intel.com"
<srinivas.pandruvada@...ux.intel.com>,
"lenb@...nel.org" <lenb@...nel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac
On Tue, Jul 18, 2017 at 06:15:45PM -0300, Mauro Carvalho Chehab wrote:
> The way it is, ghes_edac is a poor man's driver. What it hopefully
> provide is a detection that an error happened, without really telling
> the user what component should be replaced.
I beg to differ. From the UEFI spec:
"The module number of the memory error location. (NODE, CARD, and MODULE
should provide the information necessary to identify the failing FRU)."
So this tuple is sufficient to pinpoint the DIMM, IIUC.
Which means, ghes_edac can have a single layer of DIMMs without channels.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
Powered by blists - more mailing lists