linux-toradex.git/drivers/edac, branch v5.5-rc7

riscv: move sifive_l2_cache.h to include/soc

2020-01-12T18:12:44+00:00

The commit 9209fb51896f ("riscv: move sifive_l2_cache.c to drivers/soc")
moves the sifive L2 cache driver to driver/soc. It did not move the
header file along with the driver. Therefore this patch moves the header
file to driver/soc

Signed-off-by: Yash Shah 
Reviewed-by: Anup Patel 
[paul.walmsley@sifive.com: updated to fix the include guard]
Fixes: 9209fb51896f ("riscv: move sifive_l2_cache.c to drivers/soc")
Signed-off-by: Paul Walmsley

riscv: move sifive_l2_cache.c to drivers/soc

2019-12-20T11:40:24+00:00

The sifive_l2_cache.c is in no way related to RISC-V architecture
memory management.  It is a little stub driver working around the fact
that the EDAC maintainers prefer their drivers to be structured in a
certain way that doesn't fit the SiFive SOCs.

Move the file to drivers/soc and add a Kconfig option for it, as well
as the whole drivers/soc boilerplate for CONFIG_SOC_SIFIVE.

Fixes: a967a289f169 ("RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs")
Signed-off-by: Christoph Hellwig 
Reviewed-by: Borislav Petkov 
[paul.walmsley@sifive.com: keep the MAINTAINERS change specific to the L2$ controller code]
Signed-off-by: Paul Walmsley

EDAC/altera: Use the Altera System Manager driver

2019-11-22T09:18:29+00:00

Simplify by using the Altera System Manager driver that abstracts the
differences between ARM32 and ARM64. Also allows the removal of the
Arria10 test function since this is handled by the System Manager
driver.

Signed-off-by: Thor Thayer 
Signed-off-by: Borislav Petkov 
Cc: James Morse 
Cc: linux-edac 
Cc: Mauro Carvalho Chehab 
Cc: Meng.Li@windriver.com
Cc: Robert Richter 
Cc: Tony Luck 
Link: https://lkml.kernel.org/r/1574361048-17572-4-git-send-email-thor.thayer@linux.intel.com

EDAC/altera: Cleanup the ECC Manager

2019-11-22T09:16:43+00:00

Cleanup the ECC Manager peripheral test in probe function as suggested
by James. Remove the check for Stratix10.

Suggested-by: James Morse 
Signed-off-by: Thor Thayer 
Signed-off-by: Borislav Petkov 
Cc: linux-edac 
Cc: Mauro Carvalho Chehab 
Cc: Robert Richter 
Cc: Tony Luck 
Link: https://lkml.kernel.org/r/1573156890-26891-2-git-send-email-thor.thayer@linux.intel.com

EDAC/altera: Use fast register IO for S10 IRQs

2019-11-22T09:14:56+00:00

When an IRQ occurs, regmap_{read,write,...}() is invoked in atomic
context. Regmap must indicate register IO is fast so that a spinlock is
used instead of a mutex to avoid sleeping in atomic context:

  lock_acquire
  __mutex_lock
  mutex_lock_nested
  regmap_lock_mutex
  regmap_write
  a10_eccmgr_irq_unmask
  unmask_irq.part.0
  irq_enable
  __irq_startup
  irq_startup
  __setup_irq
  request_threaded_irq
  devm_request_threaded_irq
  altr_sdram_probe

Mark it so.

 [ bp: Massage. ]

Fixes: 3dab6bd52687 ("EDAC, altera: Add support for Stratix10 SDRAM EDAC")
Reported-by: Meng Li 
Signed-off-by: Meng Li 
Signed-off-by: Thor Thayer 
Signed-off-by: Borislav Petkov 
Cc: James Morse 
Cc: linux-edac 
Cc: Mauro Carvalho Chehab 
Cc: Robert Richter 
Cc: stable 
Cc: Tony Luck 
Link: https://lkml.kernel.org/r/1574361048-17572-2-git-send-email-thor.thayer@linux.intel.com

EDAC/ghes: Do not warn when incrementing refcount on 0

2019-11-22T08:53:08+00:00

The following warning from the refcount framework is seen during ghes
initialization:

  EDAC MC0: Giving out device to module ghes_edac.c controller ghes_edac: DEV ghes (INTERRUPT)
  ------------[ cut here ]------------
  refcount_t: increment on 0; use-after-free.
  WARNING: CPU: 36 PID: 1 at lib/refcount.c:156 refcount_inc_checked
 [...]
  Call trace:
   refcount_inc_checked
   ghes_edac_register
   ghes_probe
   ...

It warns if the refcount is incremented from zero. This warning is
reasonable as a kernel object is typically created with a refcount of
one and freed once the refcount is zero. Afterwards the object would be
"used-after-free".

For GHES, the refcount is initialized with zero, and that is why this
message is seen when initializing the first instance. However, whenever
the refcount is zero, the device will be allocated and registered. Since
the ghes_reg_mutex protects the refcount and serializes allocation and
freeing of ghes devices, a use-after-free cannot happen here.

Instead of using refcount_inc() for the first instance, use
refcount_set(). This can be used here because the refcount is zero at
this point and can not change due to its protection by the mutex.

Fixes: 23f61b9fc5cc ("EDAC/ghes: Fix locking and memory barrier issues")
Reported-by: John Garry 
Signed-off-by: Robert Richter 
Signed-off-by: Borislav Petkov 
Tested-by: John Garry 
Cc: 
Cc: James Morse 
Cc: 
Cc: linux-edac 
Cc: Mauro Carvalho Chehab 
Cc: 
Cc: Tony Luck 
Cc: 
Link: https://lkml.kernel.org/r/20191121213628.21244-1-rrichter@marvell.com

EDAC: Unify the mc_event tracepoint call

2019-11-10T11:40:14+00:00

The code in ghes_edac.c and edac_mc.c for grain_bits calculation and
calling trace_mc_event() is now the same. Move it to a single location
in edac_raw_mc_handle_error().

The only difference is the missing IS_ENABLED(CONFIG_RAS) switch, but
this is needed for ghes too.

Signed-off-by: Robert Richter 
Signed-off-by: Borislav Petkov 
Reviewed-by: Mauro Carvalho Chehab 
Cc: "linux-edac@vger.kernel.org" 
Cc: James Morse 
Cc: Tony Luck 
Link: https://lkml.kernel.org/r/20191106093239.25517-13-rrichter@marvell.com

EDAC/ghes: Remove intermediate buffer pvt->detail_location

2019-11-10T11:40:14+00:00

detail_location[] is used to collect two location strings so they can
be passed as one to trace_mc_event(). Instead of having an extra copy
step, assemble the location string in other_detail[] from the
beginning.

Using other_detail[] to call trace_mc_event() is now the same as in
edac_mc.c and code can be unified.

Signed-off-by: Robert Richter 
Signed-off-by: Borislav Petkov 
Reviewed-by: James Morse 
Reviewed-by: Mauro Carvalho Chehab 
Cc: "linux-edac@vger.kernel.org" 
Cc: Tony Luck 
Link: https://lkml.kernel.org/r/20191106093239.25517-12-rrichter@marvell.com

EDAC/ghes: Fix grain calculation

2019-11-10T11:40:14+00:00

The current code to convert a physical address mask to a grain
(defined as granularity in bytes) is:

	e->grain = ~(mem_err->physical_addr_mask & ~PAGE_MASK);

This is broken in several ways:

1) It calculates to wrong grain values. E.g., a physical address mask
of ~0xfff should give a grain of 0x1000. Without considering
PAGE_MASK, there is an off-by-one. Things are worse when also
filtering it with ~PAGE_MASK. This will calculate to a grain with the
upper bits set. In the example it even calculates to ~0.

2) The grain does not depend on and is unrelated to the kernel's
page-size. The page-size only matters when unmapping memory in
memory_failure(). Smaller grains are wrongly rounded up to the
page-size, on architectures with a configurable page-size (e.g. arm64)
this could round up to the even bigger page-size of the hypervisor.

Fix this with:

	e->grain = ~mem_err->physical_addr_mask + 1;

The grain_bits are defined as:

	grain = 1 << grain_bits;

Change also the grain_bits calculation accordingly, it is the same
formula as in edac_mc.c now and the code can be unified.

The value in ->physical_addr_mask coming from firmware is assumed to
be contiguous, but this is not sanity-checked. However, in case the
mask is non-contiguous, a conversion to grain_bits effectively
converts the grain bit mask to a power of 2 by rounding it up.

Suggested-by: James Morse 
Signed-off-by: Robert Richter 
Signed-off-by: Borislav Petkov 
Reviewed-by: Mauro Carvalho Chehab 
Cc: "linux-edac@vger.kernel.org" 
Cc: Tony Luck 
Link: https://lkml.kernel.org/r/20191106093239.25517-11-rrichter@marvell.com

EDAC/ghes: Use standard kernel macros for page calculations

2019-11-10T11:40:14+00:00

Use standard macros for page calculations.

Signed-off-by: Robert Richter 
Signed-off-by: Borislav Petkov 
Reviewed-by: James Morse 
Reviewed-by: Mauro Carvalho Chehab 
Cc: "linux-edac@vger.kernel.org" 
Cc: Tony Luck 
Link: https://lkml.kernel.org/r/20191106093239.25517-10-rrichter@marvell.com