linux-toradex.git/include/linux/edac.h, branch v5.1-rc1

EDAC: Drop per-memory controller buses

2018-11-13T20:55:24+00:00

... and use the single edac_subsys object returned from
subsys_system_register(). The idea is to have a single bus
and multiple devices on it.

Signed-off-by: Borislav Petkov 
Acked-by: Mauro Carvalho Chehab 
CC: Aristeu Rozanski Filho 
CC: Greg KH 
CC: Justin Ernst 
CC: linux-edac 
CC: Mauro Carvalho Chehab 
CC: Russ Anderson 
Cc: Tony Luck 
Link: https://lkml.kernel.org/r/20180926152752.GG5584@zn.tnic

EDAC: Raise the maximum number of memory controllers

2018-09-27T05:52:05+00:00

We observe an oops in the skx_edac module during boot:

  EDAC MC0: Giving out device to module skx_edac controller Skylake Socket#0 IMC#0
  EDAC MC1: Giving out device to module skx_edac controller Skylake Socket#0 IMC#1
  EDAC MC2: Giving out device to module skx_edac controller Skylake Socket#1 IMC#0
  ...
  EDAC MC13: Giving out device to module skx_edac controller Skylake Socket#0 IMC#1
  EDAC MC14: Giving out device to module skx_edac controller Skylake Socket#1 IMC#0
  EDAC MC15: Giving out device to module skx_edac controller Skylake Socket#1 IMC#1
  Too many memory controllers: 16
  EDAC MC: Removed device 0 for skx_edac Skylake Socket#0 IMC#0

We observe there are two memory controllers per socket, with a limit
of 16. Raise the maximum number of memory controllers from 16 to 2 *
MAX_NUMNODES (1024).

[ bp: This is just a band-aid fix until we've sorted out the whole issue
  with the bus_type association and handling in EDAC and can get rid of
  this arbitrary limit. ]

Signed-off-by: Justin Ernst 
Signed-off-by: Borislav Petkov 
Acked-by: Russ Anderson 
Cc: Mauro Carvalho Chehab 
Cc: linux-edac@vger.kernel.org
Link: https://lkml.kernel.org/r/20180925143449.284634-1-justin.ernst@hpe.com

EDAC, ghes: Use CPER module handles to locate DIMMs

2018-09-22T16:35:40+00:00

Use SMBIOS module handle type 17, on platforms which provide valid
ones, to locate the corresponding DIMM and thus have per-DIMM error
counter updates.

Signed-off-by: Fan Wu 
[ Massage commit message. ]
Signed-off-by: Borislav Petkov 
Reviewed-by: Tyler Baicar 
Reviewed-by: James Morse 
Tested-by: Toshi Kani 
Cc: Mauro Carvalho Chehab 
Cc: baicar.tyler@gmail.com
Cc: john.garry@huawei.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-edac 
Cc: shiju.jose@huawei.com
Cc: tanxiaofei@huawei.com
Cc: wanghuiqiang@huawei.com
Link: http://lkml.kernel.org/r/1537322340-1860-1-git-send-email-wufan@codeaurora.org

EDAC: Add new memory type for non-volatile DIMMs

2018-03-14T11:32:06+00:00

There are now non-volatile versions of DIMMs. Add a new entry to "enum
mem_type" and a new string in edac_mem_types[].

Signed-off-by: Tony Luck 
Cc: "Rafael J. Wysocki" 
Cc: Aristeu Rozanski 
Cc: Dan Williams 
Cc: Jean Delvare 
Cc: Len Brown 
Cc: Mauro Carvalho Chehab 
Cc: Qiuxu Zhuo 
Cc: linux-acpi@vger.kernel.org
Cc: linux-edac 
Cc: linux-nvdimm@lists.01.org
Link: http://lkml.kernel.org/r/20180312182430.10335-3-tony.luck@intel.com
Signed-off-by: Borislav Petkov

EDAC: Get rid of mci->mod_ver

2017-07-17T11:42:48+00:00

It is a write-only variable so get rid of it.

Signed-off-by: Borislav Petkov 
Acked-by: Robert Richter 
Acked-by: Michal Simek 
Acked-by: Thor Thayer 
Acked-by: Tony Luck 
Cc: Mark Gross 
Cc: Tim Small 
Cc: Ranganathan Desikan 
Cc: "Arvind R." 
Cc: Jason Baron 
Cc: "Sören Brinkmann" 
Cc: Ralf Baechle 
Cc: David Daney 
Cc: Loc Ho 
Cc: linux-edac@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org

EDAC: Rename report status accessors

2017-04-10T15:15:02+00:00

Change them to have the edac_ prefix.

No functionality change.

Signed-off-by: Borislav Petkov

EDAC: Delete edac_stub.c

2017-04-10T15:14:48+00:00

Move the remaining functionality to edac_mc.c. Convert "edac_report=" to
a module parameter.

Signed-off-by: Borislav Petkov

EDAC: Remove edac_err_assert

2017-04-10T15:14:21+00:00

... and the glue around it. It is not needed anymore.

Signed-off-by: Borislav Petkov

EDAC: Get rid of edac_handlers

2017-04-10T15:14:17+00:00

Use mc_devices list instead to check whether we have EDAC driver
instances successfully registered with EDAC core.

Signed-off-by: Borislav Petkov

x86/nmi, EDAC: Get rid of DRAM error reporting thru PCI SERR NMI

2017-04-10T15:13:48+00:00

Apparently, some machines used to report DRAM errors through a PCI SERR
NMI. This is why we have a call into EDAC in the NMI handler. See

  c0d121720220 ("drivers/edac: add new nmi rescan").

From looking at the patch above, that's two drivers: e752x_edac.c and
e7xxx_edac.c. Now, I wanna say those are old machines which are probably
decommissioned already.

Tony says that "[t]the newest CPU supported by either of those drivers
is the Xeon E7520 (a.k.a. "Nehalem") released in Q1'2010. Possibly some
folks are still using these ... but people that hold onto h/w for 7
years generally cling to old s/w too ... so I'd guess it unlikely that
we will get complaints for breaking these in upstream."

So even if there is a small number still in use, we did load EDAC with
edac_op_state == EDAC_OPSTATE_POLL by default (we still do, in fact)
which means a default EDAC setup without any parameters supplied on the
command line or otherwise would never even log the error in the NMI
handler because we're polling by default:

  inline int edac_handler_set(void)
  {
         if (edac_op_state == EDAC_OPSTATE_POLL)
                 return 0;

         return atomic_read(&edac_handlers);
  }

So, long story short, I'd like to get rid of that nastiness called
edac_stub.c and confine all the EDAC drivers solely to drivers/edac/. If
we ever have to do stuff like that again, it should be notifiers we're
using and not some insanity like this one.

Signed-off-by: Borislav Petkov 
Acked-by: Thomas Gleixner 
Cc: Tony Luck