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 06E92CFA44F for ; Wed, 23 Oct 2024 16:17:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75FCC6B007B; Wed, 23 Oct 2024 12:17:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70F366B0082; Wed, 23 Oct 2024 12:17:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B1596B0083; Wed, 23 Oct 2024 12:17:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3FA9A6B007B for ; Wed, 23 Oct 2024 12:17:05 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 48C2FAC543 for ; Wed, 23 Oct 2024 16:16:30 +0000 (UTC) X-FDA: 82705370496.27.52E2BE1 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) by imf26.hostedemail.com (Postfix) with ESMTP id 8492C140024 for ; Wed, 23 Oct 2024 16:16:49 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=W19lpIFu; spf=pass (imf26.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729700146; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZbVpk0hvfbmUrgI0RQm7j5r7sUgbzT1X7sZYFMHu3WU=; b=m0FuLgaPh7aqKGt0gSLk3XVRjBuy0MLkpLiGisVRC34ELH6CxYTLPSoGtp9DOZyNgjT7Tu vweohzbKRv3/TrYjmZE60xCmZ93S+ngz65RMbvab0Z0JkJwOtDNd8Bkzvk6416pRZVVgNu lzxioMYrbTPQNe7stowEzAeXb9HKddM= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=alien8.de header.s=alien8 header.b=W19lpIFu; spf=pass (imf26.hostedemail.com: domain of bp@alien8.de designates 65.109.113.108 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729700146; a=rsa-sha256; cv=none; b=r3LMyR5YFnE83oQSQuZauLchHYuetBgL4FH0Rq/3E0vMTx61obsXkW9HKkqZGBIwOI3mK3 5k2E6diggzq+QBi9P1eQvI4+ZE39RKPX2WOj7Qjl9i0umXWmTNs1voREa2Yja4sG+Mfom5 XciJoj54dfWiE9+R1LmtDomgv64xnKQ= Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id D903640E015F; Wed, 23 Oct 2024 16:16:57 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3knQLSADIqtL; Wed, 23 Oct 2024 16:16:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1729700213; bh=ZbVpk0hvfbmUrgI0RQm7j5r7sUgbzT1X7sZYFMHu3WU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W19lpIFuP87d30ErCdAXO0V9Rn6i6qLqfUYpO4RRk5GxzsNsqOhxQ+xQwBya28t4R OrLqbJTtWO1fexV7FatqKICpG0ipaX3nOTvP34+G8Br0prc8d5IFMdxZAZmQxqEK3/ Zbxz4TMQq8M2T3FskB15ySaBiPV9usbYQh0D8m+L2a/4xQ7hK2J2kvi4os0+BfXJpH VH3zCNNbljgQq0cu9fbj975x7vdcO67KUTvjFNEkocvOBI4Vf8jc4krVVl5HvnSKXV z4csYqEoJl2MC0kqspB8Q8d7q19lpfq9H+qBWh1HkLcsFEXu7e3+Rrp1OATrC9BXMT pT7eWmucA+TubejM3+KxPfFd7RE3ho1rU2OrdiUtoQ9kFGVeHLFPF/TFuX6MzSQigL +ne6pxY+ikLclA4FjHSgPPfKUg+gO9koPu1yAH932CEXFSN633PLyBXrHA9yih25Za tU5v31PNj9URR0bcNUg+w9Xoq/WB4ErufIMS3oIEq7lOkJE3I2D//PUxJYwG4A940Y /vGEAlZVh/wuUZFjJ4cohxNPahwaPx5zGzcuGvABKysCXmVNAbO6xsqF9Lze9XY0p0 N8SW/+J76pBEv+8h1NumlE0x60VJD7I3eVmX2Idr+J/jawe5JnxeGyPDx7jJZxPdAW Z3cagfchrgrnaLxbiZ7azmg0= Received: from zn.tnic (p5de8e8eb.dip0.t-ipconnect.de [93.232.232.235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id D827040E0191; Wed, 23 Oct 2024 16:16:09 +0000 (UTC) Date: Wed, 23 Oct 2024 18:16:03 +0200 From: Borislav Petkov 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" , "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 v13 02/18] EDAC: Add scrub control feature Message-ID: <20241023161603.GDZxkhQ65XCa-6S7RU@fat_crate.local> References: <20241009124120.1124-1-shiju.jose@huawei.com> <20241009124120.1124-3-shiju.jose@huawei.com> <20241022190454.GIZxf3VkmLVR-JLeUc@fat_crate.local> <4ee36d03a2894606a571b37f440da36f@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4ee36d03a2894606a571b37f440da36f@huawei.com> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 8492C140024 X-Stat-Signature: ifo8ekej9ywh1nj8sq18wepokeiusaaz X-HE-Tag: 1729700209-114955 X-HE-Meta: U2FsdGVkX19TIk0Rzdc9wsi36GJ9iIuFN0bIvSMSFWCLCeqo4COepFmKnzTrKC63D8eoTZNWJJmW331RGMLr+O3INwAh98U7P2qfhCm9LmuimjXtdvngcgUMZjsIeUc/DunyktGe0yxJ6B+9uVX5SYaAF8myx6Yo28kSNcK96UbPs2iGrhbNwk91MNQRchP8UA9JBdBI6jbehQhhvHHWg1VoYZ0VLl465enMCkj9l2A2jBYL9Xse7Ti2ZC67dI/ZzgO7HgVm84W9GZLsQAhFeexbXP6+/bB5eymNP0UurMapabi7boz8VFV8zBuQha3riThgRr48mZEKIUYTPdMxoQxw7HrrZaRnaYLBe9P2eNEZzVy7WeDTL3p4Alu4mO6tSiF4igzvZWOCTgt0I2pa22Ha6o27WYnEvDhG3Nb/thxHXCf4WJjBGVlohQKrOfFUXImoZgb/2S1lBIK5VUeqkOGBLDbu/gAfUkAJqMC9NoZ0RzngqRvvJl8YJMKE1tbyqKHkg4VIKDouEZQhQHYtw1zLM7nRp4G7gCUrk1mCInihLl+UStpFy2gE4VaztF9aneR9q72TsJkXxb+duaa+Xp++jDSf1ZmengUkxN4Ux6k5ZMqR2iozJjBcu9xdObCdXT3Bh+YQ6j0q1lndFmenqBOGarikIsMqIEQ5nUJlQ5zOtkXcB3HpG7JTVdiWBDz/xrn7zXydzZYQijCOjZegD7IRmX5IQPJUJoWYzzDvKfNinlGMC1iCW7xuShdsCv7wWHEW8O7Sdq8W4PABdYkA0LhbjECh346LZJczUc+cQ7EooDHq86OcgHRYB8cg4SV8bFJwzbYh7PIy2OV5rkJ5TXyuV+ZuyX51AWvHRpS3zuhZi0Z6xh9v3/TM/LVuHD1Zkaw8mTN3pfnGK0kj4uBVI93o5CqLkUZaxwv5Yu2KHizRYb+klFao1Pd5d3jkoCbM8tJHfbWg6sfxuNFdCNG gKjlEMs5 Qxr1f3CxCa5v/1FEMoRYCrhXyzYK+43n+7Ti6hTLGbJc+41ae/knk79EwOL+7kqtZStnoE9z1FTuxKqbRrpWMpOGEzC667hVSFV1nvW6+i+T73Yu7k3d3OyM3+AKFsYzJiQcZwKn6U9DG3bKCWsscKXwkAytVYkhV16DJRs58/tAuVi9mtRJOrE+XyP9Q24UAFNZW4OtXYyIP7BmEgX1TTTsi9czbtCkyZSAgQEHeOV/J56ElIYqyn9ICDq5eZcHFFP7gb5YreBi2qGbO86SsjjIVCU0b7JaDsjSwqdeDLuQ94nJsjs3b9onxSbhEln/9gwQLttbZS9WaSKPJ7bhwUD+k2w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.010693, 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, Oct 23, 2024 at 04:04:05PM +0000, Shiju Jose wrote: > >Why do you need a separate "enable" flag? > > > >Why can't it be: "writing into "addr" starts the on-demand scrubbing"? > If 'enable' attribute is removed , then there is an ordering with setting address + size. No, there won't be. You clarify the ordering and if someone doesn't adhere to it, you check for 0 values and return. > Also user space can't check whether scrubbing is enabled or not. That one is semi-valid. You can set addr to 0 when scrubbing is done but then userspace might wanna know which address it scrubbed. > >What are those three good for and why are they exposed? > Scrub has an overhead when running and that may want to be reduced by > just taking longer to do it. > Min and max scrub cycle duration returns the range of scrub rate > supported by the device. This *definitely* needs to be part of the documentation explaining the API. > >I think fail. What is a scrub feature good for if it doesn't have ops? > Here continue to check any other feature (for eg. ECS, memory repair or another scrub instance) listed > by the parent device in the ras_features[]. Why would you tolerate a semi-broken feature? This is all open source code. People will fix it when they test their feature which is missing ops. There's no point in allowing any of that. Btw, do me a favor, pls, and trim your mails when you reply just like I do. You don't want to leave text quoted to which you are not replying to. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette