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 A135CCD5BD1 for ; Tue, 2 Jun 2026 17:08:23 +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=vWT6aFPXFRC4USoJM1r5lgvpHwldtvXQAewGJObzWW4=; b=E/7RdpZKO/lHq6 fQ7VS7LAcLsD1NiYRAQ+b5Hdk5niJbCq4YugcyWsGVBTmOeLRZaF7cblSthaQ5EfiUvltnPUAC6lo 63vCEPkzxstKGXp6DFw76uNz/zT1wn0ttcMceEC87GfS4saLMU5IHrmlP2bGdHlOOxvRe7hm02luA bua/zFIi+2AIq86XkKZ0k3AOs/CVxTD12FgINgXnD4br7r0oCjPxMFqHQ6Y10b+XmRjgSHM9KgiQB NTxOpwiDkznec3VGzF1zcUxClqkm+plWEguG1Wmu3dc/Ybavf3Y3WXIrUHXt3aL+KYJuRk0HkFOg/ Om+jysw98m7Q+GUxt2XQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wUSb7-0000000DXyd-1A31; Tue, 02 Jun 2026 17:08:13 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wUSb6-0000000DXyE-0ZdM for linux-riscv@lists.infradead.org; Tue, 02 Jun 2026 17:08:12 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 6548B60120; Tue, 2 Jun 2026 17:08:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5E661F00893; Tue, 2 Jun 2026 17:08:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780420091; bh=3M0vc+nnyZUAtCakqX25nvCIWIKoTxj8AwWEe+bdm8E=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=OZnowGirIqJXWMIvwon10ID8EtU9ssuP9ICXRzhuOlVx89jK8wFqoDvteFmHS9KDh E/z1KcDLeUR3zksorVBYqnA2wBMJcNpoTTm/GgaXO47EzUu2mIKYr3V5qDxBvia7nw oF9kiaJYruPpDb19VyYLI0Nnjb9BMqFWhcRHhy7PghnPvY4IQyHiR9Cr9Lsv7VVP3b /LZe7pmbipLvrVGKcSw3O5ka56Yb9ujEUi5xVi8KZJCtxTdE47JDFyf/EZVfhwP/9O rGt7NCqeh6vvAZGbxCkIoksIJwENaE/R8Lrqdnl99CGtRimRZWGqqtTeDLxAuXCpdd U5CSY4O9wwgyA== Date: Tue, 2 Jun 2026 10:08:09 -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: <20260421143154.1590156-1-guoren@kernel.org> 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, 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv