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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BDC13C433FE for ; Tue, 2 Nov 2021 08:22:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A129D61051 for ; Tue, 2 Nov 2021 08:22:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231135AbhKBIZO (ORCPT ); Tue, 2 Nov 2021 04:25:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229920AbhKBIY4 (ORCPT ); Tue, 2 Nov 2021 04:24:56 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CF7CC061764; Tue, 2 Nov 2021 01:22:16 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id p16so41399169lfa.2; Tue, 02 Nov 2021 01:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ne7EPu6jTpGVLHdvimehHVoEG1G7OTA5OiY+BOnLe4A=; b=PjUNJMcSRJ62akTQe/diEaqWuErpiYU8V09h41nU2mp9HKydnky/bk6OV2dQuyewS2 S9RuIpT48CK73n4qcfBiHUYtyhouUpWA0+J54GBgSj7yynd2vT4DW8fv4ahrzlsrT0E6 /lijxNB4x8IwycViFV+jzEaUZm/3pQxtQJf916W/qvzbddRwXkIOIm4OiMVLn/WIZ/DY N5odBUKp0BxW4l3NBxeuLswtCe3PZ5pflo9kkmST1Cs2eJToB0wimMkmOPSuyQTpfxUg oA9KmxcFF04RD5lgmyzKxuHhhF7bgKu7R5M+jFKRFH6KtY1r31FAMN4zM91jGi33Xl0z BFsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ne7EPu6jTpGVLHdvimehHVoEG1G7OTA5OiY+BOnLe4A=; b=1WFLEUF16Ai7gOsHSqGBy/gsqn3ghIsMr0ZOnaIyQMzg9FxHIhe/GSOd1pCRzhmSgJ A+23GYFvan8gBDS5jMGfD9IUugvbtyd55BGw9cPC8s6wvoNjBOgly1YZi6qYDL4KJ5qB 8DOgy3ExtgsPVO+0qf7PFrRYyuFh0/foVVpOcgawrWUWmkdQVoYE3wJp8VXAou7y6Fij C18AzTeiiD3s66uNIyQhbxAa4Z7gpyVIf76z+ra74UwRLQAVIPB6vnpoAduyjsUrZ/YW XTO06qZkABY+0IYElKEy3MU1MLwv3SfHOKf8D8y8kvDLnE0QfzFoDG4n7651WAN7rT0K yuGA== X-Gm-Message-State: AOAM530bR1n1ELHva8LRKZdm2qD3R2nDuDI6sqUjEMMMEJfcDN/jWaCE ziucLvUbU1ZJOxFRTyuIwuCxZvllLnEL/04D0A== X-Google-Smtp-Source: ABdhPJz2sTRMCaO5nz6DI/gO9EPlcsOXPYF/+nvlvqLAyf4DhHKZV4nnIz1ld2TtCyuBcBxPgayITk4DR6CTKXKkKxk= X-Received: by 2002:a05:6512:3c9e:: with SMTP id h30mr2097037lfv.93.1635841334320; Tue, 02 Nov 2021 01:22:14 -0700 (PDT) MIME-Version: 1.0 References: <20211028141938.3530-1-lukas.bulwahn@gmail.com> <20211028141938.3530-12-lukas.bulwahn@gmail.com> In-Reply-To: From: Avi Fishman Date: Tue, 2 Nov 2021 10:22:03 +0200 Message-ID: Subject: Re: [PATCH 11/13] arm: npcm: drop selecting non-existing ARM_ERRATA_794072 To: Lukas Bulwahn Cc: Joel Stanley , Arnd Bergmann , Tomer Maimon , Russell King , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Sekhar Nori , Bartosz Golaszewski , Linus Walleij , Imre Kaloz , Krzysztof Halasa , Tali Perry , Patrick Venture , Nancy Yuen , Benjamin Fair , Dinh Nguyen , Linux ARM , OpenBMC Maillist , kernel-janitors , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, At Nuvoton we implied this WA in the past, not because we encountered a specific problem but since the errata says so and we saw this in other patches like: https://patchwork.kernel.org/project/linux-arm-kernel/patch/1396298072-13254-2-git-send-email-nitin.garg@freescale.com/ But we didn't upstream the arch/arm/mm/proc-v7.S >From the errata document. "794072 A short loop including a DMB instruction might cause a denial of service on another processor which executes a CP15 broadcast operation Status Affects: Fault Type: Fault Status: Cortex-A9 MPCore. Programmer Category B Present in: All r1, r2, r3 and r4 revisions Open Description A processor which continuously executes a short loop containing a DMB instruction might prevent a CP15 operation broadcast by another processor making further progress, causing a denial of service. Configurations affected This erratum affects all Cortex-A9 MPCore processors with two or more processors. Conditions The erratum requires the following conditions: - Two or more processors are working in SMP mode (ACTLR.SMP=1) - One of the processors continuously executes a short loop containing at least one DMB instruction. - Another processor executes a CP15 maintenance operation that is broadcast. This requires that this processor has enabled the broadcasting of CP15 operations (ACTLR.FW=1) For the erratum to occur, the short loop containing the DMB instruction must meet all of the following additional conditions: - No more than 10 instructions other than the DMB are executed between each DMB - No non-conditional Load or Store, or conditional Load or Store which pass the condition code check, are executed between each DMB When all the conditions for the erratum are met, the short loop creates a continuous stream of DMB instructions. This might cause a denial of service, by preventing the processor executing the short loop from executing the received broadcast CP15 operation. As a result, the processor that originally executed the broadcast CP15 operation is stalled until the execution of the loop is interrupted. Note that because the process issuing the CP15 broadcast operation cannot complete operation, it cannot enter any debug-mode, and cannot take any interrupt. If the processor executing the short loop also cannot be interrupted, for example if it has disabled its interrupts, or if no interrupts are routed to this processor, this erratum might cause a system livelock. Implications The erratum might create performance issues, or in the worst case it might cause a system livelock if the processor executing the DMB is in an infinite loop that cannot be interrupted. Workaround This erratum can be worked round by setting bit[4] of the undocumented Diagnostic Control Register to 1. This register is encoded as CP15 c15 0 c0 1. This bit can be written in Secure state only, with the following Read/Modify/Write code sequence: MRC p15,0,rt,c15,c0,1 ORR rt,rt,#0x10 MCR p15,0,rt,c15,c0,1 When it is set, this bit causes the DMB instruction to be decoded and executed like a DSB. Using this software workaround is not expected to have any impact on the overall performance of the processor on a typical code base. Other workarounds are also available for this erratum, to either prevent or interrupt the continuous stream of DMB instructions that causes the deadlock. For example: - Inserting a non-conditional Load or Store instruction in the loop between each DMB - Inserting additional instructions in the loop, such as NOPs, to avoid the processor seeing back to back DMB instructions. - Making the processor executing the short loop take regular interrupts." Avi On Tue, Nov 2, 2021 at 9:31 AM Lukas Bulwahn wrote: > > On Fri, Oct 29, 2021 at 8:36 AM Joel Stanley wrote: > > > > On Thu, 28 Oct 2021 at 14:57, Arnd Bergmann wrote: > > > > > > On Thu, Oct 28, 2021 at 4:19 PM Lukas Bulwahn wrote: > > > > > > > > There is no and never was a Kconfig for ARM_ERRATA_794072 in the kernel > > > > tree. So, there is no need to select ARM_ERRATA_794072 in > > > > ./arch/arm/mach-npcm/Kconfig. > > > > > > > > Simply drop selecting the non-existing ARM_ERRATA_794072. > > > > > > > > This issue was discovered with ./scripts/checkkconfigsymbols.py. > > > > > > > > Signed-off-by: Lukas Bulwahn > > > > --- > > > > > > Could this be a typo? Maybe we need to enable a different errata workaround > > > here, or maybe that code is actually needed and has to get sent. > > > > Doing some searching, u-boot had a workaround for something called > > ARM_ERRATA_794072. > > > > https://github.com/u-boot/u-boot/commit/f71cbfe3ca5d2ad20159871700e8e248c8818ba8 > > > > Lore has the review history for that patch: > > > > https://lore.kernel.org/all/6be32e0b5b454ed7b609317266a8e798@BLUPR03MB358.namprd03.prod.outlook.com/ > > > > It looks like it's the same workaround as ARM_ERRATA_742230, which the > > kernel does implement. > > > > It would be good to hear from the Nuvoton people, or an Arm person. > > > > I will happily update the patch to select ARM_ERRATA_742230 instead of > the dead non-existing ARM_ERRATA_794072. > > In contrast to the current patch that basically only cleans up "dead > config" and has no effective functional change, the new patch would > change the behaviour. I cannot test this patch (beyond some basic > compile test) on the hardware; so, we certainly need someone to have > that hardware, knows how to test it or confirm otherwise that we > should select the ARM_ERRATA_742230 fix for this hardware. > > The current patch should be subsumed by the new patch; the submission > of the new patch is deferred until that person shows up. Let's see. > > Lukas -- Regards, Avi 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2050C433EF for ; Tue, 2 Nov 2021 08:23:08 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 247E761050 for ; Tue, 2 Nov 2021 08:23:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 247E761050 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Hk2wB3CJ5z2y6F for ; Tue, 2 Nov 2021 19:23:06 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=PjUNJMcS; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2a00:1450:4864:20::12f; helo=mail-lf1-x12f.google.com; envelope-from=avifishman70@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=PjUNJMcS; dkim-atps=neutral Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Hk2vP3zNRz2xBv for ; Tue, 2 Nov 2021 19:22:23 +1100 (AEDT) Received: by mail-lf1-x12f.google.com with SMTP id y26so41269517lfa.11 for ; Tue, 02 Nov 2021 01:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ne7EPu6jTpGVLHdvimehHVoEG1G7OTA5OiY+BOnLe4A=; b=PjUNJMcSRJ62akTQe/diEaqWuErpiYU8V09h41nU2mp9HKydnky/bk6OV2dQuyewS2 S9RuIpT48CK73n4qcfBiHUYtyhouUpWA0+J54GBgSj7yynd2vT4DW8fv4ahrzlsrT0E6 /lijxNB4x8IwycViFV+jzEaUZm/3pQxtQJf916W/qvzbddRwXkIOIm4OiMVLn/WIZ/DY N5odBUKp0BxW4l3NBxeuLswtCe3PZ5pflo9kkmST1Cs2eJToB0wimMkmOPSuyQTpfxUg oA9KmxcFF04RD5lgmyzKxuHhhF7bgKu7R5M+jFKRFH6KtY1r31FAMN4zM91jGi33Xl0z BFsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ne7EPu6jTpGVLHdvimehHVoEG1G7OTA5OiY+BOnLe4A=; b=AQTOYMGPRpWHX+EH0k6cl2SEU2/ERWmxCk2VPun6ZpNCiFb7rEzp2pYl4vsy45boA2 viUS+tRAWR2K1Cj4b88YiR1/FnV8NFem9Ba49CZ3bTrXBaG95SbG8M0KNhgLWNcmU0MN QJJJcYuhgVS7pvTn88OA1oZ0246bq3KMUw0ZCaP6icH8iGm0y285c3uNxakdpFMS4vPO Jvcc999wUVJnd8ln+je4QSRXoF/0wApVt6VXF3TYlOgd1XvEyIl5zQ65yEHKblarF5VI DdM4csq+7xPz4mZx4AzabZkTbh/KP388rBCt5yJmrQTBM9HeecFAR3vEZ/r4Xy8uO7wd FP3A== X-Gm-Message-State: AOAM532kiKKBetXzVsZeacJxr4/4T40pdUDFx5CfVimuvsAZIGRZS0Tx zY2e1rErDS75ixR/f236QfCbNHJLuVV6NeYK+w== X-Google-Smtp-Source: ABdhPJz2sTRMCaO5nz6DI/gO9EPlcsOXPYF/+nvlvqLAyf4DhHKZV4nnIz1ld2TtCyuBcBxPgayITk4DR6CTKXKkKxk= X-Received: by 2002:a05:6512:3c9e:: with SMTP id h30mr2097037lfv.93.1635841334320; Tue, 02 Nov 2021 01:22:14 -0700 (PDT) MIME-Version: 1.0 References: <20211028141938.3530-1-lukas.bulwahn@gmail.com> <20211028141938.3530-12-lukas.bulwahn@gmail.com> In-Reply-To: From: Avi Fishman Date: Tue, 2 Nov 2021 10:22:03 +0200 Message-ID: Subject: Re: [PATCH 11/13] arm: npcm: drop selecting non-existing ARM_ERRATA_794072 To: Lukas Bulwahn Content-Type: text/plain; charset="UTF-8" X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tomer Maimon , kernel-janitors , Tali Perry , Fabio Estevam , Benjamin Fair , OpenBMC Maillist , Russell King , Arnd Bergmann , Sekhar Nori , Sascha Hauer , Krzysztof Halasa , Linux ARM , Patrick Venture , Linus Walleij , Linux Kernel Mailing List , Dinh Nguyen , Pengutronix Kernel Team , Imre Kaloz , Shawn Guo , Bartosz Golaszewski Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" Hi, At Nuvoton we implied this WA in the past, not because we encountered a specific problem but since the errata says so and we saw this in other patches like: https://patchwork.kernel.org/project/linux-arm-kernel/patch/1396298072-13254-2-git-send-email-nitin.garg@freescale.com/ But we didn't upstream the arch/arm/mm/proc-v7.S >From the errata document. "794072 A short loop including a DMB instruction might cause a denial of service on another processor which executes a CP15 broadcast operation Status Affects: Fault Type: Fault Status: Cortex-A9 MPCore. Programmer Category B Present in: All r1, r2, r3 and r4 revisions Open Description A processor which continuously executes a short loop containing a DMB instruction might prevent a CP15 operation broadcast by another processor making further progress, causing a denial of service. Configurations affected This erratum affects all Cortex-A9 MPCore processors with two or more processors. Conditions The erratum requires the following conditions: - Two or more processors are working in SMP mode (ACTLR.SMP=1) - One of the processors continuously executes a short loop containing at least one DMB instruction. - Another processor executes a CP15 maintenance operation that is broadcast. This requires that this processor has enabled the broadcasting of CP15 operations (ACTLR.FW=1) For the erratum to occur, the short loop containing the DMB instruction must meet all of the following additional conditions: - No more than 10 instructions other than the DMB are executed between each DMB - No non-conditional Load or Store, or conditional Load or Store which pass the condition code check, are executed between each DMB When all the conditions for the erratum are met, the short loop creates a continuous stream of DMB instructions. This might cause a denial of service, by preventing the processor executing the short loop from executing the received broadcast CP15 operation. As a result, the processor that originally executed the broadcast CP15 operation is stalled until the execution of the loop is interrupted. Note that because the process issuing the CP15 broadcast operation cannot complete operation, it cannot enter any debug-mode, and cannot take any interrupt. If the processor executing the short loop also cannot be interrupted, for example if it has disabled its interrupts, or if no interrupts are routed to this processor, this erratum might cause a system livelock. Implications The erratum might create performance issues, or in the worst case it might cause a system livelock if the processor executing the DMB is in an infinite loop that cannot be interrupted. Workaround This erratum can be worked round by setting bit[4] of the undocumented Diagnostic Control Register to 1. This register is encoded as CP15 c15 0 c0 1. This bit can be written in Secure state only, with the following Read/Modify/Write code sequence: MRC p15,0,rt,c15,c0,1 ORR rt,rt,#0x10 MCR p15,0,rt,c15,c0,1 When it is set, this bit causes the DMB instruction to be decoded and executed like a DSB. Using this software workaround is not expected to have any impact on the overall performance of the processor on a typical code base. Other workarounds are also available for this erratum, to either prevent or interrupt the continuous stream of DMB instructions that causes the deadlock. For example: - Inserting a non-conditional Load or Store instruction in the loop between each DMB - Inserting additional instructions in the loop, such as NOPs, to avoid the processor seeing back to back DMB instructions. - Making the processor executing the short loop take regular interrupts." Avi On Tue, Nov 2, 2021 at 9:31 AM Lukas Bulwahn wrote: > > On Fri, Oct 29, 2021 at 8:36 AM Joel Stanley wrote: > > > > On Thu, 28 Oct 2021 at 14:57, Arnd Bergmann wrote: > > > > > > On Thu, Oct 28, 2021 at 4:19 PM Lukas Bulwahn wrote: > > > > > > > > There is no and never was a Kconfig for ARM_ERRATA_794072 in the kernel > > > > tree. So, there is no need to select ARM_ERRATA_794072 in > > > > ./arch/arm/mach-npcm/Kconfig. > > > > > > > > Simply drop selecting the non-existing ARM_ERRATA_794072. > > > > > > > > This issue was discovered with ./scripts/checkkconfigsymbols.py. > > > > > > > > Signed-off-by: Lukas Bulwahn > > > > --- > > > > > > Could this be a typo? Maybe we need to enable a different errata workaround > > > here, or maybe that code is actually needed and has to get sent. > > > > Doing some searching, u-boot had a workaround for something called > > ARM_ERRATA_794072. > > > > https://github.com/u-boot/u-boot/commit/f71cbfe3ca5d2ad20159871700e8e248c8818ba8 > > > > Lore has the review history for that patch: > > > > https://lore.kernel.org/all/6be32e0b5b454ed7b609317266a8e798@BLUPR03MB358.namprd03.prod.outlook.com/ > > > > It looks like it's the same workaround as ARM_ERRATA_742230, which the > > kernel does implement. > > > > It would be good to hear from the Nuvoton people, or an Arm person. > > > > I will happily update the patch to select ARM_ERRATA_742230 instead of > the dead non-existing ARM_ERRATA_794072. > > In contrast to the current patch that basically only cleans up "dead > config" and has no effective functional change, the new patch would > change the behaviour. I cannot test this patch (beyond some basic > compile test) on the hardware; so, we certainly need someone to have > that hardware, knows how to test it or confirm otherwise that we > should select the ARM_ERRATA_742230 fix for this hardware. > > The current patch should be subsumed by the new patch; the submission > of the new patch is deferred until that person shows up. Let's see. > > Lukas -- Regards, Avi 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DC23C433F5 for ; Tue, 2 Nov 2021 08:23:39 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 3F78F61050 for ; Tue, 2 Nov 2021 08:23:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3F78F61050 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tfSqx14kbe6/Q3HwlYa3PntJANGjXJccxn6c6Pa2mzw=; b=mHZ+5wnBPTwYSK WEwrMEUYG17KBpqLMt0KDUejaJ2Axp/X3NZ/2+P+9i/8BNlpnrYAuEtze8LsHY3IxjD8fy2SMinDg zgTAzAqD0Ir+cb9Fk+Mz/GNIcHT7ADsEqTBZDthwf9dBKddZc/1ledRgSogmE+I+Cdom2rbk1BTlS feljDozOwpabpypGrI1Trp4UEv+PufigaZbXpcXyVW9+56i3g0ZWiUfJ+XZNrSfYPgBrxX0Gg+ZTP YGpnk24A87GhroqS6nlKgdWG2riazX4sBIEiwLdfK1GoxfYhXBbEobl4+D727HY0Z6e+D/0zDLNYX QsrSxMmsKoYnfqGJQNKw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mhp3l-000uOq-Bo; Tue, 02 Nov 2021 08:22:21 +0000 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mhp3h-000uNw-7V for linux-arm-kernel@lists.infradead.org; Tue, 02 Nov 2021 08:22:19 +0000 Received: by mail-lf1-x131.google.com with SMTP id i3so11760564lfu.4 for ; Tue, 02 Nov 2021 01:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ne7EPu6jTpGVLHdvimehHVoEG1G7OTA5OiY+BOnLe4A=; b=PjUNJMcSRJ62akTQe/diEaqWuErpiYU8V09h41nU2mp9HKydnky/bk6OV2dQuyewS2 S9RuIpT48CK73n4qcfBiHUYtyhouUpWA0+J54GBgSj7yynd2vT4DW8fv4ahrzlsrT0E6 /lijxNB4x8IwycViFV+jzEaUZm/3pQxtQJf916W/qvzbddRwXkIOIm4OiMVLn/WIZ/DY N5odBUKp0BxW4l3NBxeuLswtCe3PZ5pflo9kkmST1Cs2eJToB0wimMkmOPSuyQTpfxUg oA9KmxcFF04RD5lgmyzKxuHhhF7bgKu7R5M+jFKRFH6KtY1r31FAMN4zM91jGi33Xl0z BFsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ne7EPu6jTpGVLHdvimehHVoEG1G7OTA5OiY+BOnLe4A=; b=P0ClKcwQt5pvaL8KsCVNn8Qhb4efcDQ035iaoYRn56beGifXfWHN1jdWtuDfE1GCbF xJVHtNy47qQzFS5ratnX8cgqH5jy5h3AStpYIMpToAA1RXMB+0fUE3HSgCGrdJRM8jgS 9Vz2rOaFavziwWY4S+BkcQm+ley0u+Ejt++Z3/SIgTXGtvHt8QYRt42NAdfITT/hbTQl BAtDAJBJh99I7xFnLtcgx8yJviVi6f64gnBqtnKJw+ftJ0PY3zb2SGtjbO0AoYEKA6Mm xzxFDtWVm34jfNNpbggeDjPZYi6PQZboC0wmz+If9lpLnZ/hltxeyblVS5JOCME5K+cc aghw== X-Gm-Message-State: AOAM533DDLv9ThwynWssgJrk9l15+4mdCR22dHQ0DWkgv42xa6yNZdJZ wXTLWlSbt8Tk9eCo+27/W2Cu4lv3cGOohXINQw== X-Google-Smtp-Source: ABdhPJz2sTRMCaO5nz6DI/gO9EPlcsOXPYF/+nvlvqLAyf4DhHKZV4nnIz1ld2TtCyuBcBxPgayITk4DR6CTKXKkKxk= X-Received: by 2002:a05:6512:3c9e:: with SMTP id h30mr2097037lfv.93.1635841334320; Tue, 02 Nov 2021 01:22:14 -0700 (PDT) MIME-Version: 1.0 References: <20211028141938.3530-1-lukas.bulwahn@gmail.com> <20211028141938.3530-12-lukas.bulwahn@gmail.com> In-Reply-To: From: Avi Fishman Date: Tue, 2 Nov 2021 10:22:03 +0200 Message-ID: Subject: Re: [PATCH 11/13] arm: npcm: drop selecting non-existing ARM_ERRATA_794072 To: Lukas Bulwahn Cc: Joel Stanley , Arnd Bergmann , Tomer Maimon , Russell King , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Sekhar Nori , Bartosz Golaszewski , Linus Walleij , Imre Kaloz , Krzysztof Halasa , Tali Perry , Patrick Venture , Nancy Yuen , Benjamin Fair , Dinh Nguyen , Linux ARM , OpenBMC Maillist , kernel-janitors , Linux Kernel Mailing List X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211102_012217_359779_FFF6F39A X-CRM114-Status: GOOD ( 41.18 ) X-BeenThere: linux-arm-kernel@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-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, At Nuvoton we implied this WA in the past, not because we encountered a specific problem but since the errata says so and we saw this in other patches like: https://patchwork.kernel.org/project/linux-arm-kernel/patch/1396298072-13254-2-git-send-email-nitin.garg@freescale.com/ But we didn't upstream the arch/arm/mm/proc-v7.S >From the errata document. "794072 A short loop including a DMB instruction might cause a denial of service on another processor which executes a CP15 broadcast operation Status Affects: Fault Type: Fault Status: Cortex-A9 MPCore. Programmer Category B Present in: All r1, r2, r3 and r4 revisions Open Description A processor which continuously executes a short loop containing a DMB instruction might prevent a CP15 operation broadcast by another processor making further progress, causing a denial of service. Configurations affected This erratum affects all Cortex-A9 MPCore processors with two or more processors. Conditions The erratum requires the following conditions: - Two or more processors are working in SMP mode (ACTLR.SMP=1) - One of the processors continuously executes a short loop containing at least one DMB instruction. - Another processor executes a CP15 maintenance operation that is broadcast. This requires that this processor has enabled the broadcasting of CP15 operations (ACTLR.FW=1) For the erratum to occur, the short loop containing the DMB instruction must meet all of the following additional conditions: - No more than 10 instructions other than the DMB are executed between each DMB - No non-conditional Load or Store, or conditional Load or Store which pass the condition code check, are executed between each DMB When all the conditions for the erratum are met, the short loop creates a continuous stream of DMB instructions. This might cause a denial of service, by preventing the processor executing the short loop from executing the received broadcast CP15 operation. As a result, the processor that originally executed the broadcast CP15 operation is stalled until the execution of the loop is interrupted. Note that because the process issuing the CP15 broadcast operation cannot complete operation, it cannot enter any debug-mode, and cannot take any interrupt. If the processor executing the short loop also cannot be interrupted, for example if it has disabled its interrupts, or if no interrupts are routed to this processor, this erratum might cause a system livelock. Implications The erratum might create performance issues, or in the worst case it might cause a system livelock if the processor executing the DMB is in an infinite loop that cannot be interrupted. Workaround This erratum can be worked round by setting bit[4] of the undocumented Diagnostic Control Register to 1. This register is encoded as CP15 c15 0 c0 1. This bit can be written in Secure state only, with the following Read/Modify/Write code sequence: MRC p15,0,rt,c15,c0,1 ORR rt,rt,#0x10 MCR p15,0,rt,c15,c0,1 When it is set, this bit causes the DMB instruction to be decoded and executed like a DSB. Using this software workaround is not expected to have any impact on the overall performance of the processor on a typical code base. Other workarounds are also available for this erratum, to either prevent or interrupt the continuous stream of DMB instructions that causes the deadlock. For example: - Inserting a non-conditional Load or Store instruction in the loop between each DMB - Inserting additional instructions in the loop, such as NOPs, to avoid the processor seeing back to back DMB instructions. - Making the processor executing the short loop take regular interrupts." Avi On Tue, Nov 2, 2021 at 9:31 AM Lukas Bulwahn wrote: > > On Fri, Oct 29, 2021 at 8:36 AM Joel Stanley wrote: > > > > On Thu, 28 Oct 2021 at 14:57, Arnd Bergmann wrote: > > > > > > On Thu, Oct 28, 2021 at 4:19 PM Lukas Bulwahn wrote: > > > > > > > > There is no and never was a Kconfig for ARM_ERRATA_794072 in the kernel > > > > tree. So, there is no need to select ARM_ERRATA_794072 in > > > > ./arch/arm/mach-npcm/Kconfig. > > > > > > > > Simply drop selecting the non-existing ARM_ERRATA_794072. > > > > > > > > This issue was discovered with ./scripts/checkkconfigsymbols.py. > > > > > > > > Signed-off-by: Lukas Bulwahn > > > > --- > > > > > > Could this be a typo? Maybe we need to enable a different errata workaround > > > here, or maybe that code is actually needed and has to get sent. > > > > Doing some searching, u-boot had a workaround for something called > > ARM_ERRATA_794072. > > > > https://github.com/u-boot/u-boot/commit/f71cbfe3ca5d2ad20159871700e8e248c8818ba8 > > > > Lore has the review history for that patch: > > > > https://lore.kernel.org/all/6be32e0b5b454ed7b609317266a8e798@BLUPR03MB358.namprd03.prod.outlook.com/ > > > > It looks like it's the same workaround as ARM_ERRATA_742230, which the > > kernel does implement. > > > > It would be good to hear from the Nuvoton people, or an Arm person. > > > > I will happily update the patch to select ARM_ERRATA_742230 instead of > the dead non-existing ARM_ERRATA_794072. > > In contrast to the current patch that basically only cleans up "dead > config" and has no effective functional change, the new patch would > change the behaviour. I cannot test this patch (beyond some basic > compile test) on the hardware; so, we certainly need someone to have > that hardware, knows how to test it or confirm otherwise that we > should select the ARM_ERRATA_742230 fix for this hardware. > > The current patch should be subsumed by the new patch; the submission > of the new patch is deferred until that person shows up. Let's see. > > Lukas -- Regards, Avi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel