linux-toradex.git/drivers/edac/edac_mc_sysfs.c, branch v3.5-rc2

edac: Initialize the dimm label with the known information

2012-05-28T22:13:50+00:00

While userspace doesn't fill the dimm labels, add there the dimm location,
as described by the used memory model. This could eventually match what
is described at the dmidecode, making easier for people to identify the
memory.

For example, on an Intel motherboard where the DMI table is reliable,
the first memory stick is described as:

Memory Device
	Array Handle: 0x0029
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: 1
	Locator: A1_DIMM0
	Bank Locator: A1_Node0_Channel0_Dimm0
	Type: 
	Type Detail: Synchronous
	Speed: 800 MHz
	Manufacturer: A1_Manufacturer0
	Serial Number: A1_SerNum0
	Asset Tag: A1_AssetTagNum0
	Part Number: A1_PartNum0

The memory named as "A1_DIMM0" is physically located at the first
memory controller (node 0), at channel 0, dimm slot 0.

After this patch, the memory label will be filled with:
	/sys/devices/system/edac/mc/csrow0/ch0_dimm_label:mc#0channel#0slot#0

And (after the new EDAC API patches) as:
	/sys/devices/system/edac/mc/mc0/dimm0/dimm_label:mc#0channel#0slot#0

So, even if the memory label is not initialized on userspace, an useful
information with the error location is filled there, expecially since
several systems/motherboards are provided with enough info to map from
channel/slot (or branch/channel/slot) into the DIMM label. So, letting the
EDAC core fill it by default is a good thing.

It should noticed that, as the label filling happens at the
edac_mc_alloc(), drivers can override it to better describe the memories
(and some actually do it).

Cc: Aristeu Rozanski 
Cc: Doug Thompson 
Signed-off-by: Mauro Carvalho Chehab

edac: move nr_pages to dimm struct

2012-05-28T22:10:58+00:00

The number of pages is a dimm property. Move it to the dimm struct.

After this change, it is possible to add sysfs nodes for the DIMM's that
will properly represent the DIMM stick properties, including its size.

A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
the memory controller represents the memory via chip select rows.

Reviewed-by: Aristeu Rozanski 
Acked-by: Borislav Petkov 
Acked-by: Chris Metcalf 
Cc: Doug Thompson 
Cc: Mark Gross 
Cc: Jason Uhlenkott 
Cc: Tim Small 
Cc: Ranganathan Desikan 
Cc: "Arvind R." 
Cc: Olof Johansson 
Cc: Egor Martovetsky 
Cc: Michal Marek 
Cc: Jiri Kosina 
Cc: Joe Perches 
Cc: Dmitry Eremin-Solenikov 
Cc: Benjamin Herrenschmidt 
Cc: Hitoshi Mitake 
Cc: Andrew Morton 
Cc: "Niklas Söderlund" 
Cc: Shaohui Xie 
Cc: Josh Boyer 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab

edac: move dimm properties to struct dimm_info

2012-05-28T22:10:58+00:00

On systems based on chip select rows, all channels need to use memories
with the same properties, otherwise the memories on channels A and B
won't be recognized.

However, such assumption is not true for all types of memory
controllers.

Controllers for FB-DIMM's don't have such requirements.

Also, modern Intel controllers seem to be capable of handling such
differences.

So, we need to get rid of storing the DIMM information into a per-csrow
data, storing it, instead at the right place.

The first step is to move grain, mtype, dtype and edac_mode to the
per-dimm struct.

Reviewed-by: Aristeu Rozanski 
Reviewed-by: Borislav Petkov 
Acked-by: Chris Metcalf 
Cc: Doug Thompson 
Cc: Borislav Petkov 
Cc: Mark Gross 
Cc: Jason Uhlenkott 
Cc: Tim Small 
Cc: Ranganathan Desikan 
Cc: "Arvind R." 
Cc: Olof Johansson 
Cc: Egor Martovetsky 
Cc: Michal Marek 
Cc: Jiri Kosina 
Cc: Joe Perches 
Cc: Dmitry Eremin-Solenikov 
Cc: Benjamin Herrenschmidt 
Cc: Hitoshi Mitake 
Cc: Andrew Morton 
Cc: James Bottomley 
Cc: "Niklas Söderlund" 
Cc: Shaohui Xie 
Cc: Josh Boyer 
Cc: Mike Williams 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab

edac: Create a dimm struct and move the labels into it

2012-05-28T22:10:57+00:00

The way a DIMM is currently represented implies that they're
linked into a per-csrow struct. However, some drivers don't see
csrows, as they're ridden behind some chip like the AMB's
on FBDIMM's, for example.

This forced drivers to fake^Wvirtualize a csrow struct, and to create
a mess under csrow/channel original's concept.

Move the DIMM labels into a per-DIMM struct, and add there
the real location of the socket, in terms of csrow/channel.
Latter patches will modify the location to properly represent the
memory architecture.

All other drivers will use a per-csrow type of location.
Some of those drivers will require a latter conversion, as
they also fake the csrows internally.

TODO: While this patch doesn't change the existing behavior, on
csrows-based memory controllers, a csrow/channel pair points to a memory
rank. There's a known bug at the EDAC core that allows having different
labels for the same DIMM, if it has more than one rank. A latter patch
is need to merge the several ranks for a DIMM into the same dimm_info
struct, in order to avoid having different labels for the same DIMM.

The edac_mc_alloc() will now contain a per-dimm initialization loop that
will be changed by latter patches in order to match other types of
memory architectures.

Reviewed-by: Aristeu Rozanski 
Reviewed-by: Borislav Petkov 
Cc: Doug Thompson 
Cc: Ranganathan Desikan 
Cc: "Arvind R." 
Cc: "Niklas Söderlund" 
Signed-off-by: Mauro Carvalho Chehab

EDAC: Correct scrub rate API

2012-03-19T11:03:58+00:00

The original scrub rate API definition states that if scrub rate
accessors are not implemented, a negative value (-1) should be written
to the sysfs file (/sys/devices/system/edac/mc/mc/sdram_scrub_rate,
where N is the memory controller number on the system). This is
counter-intuitive and awkward at the very least because, when setting
the scrub rate, userspace has to write to sysfs and then read it back to
check error status of the operation.

As Tony notes, best it would be to not have the sdram_scrub_rate in
sysfs if scrub rate support is not implemented. It is too late about
that and a bunch of drivers on a bunch of arches would need to be
changed and tested which is not a trivial task ATM.

Instead, settle for the next best thing of returning -ENODEV when
implementation is missing and -EINVAL when there was an error
encountered while setting the scrub rate.

Reported-by: Han Pingtian 
Cc: Tony Luck 
Link: http://lkml.kernel.org/r/20110916105856.GA13253@hpt.nay.redhat.com
Signed-off-by: Borislav Petkov

edac: convert sysdev_class to a regular subsystem

2011-12-14T23:21:07+00:00

After all sysdev classes are ported to regular driver core entities, the
sysdev implementation will be entirely removed from the kernel.

Cc: Doug Thompson 
Cc: Paul Gortmaker 
Cc: Lucas De Marchi 
Cc: Borislav Petkov 
Signed-off-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

EDAC: Remove debugging output in scrub rate handling

2011-04-21T10:44:58+00:00

This patch removes superfluous debugging output in the sysfs scrub rate
handler. It also consolidates the error handling in the scrub rate
accessors.

Signed-off-by: Markus Trippelsdorf 
Signed-off-by: Borislav Petkov

Fix common misspellings

2011-03-31T14:26:23+00:00

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi

EDAC: Shut up sysfs registration debug code

2011-03-17T13:46:10+00:00

Raise the debug level of these routines so that their output get issued
out only when the highest debug level is selected. Otherwise, don't
pollute driver debug output.

Signed-off-by: Borislav Petkov

EDAC: Fixup scrubrate manipulation

2011-01-07T10:38:31+00:00

Make the ->{get|set}_sdram_scrub_rate return the actual scrub rate
bandwidth it succeeded setting and remove superfluous arg pointer used
for that. A negative value returned still means that an error occurred
while setting the scrubrate. Document this for future reference.

Signed-off-by: Borislav Petkov