linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Shiju Jose <shiju.jose@huawei.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"dave@stgolabs.net" <dave@stgolabs.net>,
	"Jonathan Cameron" <jonathan.cameron@huawei.com>,
	"dave.jiang@intel.com" <dave.jiang@intel.com>,
	"alison.schofield@intel.com" <alison.schofield@intel.com>,
	"vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
	"ira.weiny@intel.com" <ira.weiny@intel.com>,
	"david@redhat.com" <david@redhat.com>,
	"Vilas.Sridharan@amd.com" <Vilas.Sridharan@amd.com>,
	"leo.duran@amd.com" <leo.duran@amd.com>,
	"Yazen.Ghannam@amd.com" <Yazen.Ghannam@amd.com>,
	"rientjes@google.com" <rientjes@google.com>,
	"jiaqiyan@google.com" <jiaqiyan@google.com>,
	"Jon.Grimm@amd.com" <Jon.Grimm@amd.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"naoya.horiguchi@nec.com" <naoya.horiguchi@nec.com>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"jthoughton@google.com" <jthoughton@google.com>,
	"somasundaram.a@hpe.com" <somasundaram.a@hpe.com>,
	"erdemaktas@google.com" <erdemaktas@google.com>,
	"pgonda@google.com" <pgonda@google.com>,
	"duenwen@google.com" <duenwen@google.com>,
	"mike.malvestuto@intel.com" <mike.malvestuto@intel.com>,
	"gthelen@google.com" <gthelen@google.com>,
	"wschwartz@amperecomputing.com" <wschwartz@amperecomputing.com>,
	"dferguson@amperecomputing.com" <dferguson@amperecomputing.com>,
	"wbs@os.amperecomputing.com" <wbs@os.amperecomputing.com>,
	"nifan.cxl@gmail.com" <nifan.cxl@gmail.com>,
	"jgroves@micron.com" <jgroves@micron.com>,
	"vsalve@micron.com" <vsalve@micron.com>,
	tanxiaofei <tanxiaofei@huawei.com>,
	"Zengtao (B)" <prime.zeng@hisilicon.com>,
	"Roberto Sassu" <roberto.sassu@huawei.com>,
	"kangkang.shen@futurewei.com" <kangkang.shen@futurewei.com>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	Linuxarm <linuxarm@huawei.com>
Subject: RE: [PATCH v11 01/14] EDAC: Add support for EDAC device feature's control
Date: Mon, 9 Sep 2024 11:17:47 +0000	[thread overview]
Message-ID: <dc4cc7313d444035a90e1d4e0c37f858@huawei.com> (raw)
In-Reply-To: <20240903163519.GAZtc6x7o9Cy1MQAsb@fat_crate.local>

Thank you for the feedbacks.
Apologies for the delay in replying.

>-----Original Message-----
>From: Borislav Petkov <bp@alien8.de>
>Sent: 03 September 2024 17:35
>To: Shiju Jose <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 <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; 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 <tanxiaofei@huawei.com>; Zengtao (B)
><prime.zeng@hisilicon.com>; Roberto Sassu <roberto.sassu@huawei.com>;
>kangkang.shen@futurewei.com; wanghuiqiang <wanghuiqiang@huawei.com>;
>Linuxarm <linuxarm@huawei.com>
>Subject: Re: [PATCH v11 01/14] EDAC: Add support for EDAC device feature's
>control
>
>On Fri, Aug 16, 2024 at 05:42:24PM +0100, shiju.jose@huawei.com wrote:
>> From: Shiju Jose <shiju.jose@huawei.com>
>>
>> Add generic EDAC device feature's control supports registering
>
>"features"
>
>Check your whole set.
Sure. Modified.
>
>> RAS features supported in the system. Driver exposes feature's control
>> attributes to the userspace in
>
>s/the //
Changed.
>
>> /sys/bus/edac/devices/<dev-name>/<ras-feature>/
>>
>> 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 | 178
>+++++++++++++++++++++++++++++++++++++
>>  include/linux/edac.h       |  60 +++++++++++++
>>  2 files changed, 238 insertions(+)
>>
>> diff --git a/drivers/edac/edac_device.c b/drivers/edac/edac_device.c
>> index 621dc2a5d034..635a41db8b5a 100644
>> --- a/drivers/edac/edac_device.c
>> +++ b/drivers/edac/edac_device.c
>> @@ -570,3 +570,181 @@ 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);
>
>Ew, no, don't do such silly linebreaks pls.
Changed.
>
>> +	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_feature_init - Init a ras feature
>
>s/ras/RAS/g
>
>Check your whole set.
Sure. Modified.
>
>> + * @parent: client device.
>> + * @dev_data: pointer to struct edac_dev_data.
>
>I can see it is a pointer. What it is used for?
Updated.
>
>> + * @feat: pointer to struct edac_dev_feature.
>> + * @attr_groups: pointer to attribute group's container.
>> + *
>> + * Returns number of scrub feature's attribute groups on success,
>> + * 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->feat) {
>> +	case RAS_FEAT_SCRUB:
>> +		dev_data->scrub_ops = ras_feat->scrub_ops;
>> +		dev_data->private = ras_feat->scrub_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->ecs_ctx;
>> +		return num;
>> +	case RAS_FEAT_PPR:
>> +		dev_data->ppr_ops = ras_feat->ppr_ops;
>> +		dev_data->private = ras_feat->ppr_ctx;
>> +		return 1;
>> +	default:
>> +		return -EINVAL;
>> +	}
>> +}
>> +
>> +/**
>> + * edac_dev_register - register device for ras features with edac
>
>s/edac/EDAC/g
>
>Check your whole set.
Modified.
>
>> + * @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_dev_feat_ctx would be freed automatically.
>> + */
>> +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_data *dev_data;
>> +	struct edac_dev_feat_ctx *ctx;
>> +	int ppr_cnt = 0, ppr_inst = 0;
>> +	int attr_gcnt = 0;
>> +	int ret, feat;
>> +
>> +	if (!parent || !name || !num_features || !ras_features)
>> +		return -EINVAL;
>> +
>> +	/* Double parse so we can make space for attributes */
>
>Who's "we"?
>
>Please use passive voice in your comments: no "we" or "I", etc.
Fixed.
>
>Personal pronouns are ambiguous in text, especially with so many
>parties/companies/etc developing the kernel so let's avoid them please.
>
>> +	for (feat = 0; feat < num_features; feat++) {
>> +		switch (ras_features[feat].feat) {
>> +		case RAS_FEAT_SCRUB:
>
>Does this need "fallthrough;" or somesuch?
It is a bug, fixed. 
>
>> +		case RAS_FEAT_PPR:
>> +			attr_gcnt++;
>> +			ppr_cnt++;
>> +			break;
>> +		case RAS_FEAT_ECS:
>> +			attr_gcnt +=
>ras_features[feat].ecs_info.num_media_frus;
>> +			break;
>> +		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;
>> +	}
>> +
>> +	if (ppr_cnt) {
>> +		ctx->ppr = kcalloc(ppr_cnt, sizeof(*(ctx->ppr)), GFP_KERNEL);
>> +		if (!ctx->ppr) {
>> +			ret = -ENOMEM;
>> +			goto groups_free;
>> +		}
>> +	}
>> +
>> +	attr_gcnt = 0;
>> +	for (feat = 0; feat < num_features; feat++, ras_features++) {
>> +		switch (ras_features->feat) {
>> +		case RAS_FEAT_SCRUB:
>> +			if (!ras_features->scrub_ops)
>> +				continue;
>> +			dev_data = &ctx->scrub;
>> +			break;
>> +		case RAS_FEAT_ECS:
>> +			if (!ras_features->ecs_ops)
>> +				continue;
>> +			dev_data = &ctx->ecs;
>> +			break;
>> +		case RAS_FEAT_PPR:
>> +			if (!ras_features->ppr_ops)
>> +				continue;
>> +			dev_data = &ctx->ppr[ppr_inst];
>> +			dev_data->instance = ppr_inst;
>> +			ppr_inst++;
>> +			break;
>> +		default:
>> +			ret = -EINVAL;
>> +			goto data_mem_free;
>> +		}
>> +		ret = edac_dev_feat_init(parent, dev_data, ras_features,
>> +					 &ras_attr_groups[attr_gcnt]);
>> +		if (ret < 0)
>> +			goto data_mem_free;
>> +
>> +		attr_gcnt += ret;
>> +	}
>
>Newline.
Added newline.
>
>> +	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);
>
>Ditto.
Added newline.
>
>> +	ret = dev_set_name(&ctx->dev, name);
>> +	if (ret)
>> +		goto data_mem_free;
>> +
>> +	ret = device_register(&ctx->dev);
>> +	if (ret) {
>> +		put_device(&ctx->dev);
>> +		goto data_mem_free;
>> +		return ret;
>> +	}
>> +
>> +	return devm_add_action_or_reset(parent, edac_dev_unreg, &ctx->dev);
>> +
>> +data_mem_free:
>> +	if (ppr_cnt)
>> +		kfree(ctx->ppr);
>> +groups_free:
>> +	kfree(ras_attr_groups);
>> +ctx_free:
>> +	kfree(ctx);
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(edac_dev_register);
>> diff --git a/include/linux/edac.h b/include/linux/edac.h index
>> b4ee8961e623..cc96f55ac714 100644
>> --- a/include/linux/edac.h
>> +++ b/include/linux/edac.h
>> @@ -661,4 +661,64 @@ 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
>> +
>> +enum edac_dev_feat {
>> +	RAS_FEAT_SCRUB,
>> +	RAS_FEAT_ECS,
>> +	RAS_FEAT_PPR,
>
>What are those? Comments ontop explaining pls.
Added comments.
>
>> +	RAS_FEAT_MAX
>> +};
>> +
>> +struct edac_ecs_ex_info {
>> +	u16 num_media_frus;
>> +};
>> +
>> +/*
>> + * EDAC device feature information structure  */ struct edac_dev_data
>> +{
>> +	union {
>> +		const struct edac_scrub_ops *scrub_ops;
>> +		const struct edac_ecs_ops *ecs_ops;
>> +		const struct edac_ppr_ops *ppr_ops;
>> +	};
>> +	u8 instance;
>> +	void *private;
>> +};
>> +
>> +struct device;
>> +
>> +struct edac_dev_feat_ctx {
>> +	struct device dev;
>> +	void *private;
>> +	struct edac_dev_data scrub;
>> +	struct edac_dev_data ecs;
>> +	struct edac_dev_data *ppr;
>> +};
>> +
>> +struct edac_dev_feature {
>> +	enum edac_dev_feat feat;
>
>			ft_type;
Sure. Changed.
>
>> +	u8 instance;
>> +	union {
>> +		const struct edac_scrub_ops *scrub_ops;
>> +		const struct edac_ecs_ops *ecs_ops;
>> +		const struct edac_ppr_ops *ppr_ops;
>> +	};
>> +	union {
>> +		void *scrub_ctx;
>> +		void *ecs_ctx;
>> +		void *ppr_ctx;
>> +	};
>
>Or drop the silly union and simply do
>
>	void *ctx;
Modified.
>
>> +	union {
>> +		struct edac_ecs_ex_info ecs_info;
>> +	};
>
>Union with a single member?!
Removed Union.
>
>> +};
>> +
>> +int edac_dev_register(struct device *parent, char *dev_name,
>> +		      void *parent_pvt_data, int num_features,
>> +		      const struct edac_dev_feature *ras_features);
>>  #endif /* _LINUX_EDAC_H_ */
>> --
>> 2.34.1
>>
>
>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette

Thanks,
Shiju


  reply	other threads:[~2024-09-09 11:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-16 16:42 [PATCH v11 00/14] EDAC: Scrub: introduce generic EDAC RAS control feature driver + CXL/ACPI-RAS2 drivers shiju.jose
2024-08-16 16:42 ` [PATCH v11 01/14] EDAC: Add support for EDAC device feature's control shiju.jose
2024-08-18  7:11   ` kernel test robot
2024-08-19  0:29   ` kernel test robot
2024-09-03 16:35   ` Borislav Petkov
2024-09-09 11:17     ` Shiju Jose [this message]
2024-08-16 16:42 ` [PATCH v11 02/14] EDAC: Add EDAC scrub control driver shiju.jose
2024-08-16 16:42 ` [PATCH v11 03/14] EDAC: Add EDAC ECS " shiju.jose
2024-08-16 16:42 ` [PATCH v11 04/14] cxl/mbox: Add GET_SUPPORTED_FEATURES mailbox command shiju.jose
2024-08-18 19:23   ` kernel test robot
2024-08-20 22:46   ` Dave Jiang
2024-08-21 16:11     ` Shiju Jose
2024-08-21 16:50       ` Dave Jiang
2024-08-16 16:42 ` [PATCH v11 05/14] cxl/mbox: Add GET_FEATURE " shiju.jose
2024-08-16 16:42 ` [PATCH v11 06/14] cxl/mbox: Add SET_FEATURE " shiju.jose
2024-08-16 16:42 ` [PATCH v11 07/14] cxl/memfeature: Add CXL memory device patrol scrub control feature shiju.jose
2024-08-16 21:21   ` kernel test robot
2024-08-16 16:42 ` [PATCH v11 08/14] cxl/memfeature: Add CXL memory device ECS " shiju.jose
2024-08-16 16:42 ` [PATCH v11 09/14] platform: Add __free() based cleanup function for platform_device_put shiju.jose
2024-08-16 16:42 ` [PATCH v11 10/14] ACPI:RAS2: Add ACPI RAS2 driver shiju.jose
2024-08-16 16:42 ` [PATCH v11 11/14] ras: mem: Add memory " shiju.jose
2024-08-16 16:42 ` [PATCH v11 12/14] EDAC: Add EDAC PPR control driver shiju.jose
2024-08-16 16:42 ` [PATCH v11 13/14] cxl/mbox: Add support for PERFORM_MAINTENANCE mailbox command shiju.jose
2024-08-16 16:42 ` [PATCH v11 14/14] cxl/memfeature: Add CXL memory device PPR control feature shiju.jose
2024-08-18  7:52   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc4cc7313d444035a90e1d4e0c37f858@huawei.com \
    --to=shiju.jose@huawei.com \
    --cc=Jon.Grimm@amd.com \
    --cc=Vilas.Sridharan@amd.com \
    --cc=Yazen.Ghannam@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=david@redhat.com \
    --cc=dferguson@amperecomputing.com \
    --cc=duenwen@google.com \
    --cc=erdemaktas@google.com \
    --cc=gthelen@google.com \
    --cc=ira.weiny@intel.com \
    --cc=james.morse@arm.com \
    --cc=jgroves@micron.com \
    --cc=jiaqiyan@google.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=jthoughton@google.com \
    --cc=kangkang.shen@futurewei.com \
    --cc=lenb@kernel.org \
    --cc=leo.duran@amd.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxarm@huawei.com \
    --cc=mchehab@kernel.org \
    --cc=mike.malvestuto@intel.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=nifan.cxl@gmail.com \
    --cc=pgonda@google.com \
    --cc=prime.zeng@hisilicon.com \
    --cc=rafael@kernel.org \
    --cc=rientjes@google.com \
    --cc=roberto.sassu@huawei.com \
    --cc=somasundaram.a@hpe.com \
    --cc=tanxiaofei@huawei.com \
    --cc=tony.luck@intel.com \
    --cc=vishal.l.verma@intel.com \
    --cc=vsalve@micron.com \
    --cc=wanghuiqiang@huawei.com \
    --cc=wbs@os.amperecomputing.com \
    --cc=wschwartz@amperecomputing.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox