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 633E1C77B73 for ; Thu, 20 Apr 2023 17:03:39 +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: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=O4I9EGTQv6XJUkhCQKQlQUo3CcGyg8sj03Da6EHKpBY=; b=gGnOj2x2kp3rhk kY1SmHatwUZQu6iQ4nc/P34Oix4UHwtju6V6F7sjTe8lZXKfHzHpegKoqPPx/gy7QXWBzfbgpf03q 3FZu72qBN91D9+/s+TS5vcfH6YOWHHZVIqPXB/JAIkrW0Hy/NGW0AclT08fplZ4q7dll4unWMp5eH AZQ15bsoABy6UUMaF2Tuk0P46qHQpXod6Tv70LGPq8M0crIptsC9vAFIDiLAh/D/xBXZqgITCjD2n tr+rLAUhsmQPi80inPLHMT9J3a54XfXwVvimjTpJzJPBy2iU++tBoo7fUeAq1PgzPSZ+MpkbgJX7A d0xylTaju8K/USzR3Ngg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ppXg4-008b0t-01; Thu, 20 Apr 2023 17:02:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ppXg0-008b0R-11 for linux-arm-kernel@lists.infradead.org; Thu, 20 Apr 2023 17:02:34 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2853C1480; Thu, 20 Apr 2023 10:03:11 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3A6143F6C4; Thu, 20 Apr 2023 10:02:26 -0700 (PDT) Message-ID: Date: Thu, 20 Apr 2023 18:02:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] arm64: errata: Add NXP iMX8QM workaround for A53 Cache coherency issue Content-Language: en-GB To: "Ivan T. Ivanov" , Mark Rutland Cc: Catalin Marinas , Will Deacon , Mark Brown , Shawn Guo , Dong Aisheng , linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com References: <20230412125506.21634-1-iivanov@suse.de> <8890bcc1-b881-e418-40a5-1b5d6cc8757e@arm.com> From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230420_100232_422900_D043354B X-CRM114-Status: GOOD ( 16.08 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 18/04/2023 5:54 pm, Ivan T. Ivanov wrote: > On 04-17 16:35, Mark Rutland wrote: > >>>>> @@ -835,7 +835,8 @@ static inline bool system_supports_bti(void) >>>>> static inline bool system_supports_tlb_range(void) >>>>> { >>>>> return IS_ENABLED(CONFIG_ARM64_TLB_RANGE) && >>>>> - cpus_have_const_cap(ARM64_HAS_TLB_RANGE); >>>>> + cpus_have_const_cap(ARM64_HAS_TLB_RANGE) && >>>>> + !cpus_have_const_cap(ARM64_WORKAROUND_NXP_ERR050104); >>>>> } >>>> >>>> It'd be better to handle this in the detection of ARM64_HAS_TLB_RANGE, as we >>>> have for CNP where has_useable_cnp() checks for ARM64_WORKAROUND_NVIDIA_CARMEL_CNP. >>> >>> It's not needed in either place, since neither Cortex-A53 or Cortex-A72 >>> support FEAT_TLBIRANGE, so this could never be true on affected platforms >>> anyway. >> >> Ah, even better -- we can just drop it. > > Ok. > >> >>> Tangentially, I understand this platform has an SMMU[1], so I'd say it would >>> also be worth checking what SMMU_IDR0.BTM reports. With any luck it might be >>> 0, but if it's 1 then strictly it would want to be overridden as part of a >>> complete workaround as well. That wouldn't be a practical issue right now, >>> not least since the current Linux driver doesn't even use BTM, but it's >>> something which could need to be borne in mind in future. >> >> Absolutely. > > I don't completely understand implication of this, but for SMMU inside > iMX8QM report that "Broadcast TLB maintenance is supported" Aha, in fact it seems we might be OK. I double-checked and it turns out that thanks to an MMU-500 erratum, we can't necessarily believe IDR0.BTM anyway. Thus anyone who adds DVM support to an SMMUv2 driver is going to need to implement some new firmware property or platform detection, at which point the chances of it getting silently enabled for i.MX8 (if indeed BTM isn't already a lie there) seem sufficiently remote that I'd feel fairly comfortable not doing anything explicit for now. (The case of concern wouldn't be so much the expected use of DVM to share CPU pagetables with the SMMU, which in principle the regular CPU workaround should already cover, but more anyone trying to play clever tricks using DVM and CPU instructions to maintain private SMMU contexts rather than register-based commands.) Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel