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 B8D19C04FFE for ; Fri, 17 May 2024 11:16:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CBF166B007B; Fri, 17 May 2024 07:16:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C471D6B0083; Fri, 17 May 2024 07:16:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC0F26B0085; Fri, 17 May 2024 07:16:05 -0400 (EDT) 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 8DC826B007B for ; Fri, 17 May 2024 07:16:05 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 02BC11C051E for ; Fri, 17 May 2024 11:16:04 +0000 (UTC) X-FDA: 82127633490.30.6F67A59 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf10.hostedemail.com (Postfix) with ESMTP id EE8F2C0021 for ; Fri, 17 May 2024 11:16:01 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@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=1715944562; 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=K+01ljcguaWDxB9CIIY1A5lXghq+OCfCo99jFPfBzS8=; b=aNFdkDj4CIn3/yiHZe+XtbuiVBVII+ywCkKhx83Uw3LPoYBlYH+B0JQduig/Xvw4zmxtOz avJsXzqXiFk+vTRfimBY7HLdYx59/zGE0Du5CkLzOwaCPyM6Ss3idmRjxQXquEmPz60esS xwGqii2xJ+6mAQQ1Nl2TDUkJUFFsU9M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715944562; a=rsa-sha256; cv=none; b=Y00vKZSqSslia1daeIubxiMSIKoq0SXNQuc1elvkgNBbbPyRiUvgWoA5Qb83xoLk4x3b/O B5Tf4ah1iod2AosBPR1gfuze7UBARkkRxCTpawU+sjdxl7C3J3S8LNn8fqJO7ZXYm44f4L AmpLb8bFeSyHoRQ5uP1J4bN55/Xvboc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Vgknq1Jnvz6JBHH; Fri, 17 May 2024 19:12:31 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 9E417140A70; Fri, 17 May 2024 19:15:56 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 17 May 2024 12:15:55 +0100 Date: Fri, 17 May 2024 12:15:54 +0100 From: Jonathan Cameron To: Borislav Petkov CC: Dan Williams , Shiju Jose , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "dave@stgolabs.net" , "dave.jiang@intel.com" , "alison.schofield@intel.com" , "vishal.l.verma@intel.com" , "ira.weiny@intel.com" , "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "david@redhat.com" , "Vilas.Sridharan@amd.com" , "leo.duran@amd.com" , "Yazen.Ghannam@amd.com" , "rientjes@google.com" , "jiaqiyan@google.com" , "tony.luck@intel.com" , "Jon.Grimm@amd.com" , "dave.hansen@linux.intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "naoya.horiguchi@nec.com" , "james.morse@arm.com" , "jthoughton@google.com" , "somasundaram.a@hpe.com" , "erdemaktas@google.com" , "pgonda@google.com" , "duenwen@google.com" , "mike.malvestuto@intel.com" , "gthelen@google.com" , "wschwartz@amperecomputing.com" , "dferguson@amperecomputing.com" , "wbs@os.amperecomputing.com" , "nifan.cxl@gmail.com" , tanxiaofei , "Zengtao (B)" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm , "Greg Kroah-Hartman" , Jean Delvare , Guenter Roeck , Dmitry Torokhov Subject: Re: [RFC PATCH v8 01/10] ras: scrub: Add scrub subsystem Message-ID: <20240517121554.000031d4@Huawei.com> In-Reply-To: <20240511101705.GAZj9FoVbThp7JUK16@fat_crate.local> References: <4ceb38897d854cc095fca1220d49a4d2@huawei.com> <20240508192546.GHZjvRuvtu0XSJbkmz@fat_crate.local> <20240509101939.0000263a@Huawei.com> <20240509200306.GAZj0r-h5Tnc0ecIOz@fat_crate.local> <663d3e58a0f73_1c0a1929487@dwillia2-xfh.jf.intel.com.notmuch> <20240509215147.GBZj1Fc06Ieg8EQfnR@fat_crate.local> <663d55515a2d9_db82d2941e@dwillia2-xfh.jf.intel.com.notmuch> <20240510092511.GBZj3n9ye_BCSepFZy@fat_crate.local> <663e55c59d9d_3d7b429475@dwillia2-mobl3.amr.corp.intel.com.notmuch> <20240511101705.GAZj9FoVbThp7JUK16@fat_crate.local> 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.202.227.76] X-ClientProxiedBy: lhrpeml500004.china.huawei.com (7.191.163.9) To lhrpeml500005.china.huawei.com (7.191.163.240) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: EE8F2C0021 X-Rspam-User: X-Stat-Signature: 69jhnso6nyhi93wcfryoc4sc4d513y9m X-HE-Tag: 1715944561-402932 X-HE-Meta: U2FsdGVkX18VYtDz6/3tVvIRVINv1gazHVuvA3z72xN5BW4gRuk9Dfl86RWvZ2iScsK07ZscB8a78jGFkD//LXHs6jCGdc96NG5Txn0ByB0r9VTBPed3238F3qOazk1w+cwqKWJ9tPyhG97o0E33sZJVq9a5fBSXOPRWqXAAJpHphCKc5ZgLnfm+eF60kvtxkrVHd56344bLSCEbjDi6jYH9CA70MjcvNQe258xjBg1hidy+DCrcPHq86CQ4IMV63YIsXUd5PygscXNaINw61VHdOj+8tKYMiapguOzTEH2bWbzrJtNjQQcnUXykzNykX1kxAxEZ7Cfi6rWpNOinrNENWfDMBDTxiYFqbXnOhgf6yzBYZcwUwKsaSwY9lhyJKpZlE1FoiukrDkHGlD65gc1cttvzMQWP47GGkM+7ae8+Da4t/qIYn7sEK+QDbEJnnYrUK0F+va1aqN0t0HhyMhLf62vCvuWUqBFcdiEs0/wgYxH2wQR3dw8MRfON/qG45xv3ukAm5pED6nm13HcAajgVrIjpru5SFxE94V4XLVIu2UWXdeZ3FLj0DzlGbDXoSPq5dgeVQ6xgPqX8idS0B8IkHT06ZXJlBXJSW8HAGBBQGH47x+NeTbX0G9ctKKAulZ/j0lexYl35S1hEu+RXWuLZbfXdqjwKLUNWMNLwnjxydTpSIw8lDLwwvYNk1fUl5mw7GAzxiZDzG6KKAzvUIt+nd1HA3qBVLY4l0qmV93C1Jjz3Wcjp3YQAxxCMo6OjFN+51mM//B8fq2fILNvXPbPdZ5gz3vN7IA1v8g1wzrItSwQH+j3AjByH8tSdjaTOSd+411Dqz+OVYAs2n0mkVol0sxMGESnETuS3AtTTm6TVLhWBMhXGXZ0CFygruYtVbv3qoxHszuBexyMLSNLv9rJoTYpPndCTtI/KmKXxf9ojdWPU5u2mmMMH5lv4Nm/5laZfiivSlKvZIsjEL/d /7BYOx7/ OST4ZoG2J5ru6Rrz35JLvdFTH7lVH2JCQ8l0/plnHLLs3eJ5sv27AZG5Phetie5QVatMpnjBYUwop6F0iW/98cGOuA93Cp0fbbaR/twQ0zhtp6OEQQ7e2ezZb9PoirPg82N7VvMmESjYyqaXPHq4no0oJf3+pbap+OW3wbTJKVuR6ujARBfJTRfx2Qerd0mlHb3BG/xQ+HtrPNnzRCUVtfFMzR8wVZgvKHydcSdkBhuq2leg0YU3mpFfXTmqzBUU2FwbAPHo7DvU9YQXSLCDunUnbFJBYT8mktnXPqhfNCa0fSOfE8VMeZJ+fAzA4PSikPh0C 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: Focusing on just one bit. > > Now, the question of how many legacy scrub interfaces should be > > considered in this design out of the gate is a worthwhile discussion. I > > am encouraged that this ABI is at least trying to handle more than 1 > > backend, which makes me feel better that adding a 3rd and 4th might not > > be prohibitive. > > See above. > > I'm perfectly fine with: "hey, we have a new scrub API interfacing to > RAS scrub capability and it is *the* thing to use and all other hw scrub > functionality should be shoehorned into it. > > So this thing's design should at least try to anticipate supporting > other scrub hw. > > Because there's EDAC too. Why isn't this scrub thing part of EDAC? Why > isn't this scrub API part of edac_core? I mean, this is all RAS so why > design a whole new thing when the required glue is already there? > > We can just as well have a > > /sys/devices/system/edac/scrub/ > > node hierarchy and have everything there. A few questions about this. It seems an unusual use fake devices and a bus so I'm trying to understand how we might do something that looks more standard but perhaps also fit within the existing scheme. I appreciate this stuff has evolved over a long time, so lots of backwards compatibility concerns. If I follow this right the current situation is: /sys/devices/system/edac is the 'virtual' device registered on the edac bus. > > Why does it have to be yet another thing? > > And if it needs to be separate, who's going to maintain it? > > > Which matches what I reacted to on the last posting: > > > > "Maybe it is self evident to others, but for me there is little in these > > changelogs besides 'mechanism exists, enable it'" > > > > ...and to me that feedback was taken to heart with much improved > > changelogs in this new posting. > > Ok. > > > This init time feature probing discussion feels like it was born from a > > micommunication / misunderstanding. > > Yes, it seems so, thanks for clarifying things. > > I still am unclear on the usecases and how this is supposed to be used > and also, as mentioned above, we have a *lot* of RAS functionality > spread around the kernel. Perhaps we should start unifying it instead of > adding more... > > So the big picture and where we're headed to, needs to be clarified first. > > Thx. >