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 F0450C282EC for ; Thu, 6 Mar 2025 09:32:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 09A17280002; Thu, 6 Mar 2025 04:32:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 02337280001; Thu, 6 Mar 2025 04:32:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E052C280002; Thu, 6 Mar 2025 04:32:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BE5B9280001 for ; Thu, 6 Mar 2025 04:32:36 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 60FFF8128A for ; Thu, 6 Mar 2025 09:32:37 +0000 (UTC) X-FDA: 83190611154.07.3F9DAB3 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf18.hostedemail.com (Postfix) with ESMTP id 3819D1C000E for ; Thu, 6 Mar 2025 09:32:33 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf18.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741253555; a=rsa-sha256; cv=none; b=wMOWMbD8eRboOcPm491ogKyvts2Y4MhPRhYA2tFj/VRjS9VyHH/OzWzhdn8QdG8zv2xKE8 KduaeEQNtgThHVDb1ORmbRXcz7KU7IGIwp4ff9nmaLC0luWcP9x5wZl+qn7Fy18q862Q7o QEJ5CyH7NM73fnbSL7g5Q5MgkcjrFUg= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf18.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741253555; 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; bh=LWR6+xRbZhtYgI9Bt/w4fP1wTQcQaEX7NLGxhfoEfB4=; b=Rg+j28GNZkEu+0MmxAfb98SelUnQBZ96IVR/mYAnSD8xdehb+oFzUoAe7skydeWuRyZbHr QCl3rfH+eC3B0B36JEXf4ev8POj3J1aig+u5eJYg5zDHaP6DVTdLqBHDECTKAQnr7jiCHq pr//wDZPKxOGi/H7ecx9Gv4+G4D5KYQ= Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Z7kcN4T2yz67QRR; Thu, 6 Mar 2025 17:28:20 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id A431C140A70; Thu, 6 Mar 2025 17:32:29 +0800 (CST) Received: from localhost (10.96.237.92) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 6 Mar 2025 10:32:18 +0100 Date: Thu, 6 Mar 2025 17:32:14 +0800 From: Jonathan Cameron To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 3/3] ras: mem: Add memory ACPI RAS2 driver Message-ID: <20250306173214.0000204e@huawei.com> In-Reply-To: <20250305180225.1226-4-shiju.jose@huawei.com> References: <20250305180225.1226-1-shiju.jose@huawei.com> <20250305180225.1226-4-shiju.jose@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.96.237.92] X-ClientProxiedBy: lhrpeml100004.china.huawei.com (7.191.162.219) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspamd-Queue-Id: 3819D1C000E X-Stat-Signature: 4oepjg86jpbk9t75pun3hz3ttrwck6uq X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1741253553-431910 X-HE-Meta: U2FsdGVkX1/14Y1sDShBzfmJli0dkRYo7nj9Tin/kWyIhBvged12PwYsZTBQrJh9VZ9nxkdv4csP8hNPKTkQLALBVrpMPyLTEQWjGmiAAUgbvcXJM33lfQ9aAEB0Tc30cnlnOZwAJZTOZmgyUI+LT723Bz+dLGeYh2l1YKAT92CaQyM2eUF5Xxy84OHvdhVbKlFVJSFkK3ugdWnWjuUVU3MaeoT7gT40HftTYMVSSNExlk6tVnoOFfRyDs3sR5hjPuT34J6pFwZg6r7XY/LbdKqrOgzR/ttsZpxBU/YcqecnGK9WaFJmZADUVUXXAQWClRG0jJG9szzVhlFsHTmJ2eQMvdjFGJukV1kbHsyKDwUY4FIzak2Yi5iFFBLCcMJtmPnQHn7Kttkezbbb5oVICfjkJV7TT1MkEGsZM1CIB5K6mWmTRda4dM5TuYbbkkMTlpl7Y2Als7ATqlGlXgzE9ayc4w6nWfyykfa70pIr49Ks0l27rDQ4GHxb5f27ey/xR4r9Jodv1HB7Rkt8eUlDnQxxrBlyGuK1NEfqiPo4vcKjmq7PSGAS4I0wu1wPRgp0ZhNOWoBi9bXYNQUsIk2dBOnjhy68E/yoCOE3zYAFQNEX0XGr2Cjm+ULMpMmU2fFaaWA+bG8PhltmE3ex2xRF8bxT5zzbs+yNSjY8hVvjt7CMZW+h19r7lHN3hTwNUOoDGAivpPxIX6W4KxzsJBUVH7UEtTh54QMPdJFopjwq8nfTPpUzXiKnk5Jiyg+r3EcCIHpmwzoRxB3g31tYK9TXHp2Bp+ZKTGSXRqznuN1CIShZ6mPI14nCDd5qDTLeI6iuQMjyh6Jvzzzk5sUSNqj38gFsHiUnJHdDm7hsVnrneB63cGMkxMNTsQVX7rjBf1aEdooYhHKXN5eX+IEc2BVVesvQ3uJwl4MhyEK4bxcTiKtAkUkGtxABTLz5007axwmplAhtb2A375gPSQDZOlg 6WCKWQrD jLdvXTryHK7uoFqRbLC31jROjcoMlkbY7EQa/yy7ietsQ+5HU9fDeGjb0aviBx9y2sI715rM4zJbTlp2pMBenvjGc6T9mIj8U9RWE3VLaQOidAIucJMGFz7+O4kNzRRcTpuvGx2y0BfP7tDW0uLoTQ5H9Ba5iaDhGpYfxFb6Gk1UPDNbrS+8VLfdzPTPE+dbVXzbe1yJfAGtTQ3b96vpJlqBTgygDgW6WKYQB4EgMOgtwwPafqa2Q0GxnZN5SQR8rvcEQTZj6bkcSxMVOdsgzDEUPQwZocPh+0ym4h3VNDyE3+SidpmJ+aT23/xUPOxqsKtubQFCaXAOJFnI= 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, 5 Mar 2025 18:02:24 +0000 wrote: > From: Shiju Jose > > 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 > Signed-off-by: Jonathan Cameron > Tested-by: Daniel Ferguson > Signed-off-by: Shiju Jose > 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. > +}