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 D0DA1C3ABA2 for ; Mon, 16 Sep 2024 10:50:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DF5C6B0089; Mon, 16 Sep 2024 06:50:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28FD76B008A; Mon, 16 Sep 2024 06:50:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 157726B008C; Mon, 16 Sep 2024 06:50:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id ED75F6B0089 for ; Mon, 16 Sep 2024 06:50:25 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8DDA01A028E for ; Mon, 16 Sep 2024 10:50:25 +0000 (UTC) X-FDA: 82570282410.06.5349E25 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf18.hostedemail.com (Postfix) with ESMTP id 6D79E1C0010 for ; Mon, 16 Sep 2024 10:50:21 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf18.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726483791; a=rsa-sha256; cv=none; b=KoffU0k3eROiX+rODcSzKnkQJKNo+1BQAxFEio+sN0gf+bHtDWNx5BVPG/eOzQVSQZh3cc JovTCPIMSqKrINAP1Wc5VtTZj4GtjtoW8e2w62xnJjea1RMndMAJ2Vu20Njjqmxy1AQSOl WK64DKjLzdp+mfikCGSIO42NCA43QaQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf18.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726483791; 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=LYVHE8XXhiQeMS8sezI4VhAtH59sNazwLKCnps0L7jY=; b=A8s1HQfI8IsXab0vWuQZxy6O9yqv0PkYP8cZ9v0XPLtrsIlPqo299Aw9VtBBAp/4kTDeB1 /F7Z+8OUpQ+KvU7Nybspu4hLpJ+NHkfIc5wk45rx+EOwwpQqrfV/xWyB/GK4I3GvG0LE0X 4scbVq30BtS/OZm1thaOFh7zqoCGWLg= Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4X6hWp1XDXz6K5xQ; Mon, 16 Sep 2024 18:50:14 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 06083140F5E; Mon, 16 Sep 2024 18:50:18 +0800 (CST) Received: from localhost (10.203.177.66) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 16 Sep 2024 12:50:16 +0200 Date: Mon, 16 Sep 2024 11:50:14 +0100 From: Jonathan Cameron To: Shiju Jose CC: Borislav Petkov , "linux-edac@vger.kernel.org" , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "tony.luck@intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "dan.j.williams@intel.com" , "dave@stgolabs.net" , "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" , "jgroves@micron.com" , "vsalve@micron.com" , tanxiaofei , "Zengtao (B)" , "Roberto Sassu" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: Re: [PATCH v12 01/17] EDAC: Add support for EDAC device features control Message-ID: <20240916115014.000064bf@Huawei.com> In-Reply-To: References: <20240911090447.751-1-shiju.jose@huawei.com> <20240911090447.751-2-shiju.jose@huawei.com> <20240913164041.GKZuRrCeoFZBapVYaU@fat_crate.local> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.177.66] X-ClientProxiedBy: lhrpeml500004.china.huawei.com (7.191.163.9) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspam-User: X-Rspamd-Queue-Id: 6D79E1C0010 X-Rspamd-Server: rspam01 X-Stat-Signature: y5qmsbdq1xy69kaoq3h44fw1fk4yccdj X-HE-Tag: 1726483821-967971 X-HE-Meta: U2FsdGVkX18y/s7b31XeCCFcAVe981eVKKMzyyuFJOceZLREgho6EX2OPzzNLkBiKeDyH1oSOLQZBrWZNKtmAZbpcFTBgFzDXVUPkBu0KIRn2EURivdO35ywG5zuVD3w7SpcM3nDjVM1ope1YWBmujO0hDEAfb/cCEAGNL/ns4IWTkEI8t7ilzqeWJtglhkcJt3T9ANObNisU9JUJzVjPvsE90EcQEIMqmtHxtn3iQ7KmORsmguCkHdzhFTgk3NQxUg4Rkzax4dVmi7jrrWss5K2JMA/7AWPZa0DxmTf52vCWRM+o8LDt/J3fLTnBfFCflfhGkaaFT7V2CjWDQ/z3CqVobdWtx5h/rrHc10I0t8MQmx85gzOXQsP5KtSmr+gJMyuNSl8wwug1tg0VmYSLis1AqK2yLFEOCzU0ddQos9IfyyrQHET2tICyqSCtS8zulGb3qlT6/5Xwvsg9qBNm2MGrYKIGsPAGQXqrofMDyZWmN+JmLcDfaE27foMlWEz9ppdfAEH60wqUitqMGU8d8F1TJCCvPBrEMreWfnri84dq1nJ08/o+aOFGBufXqFcRxW3CevHp0wjEKEKNMJDzSxa1azjO+meYz2P1084S0ZNnTnQeIaDWyiF6SzsZSZHFvChiMD0GMMEXMZd/N1N2mwsBU4SbqT1ENhEOHiUIMF4NkG7NLcKF3V1FXKQ1i/bh94mFoLsX/MgHkCN25KQbKBylQXrzPEh42/0iwG6v1vBvIT4+sGEYNaeoMPmlTXVi91GS01luKOWVN6i1erdGRWaS5eJ8EYUYMLMnFi80IowL1HQN6oSUN0Q4zO0L5IUmTP/vV3yJCczw3zGdSEKu4484s4ayAnGwYPYGrQRtwwYxOlCvl0ylu2HiPMf46OA3+QoxdaS9y9L+Wu94atA6fzWlQJcJyUOvSrZQvHpva3mEIhLcvXxp1rBzxfwljdj3UbBAOxxV26YiUrPlC3 fbsNIedc tKDr8Y6rrIxVNTbehtlavRAcLLnawaIQxTrKw/dw5egTvd1egEw8Ex/dah+Ei8v1AmpD1ldxwGhDjVerx3pkI0YkwhVdeIcJQ3ZaibEOxIqz9Vd/vGuvhyQdrzK4vNJAIoAfifNzPlPfjeUg+yQIPV8GZHpy7vSuOh1eM8hhqBUmAYnlNJn9vSFj1M3/6XhoQYm9kIxxNd6wp6enhfCkhidTidwYQkRd7n2J8jhweS9CAMpReiNq/KBGslaJaaA1Tj7yLorbgr37A0ARQ/mHZg1oZXxnXpx9nwKKjJ6vsCoJ2lA/gyj/ytzDxPWnT1kT/NcM0DMF0wORNf/po/+LUVwMxJ9To85FYayiAyJwKygFF6EMgXXFTL8AadAU8oqPhMpP1vJo7P4u9zdr9FplFB9WdVvEPqvHf8LwacT2jRBf2uCo5RtR+mnVkF/0QQjLtLEwe3qwUkNM1JSuydLPJfUYaj+oew42fmm7fMdVbkGGspK4F9YcbzdFN0uIbYZ03kf/iR3Gm8DbJJNQSpUIXksTD/1eXBWJ+JbJkc98/j16ov6+EuM8V4H2QI4SNlSVOrX0PBhK44Xhane2kCqi0pnoODFZTZJQnXm87UZn4EKMsoxpPdRcXHWuH9bPGmUZS6NBOOQR5f9jeheKI/AG8XKye6iuF+4T3Z7r9LBAOv6bhB82FEcC6XecvbUvmvwY7ChU7Ma3cFtBNGYqC5Z1y14PHlzlRGT8mJPTf4g7tft12x5YXu2NlgZ8sgSaOZX/5gtSQ9qJfQdTMmpVdGGLSa4oNo5sx023jn5LziUnZsCCY7P9Csg7tAPpqbBvI0OzJcPLOiqJ+Rt6FR10Op6i1uUXf7f8AxSR24wpXBDTl5eSQKJu4rtBqQfT2/jXcFEoPtcz4NADqoJsBUckjs+wKSPCrf7h4w4TLMutb8dVjwDpPnBgIWJMDn5d/fQ== 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: On Mon, 16 Sep 2024 10:21:58 +0100 Shiju Jose wrote: > Thanks for reviewing. > > >-----Original Message----- > >From: Borislav Petkov > >Sent: 13 September 2024 17:41 > >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; > >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; jgroves@micron.com; > >vsalve@micron.com; tanxiaofei ; Zengtao (B) > >; Roberto Sassu ; > >kangkang.shen@futurewei.com; wanghuiqiang ; > >Linuxarm > >Subject: Re: [PATCH v12 01/17] EDAC: Add support for EDAC device features > >control > > > >On Wed, Sep 11, 2024 at 10:04:30AM +0100, shiju.jose@huawei.com wrote: > >> +/** > >> + * edac_dev_feature_init - Init a RAS feature > >> + * @parent: client device. > >> + * @dev_data: pointer to the edac_dev_data structure, which contains > >> + * client device specific info. > >> + * @feat: pointer to struct edac_dev_feature. > >> + * @attr_groups: pointer to attribute group's container. > >> + * > >> + * Returns number of scrub features attribute groups on success, > > > >Not "scrub" - this is an interface initializing a generic feature. > Will correct. > > > >> + * error otherwise. > >> + */ > >> +static int edac_dev_feat_init(struct device *parent, > >> + struct edac_dev_data *dev_data, > >> + const struct edac_dev_feature *ras_feat, > >> + const struct attribute_group **attr_groups) { > >> + int num; > >> + > >> + switch (ras_feat->ft_type) { > >> + case RAS_FEAT_SCRUB: > >> + dev_data->scrub_ops = ras_feat->scrub_ops; > >> + dev_data->private = ras_feat->ctx; > >> + return 1; > >> + case RAS_FEAT_ECS: > >> + num = ras_feat->ecs_info.num_media_frus; > >> + dev_data->ecs_ops = ras_feat->ecs_ops; > >> + dev_data->private = ras_feat->ctx; > >> + return num; > >> + case RAS_FEAT_PPR: > >> + dev_data->ppr_ops = ras_feat->ppr_ops; > >> + dev_data->private = ras_feat->ctx; > >> + return 1; > >> + default: > >> + return -EINVAL; > >> + } > >> +} > > > >And why does this function even exist and has kernel-doc comments when all it > >does is assign a couple of values? And it gets called exactly once? > > > >Just merge its body into the call site. There you can reuse the switch-case there > >too. No need for too much noodling around. > edac_dev_feat_init () function is updated with feature specific function call() etc in subsequent > EDAC feature specific patches. Thus added a separate function. > > > >> diff --git a/include/linux/edac.h b/include/linux/edac.h index > >> b4ee8961e623..b337254cf5b8 100644 > >> --- a/include/linux/edac.h > >> +++ b/include/linux/edac.h > >> @@ -661,4 +661,59 @@ static inline struct dimm_info > >> *edac_get_dimm(struct mem_ctl_info *mci, > >> > >> return mci->dimms[index]; > >> } > >> + > >> +/* EDAC device features */ > >> + > >> +#define EDAC_FEAT_NAME_LEN 128 > >> + > >> +/* RAS feature type */ > >> +enum edac_dev_feat { > >> + RAS_FEAT_SCRUB, > >> + RAS_FEAT_ECS, > >> + RAS_FEAT_PPR, > >> + RAS_FEAT_MAX > > > >I still don't know what ECS or PPR is. > I will add comment/documentation here with a short explanation of features > if that make sense? > Each feature is described in the subsequent EDAC feature specific patches. Can you bring the enum entries in with those patches? That way there is no reference to them before we have the information on what they are. J > > > >-- > >Regards/Gruss, > > Boris. > > > >https://people.kernel.org/tglx/notes-about-netiquette > > Thanks, > Shiju >