[PATCH] EDAC: mc numbers refactor 1-of-2
Remove add_mc_to_global_list(). In next patch, this function will be
reimplemented with different semantics.
1 Reimplement add_mc_to_global_list() with semantics that allow the caller to
determine the ID number for a mem_ctl_info structure. Then modify
edac_mc_add_mc() so that the caller specifies the ID number for the new
mem_ctl_info structure. Platform-specific code should be able to assign the
ID numbers in a platform-specific manner. For instance, on Opteron it makes
sense to have the ID of the mem_ctl_info structure match the ID of the node
that the memory controller belongs to.
2 Modify callers of edac_mc_add_mc() so they use the new semantics.
Signed-off-by: Doug Thompson <norsk5@xmission.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/drivers/edac/e752x_edac.c b/drivers/edac/e752x_edac.c
index de9f332..5e773e3 100644
--- a/drivers/edac/e752x_edac.c
+++ b/drivers/edac/e752x_edac.c
@@ -953,7 +953,10 @@
"tolm = %x, remapbase = %x, remaplimit = %x\n", pvt->tolm,
pvt->remapbase, pvt->remaplimit);
- if (edac_mc_add_mc(mci)) {
+ /* Here we assume that we will never see multiple instances of this
+ * type of memory controller. The ID is therefore hardcoded to 0.
+ */
+ if (edac_mc_add_mc(mci,0)) {
debugf3("%s(): failed edac_mc_add_mc()\n", __func__);
goto fail;
}