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 8C10DC02185 for ; Wed, 15 Jan 2025 12:04:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD21B6B0093; Wed, 15 Jan 2025 07:04:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C579E280003; Wed, 15 Jan 2025 07:04:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAAA0280002; Wed, 15 Jan 2025 07:04:04 -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 87FB86B0093 for ; Wed, 15 Jan 2025 07:04:04 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3F884B04BA for ; Wed, 15 Jan 2025 12:04:04 +0000 (UTC) X-FDA: 83009552808.09.4E8006E Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf19.hostedemail.com (Postfix) with ESMTP id 9720B1A0005 for ; Wed, 15 Jan 2025 12:04:02 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hrl9KSqc; spf=pass (imf19.hostedemail.com: domain of mchehab+huawei@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mchehab+huawei@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736942642; 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:dkim-signature; bh=x8Lc9vZx6eNAlQ/KipzV2HTDwd5eixDR+kmYJy0o7Lg=; b=GflmpIybEiIqGLl2CV26CHhDNcJ3oo4dT6h+DUQpA1GppORPp5rBxs8ITppi7a8doIcnIH lZ6tHRGLKZDZe9Pd0kyFl802HFB2HfD5lPs6Zo0MQPUNahRxs0ojNz98dqQT8oAnOm1weX lMn1tmbvg/wQCYB6Z88CfsokmCkK6Rg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736942642; a=rsa-sha256; cv=none; b=ak7c0qvQTYPT+BQG0xuZQSS/oIwLtSw4mezmUTmCHe1xxoWGsVt8FYmANwplR/E0LUidAk UdON/j7sidyesA5ZKGmLnQ45Ad3u1HagUXXostB5uEIUplBZimoXpfxDJGd5QkNefMcAmm EiSX1J/2DuWA4LjW8QuKvpaEtCXezlo= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hrl9KSqc; spf=pass (imf19.hostedemail.com: domain of mchehab+huawei@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mchehab+huawei@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 78CB8A41EF4; Wed, 15 Jan 2025 12:02:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91D74C4CEDF; Wed, 15 Jan 2025 12:03:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736942641; bh=yUx/yUguaizzZsiI9KbLT/PSUorU7als0RUQxxoKr7Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hrl9KSqc1A7sY0vPdhGUstBdZR424Pe9WSR+Fxb6PymyiuAkAGvIJln2fpMBv0C9f W2OYf/Hn7K8d0hJVQDIaGo8zhk1n0AwiWDcsYAAU9gYY2m9kOLCKNyDnp+Me+A+9oj PY8v+eDlYl4j0cxbkWOlS7wF6TDRp89Lmk4seB+uCDagW0kfVELkQrKUtR9vNNdpJH hvcd0rkN81jv3sT58bJ6lwB/m9yiCdh4OaRGzNwul7zjZ0MoNNJK3sfAYPQ0hrjeqh HIhOgyc/rJtSCODYHMpT4eIU3QYfcOMg7Ozk/olBtL7vuBcNguM64eoVggN9O0IYh0 aE8nDsuD1YVMg== Date: Wed, 15 Jan 2025 13:03:49 +0100 From: Mauro Carvalho Chehab To: Shiju Jose 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" , "bp@alien8.de" , "tony.luck@intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "dan.j.williams@intel.com" , "dave@stgolabs.net" , "Jonathan Cameron" , "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" , "gthelen@google.com" , "wschwartz@amperecomputing.com" , "dferguson@amperecomputing.com" , "wbs@os.amperecomputing.com" , "nifan.cxl@gmail.com" , tanxiaofei , "Zengtao (B)" , "Roberto Sassu" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: Re: [PATCH v18 04/19] EDAC: Add memory repair control feature Message-ID: <20250115130349.655c5461@foz.lan> In-Reply-To: <7a758dde8f044a0d955413b379179b93@huawei.com> References: <20250106121017.1620-1-shiju.jose@huawei.com> <20250106121017.1620-5-shiju.jose@huawei.com> <20250114144712.49cd98f2@foz.lan> <7a758dde8f044a0d955413b379179b93@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 9720B1A0005 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: ux4gkbpw4u5ng6k7idsfb6465wgw1q4h X-HE-Tag: 1736942642-74433 X-HE-Meta: U2FsdGVkX1/77E1hJOwGfUCs/c1Ul3+DSaheiiqpwtMTvFUpBz8At6CN1Km0R/O5DnFwD3L9JfYV0HS5NUyEm+ltzb5xUuaZdhBpTnNWtMoNqj04FiwdavSJRO0YDF5h18KUa/FHO17X0Zy7Dh4juY1J0G1HHuOADma7RAos6J2HxaE9V05UoHMyfXshx1kkGKVs3NRmNY1nNHKl015r5mR71Son7UA3qvkPIqxzJiFWOkUP8gU0XVLWjZWx4IR58CnxU4mOkXYBm9DdK9XoQrw2JqU9l5OgwOW8daOqE+n+H2pHLsJwbfa8gxCTjgdkvKQmSklzrf5+30vAaWCXwLyG/Wd9xKtDHqHJDPPTvt3uoNG9RO+pUSAs0wDZWRtjl367AlfvZ9IgTxPj8jMSsjvOdxcKydTq8uaQMAFdukLQnZqDS8LzN050x4rbdGUWqKgUqe5vKLsm8u8vafcjBRarnoEuy4eDntfHyCkwTF24iRoNGsD9zgOyE3h2R0w5DZoNFtxkW5XMmkJ61Q3nPMoa3HbiEPzvx5Wsc+v02w0q+GZnKAhW+aY7zscSbwmacvVcgppXJvstcLNUD61mLPPfUJHF/WYgJy46OUKQqFPybDb5sH/m8K+Cxs8v2iMv2icC6B8G8Z+IBhPi2fhla8QWSow8+ifntAgSBDA8fk1ytQQxTG5PEO4lWfbob1zdyOIu3xjVWbdEc0lwA5yoFbI+6tvpf8bEthUTtYn8h6ZuoYE//PEPEDyZdakB7Ps37SGaxF+tu808kjITv3tmR6+zy9PN7kI7wK+0gIWJ+da47MybamAg74iCLG4sNvNbnvehHGYP8jn9E3Jby5kb4lmAv1MDggqWyV+36L0t29pE8K0rkyHOkHtaFYmLXHcDQXJGanJLKmzQf95D19iIOMGlUrnt9UA4saqQS+SbEPi6sD0xN7ifbp6gkH3HNJyRfXlIKLl1C7HSPilDcXb /67QmeN1 RxJUA+LEufuaAo1T8LogihzjCew+xJSH2+iQCTtG/4SnGzImD9Z0B1SQryBhU2hENy/3qi1tQB+LlQwGEHXkIifaOL0DRYSNPFxIR9xP44Mfi4GSgivwZT5adLeavtPAUHOlCKPRw0olOGpczPQnqtd+NofMmF/QqJqP9m6QupYu9Q7BsMyiXKPCei1pwtmdbnUqO/1jc2MSEaRvR/MsLD/N4YlLZ95MS1ddslpjMH8Vy7ck40PD+hb7FxrZGdp0dXU+g1cdqem8Q5O0NvaXZxcMki9cbyI3xhJwhsG/hTNRIRw3GGeGeEspcDbye8xLRUi4kID5W332qQc8Buj3Ef4+JQqSzBKAW1qDayyc/Ew6flYHTX4ZFT0qruJjkMoJOEDWgF2O42ZgIW3MbDr5qA7A0/TOVFhNCNcgxF5jnLrwoDP3iTqX2FkFmXd8qVT8b9S6qzROR1nhU/D69RBdWUebQPM8JP+NWhUUSCVZY/0eJmWqjx2EsfifYGOYdczrmOahIw75ld7f2yPX7nrTqtOWrGC0AETrNk51OpUxF2NBTiQgdmr61+zPYp+B2q24p3+jGrOOyz7SwgKup6etYHjc8c0krm++BTW54zOAp+0ZWqD0TsaWgH8uKzjeHANABvb+sV5gmmR+1DXjldLKZ+7XCedYeUOig2aC53xmD/Cm5DGiMxknrD4bAxwOGra6pcJ4KFNJiIjEWYD0/8hGwbH6QoHFqgZmLd7+FMbOYGj+NRc20xCRR4+nMXxZLAl1HZd6PbyZMUnynzG4lxuRuCYFsl0OZJwDtIfciL4L1MoEH+i7keqo76JU2rMXkZ6aP34NAX1jrPQcmWnlINL5Ltn9Xwp5i0LzWiXiBcAUaqbypIJ6RgYveIEOW7SmhQ33Wwz5Nz2n06PLR/vE= 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: Em Tue, 14 Jan 2025 14:30:53 +0000 Shiju Jose escreveu: > >-----Original Message----- > >From: Mauro Carvalho Chehab > >Sent: 14 January 2025 13:47 > >To: Shiju Jose > >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; > >bp@alien8.de; tony.luck@intel.com; rafael@kernel.org; lenb@kernel.org; > >mchehab@kernel.org; dan.j.williams@intel.com; dave@stgolabs.net; Jonathan > >Cameron ; 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; gthelen@google.com; > >wschwartz@amperecomputing.com; dferguson@amperecomputing.com; > >wbs@os.amperecomputing.com; nifan.cxl@gmail.com; tanxiaofei > >; Zengtao (B) ; Roberto > >Sassu ; kangkang.shen@futurewei.com; > >wanghuiqiang ; Linuxarm > > > >Subject: Re: [PATCH v18 04/19] EDAC: Add memory repair control feature > > > >Em Mon, 6 Jan 2025 12:10:00 +0000 > > escreveu: > > > >> +What: /sys/bus/edac/devices/ >name>/mem_repairX/repair_function > >> +Date: Jan 2025 > >> +KernelVersion: 6.14 > >> +Contact: linux-edac@vger.kernel.org > >> +Description: > >> + (RO) Memory repair function type. For eg. post package repair, > >> + memory sparing etc. > >> + EDAC_SOFT_PPR - Soft post package repair > >> + EDAC_HARD_PPR - Hard post package repair > >> + EDAC_CACHELINE_MEM_SPARING - Cacheline memory sparing > >> + EDAC_ROW_MEM_SPARING - Row memory sparing > >> + EDAC_BANK_MEM_SPARING - Bank memory sparing > >> + EDAC_RANK_MEM_SPARING - Rank memory sparing > >> + All other values are reserved. > >> + > >> +What: /sys/bus/edac/devices/ >name>/mem_repairX/persist_mode > >> +Date: Jan 2025 > >> +KernelVersion: 6.14 > >> +Contact: linux-edac@vger.kernel.org > >> +Description: > >> + (RW) Read/Write the current persist repair mode set for a > >> + repair function. Persist repair modes supported in the > >> + device, based on the memory repair function is temporary > >> + or permanent and is lost with a power cycle. > >> + EDAC_MEM_REPAIR_SOFT - Soft repair function (temporary > >repair). > >> + EDAC_MEM_REPAIR_HARD - Hard memory repair function > >(permanent repair). > >> + All other values are reserved. > >> + > > > >After re-reading some things, I suspect that the above can be simplified a little > >bit by folding soft/hard PPR into a single element at /repair_function, and letting > >it clearer that persist_mode is valid only for PPR (I think this is the case, right?), > >e.g. something like: > persist_mode is valid for memory sparing features(atleast in CXL) as well. > In the case of CXL memory sparing, host has option to request either soft or hard sparing > in a flag when issue a memory sparing operation. Ok. > > > > > What: /sys/bus/edac/devices/ >name>/mem_repairX/repair_function > > ... > > Description: > > (RO) Memory repair function type. For e.g. post > >package repair, > > memory sparing etc. Valid values are: > > > > - ppr - post package repair. > > Please define its mode via > > /sys/bus/edac/devices/ >name>/mem_repairX/persist_mode > > - cacheline-sparing - Cacheline memory sparing > > - row-sparing - Row memory sparing > > - bank-sparing - Bank memory sparing > > - rank-sparing - Rank memory sparing > > - All other values are reserved. > > > >and define persist_mode in a different way: > Note: For return as decoded strings instead of raw value, I need to add some extra callback function/s > in the edac/memory_repair.c for these attributes and which will reduce the current level of optimization done to > minimize the code size. You're already using a callback at EDAC_MEM_REPAIR_ATTR_SHOW macro. So, no need for any change at the current code, except for the type used at the EDAC_MEM_REPAIR_ATTR_SHOW() call. Something similar to this (not tested) would work: int get_repair_function(struct device *dev, void *drv_data, const char **val) { unsigned int type; // Some logic to get repair type from *drv_data, storing into "unsigned int type" const char *repair_type[] = { [EDAC_SOFT_PPR] = "ppr", [EDAC_HARD_PPR] = "ppr", [EDAC_CACHELINE_MEM_SPARING] = "cacheline-sparing", ... } if (type < ARRAY_SIZE(repair_type)) { *val = repair_type(type); return 0; } return -EINVAL; } EDAC_MEM_REPAIR_ATTR_SHOW(repair_function, get_repair_function, const char *, "%s\n"); Thanks, Mauro