From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34AB5C3DA42 for ; Wed, 17 Jul 2024 11:02:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7B996B00A3; Wed, 17 Jul 2024 07:02:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2ADE6B00A4; Wed, 17 Jul 2024 07:02:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87DD66B00A5; Wed, 17 Jul 2024 07:02:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 63BAB6B00A3 for ; Wed, 17 Jul 2024 07:02:07 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 114A6A0A91 for ; Wed, 17 Jul 2024 11:02:07 +0000 (UTC) X-FDA: 82348955094.05.F7D9B76 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf12.hostedemail.com (Postfix) with ESMTP id AB79C40016 for ; Wed, 17 Jul 2024 11:02:03 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721214094; a=rsa-sha256; cv=none; b=17ui6CJoQEzvcuKizONFiB0wxSYdOTN7ULrUPBDKxGYVMw+A8LC5PukX7LhyLwmhaQS4rh 6SL0CGbchqH4vttpxzYECxzJqoxE1NPY9vniB+43ba3uJNHkSO8PJHj1gA3E0NcQzGsonF cqGxMLenTL7ZT/9oa0Qs58/N+ko7aw8= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721214094; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5Z5Wk5hgPto7qAY8Tf3dx4zVmr4BLfRP7ceCNVQgS30=; b=EZCttNVFc6qFqNhHTqOTUY9QgM6VvNmzR6XZ017UrqitjG/mUQ2a2VRTa+qnHxi6g4Ba8b ePxIp6/1QBjuHTuq32huY720hc6etdY7SwqBdjzHQyiljN0YsyEjDF6qcAHMg4XCbAr2ir lWOT/qUzjDmpx95gmP/ViyW7NLkyhgA= Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4WPCcw4Y3gz6K98Q; Wed, 17 Jul 2024 18:59:44 +0800 (CST) Received: from lhrpeml100005.china.huawei.com (unknown [7.191.160.25]) by mail.maildlp.com (Postfix) with ESMTPS id 2F9461400DB; Wed, 17 Jul 2024 19:01:59 +0800 (CST) Received: from lhrpeml500006.china.huawei.com (7.191.161.198) by lhrpeml100005.china.huawei.com (7.191.160.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 17 Jul 2024 12:01:58 +0100 Received: from lhrpeml500006.china.huawei.com ([7.191.161.198]) by lhrpeml500006.china.huawei.com ([7.191.161.198]) with mapi id 15.01.2507.039; Wed, 17 Jul 2024 12:01:58 +0100 From: Shiju Jose To: Mauro Carvalho Chehab CC: "linux-edac@vger.kernel.org" , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "bp@alien8.de" , "tony.luck@intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "dan.j.williams@intel.com" , "dave@stgolabs.net" , "Jonathan Cameron" , "dave.jiang@intel.com" , "alison.schofield@intel.com" , "vishal.l.verma@intel.com" , "ira.weiny@intel.com" , "david@redhat.com" , "Vilas.Sridharan@amd.com" , "leo.duran@amd.com" , "Yazen.Ghannam@amd.com" , "rientjes@google.com" , "jiaqiyan@google.com" , "Jon.Grimm@amd.com" , "dave.hansen@linux.intel.com" , "naoya.horiguchi@nec.com" , "james.morse@arm.com" , "jthoughton@google.com" , "somasundaram.a@hpe.com" , "erdemaktas@google.com" , "pgonda@google.com" , "duenwen@google.com" , "mike.malvestuto@intel.com" , "gthelen@google.com" , "wschwartz@amperecomputing.com" , "dferguson@amperecomputing.com" , "wbs@os.amperecomputing.com" , "nifan.cxl@gmail.com" , tanxiaofei , "Zengtao (B)" , "Roberto Sassu" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: RE: [RFC PATCH v9 01/11] EDAC: Add generic EDAC RAS feature driver Thread-Topic: [RFC PATCH v9 01/11] EDAC: Add generic EDAC RAS feature driver Thread-Index: AQHa15FyV2KoSGHoUUqpwpmK3mdCjbH6oGWAgAAYuNA= Date: Wed, 17 Jul 2024 11:01:58 +0000 Message-ID: <2cb0dde458bd4eb79b0a96cb99fe1ef5@huawei.com> References: <20240716150336.2042-1-shiju.jose@huawei.com> <20240716150336.2042-2-shiju.jose@huawei.com> <20240717120027.7168536a@foz.lan> In-Reply-To: <20240717120027.7168536a@foz.lan> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.247.218] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Queue-Id: AB79C40016 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: n57azep4jz1ccxdrfrcd6fs4f37gak8h X-HE-Tag: 1721214123-474139 X-HE-Meta: U2FsdGVkX1+TEEqOgQ2YuHsBopmeg1el+3NgT5pThHWIZfcM+tMp88qY/cg56WGSfLRMdq11/FlgjYUZ7WoHPTyGTiCNQ60U4WAzUO2/JrFcPVrEm1XJc2zxvPSC2ww6qDrtjCOoPE2jqAvy4DE5QlCi8rx43r0sQd0C9s+LgqaGbBngtdOTkbsbETNNPAEmreEIubsaxCq7xkAtAGD1JVs6GUiiH9I1/RhPY2gGWbfFGW7pwMPQvXrLbjBTbkOjova+kbU/XW6bkdfa0XpzZ5L5oulO5SCD5htstcG48VLTH8kPszUlopU4aGWjDHCf/QBsqKMtkQUZL9+RINkOlIcQHNQqBZ5Ts2eXE/kIDd/ZvEoju36r0WWw3cX4TdM46rJSshlWISG2VyOEfyUzgPkxNL/I6RlsOHYf6eNataUXF93dPwTCK89KM1FwHi36iTtlVsppRTIzTG5DAKvdaH66m8vP7ypFg4KY2TMHvhT6lDVNKhZQMc1IAz+f0UytVsiRM1xrvIa4EdDeW2eFaeCB+kRp99j3tXkpWSre/nQLk87hlJ3UHPOIab+fCPKbvNdhoSUavI4rxkQh5BFE0EykPqeFIcQXHjmkLKfZ9vS2Mi8abaRPISbiM23atorySxgPQvzzFj+iJ2/hCyC2zljyI1HpmD6udj8SSJkLqfNhkeYs86HfcIA/32Wq5YRMVje1CkgGS2IJRwmT0v4+ljmLbXUUWNxTZrAznUHE292HpIfDgnnX11WR/5SvgzVNGalqwgLpLGByjuYd+pqf23Iu8g3mtSG4nb641Giz80oMyt8LOVs0TyykyVj7sqFMwjq0BxgospkBt7/6chsySY/TPTXFiGScXS06y5YJqG2y236UwlGh/PwzpoZVe15LYz0BhzAx4zM8Q82UrADQ7BRZHFdU9E6Q1d5B5yK3e2bR9TtRufnQKMfENvWZQk1AQf1XCKhnK7JbgfruaAW qowFBCvD 3Rm3RM5FobQjcIjT0ISfAvNf8Jw5qBucnI3QARmyrjILDha0ixGPCJW6RplnupwrUS7oVq/KAm3+bPEfrOCWicV3JbSJSD0C1gjBsWz919tguvgDl6okHCtk6wxo9xSouhyToKF6/DJ2I2gPxUN4Te7iMhz1DMhRpmCx4dHfVh6DEIdgiOOzT3J/3s3am2F6+EOi4Qk6n7pySAp5F2t2QEBoNx58PtxrzByM8jTFdYE9qX1BKmWaIMSbcP0a9JkLULGDoPOc+gxfMPNs0kXk410rOBZhZf0eX6VQoa6OyAFiP2kbR0tpMidlwvM/HTLe4V2FHgrjSFihLn6wQFmG4E4NlvatkyTl+0Mm0poI7e7JA4rWVl58Uh2HgqbbOR+uBOTNUDLY5k5R2cr1i6uE7ar7kL7a/DH9+t2pRmnHeYdkdvuJdNShmVvUz07XMIx1zfpsm+9rGEpRqy2XgvJBlfGwunSA8o9rT2GuWtfhu+3azMa6X2V7+iCeDRDtYiVk2fw41JP87XAciaEZSon3Riy5xTUSD8vMg+MMEyPyYbDIJyzo6MR8X/CMGzP6TmpL9DOSJ/iHaNuJWJrtTBcV74Ala850GnwJgtNMRPhPNLPLwhUjHRkZh/+D14kv8/NeXrdJ+x7aMCTx4hTixJriIdaEWlVu0sxSXT/KkW1vDFfiWgk5YJ6HNBjLsNC2cNBjkpczSYWAUw31TQHTjF4u2YWyQyCZyANZfHWEDguj5GodrZVUFWwGxwzUW1OoBQShIHxd/Lbd+34MEUar2bNfbdpgTs97bVgdzURLUANxp/CPQ24MtYOP37Z5ux4xGkz1Z4+vFSOh85AqbgKuBdMuBe4ZARt4slo3OvkORW1FEmgVq1c9jyiR0Q/7tstJn75QAN1wBMhymVWbCHT7UhJvkIP0kMZpIV29Vi9LG X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Mauro, Thanks for the feedbacks. >-----Original Message----- >From: Mauro Carvalho Chehab >Sent: 17 July 2024 11:00 >To: Shiju Jose >Cc: linux-edac@vger.kernel.org; linux-cxl@vger.kernel.org; linux- >acpi@vger.kernel.org; linux-mm@kvack.org; linux-kernel@vger.kernel.org; >bp@alien8.de; tony.luck@intel.com; rafael@kernel.org; lenb@kernel.org; >mchehab@kernel.org; dan.j.williams@intel.com; dave@stgolabs.net; Jonathan >Cameron ; dave.jiang@intel.com; >alison.schofield@intel.com; vishal.l.verma@intel.com; ira.weiny@intel.com; >david@redhat.com; Vilas.Sridharan@amd.com; leo.duran@amd.com; >Yazen.Ghannam@amd.com; rientjes@google.com; jiaqiyan@google.com; >Jon.Grimm@amd.com; dave.hansen@linux.intel.com; >naoya.horiguchi@nec.com; james.morse@arm.com; jthoughton@google.com; >somasundaram.a@hpe.com; erdemaktas@google.com; pgonda@google.com; >duenwen@google.com; mike.malvestuto@intel.com; gthelen@google.com; >wschwartz@amperecomputing.com; dferguson@amperecomputing.com; >wbs@os.amperecomputing.com; nifan.cxl@gmail.com; tanxiaofei >; Zengtao (B) ; Roberto >Sassu ; kangkang.shen@futurewei.com; >wanghuiqiang ; Linuxarm > >Subject: Re: [RFC PATCH v9 01/11] EDAC: Add generic EDAC RAS feature drive= r > >Em Tue, 16 Jul 2024 16:03:25 +0100 > escreveu: > >> From: Shiju Jose >> >> Add generic EDAC driver supports registering RAS features supported in >> the system. The driver exposes feature's control attributes to the >> userspace in /sys/bus/edac/devices/// >> >> Co-developed-by: Jonathan Cameron >> Signed-off-by: Jonathan Cameron >> Signed-off-by: Shiju Jose >> --- >> drivers/edac/Makefile | 1 + >> drivers/edac/edac_ras_feature.c | 155 >> +++++++++++++++++++++++++++++++ include/linux/edac_ras_feature.h | >> 66 +++++++++++++ >> 3 files changed, 222 insertions(+) >> create mode 100755 drivers/edac/edac_ras_feature.c create mode >> 100755 include/linux/edac_ras_feature.h >> >> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile index >> 9c09893695b7..c532b57a6d8a 100644 >> --- a/drivers/edac/Makefile >> +++ b/drivers/edac/Makefile >> @@ -10,6 +10,7 @@ obj-$(CONFIG_EDAC) :=3D edac_core.o >> >> edac_core-y :=3D edac_mc.o edac_device.o edac_mc_sysfs.o >> edac_core-y +=3D edac_module.o edac_device_sysfs.o wq.o >> +edac_core-y +=3D edac_ras_feature.o >> >> edac_core-$(CONFIG_EDAC_DEBUG) +=3D debugfs.o >> >> diff --git a/drivers/edac/edac_ras_feature.c >> b/drivers/edac/edac_ras_feature.c new file mode 100755 index >> 000000000000..24a729fea66f >> --- /dev/null >> +++ b/drivers/edac/edac_ras_feature.c >> @@ -0,0 +1,155 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * EDAC RAS control feature driver supports registering RAS >> + * features with the EDAC and exposes the feature's control >> + * attributes to the userspace in sysfs. >> + * >> + * Copyright (c) 2024 HiSilicon Limited. >> + */ >> + > >> +#define pr_fmt(fmt) "EDAC RAS CONTROL FEAT: " fmt > >Sounds a too long prefix for my taste. Will do. Previously it was "EDAC RAS FEAT" > >> + >> +#include >> + >> +static void edac_ras_dev_release(struct device *dev) { >> + struct edac_ras_feat_ctx *ctx =3D >> + container_of(dev, struct edac_ras_feat_ctx, dev); >> + >> + kfree(ctx); >> +} >> + >> +const struct device_type edac_ras_dev_type =3D { >> + .name =3D "edac_ras_dev", >> + .release =3D edac_ras_dev_release, >> +}; >> + >> +static void edac_ras_dev_unreg(void *data) { >> + device_unregister(data); >> +} >> + >> +static int edac_ras_feat_scrub_init(struct device *parent, >> + struct edac_scrub_data *sdata, >> + const struct edac_ras_feature *sfeat, >> + const struct attribute_group **attr_groups) { >> + sdata->ops =3D sfeat->scrub_ops; >> + sdata->private =3D sfeat->scrub_ctx; >> + >> + return 1; >> +} >> + >> +static int edac_ras_feat_ecs_init(struct device *parent, >> + struct edac_ecs_data *edata, >> + const struct edac_ras_feature *efeat, >> + const struct attribute_group **attr_groups) { >> + int num =3D efeat->ecs_info.num_media_frus; >> + >> + edata->ops =3D efeat->ecs_ops; >> + edata->private =3D efeat->ecs_ctx; >> + >> + return num; >> +} > >I would place this function earlier and/or add some documentation for the = above >two functions. Will do. I guess you want place these functions above edac_ras_dev_release(= ) right?=20 > >I got confused when reviewed the first function and saw there an >unconditional: The call for the feature specific init functions are added here in the n= ext feature specific patches of this series. =20 > > return 1; > >Now, I guess the goal is to return the number of initialized features, rig= ht? Return the number of attr groups added for a feature as the instances for a= feature is dynamic, for e.g. the number of FRUs in ECS feature. =20 > >> + >> +/** >> + * edac_ras_dev_register - register device for ras features with edac >> + * @parent: client device. >> + * @name: client device's name. >> + * @private: parent driver's data to store in the context if any. >> + * @num_features: number of ras features to register. >> + * @ras_features: list of ras features to register. >> + * >> + * Returns 0 on success, error otherwise. >> + * The new edac_ras_feat_ctx would be freed automatically. >> + */ >> +int edac_ras_dev_register(struct device *parent, char *name, >> + void *private, int num_features, >> + const struct edac_ras_feature *ras_features) { >> + const struct attribute_group **ras_attr_groups; >> + struct edac_ras_feat_ctx *ctx; >> + int attr_gcnt =3D 0; >> + int ret, feat; >> + >> + if (!parent || !name || !num_features || !ras_features) >> + return -EINVAL; >> + >> + ctx =3D kzalloc(sizeof(*ctx), GFP_KERNEL); >> + if (!ctx) >> + return -ENOMEM; >> + >> + ctx->dev.parent =3D parent; >> + ctx->private =3D private; >> + >> + /* Double parse so we can make space for attributes */ >> + for (feat =3D 0; feat < num_features; feat++) { >> + switch (ras_features[feat].feat) { >> + case ras_feat_scrub: >> + attr_gcnt++; >> + break; >> + case ras_feat_ecs: >> + attr_gcnt +=3D >ras_features[feat].ecs_info.num_media_frus; >> + break; > >As already suggested, the enum names shall be in uppercase. >Having a lowercase one here looks really weird. Agree. > >> + default: >> + ret =3D -EINVAL; >> + goto ctx_free; >> + } >> + } > >I would place this logic earlier, before allocating ctx, as, in case of er= rors, the >function can just call "return -EINVAL". Ok. > >> + >> + ras_attr_groups =3D devm_kzalloc(parent, >> + (attr_gcnt + 1) * sizeof(*ras_attr_groups), >> + GFP_KERNEL); > >Hmm... why are you using devm variant here, and non-devm one for cxt? > >My personal preference is to avoid devm variants, as memory is only freed >when the device refcount becomes zero (which, depending on the driver, may >never happen in practice, as driver core may keep a refcount, depending on= how >the device was probed). Can use Kzalloc and need to add free for ras_attr_groups on error etc.=20 > >> + if (!ras_attr_groups) { >> + ret =3D -ENOMEM; >> + goto ctx_free; >> + } >> + >> + attr_gcnt =3D 0; >> + for (feat =3D 0; feat < num_features; feat++, ras_features++) { >> + if (ras_features->feat =3D=3D ras_feat_scrub) { > >I would use a switch here as well, just like the previous feature type che= ck. Will do. > >> + if (!ras_features->scrub_ops) >> + continue; >> + ret =3D edac_ras_feat_scrub_init(parent, &ctx->scrub, >> + ras_features, >&ras_attr_groups[attr_gcnt]); > >I don't think it is worth having those ancillary functions here... > >> + if (ret < 0) >> + goto ctx_free; >> + >> + attr_gcnt +=3D ret; >> + } else if (ras_features->feat =3D=3D ras_feat_ecs) { >> + if (!ras_features->ecs_ops) >> + continue; >> + ret =3D edac_ras_feat_ecs_init(parent, &ctx->ecs, >> + ras_features, >&ras_attr_groups[attr_gcnt]); > >and here, as most of the current functions are very simple: > >both just sets two arguments: > > edata->ops > edata->private > >and returned vaules are always a positive counter... > >> + if (ret < 0) >> + goto ctx_free; > >So, this check for instance, doesn't make sense. The call for the feature specific init functions are added in the next f= eature specific patches of this series and which could return error. =20 > >> + >> + attr_gcnt +=3D ret; >> + } else { >> + ret =3D -EINVAL; >> + goto ctx_free; >> + } >> + } >> + ras_attr_groups[attr_gcnt] =3D NULL; >> + ctx->dev.bus =3D edac_get_sysfs_subsys(); >> + ctx->dev.type =3D &edac_ras_dev_type; >> + ctx->dev.groups =3D ras_attr_groups; >> + dev_set_drvdata(&ctx->dev, ctx); >> + ret =3D dev_set_name(&ctx->dev, name); >> + if (ret) >> + goto ctx_free; >> + >> + ret =3D device_register(&ctx->dev); >> + if (ret) { >> + put_device(&ctx->dev); >> + return ret; >> + } >> + >> + return devm_add_action_or_reset(parent, edac_ras_dev_unreg, >> +&ctx->dev); >> + >> +ctx_free: >> + kfree(ctx); >> + return ret; >> +} >> +EXPORT_SYMBOL_GPL(edac_ras_dev_register); >> diff --git a/include/linux/edac_ras_feature.h >> b/include/linux/edac_ras_feature.h >> new file mode 100755 >> index 000000000000..000e99141023 >> --- /dev/null >> +++ b/include/linux/edac_ras_feature.h >> @@ -0,0 +1,66 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +/* >> + * EDAC RAS control features. >> + * >> + * Copyright (c) 2024 HiSilicon Limited. >> + */ >> + >> +#ifndef __EDAC_RAS_FEAT_H >> +#define __EDAC_RAS_FEAT_H >> + >> +#include >> +#include >> + >> +#define EDAC_RAS_NAME_LEN 128 >> + >> +enum edac_ras_feat { >> + ras_feat_scrub, >> + ras_feat_ecs, >> + ras_feat_max >> +}; > >Enum values in uppercase, please. Will do. > >> + >> +struct edac_ecs_ex_info { >> + u16 num_media_frus; >> +}; >> + >> +/* >> + * EDAC RAS feature information structure */ struct edac_scrub_data >> +{ >> + const struct edac_scrub_ops *ops; >> + void *private; >> +}; >> + >> +struct edac_ecs_data { >> + const struct edac_ecs_ops *ops; >> + void *private; >> +}; >> + >> +struct device; >> + >> +struct edac_ras_feat_ctx { >> + struct device dev; >> + void *private; >> + struct edac_scrub_data scrub; >> + struct edac_ecs_data ecs; >> +}; >> + >> +struct edac_ras_feature { >> + enum edac_ras_feat feat; >> + union { >> + const struct edac_scrub_ops *scrub_ops; >> + const struct edac_ecs_ops *ecs_ops; >> + }; >> + union { >> + struct edac_ecs_ex_info ecs_info; >> + }; > >I would place the variable structs union at the end. This may help with >alignments, if you place the pointers earlier. Will do. > >> + union { >> + void *scrub_ctx; >> + void *ecs_ctx; >> + }; >> +}; >> + >> +int edac_ras_dev_register(struct device *parent, char *dev_name, >> + void *parent_pvt_data, int num_features, >> + const struct edac_ras_feature *ras_features); #endif >/* >> +__EDAC_RAS_FEAT_H */ > > > >Thanks, >Mauro > Thanks, Shiju