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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.