EDAC: Update memory repair control interface for memory sparing feature

Update memory repair control interface for memory sparing feature.

CXL memory devices can support soft and hard memory sparin

EDAC: Update memory repair control interface for memory sparing feature

Update memory repair control interface for memory sparing feature.

CXL memory devices can support soft and hard memory sparing at cacheline,
row, bank and rank granularities. Memory sparing is defined as a repair
function that replaces a portion of memory with a portion of functional
memory at that same granularity.

When a CXL device detects an error in memory, it will report to the host
that there's need for a repair maintenance operation by using an event
record where the "maintenance needed" flag is set.

The event records contain the device physical address (DPA) and other
attributes of the memory to repair such as bank group, bank, rank, row,
column, channel etc.

The kernel will report the corresponding CXL general media or DRAM trace
event to userspace, and userspace tools (e.g. rasdaemon) will initiate
a repair operation in response to the device request via the sysfs
repair control.

[ bp: Massage. ]

Signed-off-by: Shiju Jose <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

EDAC: Add a memory repair control feature

Add a generic EDAC memory repair control driver to manage memory repairs in
the system, such as CXL Post Package Repair (PPR) and other soft and hard PPR
fe

EDAC: Add a memory repair control feature

Add a generic EDAC memory repair control driver to manage memory repairs in
the system, such as CXL Post Package Repair (PPR) and other soft and hard PPR
features.

For example, a CXL device with DRAM components that support PPR features may
implement PPR maintenance operations. DRAM components may support two types of
PPR:

- hard PPR, for a permanent row repair, and
- soft PPR, for a temporary row repair.

Soft PPR is much faster than hard PPR, but the repair is lost with a power
cycle.

When a CXL device detects an error in a memory, it may report the need for
a repair maintenance operation by using an event record where the "maintenance
needed" flag is set. The event records contain the device physical
address (DPA) and other optional attributes of the memory to repair.

The kernel will report the corresponding CXL general media or DRAM trace event
to userspace, and userspace tools (e.g. rasdaemon) will initiate a repair
operation in response to the device request via the sysfs repair control.

Device with memory repair features registers with EDAC device driver, which
retrieves a memory repair descriptor from EDAC memory repair driver and exposes
the sysfs repair control attributes to userspace in

/sys/bus/edac/devices/<dev-name>/mem_repairX/.

The common memory repair control interface abstracts the control of arbitrary
memory repair functionality into a standardized set of functions. The sysfs
memory repair attribute nodes are only available if the client driver has
implemented the corresponding attribute callback function and provided
operations to the EDAC device driver during registration.

[ bp: Massage, fixup edac_dev_register() retvals, merge
write_overflow fix to mem_repair_create_desc() ]

Signed-off-by: Shiju Jose <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

EDAC: Add a Error Check Scrub control feature

Add an Error Check Scrub (ECS) control to manage a memory device's ECS
feature.

The ECS is a feature defined in JEDEC DDR5 SDRAM Specification (JESD79-

EDAC: Add a Error Check Scrub control feature

Add an Error Check Scrub (ECS) control to manage a memory device's ECS
feature.

The ECS is a feature defined in JEDEC DDR5 SDRAM Specification (JESD79-5) and
allows the DRAM to internally read, correct single-bit errors, and write back
corrected data bits to the DRAM array while providing transparency to error
counts.

The DDR5 device contains a number of memory media Field Replaceable Units
(FRU) per device. The DDR5 ECS feature and thus the ECS control driver
supports configuring the ECS parameters per FRU.

Memory devices support the ECS feature register with the EDAC device driver,
which retrieves the ECS descriptor from the EDAC ECS driver. This driver
exposes sysfs ECS control attributes to userspace via

/sys/bus/edac/devices/<dev-name>/ecs_fruX/.

The common sysfs ECS control interface abstracts the control of an arbitrary
ECS functionality to a common set of functions.

Support for the ECS feature is added separately because the control attributes
of the DDR5 ECS feature differ from those of the scrub feature.

The sysfs ECS attribute nodes are only present if the client driver has
implemented the corresponding attribute callback function and passed the
necessary operations to the EDAC RAS feature driver during registration.

[ bp: Massage, fixup edac_dev_register() retvals. ]

Co-developed-by: Jonathan Cameron <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Shiju Jose <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Fan Ni <[email protected]>
Tested-by: Fan Ni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

EDAC: Add scrub control feature

Add a scrub control to manage memory scrubbers in the system.

Devices with a scrub feature register with the EDAC device driver which
retrieves the scrub descriptor

EDAC: Add scrub control feature

Add a scrub control to manage memory scrubbers in the system.

Devices with a scrub feature register with the EDAC device driver which
retrieves the scrub descriptor from the scrub driver and exposes the
control attributes for a instance to userspace at

/sys/bus/edac/devices/<dev-name>/scrubX/.

The common sysfs scrub control interface abstracts the control of
arbitrary scrubbing functionality into a common set of functions. The
attribute nodes are only present if the client driver has implemented
the corresponding attribute callback function and passed the operations
to the device driver during registration.

[ bp: Massage commit message, docs and code, simplify text a bit.
Integrate fixup for: https://lore.kernel.org/r/[email protected]
Reported-by: kernel test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]> ]

Co-developed-by: Jonathan Cameron <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Shiju Jose <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Tested-by: Daniel Ferguson <[email protected]>
Tested-by: Fan Ni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

EDAC: Add support for EDAC device features control

Add generic EDAC device feature controls supporting the registration of RAS
features available in the system. The driver exposes control attributes

EDAC: Add support for EDAC device features control

Add generic EDAC device feature controls supporting the registration of RAS
features available in the system. The driver exposes control attributes for
these features to userspace in

/sys/bus/edac/devices/<dev-name>/<ras-feature>

[ bp: Touch-up documentation, simplify, make edac_dev_type static,
fixup edac_dev_register() retvals. ]

Co-developed-by: Jonathan Cameron <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>
Signed-off-by: Shiju Jose <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Fan Ni <[email protected]>
Tested-by: Daniel Ferguson <[email protected]>
Tested-by: Fan Ni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

EDAC: constantify the struct bus_type usage

In many places in the edac code, struct bus_type pointers are passed
around and then eventually sent to the driver core, which can handle a
constant point

EDAC: constantify the struct bus_type usage

In many places in the edac code, struct bus_type pointers are passed
around and then eventually sent to the driver core, which can handle a
constant pointer. So constantify all of the edac usage of these as well
because the data in them is never modified by the edac code either.

Cc: Borislav Petkov <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: James Morse <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Robert Richter <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/2023121909-tribute-punctuate-4b22@gregkh
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

EDAC/mc: Add support for HBM3 memory type

AMD MI300A models use HBM3 (High Bandwidth Memory Gen 3) memory. HBM is
a high-speed computer memory interface for 3D-stacked synchronous
dynamic random-acc

EDAC/mc: Add support for HBM3 memory type

AMD MI300A models use HBM3 (High Bandwidth Memory Gen 3) memory. HBM is
a high-speed computer memory interface for 3D-stacked synchronous
dynamic random-access memory (SDRAM).

Signed-off-by: Muralidhara M K <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

EDAC/mc: Replace spaces with tabs in memtype flags definition

Currently, the memory type macros are partly defined with multiple
spaces between the macro name and its definition. Replace the spaces

EDAC/mc: Replace spaces with tabs in memtype flags definition

Currently, the memory type macros are partly defined with multiple
spaces between the macro name and its definition. Replace the spaces
with tabs as the kernel coding style requires.

Signed-off-by: Serge Semin <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

EDAC: Add RDDR5 and LRDDR5 memory types

Include Registered-DDR5 and Load-Reduced DDR5 in the list of memory
types.

Signed-off-by: Yazen Ghannam <[email protected]>
Signed-off-by: Borislav Petko

EDAC: Add RDDR5 and LRDDR5 memory types

Include Registered-DDR5 and Load-Reduced DDR5 in the list of memory
types.

Signed-off-by: Yazen Ghannam <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

EDAC/mc: Add new HBM2 memory type

Add a new entry to 'enum mem_type' and a new string to 'edac_mem_types[]'
for HBM2 (High Bandwidth Memory Gen 2) new memory type.

Reviewed-by: Yazen Ghannam <yazen

EDAC/mc: Add new HBM2 memory type

Add a new entry to 'enum mem_type' and a new string to 'edac_mem_types[]'
for HBM2 (High Bandwidth Memory Gen 2) new memory type.

Reviewed-by: Yazen Ghannam <[email protected]>
Signed-off-by: Muralidhara M K <[email protected]>
Signed-off-by: Naveen Krishna Chatradhi <[email protected]>
Signed-off-by: Tony Luck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

EDAC: Add DDR5 new memory type

Add a new entry to 'enum mem_type' and a new string to
'edac_mem_types[]' for DDR5 new memory type.

Signed-off-by: Qiuxu Zhuo <[email protected]>
Signed-off-by: To

EDAC: Add DDR5 new memory type

Add a new entry to 'enum mem_type' and a new string to
'edac_mem_types[]' for DDR5 new memory type.

Signed-off-by: Qiuxu Zhuo <[email protected]>
Signed-off-by: Tony Luck <[email protected]>

show more ...

EDAC: Add three new memory types

There are {Low-Power DDR3/4, WIO2} types of memory.
Add new entries to 'enum mem_type' and new strings to
'edac_mem_types[]' for the new types.

Signed-off-by: Qiuxu

EDAC: Add three new memory types

There are {Low-Power DDR3/4, WIO2} types of memory.
Add new entries to 'enum mem_type' and new strings to
'edac_mem_types[]' for the new types.

Signed-off-by: Qiuxu Zhuo <[email protected]>
Signed-off-by: Tony Luck <[email protected]>

show more ...

EDAC: Fix some kernel-doc markups

Kernel-doc markup should use this format:
identifier - description

Correct that and also fix some enums' names in the kernel-doc markup.

Signed-off-by: Ma

EDAC: Fix some kernel-doc markups

Kernel-doc markup should use this format:
identifier - description

Correct that and also fix some enums' names in the kernel-doc markup.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Link: https://lkml.kernel.org/r/1d291393ba58c7b80908a3fedf02d2f53921ffe9.1603469755.git.mchehab+huawei@kernel.org

show more ...

EDAC: Remove edac_get_dimm_by_index()

It is unused now.

Signed-off-by: Borislav Petkov <[email protected]>

EDAC: Drop the EDAC report status checks

When acpi_extlog was added, we were worried that the same error would
be reported more than once by different subsystems. But in the ensuing
years I've seen

EDAC: Drop the EDAC report status checks

When acpi_extlog was added, we were worried that the same error would
be reported more than once by different subsystems. But in the ensuing
years I've seen complaints that people could not find an error log
(because this mechanism suppressed the log they were looking for).

Rip it all out. People are smart enough to notice the same address from
different reporting mechanisms.

Signed-off-by: Tony Luck <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Tested-by: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC/mc: Remove per layer counters

Looking at how mci->{ue,ce}_per_layer[EDAC_MAX_LAYERS] is used, it
turns out that only the leaves in the memory hierarchy are consumed
(in sysfs), but not the inte

EDAC/mc: Remove per layer counters

Looking at how mci->{ue,ce}_per_layer[EDAC_MAX_LAYERS] is used, it
turns out that only the leaves in the memory hierarchy are consumed
(in sysfs), but not the intermediate layers, e.g.:

count = dimm->mci->ce_per_layer[dimm->mci->n_layers-1][dimm->idx];

These unused counters only add complexity, remove them. The error
counter values are directly stored in struct dimm_info now.

Signed-off-by: Robert Richter <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Aristeu Rozanski <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC/mc: Remove enable_per_layer_report function argument

Many functions carry the enable_per_layer_report argument. This is a
bool value indicating the error information contains some location
data

EDAC/mc: Remove enable_per_layer_report function argument

Many functions carry the enable_per_layer_report argument. This is a
bool value indicating the error information contains some location
data where the error occurred. This can easily being determined by
checking the pos[] array for values. Negative values indicate there is
no location available. So if the top layer is negative, the error
location is unknown.

Just check if the top layer is negative and remove
enable_per_layer_report as function argument and also from struct
edac_raw_error_desc.

[ bp: Reflow comments to 80 columns, while at it. ]

Signed-off-by: Robert Richter <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Aristeu Rozanski <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC: Store error type in struct edac_raw_error_desc

Store the error type in struct edac_raw_error_desc. This makes the
type parameter of edac_raw_mc_handle_error() obsolete.

[ kernel-doc typo ]
Re

EDAC: Store error type in struct edac_raw_error_desc

Store the error type in struct edac_raw_error_desc. This makes the
type parameter of edac_raw_mc_handle_error() obsolete.

[ kernel-doc typo ]
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Robert Richter <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Acked-by: Aristeu Rozanski <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC: Remove misleading comment in struct edac_raw_error_desc

There never has been such function edac_raw_error_desc_clean() and in
function ghes_edac_report_mem_error() the whole struct is zero'ed

EDAC: Remove misleading comment in struct edac_raw_error_desc

There never has been such function edac_raw_error_desc_clean() and in
function ghes_edac_report_mem_error() the whole struct is zero'ed
including the string arrays. Remove that comment.

Signed-off-by: Robert Richter <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Cc: "[email protected]" <[email protected]>
Cc: James Morse <[email protected]>
Cc: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC: Introduce an mci_for_each_dimm() iterator

Introduce an mci_for_each_dimm() iterator. It returns a pointer to
a struct dimm_info. This makes the declaration and use of an index
obsolete and avo

EDAC: Introduce an mci_for_each_dimm() iterator

Introduce an mci_for_each_dimm() iterator. It returns a pointer to
a struct dimm_info. This makes the declaration and use of an index
obsolete and avoids access to internal data of struct mci (direct array
access etc).

[ bp: push the struct dimm_info *dimm; declaration into the
CONFIG_EDAC_DEBUG block. ]

Signed-off-by: Robert Richter <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Cc: "[email protected]" <[email protected]>
Cc: James Morse <[email protected]>
Cc: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC: Remove EDAC_DIMM_OFF() macro

The EDAC_DIMM_OFF() macro takes 5 arguments to get the DIMM's index.
Simplify this by storing the index in struct dimm_info to avoid its
calculation and remove the

EDAC: Remove EDAC_DIMM_OFF() macro

The EDAC_DIMM_OFF() macro takes 5 arguments to get the DIMM's index.
Simplify this by storing the index in struct dimm_info to avoid its
calculation and remove the EDAC_DIMM_OFF() macro. The index can be
directly used then.

Another advantage is that edac_mc_alloc() could be used even if the
exact size of the layers is unknown. Only the number of DIMMs would be
needed.

Rename iterator variable to idx, while at it. The name is more handy,
esp. when searching for it in the code.

Signed-off-by: Robert Richter <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Cc: "[email protected]" <[email protected]>
Cc: James Morse <[email protected]>
Cc: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC: Replace EDAC_DIMM_PTR() macro with edac_get_dimm() function

The EDAC_DIMM_PTR() macro takes 3 arguments from struct mem_ctl_info.
Clean up this interface to only pass the mci struct and replac

EDAC: Replace EDAC_DIMM_PTR() macro with edac_get_dimm() function

The EDAC_DIMM_PTR() macro takes 3 arguments from struct mem_ctl_info.
Clean up this interface to only pass the mci struct and replace this
macro with a new function edac_get_dimm().

Also introduce an edac_get_dimm_by_index() function for later use.
This allows it to get a DIMM pointer only by a given index. This can
be useful if the DIMM's position within the layers of the memory
controller or the exact size of the layers are unknown.

Small style changes made for some hunks after applying the semantic
patch.

Semantic patch used:

@@ expression mci, a, b,c; @@

-EDAC_DIMM_PTR(mci->layers, mci->dimms, mci->n_layers, a, b, c)
+edac_get_dimm(mci, a, b, c)

[ bp: Touchups. ]

Signed-off-by: Robert Richter <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Cc: "[email protected]" <[email protected]>
Cc: James Morse <[email protected]>
Cc: Jason Baron <[email protected]>
Cc: Qiuxu Zhuo <[email protected]>
Cc: Tero Kristo <[email protected]>
Cc: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC: Prefer 'unsigned int' to bare use of 'unsigned'

Use of 'unsigned int' instead of bare use of 'unsigned'. Fix this for
edac_mc*, ghes and the i5100 driver as reported by checkpatch.pl.

While a

EDAC: Prefer 'unsigned int' to bare use of 'unsigned'

Use of 'unsigned int' instead of bare use of 'unsigned'. Fix this for
edac_mc*, ghes and the i5100 driver as reported by checkpatch.pl.

While at it, struct member dev_ch_attribute->channel is always used as
unsigned int. Change type to unsigned int to avoid type casts.

[ bp: Massage. ]

Signed-off-by: Robert Richter <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Cc: "[email protected]" <[email protected]>
Cc: James Morse <[email protected]>
Cc: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC: Drop per-memory controller buses

... 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:

EDAC: Drop per-memory controller buses

... 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 <[email protected]>
Acked-by: Mauro Carvalho Chehab <[email protected]>
CC: Aristeu Rozanski Filho <[email protected]>
CC: Greg KH <[email protected]>
CC: Justin Ernst <[email protected]>
CC: linux-edac <[email protected]>
CC: Mauro Carvalho Chehab <[email protected]>
CC: Russ Anderson <[email protected]>
Cc: Tony Luck <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

EDAC: Raise the maximum number of memory controllers

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

EDAC: Raise the maximum number of memory controllers

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 <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Acked-by: Russ Anderson <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]

show more ...