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 3B022D21240 for ; Thu, 17 Oct 2024 08:37:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C4DF56B0089; Thu, 17 Oct 2024 04:37:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFDB56B008A; Thu, 17 Oct 2024 04:37:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A50BC6B008C; Thu, 17 Oct 2024 04:37:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 805446B0089 for ; Thu, 17 Oct 2024 04:37:57 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C44E041158 for ; Thu, 17 Oct 2024 08:37:50 +0000 (UTC) X-FDA: 82682441100.24.EB6DC0A Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf08.hostedemail.com (Postfix) with ESMTP id 67791160017 for ; Thu, 17 Oct 2024 08:37:48 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.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=1729154115; 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=ZOLJbkhO8CF12AXvkGOQpPBfTXQmCceX929/1ORxTcY=; b=sfjcRLVedp/m9peXPD4Yvx/dxWo4HSza9WNN4BxF5eRH2owyl+XBSHjMaRj0ju4Yk/ksYV y88ZDrMOnYR5z/qEwX6Jih9/mMrq1iY65a4FUGvbcpGQitwG5xseTMnUSTMHTW0F3I99li a7Tube+VvAxSHaa1v/KTgNY7B+loCVo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729154115; a=rsa-sha256; cv=none; b=aqg6x86ERIqhEY09mU8n13A+UKaRtIWXcjaKAFMeWd1Duyf+CDb1U41fdTh3ifGkKbgIKb RWSbT6gpcj7h3kkIO5Yg/KQgdxu44B04wNbOEqAu1/2nChjZBRuC1gMjK4OVPH7uQwk1GU NazwsfDH3BVk9s8kTOU/bdljUYBM4wg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XTh605KJKz6K9C4; Thu, 17 Oct 2024 16:37:12 +0800 (CST) Received: from frapeml100007.china.huawei.com (unknown [7.182.85.133]) by mail.maildlp.com (Postfix) with ESMTPS id 7DB13140119; Thu, 17 Oct 2024 16:37:52 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100007.china.huawei.com (7.182.85.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 17 Oct 2024 10:37:52 +0200 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.039; Thu, 17 Oct 2024 10:37:51 +0200 From: Shiju Jose To: Borislav Petkov 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" , "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: [PATCH v13 01/18] EDAC: Add support for EDAC device features control Thread-Topic: [PATCH v13 01/18] EDAC: Add support for EDAC device features control Thread-Index: AQHbGkjIT8EMR4nHhkSztyssI50yp7KJHpUAgABGrZA= Date: Thu, 17 Oct 2024 08:37:51 +0000 Message-ID: References: <20241009124120.1124-1-shiju.jose@huawei.com> <20241009124120.1124-2-shiju.jose@huawei.com> <20241016105832.GSZw-cWDOFweQMWRgZ@fat_crate.local> In-Reply-To: <20241016105832.GSZw-cWDOFweQMWRgZ@fat_crate.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.175.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 67791160017 X-Stat-Signature: nm74mis1w3xse8dd3tcbe6w541o8i41x X-Rspam-User: X-HE-Tag: 1729154268-601080 X-HE-Meta: U2FsdGVkX19Sa+9lkLK9Zla1UtFD93apWptM0xZMKt4wp17VHEsrQVDFMCrWZ8dM2ZJ2XqLD/I5z9nfig2kCHFeN+v05pObNoCdVnNWEoZpUT/pd9jbGECnH4eH6q9ePGNbUkFbs0f6WGvN92fLeIL28LXfJ7Rq+NknOwtp2QHkx1DC/3g2KzAwhZlsOB4flwM5adoIF6szHEJ5nsDCUG135zMc7OpxonatjJYLfU2RADBXb1TzUXrFSZYhoFb/2U6NXPJ/OqWDNNoQaJ0aeBhU+HtsJaVfbyFGsPBS8khG3rHdIqf49vzrrgqDobnl+dui3Z4hNOYmpBGSRzcPhHRDdPzR03qZ222FONCWofC2pYWYPa07KweuLCHy1PqYWYfGMfkSQmydr1ibrX2roofCkwG5WcgynnKwoUJ6x10NlobOiImZ6YebSqv+tvdNcdA020hNfCcHjsRAznfFEnM2t27x7z/DG8IZtH5EP260EnhdKKPogbq6cO6kF/UV3pI6xvhyHZjs6Hm6PGufCxj2X8GDoQtT9buX5oOK1JVSRUWEJ4V1vdq4aPaFW1MrcUHc6Xc12rweQrA1x6dxOaK7Xti+5vLoX+9gyn86CfAELv3UW4w4TgmKOyzn4IiTEEinp3uU6Vhn7D9nTR1qjdEMO7C6VWT2MQ9TiSeGqyctDUblucYLzp1Y0ZSacOoWRMZV9RUyQgDfXylbqhmHKirzf3lf01voBpPGzRsaUQFoW1fJqPul4mD/+7vWfKJUuRnaW/XsOw8U1Rwr3jH/IaqOZv2aNr+vuDqed9trbkIuA2L6n/QabAjc25OihkgJFsL5y35Ppq/VVmTUxcEx+cP/QzU9WxPnuVeekOmiBuP4/xoJHFsmolDQxoMekdYtRsE2RxCDSUXBLwgYeXMyr2bLH2KWf9/rnCppaxIEi1ivtvbbw32DKX+N1aEOVeAe7HHXohmeSPVc/vdx/1Yv LnUZzoPN RN0BuAnFKLUr1qvvDx8+u8Dn4xF0KAU4bHcj9yJGnAbWcpjWI6r6r0QEgdxJdyDg2oV3eSkObD4i1BorLQwk0TPOu2UYDGT7wULgATrM6KQ/ZDstuFipJdhTe860cxEgf9jxw65/CKJJ3RuYKhem8u/QijNOouZTlekTXBOYC/Izi7N1sGWlFrYe4DiTTNsU/nuL2W7xmxDzJuhb+hXwtNejypC4JP7EJYK8pae3yBF14dBoh4XfRc6MclFm0Nmak1D8WsnpWHW5y/9Kpg9ZZA0h4Fy8HXwUE8YJr3/YKMMpJwwRabj+0A37YXa4lSqbQ258d88nB0Nsbj+3ZL6DjEqlSr+rvwjhAt6VdDg9LVgLFMNNA5iASWTk8DoDH3o1YHMBgxGexF732feWGcO7Y/9hR+nKpzddbvYRSUNKstX2hzf8N25GR7uT4BnTdTJh88ueVSBK4dk9BkhkyEn4slOUmKBBbT2xiWbhe1a6SsJbCo61vbgbFK7aqJgcIZyoYNjvDmjSfcBVJuJjll9CoCKD9nbe6Joia6dI6oU2d+65TXbG3dFh6Mona/kGULTxCESu7+B/jqPtSWcGq02L5NK3uMjRocjVsaGEHpz2n0B8XpxkId/10rmk0AJdCe6tU1mqtD5y0mtIKaFGsgaHl+YjZlQ1JjUsK/uKksu7ABMAU8aJkjS/pcXCgzwueOwfePYthrUb2jjpgwMCpyGiAmVeQDymCeBsShW541i8KdIVL576shLnuHCyFGuznQrRM2MRDyUK4IrSTHBTjyIiOIiFz1l4rNc76kthxMfm4s6j5vZVDERt8xyXcPQaddSQ2lCaVZmCLMQnBreOTe0vUW6ajCw== 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 Boris, Thanks for the comments. >-----Original Message----- >From: Borislav Petkov >Sent: 16 October 2024 11:59 >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; 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: [PATCH v13 01/18] EDAC: Add support for EDAC device features >control > >On Wed, Oct 09, 2024 at 01:41:02PM +0100, shiju.jose@huawei.com wrote: >> From: Shiju Jose >> >> Add generic EDAC device features control supports registering RAS >> features supported in the system. Driver exposes features control >> attributes to userspace in >> /sys/bus/edac/devices/// > >Chatgpt prompt: > >| Please check the grammar in this English text: "Add generic EDAC >| device features control supports registering RAS features supported in t= he >system. >| Driver exposes features control attributes to userspace in >| /sys/bus/edac/devices/// > >Response: > >| Here's a corrected version of the text: >| >| "Add generic EDAC device feature control support for registering RAS >| features supported in the system. The driver exposes feature control >| attributes to userspace in /sys/bus/edac/devices///." >| >| Changes made: >| >| * "features control" was changed to "feature control" for consistency >| and clarity. >| >| * "supports registering" was changed to "support for registering" to >| match the structure of the sentence. >| >| * Added "The" at the beginning of the second sentence for better flow. >| >| * Corrected the syntax around the file path to ensure clarity and >| proper >| * punctuation. > >Please run all your commit text through some LLM AI as they're apparently = good >enough now to help me in correcting grammar. Will do. > >> Co-developed-by: Jonathan Cameron >> Signed-off-by: Jonathan Cameron >> Signed-off-by: Shiju Jose >> --- >> drivers/edac/edac_device.c | 105 >+++++++++++++++++++++++++++++++++++++ >> include/linux/edac.h | 32 +++++++++++ >> 2 files changed, 137 insertions(+) >> >> diff --git a/drivers/edac/edac_device.c b/drivers/edac/edac_device.c >> index 621dc2a5d034..0b8aa8150239 100644 >> --- a/drivers/edac/edac_device.c >> +++ b/drivers/edac/edac_device.c >> @@ -570,3 +570,108 @@ void edac_device_handle_ue_count(struct >edac_device_ctl_info *edac_dev, >> block ? block->name : "N/A", count, msg); } >> EXPORT_SYMBOL_GPL(edac_device_handle_ue_count); >> + >> +/* EDAC device feature */ >> +static void edac_dev_release(struct device *dev) { >> + struct edac_dev_feat_ctx *ctx =3D container_of(dev, struct >> +edac_dev_feat_ctx, dev); >> + >> + kfree(ctx->dev.groups); >> + kfree(ctx); >> +} >> + >> +const struct device_type edac_dev_type =3D { >> + .name =3D "edac_dev", >> + .release =3D edac_dev_release, >> +}; >> + >> +static void edac_dev_unreg(void *data) { >> + device_unregister(data); >> +} >> + >> +/** >> + * edac_dev_register - register device for RAS features with EDAC >> + * @parent: client device. > >If this is a client device, why is the variable called "parent" and not "c= lient"? > >I.e., > > struct device *client; > >For clarity and simplicity. > >Or call it "parent" because you do: > > ctx->dev.parent =3D parent; > >and forget "client" altogether. Changed to "parent".=20 > >> + * @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. >> + * >> + * Return: >> + * * %0 - Success. >> + * * %-EINVAL - Invalid parameters passed. >> + * * %-ENOMEM - Dynamic memory allocation failed. >> + * >> + * The new edac_dev_feat_ctx would be freed automatically. > >Why is this important to call out here? > >It is a common coding pattern of freeing resources in the release function= ... Deleted. > >> + */ >> +int edac_dev_register(struct device *parent, char *name, >> + void *private, int num_features, >> + const struct edac_dev_feature *ras_features) { >> + const struct attribute_group **ras_attr_groups; >> + struct edac_dev_feat_ctx *ctx; >> + int attr_gcnt =3D 0; >> + int ret, feat; >> + >> + if (!parent || !name || !num_features || !ras_features) >> + return -EINVAL; >> + >> + /* Double parse to make space for attributes */ >> + for (feat =3D 0; feat < num_features; feat++) { >> + switch (ras_features[feat].ft_type) { >> + /* Add feature specific code */ >> + default: >> + return -EINVAL; >> + } >> + } >> + >> + ctx =3D kzalloc(sizeof(*ctx), GFP_KERNEL); >> + if (!ctx) >> + return -ENOMEM; >> + >> + ctx->dev.parent =3D parent; >> + ctx->private =3D private; >> + >> + ras_attr_groups =3D kcalloc(attr_gcnt + 1, sizeof(*ras_attr_groups), >GFP_KERNEL); >> + if (!ras_attr_groups) { >> + ret =3D -ENOMEM; >> + goto ctx_free; >> + } >> + >> + attr_gcnt =3D 0; >> + for (feat =3D 0; feat < num_features; feat++, ras_features++) { >> + switch (ras_features->ft_type) { >> + /* Add feature specific code */ >> + default: >> + ret =3D -EINVAL; >> + goto groups_free; >> + } >> + } >> + >> + ras_attr_groups[attr_gcnt] =3D NULL; >> + ctx->dev.bus =3D edac_get_sysfs_subsys(); >> + ctx->dev.type =3D &edac_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 groups_free; >> + >> + ret =3D device_register(&ctx->dev); >> + if (ret) { >> + put_device(&ctx->dev); >> + goto groups_free; >> + return ret; > ^^^^^^^^^^ > >Come again?! > >There's code after a "goto"? Fixed. > >-- >Regards/Gruss, > Boris. > >https://people.kernel.org/tglx/notes-about-netiquette Thanks, Shiju