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 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E42FC433DB for ; Wed, 10 Feb 2021 23:01:06 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 F32FD64EBB for ; Wed, 10 Feb 2021 23:01:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F32FD64EBB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=sIz+4xGquzA3H6w/5L20ksW+f9TxBoDPjatQ4USGoq8=; b=YR8yIZPsL6NhgtkjJjU537KBn nIjbyUVSQiHgfR8Ovxmq9evDqCJETsBxFUMH5gWjShc2Q9elvjozxKidh74Fpt4PZBqt9rdLpxfcd vpBMn8YKvRpVYc0EepvYJaj32lyRgLHlg39iP5JKvM9s/SIEaapUrYbOzOP7hJTg7ukLJrlgA9g2X 8vcwS3Ct0Xn/o3iEY/N4i2MTfrby8fPu/pTLxLgrpqIIj8hlClsBWOAa1pf/zoZgT0IEIbr3uooC1 /3tMkuekdxtaeUfIzn1wWc2k1QD4SNOsFiOuwUYiPUjsSx0axCK4JzETdKew2hIe3nFFo/VcXwUbq 8gsltL3Rg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9ySk-00022x-4C; Wed, 10 Feb 2021 22:59:58 +0000 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9ySh-00022H-7v for linux-arm-kernel@lists.infradead.org; Wed, 10 Feb 2021 22:59:56 +0000 Received: by mail-pg1-x531.google.com with SMTP id t26so2249580pgv.3 for ; Wed, 10 Feb 2021 14:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KT1/+q26UpMTGY5hez+ykySBsh/GlZRPF35yJMtlWVA=; b=R2zvjlRWz47+CI6PwBa5mA9+zEsWKdASVNkzwaFRkBS0MshqfBzI/RuZHgtGGL20+K /8Q2orswd8eEHES2Ygt5FWwhnV7pBR7ZckC77wOC3hI+hUgs8AQUVtK7yRdCiqw4p8Pm M84+FlLhtZqfrS5nn5qPg/qj54CMzqe7+ULm5rcc2Mrkx0dkNiK5BcyybXy+Ul6g/1lm RdML9KVwjl5B8ZGg1lHCOpe79jvNir/j8ZgKz7FnQeiuvDj1TvelBdPa9MCzqV0j7dhN 98Whn3vOygAhHm7uNVBgsgczjPK2h1YJStQzuw2B1y6VTZLU9p6qblm5wLFoKRV0IZ5S /cOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KT1/+q26UpMTGY5hez+ykySBsh/GlZRPF35yJMtlWVA=; b=h8fp2zm2D2syUdIeknRuJAnfy+57bkBkE+PQzLZTaIG36pVazpJO+IK8iPdTqPn3d5 dvaZn98iyp/aiBUgab5DRGL9bAs0+zU4kDSm5MaXC2BwRW0sW8KaX2sxUDe/yN5ivbFW Mr+rb891iRLL+RTzTuYqb2ARFP52T0o90V2xcz1tFLmOxXfEUXKo0a6LSZk0VUorvrvs pEqyksxyWtBkBJ+WCZYJI3YtOPb1iMRy/Gc+/2r+GlS9RLrRVrCtVJa5ojO+nYafyJFQ yX0W4ZjZEL/pI13/j6l33BFWU4wU3+oZACOPMQ/UPjFRmDruKn4VP8k7MN8aEqb1sff4 zpWw== X-Gm-Message-State: AOAM531XjqeITHy0iSeHgldNgzykoaJsh+eIfLQUyspC+bBbY+BAxjqq Y6NZChlQlfLQCS4wkl6P7vbyjwpg3es= X-Google-Smtp-Source: ABdhPJxaG/M0B4A/sBmPVP7xbuAxvBMYhH7GqnHxNk2UDcS4vU4spH22S2zKwEwDv1cIe/xBd/+vtw== X-Received: by 2002:a63:eb05:: with SMTP id t5mr5086534pgh.389.1612997992978; Wed, 10 Feb 2021 14:59:52 -0800 (PST) Received: from [10.230.29.30] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id y67sm3395360pfb.71.2021.02.10.14.59.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Feb 2021 14:59:52 -0800 (PST) Subject: Re: bcm2711_thermal: Kernel panic - not syncing: Asynchronous SError Interrupt To: Nicolas Saenz Julienne , Robin Murphy , Juerg Haefliger , stefan.wahren@i2se.com, Florian Fainelli , Catalin Marinas , Robin Murphy References: <20210210114829.2915de78@gollum> <6d9ca41b4ad2225db102da654d38bc61f6c1c111.camel@suse.de> <35e17dc9-c88d-582f-607d-1d90b20868fa@arm.com> From: Florian Fainelli Message-ID: <6612b35f-86bb-bb1e-bae8-188366495dbe@gmail.com> Date: Wed, 10 Feb 2021 14:59:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210210_175955_371930_827C5712 X-CRM114-Status: GOOD ( 24.04 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bcm-kernel-feedback-list@broadcom.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org 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 On 2/10/2021 8:55 AM, Nicolas Saenz Julienne wrote: > Hi Robin, > > On Wed, 2021-02-10 at 16:25 +0000, Robin Murphy wrote: >> On 2021-02-10 13:15, Nicolas Saenz Julienne wrote: >>> [ Add Robin, Catalin and Florian in case they want to chime in ] >>> >>> Hi Juerg, thanks for the report! >>> >>> On Wed, 2021-02-10 at 11:48 +0100, Juerg Haefliger wrote: >>>> Trying to dump the BCM2711 registers kills the kernel: >>>> >>>> # cat /sys/kernel/debug/regmap/dummy-avs-monitor\@fd5d2000/range >>>> 0-efc >>>> # cat /sys/kernel/debug/regmap/dummy-avs-monitor\@fd5d2000/registers >>>> >>>> [ 62.857661] SError Interrupt on CPU1, code 0xbf000002 -- SError >>> >>> So ESR's IDS (bit 24) is set, which means it's an 'Implementation Defined >>> SError,' hence IIUC the rest of the error code is meaningless to anyone outside >>> of Broadcom/RPi. >> >> It's imp-def from the architecture's PoV, but the implementation in this >> case is Cortex-A72, where 0x000002 means an attributable, containable >> Slave Error: >> >> https://developer.arm.com/documentation/100095/0003/system-control/aarch64-register-descriptions/exception-syndrome-register--el1-and-el3?lang=en >> >> In other words, the thing at the other end of an interconnect >> transaction said "no" :) >> >> (The fact that Cortex-A72 gets too far ahead of itself to take it as a >> synchronous external abort is a mild annoyance, but hey...) > > Thanks for both your clarifications! Reading arm documentation is a skill on > its own. Yes it is. > >>> The regmap is created through the following syscon device: >>> >>> avs_monitor: avs-monitor@7d5d2000 { >>> compatible = "brcm,bcm2711-avs-monitor", >>> "syscon", "simple-mfd"; >>> reg = <0x7d5d2000 0xf00>; >>> >>> thermal: thermal { >>> compatible = "brcm,bcm2711-thermal"; >>> #thermal-sensor-cells = <0>; >>> }; >>> }; >>> >>> I've done some tests with devmem, and the whole <0x7d5d2000 0xf00> range is >>> full of addresses that trigger this same error. Also note that as per Florian's >>> comments[1]: "AVS_RO_REGISTERS_0: 0x7d5d2200 - 0x7d5d22e3." But from what I can >>> tell, at least 0x7d5d22b0 seems to be faulty too. >>> >>> Any ideas/comments? My guess is that those addresses are marked somehow as >>> secure, and only for VC4 to access (VC4 is RPi4's co-processor). Ultimately, >>> the solution is to narrow the register range exposed by avs-monitor to whatever >>> bcm2711-thermal needs (which is ATM a single 32bit register). >> >> When a peripheral decodes a region of address space, nobody says it has >> to accept accesses to *every* address in that space; registers may be >> sparsely populated, and although some devices might be "nice" and make >> unused areas behave as RAZ/WI, others may throw slave errors if you poke >> at the wrong places. As you note, in a TrustZone-aware device some >> registers may only exist in one or other of the Secure/Non-Secure >> address spaces. >> >> Even when there is a defined register at a given address, it still >> doesn't necessarily accept all possible types of access; it wouldn't be >> particularly friendly, but a device *could* have, say, some registers >> that support 32-bit accesses and others that only support 16-bit >> accesses, and thus throw slave errors if you do the wrong thing in the >> wrong place. >> >> It really all depends on the device itself. > > All in all, assuming there is no special device quirk to apply, the feeling I'm > getting is to just let the error be. As you hint, firmware has no blame here, > and debugfs is a 'best effort, zero guarantees' interface after all. We should probably fill a regmap_access_table to deny reading registers for which there is no address decoding and possibly another one to deny writing to the read-only registers. -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel