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 38811D18130 for ; Mon, 14 Oct 2024 17:02:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CABDD6B0089; Mon, 14 Oct 2024 13:02:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C356C6B008A; Mon, 14 Oct 2024 13:02:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD7786B008C; Mon, 14 Oct 2024 13:02:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8F1EB6B0089 for ; Mon, 14 Oct 2024 13:02:27 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 509BCAC1A3 for ; Mon, 14 Oct 2024 17:02:11 +0000 (UTC) X-FDA: 82672826124.26.05990CF Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf29.hostedemail.com (Postfix) with ESMTP id 97BB012001D for ; Mon, 14 Oct 2024 17:02:16 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf29.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=1728925240; a=rsa-sha256; cv=none; b=26JSkzgWiaDE0C/L0dAM4rfejg7ZjTHR+uZ4Ik2GKSXYfQgnOY418vNwEJFOrL/qn5M7tS 0L4juO2CQl7tzbjNoQzHQO/fFmNRxo1FCjF9ubUx2IX57Y/HLIdCVQXxz33VHB7Rtq/NQo X9nEEzEYDCs9oQv81LD2Qm8L3pqbvSw= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf29.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=1728925240; 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=GZld9E2CXs+J26zLz5T0Q55PYdEpcvbqCV/nuB3Imuo=; b=zqWS5TJoyz4igjHD2W3i6sKAQZJgiBWa9bJ/aD+XNxmdFGPsNksbcAkfarZWPN3FSrpG0Z 3hOqss8CD6K1FALPlWUL9iflqX3ji7sUi2prp5bbZx7iZmn7JhURxSctoErJ/nupm6XjvB cZ0xYcE3HsXB1oDHJZc+xALEsxQd+4o= Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XS3QR2yBmz6J6qD; Tue, 15 Oct 2024 01:00:47 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 734101404F5; Tue, 15 Oct 2024 01:02:22 +0800 (CST) Received: from localhost (10.203.177.66) 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; Mon, 14 Oct 2024 19:02:19 +0200 Date: Mon, 14 Oct 2024 18:02:17 +0100 From: Jonathan Cameron 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" , "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 v13 15/18] EDAC: Add memory repair control feature Message-ID: <20241014180217.0000299a@Huawei.com> In-Reply-To: <162f5e44507b46029eebb007dedef0d5@huawei.com> References: <20241009124120.1124-1-shiju.jose@huawei.com> <20241009124120.1124-16-shiju.jose@huawei.com> <20241014172312.00007034@Huawei.com> <162f5e44507b46029eebb007dedef0d5@huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.177.66] X-ClientProxiedBy: lhrpeml100005.china.huawei.com (7.191.160.25) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspamd-Queue-Id: 97BB012001D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: anm6pcyh44fmymhufj5zswwf8zu6ht5j X-HE-Tag: 1728925336-810019 X-HE-Meta: U2FsdGVkX19Fs2BD4gwqfsXSqAoHf0dMq3BqcLA0EH72lRegpg5HeItzanYg30HFHUIvskQO3vdoXc1BW7NwZE8r80cMZ+NQL2UXFq9VpNIQ87eLrNeuW0VtilSXkvOmkiXBA49C0OHjeiL+UsMPY6YauVZFGyaS7MWCwcc57QonVgE6rAGQ8ODiRhvkBwmYRbqxgjvI7ihwjsbUtGz57siLuaQ+14+x2XN8/YYgmhFIFoWG0QeEc0jL1prL46Jqcc3xUy/EZ+uKHd1CTSem+uqWZaWsOZ3bDFrAZqcT3BzmicGQJSuXyWBYTc/EzT3uPlSBjnzY0cuxE0bg6HhCys39sAW3zKnPgPbhrLx+v4x5gowYmoF+I1AJ0/fGzFU4iqf/VBcxEGoitR8j+DxgAgaC1HpCFZcm2cVufv8UZeLIQGABiqIDAlEbDs1N+kv5p4nUAW58SL7IPfF48UAzan5TPeZHnm6dyJZRhdg1Do4A3q2aKFuhYWxpO7zX8NmRHJDXP+V+2BRaV0+dPL8y6H1c6ae1G52gz+2ue7ROKI8EJvQPbxVQJQEBq8jSw5YxkBmQRNDm6wADKR9T1AgR9qk0g7rCWTZkWGc8wQ7+OVsiWYaWrHy93uaNRSurm71J+B7Jy3QsBG48PZS4ZIa7LPUhtNhikl/1/enZ+8D7nx0ChYYDmFp8tfcExBmb7VMq/ilVsP3sHgDJqwxYaNXChlNSb6FaCdAnziLgvHg5to2kxnLFyq+ikHTpPu/7t4rKwBBvcGww0YsJrkU503R+LjFGQ5Za8RtEcgDsX29S4MyRe77cvsi+nBAf3JTB+tblvHZevJkO9ewyQgScCZ3He9UI965cZhKVZdbKWktHCSnz3vBRUkV5EvBcFCB/I517FPmpGI/CkEY8FE1cQ3h/n2mplkQm79JGo3a5rsX2JjOv+QzSNysLUlO1kfD/U6s9BTMlE5D0+tbJON5SMXa QkPyVKwJ VW9DoRKzza5XTNdGhss7/5AhdqYh+h6MxdiusVAUBP8ac7CHFymih20u1183WquaGgYgG0hRmZboz+XX1slgJwNIZoSRM9HU3AqbhXsX33lNQsU5hgy1BuWFM1nxmnug8C497RUOV/54Zi9ptVc0U6SNM3ikEfeqOWOMNr+lw2afXiztShYZKp5+UrNHWLAjvCiT5K1Pkv41rLriKo+i4DLpy4umezsl1ow9H7ASaeHhiQAgiLn+ne8urqcoJJ04wuT5Etoz6u4xLotQGSxwE2yX+oEwD/s4w1GFD8VciIMn1R/3ima34fU97Ii1e5Fcus5Fxd420S8apblBcAF/HsakXIstDqDi5ABc7u1vFVciBz7JMpKmyH38s+ROFXfFv3hzgWZg+egw8Ia20BYWYpvbvwClifnBTRFQL7F8L3aI3lCZQiykkQoTGSLGBO45uEt2KcX/Zd40rG2pLzRdndJQKy+aoEA8TU4/8lsAF1KA0m1NsssdmytXteRxSK5pfTdzlz0kTmx7mQDQjMYuOiQQb7S4+BvlFckgQfdtqKvPDIq8ERS+ctJo0Tx6Ob7OfBLsm57titlkJ9FMrZQAGReVV9zGRAUCeruJMCkxyUiGOd+q25j6wMLEN/0dsA8VwK1d27vkQ+9f3x0AL2I0zrWrsgno2ySlWLmpp62MI3UkvOUVwJ5b48ICDpUkgVQ235FGb6LC4qA4s80dercziCTwFngJfA8Q4fhSedCuQuH3C8fzzvGLYrKi13hXh8SeNGlkHd3noqDVsrho9Nnpeb5dyxAjQqRdIXGPCA4/5TETKcZwCB2uDfvZvPT2ReCBrqviBrLwVAdYtX1/HJ7ojWKz/JsH9bMFo3WorOHLuMjizDZ+ZRGIzCvlMfZAeLY1oq2ho 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 Mon, 14 Oct 2024 17:39:12 +0100 Shiju Jose wrote: > >-----Original Message----- > >From: Jonathan Cameron > >Sent: 14 October 2024 17:23 > >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; > >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 v13 15/18] EDAC: Add memory repair control feature > > > >On Wed, 9 Oct 2024 13:41:16 +0100 > > wrote: > > > >> From: Shiju Jose > >> > >> Add generic EDAC memory repair control, eg. PPR(Post Package Repair), > >> memory sparing etc, control driver in order to control memory repairs > >> in the system. Supports sPPR(soft PPR), hPPR(hard PPR), soft/hard > >> memory sparing, memory sparing at cacheline/row/bank/rank granularity etc. > >> Device with memory repair features registers with EDAC device driver, > >> which retrieves memory repair descriptor from EDAC memory repair > >> driver and exposes the sysfs repair control attributes to userspace in > >> /sys/bus/edac/devices//mem_repairX/. > >> > >> The common memory repair control interface abstracts the control of an > >> arbitrary memory repair functionality to a common set of functions. > >> The sysfs memory repair attribute nodes would be present only if the > >> client driver has implemented the corresponding attribute callback > >> function and passed in ops to the EDAC device driver during registration. > >> > >> Signed-off-by: Shiju Jose > [...] > > > >> + > >> +What: /sys/bus/edac/devices//mem_repairX/hpa > >> +Date: Oct 2024 > >> +KernelVersion: 6.12 > >> +Contact: linux-edac@vger.kernel.org > >> +Description: > >> + (WO) Set HPA (Host Physical Address) for memory repair. > > > >Can we not just read back what was written? Seems like userspace might expect > >that? > I am fine to add read back. > I did not add read back for controls because there was no such requirement from the client driver and > also tried to reduce the number of callbacks in the initial version. I think we can for now at least just cache in the core code. If we have future implementations where more validation is possible then we can add optional callbacks at that stage. Jonathan > > Thanks, > Shiju