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 700BFE77188 for ; Tue, 14 Jan 2025 14:31:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA3EA6B0085; Tue, 14 Jan 2025 09:31:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E547D6B0088; Tue, 14 Jan 2025 09:31:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1CA66B0089; Tue, 14 Jan 2025 09:31:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9AAF76B0085 for ; Tue, 14 Jan 2025 09:31:00 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 006521C763E for ; Tue, 14 Jan 2025 14:30:59 +0000 (UTC) X-FDA: 83006294280.14.4095168 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf30.hostedemail.com (Postfix) with ESMTP id C826080020 for ; Tue, 14 Jan 2025 14:30:56 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736865057; 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=CWnlieT+KGGKlc5o59kZQY/8khRlwKAVyK+5pAQD7+Y=; b=qiOqWmzwOf4Fc0wlwPlE1sVOjjQii0MoEoIZEUXlGCsYXdrHj2FAsDyigXrGVcQrvl6cfm LfOrpbqtV2Vy4rTqIHNsv8+ZdLFL/Fiu+7zuo26AZO7ASDqpEJNW6labrN0B7NXYyfb66n 2wv67cMXRdsjRxh7uVI2SeV5fL4VniI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736865057; a=rsa-sha256; cv=none; b=i3dogpxZfXIK26EEfHCkR3Q2EmiLZ1nl1igqQ/hU4EAtcJsixuaJtVFiTVvjOuqsY02JaZ Px4jo+aQjws19MxxKlNsuGlxDdHatJJv+5IWw+qykr7fHDlUlVDFxoKzkftba7V58pNx8h ro3IkBp40aTBdou4b64+nzYGxk8h8Qg= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4YXWjL4tSZz6FHCC; Tue, 14 Jan 2025 22:29:26 +0800 (CST) Received: from frapeml100008.china.huawei.com (unknown [7.182.85.131]) by mail.maildlp.com (Postfix) with ESMTPS id CBA3014038F; Tue, 14 Jan 2025 22:30:53 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100008.china.huawei.com (7.182.85.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 14 Jan 2025 15:30:53 +0100 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.039; Tue, 14 Jan 2025 15:30:53 +0100 From: Shiju Jose To: Mauro Carvalho Chehab 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 Thread-Topic: [PATCH v18 04/19] EDAC: Add memory repair control feature Thread-Index: AQHbYDQgB18e2Mzm30SSjInW5UV51bMWRHQAgAAVmdA= Date: Tue, 14 Jan 2025 14:30:53 +0000 Message-ID: <7a758dde8f044a0d955413b379179b93@huawei.com> References: <20250106121017.1620-1-shiju.jose@huawei.com> <20250106121017.1620-5-shiju.jose@huawei.com> <20250114144712.49cd98f2@foz.lan> In-Reply-To: <20250114144712.49cd98f2@foz.lan> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.158.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: C826080020 X-Stat-Signature: 58x9sjji799taa75qsrzbphfghcmjmhe X-Rspam-User: X-HE-Tag: 1736865056-117240 X-HE-Meta: U2FsdGVkX18yadD2Qh1t7VsbDKpexT/ktQaOLwPs343V4QzUnqH/SXxBcipXIsoiT5tI9NbLNwGfFzWTQj45gNkLLb1Af4e9YDqnaCxG8m9UYS1SXvfLT500M9t6r1cIa0RBIsVAwyzsurFc+C2+mZ9fxd/ZsCoqcGHsNDBcsarEJaj95dNaOxQm1Wyf+3dWKQLMIW9vdyM8RblsveVmENXVOGyihwsltRjlZ/EruaN8nhx4mhwsGCn7X7fk1ByeM3vy5nODJ184Lz338FX7Il+qxYX0LTqBHNGRyTQneHyf+fbDW5kr3rhZQFLoKZuTGhQudA1F1dDuyvJfbUKS+JMeGcrOytJ1Q4ITh2BES/PKEPJPIs1dIiAKSnYzFM8m6uX5jRAqA91BtU5HMNP6Vt/zAg6v+DWZrEmq3sNuFcZnA6OP11YmSE0Xj0bPuIXBBscAc5Qr6Qg7UmS35qdwwcgi1YHJ3ZogFjes0W8c+GOBbKG8jGsXJF8x5Dh07cgevzgWCtMnroDnzkyxr0fsaQ83mEIIPwHGgqnWmZtqcxZKgYUsTyByXznnF12dhUikWgUzkiddhwBiKGS//8iytyQjkqW6swvhN5sFcA3/inSlHz4AmUZLvQRvB5F1PxE+bmc3NtYKDJ8nNhzBt8/65WoNB91WkFlWFmu9/Kf7kJ8vRspZHx8ZvKnThfYlJzKLM7T0LC7+w1MXbEffsOnDD/e22om+H/YjFl1B57zRy2lNmPEE0Uv7WhdCwpMhlhmbiNzPA4OfKcYagdikd63IQlyGgoFgudcsgEvpqHGZYRy05HjqMryxq9a8BPHOvBJdRZxA0tQcRMPUvG5U1jW8ySAIAgqi3498j/ydGiFuHSsv7GAQMfW8VDf0/TD31uOrbVgiul6tYiwSvUfKND2skXizAZu3YivML8uEygSI21DptsXj+z9USREuViOqFjgVNR1vobcTQ3zPcRQnDQM +UG52Bos 4I7OiaDO0CiqUDpP0R7AWUHJKF0za4TI4B7fw68BoKFRRd/sfsmRz2KHnAgS25Ag1XsrU+/Lcnn2NRAMLpskfQkbyoGXv+H2Pjw6la7pn/Xsn3Nz49ngNahsYKF/OhNnBSCP5aC7w4uqzYDwsyVUKRNTuZh1j8AiUEgJo8NYEVEtVtHobKc2Oponi+ok3YXR28OgYHIVHwXxAy1v6YBEdNweE/+rjebrbMGKVAn11GaLqWhljR4bQc7pAGUYm1D64bBfWe+a5QlCcDSlNLWjvbOQSgGuxoIT9NO9t9BTxUFNXU4M47t7vlre/IaGRisqwPQ/W3bO6c4cHZYfYdxolxY+YgQ85+M8yntqGKWx/EBkiv1EMO0/SFRHNa+zRtydeWUGMcXGToVJoONrd3+prqHJW4mhl32WzE8N6aJN8gXht5fMi9KiWgzwTtcZdBOoCZiopmpyUaWy4BVcIU/OvZCb1gptPZUDrNrrLFw5DgFT9vJeRMr2Iyp3kw/QU10XPAlUUoK9uYZi+vjwt9oujV+h/Yf/YaRmwe9JZF59EFAmNTvYOZhI8Bb2BNDSq2BspGNrx2E+l3Ii2MkVsKiJQyFehIiOP43ymYpq/E60fYm1HF4de3bNdBpefF6fph1Bp+2hrquHqPcTb12MBbdYek+C6SVVWW9rc7DS7LXFeYvih+L6oqOisbHzHEdQN7TSsHfb/+tRwk/uUj2ddxFM7f6KT2IvZYVw52uNYo7eL8BnN9qKDS4gT4Rw2bnMAQ04MYDs8km6qIa2wRZSJyenH4YpmGRGHPIODpLlmMdP3ScfO2oVPxtkiAt3Z1fH0eBvNInGvVvF64fVJA+ZkSXv5PM/wmA== 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: >-----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, an= d letting >it clearer that persist_mode is valid only for PPR (I think this is the ca= se, 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 o= r hard sparing in a flag when issue a memory sparing operation. > > 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 so= me extra callback function/s in the edac/memory_repair.c for these attributes and which will reduce th= e current level of optimization done to minimize the code size. > > What: /sys/bus/edac/devices/name>/mem_repairX/ppr_persist_mode Same as above. persist_mode is needed for memory sparing feature too. > ... > Description: > (RW) Read/Write the current persist repair (PPR) mode set for a > post package 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. Valid values are: > > - repair-soft - Soft PPR function (temporary repair). > - repair-hard - Hard memory repair function (permanent >repair). > - All other values are reserved. > >Thanks, >Mauro Thanks, Shiju