From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: <shiju.jose@huawei.com>
Cc: <linux-edac@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
<bp@alien8.de>, <tony.luck@intel.com>, <rafael@kernel.org>,
<lenb@kernel.org>, <mchehab@kernel.org>, <leo.duran@amd.com>,
<Yazen.Ghannam@amd.com>, <linux-cxl@vger.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>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<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 v2 3/3] ras: mem: Add memory ACPI RAS2 driver
Date: Thu, 6 Mar 2025 17:32:14 +0800 [thread overview]
Message-ID: <20250306173214.0000204e@huawei.com> (raw)
In-Reply-To: <20250305180225.1226-4-shiju.jose@huawei.com>
On Wed, 5 Mar 2025 18:02:24 +0000
<shiju.jose@huawei.com> wrote:
> From: Shiju Jose <shiju.jose@huawei.com>
>
> Memory ACPI RAS2 auxiliary driver binds to the auxiliary device
> add by the ACPI RAS2 table parser.
>
> Driver uses a PCC subspace for communicating with the ACPI compliant
> platform.
>
> Device with ACPI RAS2 scrub feature registers with EDAC device driver,
> which retrieves the scrub descriptor from EDAC scrub and exposes
> the scrub control attributes for RAS2 scrub instance to userspace in
> /sys/bus/edac/devices/acpi_ras_mem0/scrubX/.
>
> Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Tested-by: Daniel Ferguson <danielf@os.amperecomputing.com>
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
> diff --git a/Documentation/edac/scrub.rst b/Documentation/edac/scrub.rst
> index daab929cdba1..fc8dcbd13f91 100644
> --- a/Documentation/edac/scrub.rst
> +++ b/Documentation/edac/scrub.rst
> @@ -264,3 +264,76 @@ Sysfs files are documented in
...
> +1.2.4. Program background scrubbing for RAS2 device to repeat in every 21600 seconds (quarter of a day).
wrap to 80 chars. I think that is fine for titles in sphinx.
> +
> +# echo 21600 > /sys/bus/edac/devices/acpi_ras_mem0/scrub0/current_cycle_duration
> +
> +1.2.5. Start 'background scrubbing'.
> +
> +# echo 1 > /sys/bus/edac/devices/acpi_ras_mem0/scrub0/enable_background
> diff --git a/drivers/ras/acpi_ras2.c b/drivers/ras/acpi_ras2.c
> new file mode 100644
> index 000000000000..2f9317aa7b81
> --- /dev/null
> +++ b/drivers/ras/acpi_ras2.c
> @@ -0,0 +1,391 @@
> +struct acpi_ras2_ps_shared_mem {
> + struct acpi_ras2_shmem common;
> + struct acpi_ras2_patrol_scrub_param params;
> +};
...
> +static int ras2_update_patrol_scrub_params_cache(struct ras2_mem_ctx *ras2_ctx)
> +{
> + struct acpi_ras2_ps_shared_mem __iomem *ps_sm =
> + (void *)ras2_ctx->comm_addr;
Would a container_of() be better here given the type cast is doing
that with the assumption of it being first element of ps_shared_mem.
Same in other places, so maybe a macro.
> + int ret;
> +
> + ps_sm->common.set_caps[0] = RAS2_SUPPORT_HW_PARTOL_SCRUB;
> + ps_sm->params.cmd = RAS2_GET_PATROL_PARAMETERS;
...
> +
> +static int ras2_hw_scrub_set_enabled_bg(struct device *dev, void *drv_data, bool enable)
> +{
> + struct ras2_mem_ctx *ras2_ctx = drv_data;
> + struct acpi_ras2_ps_shared_mem __iomem *ps_sm =
> + (void *)ras2_ctx->comm_addr;
As above, maybe container_of appropriate as we have
a definition of what we are casting it to that has the thing
we are casting from as first element.
> + bool running;
> + int ret;
> +
...
> +
> +static int ras2_probe(struct auxiliary_device *auxdev,
> + const struct auxiliary_device_id *id)
> +{
> + struct ras2_mem_ctx *ras2_ctx = container_of(auxdev, struct ras2_mem_ctx, adev);
> + struct edac_dev_feature ras_features[RAS2_DEV_NUM_RAS_FEATURES];
Given we only have 1 RAS2 feature I'd be tempted to leave
making this flexible for some future series that adds a second one.
So maybe just have a single feature rather than array of 1.
> + char scrub_name[RAS2_SCRUB_NAME_LEN];
> + int num_ras_features = 0;
With change below this isn't needed.
> + int ret;
> +
> + if (!ras2_is_patrol_scrub_support(ras2_ctx))
> + return -EOPNOTSUPP;
> +
> + ret = ras2_update_patrol_scrub_params_cache(ras2_ctx);
> + if (ret)
> + return ret;
> +
> + snprintf(scrub_name, sizeof(scrub_name), "acpi_ras_mem%d",
> + ras2_ctx->id);
> +
> + ras_features[num_ras_features].ft_type = RAS_FEAT_SCRUB;
> + ras_features[num_ras_features].instance = ras2_ctx->instance;
> + ras_features[num_ras_features].scrub_ops = &ras2_scrub_ops;
> + ras_features[num_ras_features].ctx = ras2_ctx;
> + num_ras_features++;
As above, can also just assume this is 1 becasue it always is.
> +
> + return edac_dev_register(&auxdev->dev, scrub_name, NULL,
> + num_ras_features, ras_features);
here pass in &ras_feature after making it not be an array.
> +}
next prev parent reply other threads:[~2025-03-06 9:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 18:02 [PATCH v2 0/3] ACPI: Add support for ACPI RAS2 feature table shiju.jose
2025-03-05 18:02 ` [PATCH v2 1/3] ACPI: ACPI 6.5: RAS2: Shorten RAS2 table structure and variable names shiju.jose
2025-03-05 18:51 ` Luck, Tony
2025-03-06 2:03 ` Jonathan Cameron
2025-03-06 6:05 ` Jonathan Cameron
2025-03-05 18:02 ` [PATCH v2 2/3] ACPI:RAS2: Add ACPI RAS2 driver shiju.jose
2025-03-06 9:19 ` Jonathan Cameron
2025-03-06 11:21 ` Shiju Jose
2025-03-10 12:44 ` Jonathan Cameron
2025-03-05 18:02 ` [PATCH v2 3/3] ras: mem: Add memory " shiju.jose
2025-03-06 9:32 ` Jonathan Cameron [this message]
2025-03-07 21:51 ` Daniel Ferguson
2025-03-10 11:12 ` Shiju Jose
2025-03-10 14:36 ` Shiju Jose
2025-03-10 17:14 ` Daniel Ferguson
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=20250306173214.0000204e@huawei.com \
--to=jonathan.cameron@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=jiaqiyan@google.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=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=shiju.jose@huawei.com \
--cc=somasundaram.a@hpe.com \
--cc=tanxiaofei@huawei.com \
--cc=tony.luck@intel.com \
--cc=vishal.l.verma@intel.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