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 34DB8C04A68 for ; Thu, 28 Jul 2022 09:08:33 +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-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2UW/6VNTFize908KpjxKKoLOTzMErXCb80Ub5BXlPSg=; b=d1/mb41Hx5cixcIJS4AGchwOb5 1il8Ancb4lkWeZT6DUNoUqyVheZygWgPakLF3uxGZAAAVtHlh5zrZtCiYFKFmHDSIRJz5YUdzWsxE GZdeL+G5fZnvTeAKGk4ZVyShReLD7xV2hebritz3Lb6QA3XTECUHvkHVdxqsUOKF2ucZo9k28zEu9 9lm8MawZnCjM6zgxgtuPmVS1xq8mbGJWScZmujDpmyX9z0IOlRpbgBZAWSd4T7IaZltt4nq7c1Q6j lTAVHSnlfVstfwtXgqfQFAoD+bu5DS3OPp70w7EW4mVsY/xIVWwVnZ+LdHC7lXn6E40smovX/cP4I RETVspwQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGzU8-0069DC-CO; Thu, 28 Jul 2022 09:07:12 +0000 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGzU3-0068yS-Vw for linux-arm-kernel@lists.infradead.org; Thu, 28 Jul 2022 09:07:10 +0000 Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) (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 smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 0B4E03F12F for ; Thu, 28 Jul 2022 09:07:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1658999220; bh=o//0J/rFHiNnqttRw+SylsLKNgE8xkBj7uOZ2eW9hjI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZCnJWEKfd+8xEbVnwCqtMKEZ+QvXVgxf2JYOLXPoZBUrmT0YoecuQXynl6FS1V2lg obdJZ3iAHxJ+6tzgcvlCRLzwp7XGw86V4G4mV0kv4yyoO/0+GX2/KHcuzRPsqYwUWo 5OT/VeF9jfADlHvdvrpT0wE+kgUyjiudv1UKTPz0JvoFLRCva89c2jv+X6fqUpcwI4 QNIlYdqjBlaq6nX7JiQDjblYPeAKKQSVroaETwBkrPzeJ4ih0PrCttoc6alm53HuSw fQ9IzkCqyfIefLb7v4BuIJYVEyHMqpP/IInTnIw/xTgLSvgYi1F93G0meKC+RMjZw0 uft/CvngGpp2Q== Received: by mail-ej1-f72.google.com with SMTP id sd24-20020a1709076e1800b0072b582293c2so442926ejc.0 for ; Thu, 28 Jul 2022 02:07:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:organization:references:in-reply-to:message-id:subject :cc:to:from:date:x-gm-message-state:from:to:cc; bh=o//0J/rFHiNnqttRw+SylsLKNgE8xkBj7uOZ2eW9hjI=; b=vxOp0bfM33kVgxloFfPxFfi9+qQtYj80UEP34pvghaA6EyWkrlOU4Bt88PP1NxBEuK L43w2WQeUoQAk+UxJGdH1xrtIOA14G/BC1qnaD0LIaU1jGaTBScHxmWco/SwAe4A/rSX dSHMYCKGTzkadk14fxKF/8l1BQGUMgyNutDxLMZG5kmPFejuw+iviAOtv+fiBNeRWPij Hb71xSz/EH4EmsXR5KAEsKct2WtxKDfbCDfMVH6xQFHq9JEGauT90IlHEM8/z0W4rIaV 24OQNkPIGnR2lSU6pMtoQasUDPzcilJtBvFARK2uM6tkV5ncp3gIYtEg97CxxXKuFD+i 5j+A== X-Gm-Message-State: AJIora9VsgtEZP9aZ1+j/3LlalMPEWdGK1OwiCjagmbVu/zj2cO0j+PZ t8Sj8taMyUDzuoND5vUJCRTNRuS91mUqhlbZpRQxIcsne9BOSHmcyLFAYCLBHOgjALKJcf2cnym 5dnl934gVqdRS0hATVDxfMJkYMkz1JBXIhsLSuBzcmnlEDPZtUsJ/ X-Received: by 2002:a17:907:2cca:b0:72b:4188:f95b with SMTP id hg10-20020a1709072cca00b0072b4188f95bmr20876604ejc.153.1658999219246; Thu, 28 Jul 2022 02:06:59 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uXGjRAGeQQE87hxFqJHsLbeWyOTab0clfdZhMxDR+EPfgB/vTnnU26UDwkNtC2bYI2jWW5eg== X-Received: by 2002:a17:907:2cca:b0:72b:4188:f95b with SMTP id hg10-20020a1709072cca00b0072b4188f95bmr20876580ejc.153.1658999218703; Thu, 28 Jul 2022 02:06:58 -0700 (PDT) Received: from gollum ([194.191.244.86]) by smtp.gmail.com with ESMTPSA id j13-20020a170906410d00b0072af0b036f3sm187789ejk.41.2022.07.28.02.06.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Jul 2022 02:06:57 -0700 (PDT) Date: Thu, 28 Jul 2022 11:06:53 +0200 From: Juerg Haefliger To: Florian Fainelli Cc: Nicolas Saenz Julienne , Robin Murphy , stefan.wahren@i2se.com, Catalin Marinas , Robin Murphy , bcm-kernel-feedback-list@broadcom.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org Subject: Re: bcm2711_thermal: Kernel panic - not syncing: Asynchronous SError Interrupt Message-ID: <20220728103513.38e93fa9@gollum> In-Reply-To: References: <20210210114829.2915de78@gollum> <6d9ca41b4ad2225db102da654d38bc61f6c1c111.camel@suse.de> <35e17dc9-c88d-582f-607d-1d90b20868fa@arm.com> <6612b35f-86bb-bb1e-bae8-188366495dbe@gmail.com> <20220727100510.4723ec84@smeagol> Organization: Canonical Ltd X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220728_020708_500946_50EAF8C7 X-CRM114-Status: GOOD ( 39.01 ) 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: multipart/mixed; boundary="===============6841680239842013763==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============6841680239842013763== Content-Type: multipart/signed; boundary="Sig_/gg=cdQaozDLXr0EmOin=E5P"; protocol="application/pgp-signature"; micalg=pgp-sha512 --Sig_/gg=cdQaozDLXr0EmOin=E5P Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 27 Jul 2022 14:51:24 -0700 Florian Fainelli wrote: > On 7/27/22 01:05, Juerg Haefliger wrote: > > On Wed, 10 Feb 2021 14:59:45 -0800 > > Florian Fainelli wrote: > > =20 > >> On 2/10/2021 8:55 AM, Nicolas Saenz Julienne wrote: =20 > >>> Hi Robin, > >>> > >>> On Wed, 2021-02-10 at 16:25 +0000, Robin Murphy wrote: =20 > >>>> On 2021-02-10 13:15, Nicolas Saenz Julienne wrote: =20 > >>>>> [ 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: =20 > >>>>>> 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/registe= rs > >>>>>> > >>>>>> [ 62.857661] SError Interrupt on CPU1, code 0xbf000002 -- SError= =20 > >>>>> > >>>>> So ESR's IDS (bit 24) is set, which means it's an 'Implementation D= efined > >>>>> SError,' hence IIUC the rest of the error code is meaningless to an= yone outside > >>>>> of Broadcom/RPi. =20 > >>>> > >>>> It's imp-def from the architecture's PoV, but the implementation in = this=20 > >>>> case is Cortex-A72, where 0x000002 means an attributable, containabl= e=20 > >>>> Slave Error: > >>>> > >>>> https://developer.arm.com/documentation/100095/0003/system-control/a= arch64-register-descriptions/exception-syndrome-register--el1-and-el3?lang= =3Den > >>>> > >>>> In other words, the thing at the other end of an interconnect=20 > >>>> transaction said "no" :) > >>>> > >>>> (The fact that Cortex-A72 gets too far ahead of itself to take it as= a=20 > >>>> synchronous external abort is a mild annoyance, but hey...) =20 > >>> > >>> Thanks for both your clarifications! Reading arm documentation is a s= kill on > >>> its own. =20 > >> > >> Yes it is. > >> =20 > >>> =20 > >>>>> The regmap is created through the following syscon device: > >>>>> > >>>>> avs_monitor: avs-monitor@7d5d2000 { > >>>>> compatible =3D "brcm,bcm2711-avs-monitor", > >>>>> "syscon", "simple-mfd"; > >>>>> reg =3D <0x7d5d2000 0xf00>; > >>>>> > >>>>> thermal: thermal { > >>>>> compatible =3D "brcm,bcm2711-thermal"; > >>>>> #thermal-sensor-cells =3D <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 p= er Florian's > >>>>> comments[1]: "AVS_RO_REGISTERS_0: 0x7d5d2200 - 0x7d5d22e3." But fro= m what I can > >>>>> tell, at least 0x7d5d22b0 seems to be faulty too. > >>>>> > >>>>> Any ideas/comments? My guess is that those addresses are marked som= ehow as > >>>>> secure, and only for VC4 to access (VC4 is RPi4's co-processor). Ul= timately, > >>>>> the solution is to narrow the register range exposed by avs-monitor= to whatever > >>>>> bcm2711-thermal needs (which is ATM a single 32bit register). =20 > >>>> > >>>> When a peripheral decodes a region of address space, nobody says it = has=20 > >>>> to accept accesses to *every* address in that space; registers may b= e=20 > >>>> sparsely populated, and although some devices might be "nice" and ma= ke=20 > >>>> unused areas behave as RAZ/WI, others may throw slave errors if you = poke=20 > >>>> at the wrong places. As you note, in a TrustZone-aware device some=20 > >>>> registers may only exist in one or other of the Secure/Non-Secure=20 > >>>> address spaces. > >>>> > >>>> Even when there is a defined register at a given address, it still=20 > >>>> doesn't necessarily accept all possible types of access; it wouldn't= be=20 > >>>> particularly friendly, but a device *could* have, say, some register= s=20 > >>>> that support 32-bit accesses and others that only support 16-bit=20 > >>>> accesses, and thus throw slave errors if you do the wrong thing in t= he=20 > >>>> wrong place. > >>>> > >>>> It really all depends on the device itself. =20 > >>> > >>> All in all, assuming there is no special device quirk to apply, the f= eeling I'm > >>> getting is to just let the error be. As you hint, firmware has no bla= me here, > >>> and debugfs is a 'best effort, zero guarantees' interface after all. = =20 > >> > >> 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. =20 > >=20 > >=20 > > Below is a patch that adds a read access table but it seems wrong to in= clude > > 'internal.h' and add the table in the thermal driver. Shouldn't this ha= ppen > > in a higher layer, somehow between syscon and the thermal node? =20 >=20 > What is the purpose of doing doing this though that cannot already be don= e using devmem/devmem2 if the point is explore the address space? The goal is to prevent a kernel crash when doing $ cat /sys/kernel/debug/regmap/dummy-avs-monitor\@fd5d2000/registers ...Juerg --Sig_/gg=cdQaozDLXr0EmOin=E5P Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEhZfU96IuprviLdeLD9OLCQumQrcFAmLiUa0ACgkQD9OLCQum QrfwCw//ZkKuqE9VxttN2czCLKeZ3LGIxVup3J4kF3toAJUygwN6P/k9wBHQnlf1 Pf4I9LJ1rpGe6FjIWLwzGXqo1eiPifd2mM56Fzf4hfdNaRen1TOCkdvmDlDGyb+S 8siFH43Ld/q9FxZpDb8FS+3oZh9OjC1wHZO2CyKQe6E2qsTkltOkdmkYfu5p0KCR 3AIWbPmTPCkYUp5xx/KxwcaIYIvVOsYrPvH305EFYUaQY8Jn/Zi6uWz5hd4YaT5R 8bqI3oHAD8eS4TbC8J0wO8s3u7k7vraW6bk+p0pvEcnlwtJUX4Kvp0Vv/g455FGs pA+X1oijLh5QVzk2/G46wJQKmzv4jS+mB75c5oaU0vDZnELqE2raHWupYJmis3LL NOkc7bE1FqBMQH91WRyPuvKubX+OqKDtCONAE3BwfUmyHuG3hXd3dyRpJI50S6l3 kH3uj5+QQPMHKzmHQUo7a7krcP2UQuI1z8jG0hJWZaOL89Av3S+vlLg7qlvp0qzZ iSnVzlACeaexyK2M+jhm4Sf1K5ZHnrX6YJ7TAH9jZXpyQES3VI7o90SYFgvbn4Ry ZM4fSIGLKhe8c+DtaidstZWRl/Hasn2Uek7BoilymKEAF8YSSMXU9buyg3uhuay5 0PPssXcJheirCTWhVck4u8vH1mZkmJwZ1aQ+lmfTLxQFugLHtUI= =PR7p -----END PGP SIGNATURE----- --Sig_/gg=cdQaozDLXr0EmOin=E5P-- --===============6841680239842013763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============6841680239842013763==--