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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BD3A9C53200 for ; Wed, 29 Jul 2026 13:43:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jc5qV0zQKoBK8dZ1irAh+ntbwd/8areVEA9NiOkofsc=; b=zHZDiWcdI+8yC3 v1Bzhbi8cLgpSjB6sz09+5sj/XroTutx70W+Oayd5XsW22RTHZFRrBB2L8fs9nxzzIj6gvNjMdGK8 p/uYHFeVIMV7c3+3gyXKkaaPHORKYuLCJkmM4LoYrWPwlDTmRgOLk3srN+yUJ8mzW+Nsd/35LFWoT DsTtGiRFYkE8M53EecxfZQNHk1YQTIfHZi//mikQDX63IuC4mcOWpmmXGXOyzqSslDw6F+iSDOnC9 5DNXCr9OJ2lyT/8Vc1S7BrS4FdiH18uMxBm64y6QTttWdT1zA3f6UYGQraCt0rUr6CLpAQ/zyzXex ht0lv6qFftuzfLep/yXg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wp4ZC-00000008AG4-2f5x; Wed, 29 Jul 2026 13:43:26 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wp4ZA-00000008AF9-42BP for linux-riscv@lists.infradead.org; Wed, 29 Jul 2026 13:43:25 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 5A94542CBD; Wed, 29 Jul 2026 13:43:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2E941F00A3A; Wed, 29 Jul 2026 13:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785332604; bh=PRcOiNq2tBTTPhKJmq+v2axNzroqRGfQ2NZU0eu9iKE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ZjSuoLL6lpaRqLc85ZT3LkyZzM0Zuhm/g6IAhMNxznnUHr+a6rLolhSNoCEWi/+XP +k6HCNUh4cSAi9zyCrMgJ02jlIO4nJcZUm5LakKUb3pjQbfw2JjFATqCogerkzUdKu 5DtyggnyhvqVRAqVowYb9SwgJsscKYOfSP0OGJxeg/F1x0agvlho4n9YPqdCoWkemo MSUrVc5OGlX5iUIMSdxmUF1lEVhqvsf443v/uXJD/wWFWvdytJ7kBBF2MY6kC6xMH4 hz2vLPNLN8qVdzpXNXCPMplDRgGhhamfwAgPHf3JuXPd6eVIuScvxjfLlZ57xhK8HX Dias68Gw4/HNw== Date: Wed, 29 Jul 2026 06:43:22 -0700 From: Drew Fustini To: Paul Walmsley Cc: Guo Ren , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Arnd Bergmann , Chen Wang , Inochi Amaoto , Leonardo Bras , Raj Vishwanathan4 , Djordje Todorovic , Alexandre Ghiti , Han Gao , Yao Zi , Xiaoguang Xing , Aleksandar Rikalo , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, sophgo@lists.linux.dev Subject: Re: [PATCH V5] riscv: errata: Add ERRATA_THEAD_WRITE_ONCE fixup Message-ID: References: <20260421143154.1590156-1-guoren@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, Jun 02, 2026 at 10:08:09AM -0700, Drew Fustini wrote: > On Tue, Apr 21, 2026 at 10:31:40AM -0400, guoren@kernel.org wrote: > > From: "Guo Ren (Alibaba DAMO Academy)" > > > > The early version of XuanTie C910 core has a store merge buffer > > delay problem. The store merge buffer could improve the store queue > > performance by merging multi-store requests, but when there are not > > continued store requests, the prior single store request would be > > waiting in the store queue for a long time. That would cause > > significant problems for communication between multi-cores. This > > problem was found on sg2042 & th1520 platforms with the qspinlock > > lock torture test. > > > > So appending a fence w.o could immediately flush the store merge > > buffer and let other cores see the write result. > > > > This will apply the WRITE_ONCE errata to handle the non-standard > > behavior via appending a fence w.o instruction for WRITE_ONCE(). > > > > This problem is only observed on the sg2042 hardware platform by > > running the lock_torture test program for half an hour. The problem > > was not found in the user space application, because interrupt can > > break the livelock. > > > > Acked-by: Arnd Bergmann > > Reviewed-by: Alexandre Ghiti > > Reviewed-by: Leonardo Bras > > Reviewed-by: Inochi Amaoto > > Tested-by: Han Gao > > Tested-by: Yao Zi > > Cc: Chen Wang > > Cc: Xiaoguang Xing > > Cc: Paul Walmsley > > Signed-off-by: Guo Ren (Alibaba DAMO Academy) > > --- > > Changelog > > > > v5: > > - Add Acked-by: Arnd Bergmann for asm/generic > > - Add Reviewed-by: Inochi Amaoto > > - Rebase on v7.0 > > Hi Paul, > > Han Gao (revy) let me know that there is now an errata entry for 'Writes > might stick in C910/C920v1 store buffer for too long' [1]. > > Does that address the concern you had about documenting the errata? > > Thanks, > Drew > > [1] https://github.com/revyos/xuantie-c900-bugs#writes-might-stick-in-c910c920v1-store-buffer-for-too-long Hi Paul, could this be considered for the upcoming merge window? Thanks, Drew _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv