Re: [PATCH v13 01/18] EDAC: Add support for EDAC device features control

[Borislav Petkov <bp@alien8.de>]

On Wed, Oct 09, 2024 at 01:41:02PM +0100, shiju.jose@huawei.com wrote:
> From: Shiju Jose <shiju.jose@huawei.com>
> 
> 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/<dev-name>/<ras-feature>/

Chatgpt prompt:

| Please check the grammar in this English text: "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/<dev-name>/<ras-"feature>/

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/<dev-name>/<ras-feature>/."
| 
| 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.
 
> Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
> ---
>  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 = container_of(dev, struct edac_dev_feat_ctx, dev);
> +
> +	kfree(ctx->dev.groups);
> +	kfree(ctx);
> +}
> +
> +const struct device_type edac_dev_type = {
> +	.name = "edac_dev",
> +	.release = 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 = 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 function...

> + */
> +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 = 0;
> +	int ret, feat;
> +
> +	if (!parent || !name || !num_features || !ras_features)
> +		return -EINVAL;
> +
> +	/* Double parse to make space for attributes */
> +	for (feat = 0; feat < num_features; feat++) {
> +		switch (ras_features[feat].ft_type) {
> +		/* Add feature specific code */
> +		default:
> +			return -EINVAL;
> +		}
> +	}
> +
> +	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> +	if (!ctx)
> +		return -ENOMEM;
> +
> +	ctx->dev.parent = parent;
> +	ctx->private = private;
> +
> +	ras_attr_groups = kcalloc(attr_gcnt + 1, sizeof(*ras_attr_groups), GFP_KERNEL);
> +	if (!ras_attr_groups) {
> +		ret = -ENOMEM;
> +		goto ctx_free;
> +	}
> +
> +	attr_gcnt = 0;
> +	for (feat = 0; feat < num_features; feat++, ras_features++) {
> +		switch (ras_features->ft_type) {
> +		/* Add feature specific code */
> +		default:
> +			ret = -EINVAL;
> +			goto groups_free;
> +		}
> +	}
> +
> +	ras_attr_groups[attr_gcnt] = NULL;
> +	ctx->dev.bus = edac_get_sysfs_subsys();
> +	ctx->dev.type = &edac_dev_type;
> +	ctx->dev.groups = ras_attr_groups;
> +	dev_set_drvdata(&ctx->dev, ctx);
> +
> +	ret = dev_set_name(&ctx->dev, name);
> +	if (ret)
> +		goto groups_free;
> +
> +	ret = device_register(&ctx->dev);
> +	if (ret) {
> +		put_device(&ctx->dev);
> +		goto groups_free;
> +		return ret;
		^^^^^^^^^^

Come again?!

There's code after a "goto"?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette