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 55851D1AD46 for ; Wed, 16 Oct 2024 10:59:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD1E06B0089; Wed, 16 Oct 2024 06:59:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D5B006B008A; Wed, 16 Oct 2024 06:59:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD4E26B008C; Wed, 16 Oct 2024 06:59:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 98EBF6B0089 for ; Wed, 16 Oct 2024 06:59:34 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 05254A0B6A for ; Wed, 16 Oct 2024 10:59:15 +0000 (UTC) X-FDA: 82679169258.05.75E1EE3 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf02.hostedemail.com (Postfix) with ESMTP id 597E980012 for ; Wed, 16 Oct 2024 10:59:15 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=fail ("body hash did not verify") header.d=alien8.de header.s=alien8 header.b=FCrxX8Yo; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf02.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729076339; a=rsa-sha256; cv=none; b=xYvYAr0sK+SjYwWy+iWBxMklQpGOOmeB5mttxDGIICcXakHUVDxJ+B3SPdRAvtl3Pt/IAA Sp7FuAHgrQMJI+4cjbRjuIcA0rQOdz4E91prJ8b81uH9WFAucra91EJveLizc5teXjtSyL +6zswVfksrhRfRfcnw1lmNvWTJwhqM0= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=fail ("body hash did not verify") header.d=alien8.de header.s=alien8 header.b=FCrxX8Yo; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf02.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729076339; 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:dkim-signature; bh=yhcuhP89HcfDh1C6XfADpSO1ws7cpSBBUpyrhmwKyaM=; b=20ireMw2gdbxvsMZ2ScLrUX6+wbKwwa2BeVt1PP20eYoT2+1WOYjMATwOlDZDxQ2jniIJ7 HEy80pNP35Rrrjciwiin7lWkassP5PmW4zd8maAJeHh1k0UdFl6fjkCtJUFP0tyZXBZ+Bb PZVq4FUzK+p+JRpE7sX6oo0I1zYaIlk= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 6A8AE40E0198; Wed, 16 Oct 2024 10:59:27 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id H-8ABRph_QdB; Wed, 16 Oct 2024 10:59:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1729076361; bh=zv5a7UXvwk4zGhwGx+Twn4ugNezq5/Up+qwxz+Hta1U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FCrxX8YoQ/0ZHFOf4iWtfypQOEK/v75QEQqJ4SCZSvzWZ6ndsHmWNi5BSVB3wDZsH ghUpOMJMJU0c7Lk59YRlV8HC+kKwfmzEkLDx9ShZgxBS/wSkiAkc1fo+s0dEL+qgBI Ft6c7lrtmoWtqZyksnii6gHt0u6RrGxL5NfWtyeAk7wHSSFZb1PW1WN3IA0BaYiNSW ppG7DJp6ZCsJ/SJySvir3y4W4nIQJx0+QDMC142tXw8u4WifNm/coXUNYyPWiMEtS2 v6geuGqyprz5T3/yD1ymW+QS4/Us0w9DZ6507bTKISm81TyhbMbfwNG5l+sr6BD2sV lNw7XDM7eCV+Ka6zhbJmZFtty7T1DnBZQRJyaqwPP1y4CDOz/5ehRWJ8lMgqH8bGK/ 5CE8GXtjuoBKQNbJZ9cvpKeAmhGAQoen6Nz38IJQwg0fBjcGKonYfrXUAjPb3SlqIN sPCcYWGsvpU03dWQTW0PtcWJkez3oCQ0m5UlwrDqvhzM48ikXuUQpmlrxQwDztE5P8 tfrGwtyJiAT7QUSbX0HXPJxj7hqg5WmPQ/8lvYOJKm61S2P1zmF7CPPZXzvyOO11/m GFCt+qosgfObsqGmYBn/tX69pJ5KGO+z3b42BcfTb6kgmY/M5vz5sMO6N5Ga/Pw1ZY QbIE8Eew44X1U944NxCePlIs= Received: from zn.tnic (p5de8e8eb.dip0.t-ipconnect.de [93.232.232.235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 4D10C40E021A; Wed, 16 Oct 2024 10:58:38 +0000 (UTC) Date: Wed, 16 Oct 2024 12:58:32 +0200 From: Borislav Petkov To: shiju.jose@huawei.com 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@huawei.com, 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@huawei.com, prime.zeng@hisilicon.com, roberto.sassu@huawei.com, kangkang.shen@futurewei.com, wanghuiqiang@huawei.com, linuxarm@huawei.com Subject: Re: [PATCH v13 01/18] EDAC: Add support for EDAC device features control Message-ID: <20241016105832.GSZw-cWDOFweQMWRgZ@fat_crate.local> References: <20241009124120.1124-1-shiju.jose@huawei.com> <20241009124120.1124-2-shiju.jose@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20241009124120.1124-2-shiju.jose@huawei.com> Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: o5xutgejcce1sx1yce76bkp16ojbodyu X-Rspamd-Queue-Id: 597E980012 X-Rspamd-Server: rspam02 X-HE-Tag: 1729076355-684424 X-HE-Meta: U2FsdGVkX18dp6DtKLy67ZJR+CfBVFejXUG0yCUdo9PJP4cbFXmglfogc65GBVdHwIF/HnpMZwRoRIABaXM334tNPj8tH0BhWpCgXitTBcT2pKvqFgrMOtv4yt4XMg+F9QEdJTnnxwQFwelWYmauz2lNbbqGUr2OIYmq3+8+sGofQw4CUPKE0xu6wOGGFhAAQC8UGSSvoV+LzoyRgJSp2EochAj+IdMoVD+9GGHb22R10pv/fhNG3PCNhNgTrJuKro3+LnYCIh1IPVop5SOimFbk1ggWQk4sq51yQ+oYc8HBakC+mI8zx4yC5lmtjkuGYI2VxlLVnBtOI1qAGR5vDeCLRVDyKPpWVPEVd60XS9+J2Tw17bMFWYOskifopQ/2/CVciWUCA5yD/EnY5ZgeeC+iKCinGw1q06Ba+6d+eIlyCwS9rEZxWQaBGmw2Yu8gdhV9ztFRrv+5zlmXwolQ1Jz/eiwEhwPDXIuqBV+XFyelnTkAFryUIyfeEcVgAiCxL/NYpXnAf3ONgd6QzDOIVirykZt1v5hiPjqF2lBxFqjM9z9IMzUZd9D/2v4A1u7P6AUqISKc7h+/hK6L98ZuTZRFp++Avgpx8xiJyZ7HEIHtwaXLsUnfcPEjLd3UvPlCS6AGoO7MlZVABnwSctQXp4Oq8doha15rcJOK67l65G8dp76WtKClQy4O2MzrftYRcuz6qqqwChChZP86faN+/IQ/wh6c+dzXZWuP5Vh0Jq2ukcLfAweDIkf8TW+kX4d1PZgdxCpGfDS0raj+hU1fKt6TD0lKdgnCvy1EzF7qW2AGR133cDpxR/iTnYat0WUHxCRYSySt40J5KnO207IUi/oUFuXqdBzftvp/UZjWUYZLTE1n1LEH/j+7km3Vn4mVytBO1gkQAOacLhd5JfpxvzgxC4S8xfUZ6hJ3mseYK5micUkAjOkz/A2WSXGTv4ONQJfiIhIRujokU1Uu17U RTks7yzi uc7lcpsXMzf7YuNwD1Bz+5fRkmN+rHcBTteOhNM1fqrZ6IZfgc1EHSnfl0iE+aFU7UFPMxOIAmxL5JGty46Ra3LKqPYB9FUnPq3AcTXPztwmmnM3lIHKMv5dQlcJr3to7BYtcUWqnqwDiv/xAl1XGH4tV4QIDOmcFucc8yp+nkmegjQM4C3Co5wiYlrzB6RQsyRtliLEZ775+M7tM3JeF304BK+w2Em4OIugX5i4tPdu4k2qjTY18lBFWim8855TQegG2MlrS+9dgqilEY3N3Wtpc6d8sV5TNkehlKNW06LiAR8O14o8KX8p8JqVAhP6t0CDNSJbWn6pfH417WNHSeR6/cwckybj7z1oZR3ZIyjgDpp9ZVxq2rQWy+JwsBH5n08JT 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 Wed, Oct 09, 2024 at 01:41:02PM +0100, shiju.jose@huawei.com wrote: > From: Shiju Jose >=20 > 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 the sys= tem. | Driver exposes features control attributes to userspace in | /sys/bus/edac/devices/// Response: | Here=E2=80=99s a corrected version of the text: |=20 | "Add generic EDAC device feature control support for registering RAS fe= atures | supported in the system. The driver exposes feature control attributes = to | userspace in /sys/bus/edac/devices///." |=20 | Changes made: |=20 | * "features control" was changed to "feature control" for consistency a= nd | clarity. |=20 | * "supports registering" was changed to "support for registering" to ma= tch the | structure of the sentence. |=20 | * Added "The" at the beginning of the second sentence for better flow. |=20 | * Corrected the syntax around the file path to ensure clarity and prope= r | * punctuation. Please run all your commit text through some LLM AI as they're apparently= good enough now to help me in correcting grammar. =20 > 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(+) >=20 > 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_devi= ce_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_f= eat_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 "client"? 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. > + * @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 functio= n... > + */ > +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"? --=20 Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette