Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1857408ybl; Sat, 25 Jan 2020 10:13:23 -0800 (PST) X-Google-Smtp-Source: APXvYqy0K4RyM96HwBLk0NrodyukTsZwCdanIK/7bWFQVzlcIc1n+/bcilbXI9bl+7i0xnSNpdD/ X-Received: by 2002:a05:6830:1353:: with SMTP id r19mr7252146otq.288.1579976002871; Sat, 25 Jan 2020 10:13:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579976002; cv=none; d=google.com; s=arc-20160816; b=etmhoZ6OlJcyNrSwaRohe3i6wBTwxtuekCgkeFUo0AmrqB6Oy4NSs8Rku8rOtNmFFv TlnwSkzWlLoOkHX2zSoMMVB/t32XCeRhjCTqHpYl67kCZkV9RvybbHkz2x7xOfxLxO3G khyTiwDkCMhsKz3jnFHVbybs9zKWkZzl1Uiw7P8DCrFplTYpGZUjDTcsoJzuScEYrNX1 d2Xq5zpvGViVZDA6UGlNz452h/K4My5kFXadBlIsar6dhPHKq++8KCnaFFzNf1AvHD4Q yxjfYHEGnQUsTOhufkkE/Mj8InaRFqZJlelE4yf+rs0uVb38YYMkIOPvqAwxiirJzwyP OG4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=eF2OUCFn8RXfuPcwbgeBQlCI+YW26selKCHUMVhWZwI=; b=Zb37LlMX2MBgLsSUIpjU0XPMkjByCfJscYAmuvnBKYUtl5WAGOHLeC9Is7E5VZe/C5 O5YrYt7Mv7sn7fa9qiRAZy6g5JmvHybofP45oGts8pLpu7dZgbcxC34SufGFkgYSgq00 /0l+U4S2iVRjvNab+SQp70e9m1iI5rxtDp93UYlm3YB9jvSeDqhQl8jOlqBffj5IygWl X2LkX1NmDfDa+KIFFlfUxgwxqv5RIbW+5t0rLjsFyKxxQuZD/DVegxEgFZHR1balLIJZ ibiFoY07R7ItLFyoNdkDurj8/4YsKbqhbovETJaPzlZydhNw2F0jmsRvLj/6WFvelqd5 qnGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jnhVI0AC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i6si5225337otj.24.2020.01.25.10.13.10; Sat, 25 Jan 2020 10:13:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jnhVI0AC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726780AbgAYSMP (ORCPT + 99 others); Sat, 25 Jan 2020 13:12:15 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:39746 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726194AbgAYSMP (ORCPT ); Sat, 25 Jan 2020 13:12:15 -0500 Received: by mail-wm1-f65.google.com with SMTP id c84so2670751wme.4 for ; Sat, 25 Jan 2020 10:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eF2OUCFn8RXfuPcwbgeBQlCI+YW26selKCHUMVhWZwI=; b=jnhVI0AC7nJ/o836vPGnFVXVOi7ROc8LnQ7lOYUAGtggE1kk/SF7n82HCKQnPvgsfV 2ejWwuN5Uz+LfQPWJO2WC/07k1q/YZx9vAACJF4eYwzyQHr+oKlMZ0tc3pq4iImmdx1z 3WNyE+KFv/fnwcETR/GQWpffXu+3VLUaHVPdOdXtrSKI0k7zIu+wnaigwdHshFWJLKWv 0Xo1Hsn3qJxDV9TZP8WzAeedM8ddFdW58WbZAoCSF0ergdhMItd5ZaIb5OipyKS7gG0n v/tsa+eKEu8IGdHVqByD3xEeoP+H/M+5LXdmkFBzHBEj3SCvrS2hsOUdYWW80UlYXSyd NtiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eF2OUCFn8RXfuPcwbgeBQlCI+YW26selKCHUMVhWZwI=; b=ccEV8pt7Qx4l1x10z8/mgNIKrbvdcBdb7hN96K2K1NCLz2vlIvKG1Jm6SYDV0ihnrx JFRdjBeKHZyU/B3GGFLwOZanGtHgdzl5b85GBuD0BakbGgVxMIuZ9yzMwcKblhnrkA6/ tmQif3gnKVWEW8vhucLYC6jv2U+IE0P6JnvvumpBLqeTyTkwziBGpvFPEhSqhuTHYbY2 0bu8ddNRaGOy7QKX+ddISPci98/Oqyz1DDeSUhpT3NDEqlAFL51GQfeR3s9V1PpFbDdI K3dZ2m3KVV4xkCphi+HlRevChJnI+inhuaU3cs/IXtsDzRulKMZ7sciVYcp8HHJ0NKSc LSmQ== X-Gm-Message-State: APjAAAUeR0l6ORe01w3iW1ckWmtJcwn8os8SjOMdL5CotN0cpMeO01D3 X9mrwD5Ip2gNgBUwbPgMdfRLuAi+9YaRIwjffGjC2A== X-Received: by 2002:a05:600c:248:: with SMTP id 8mr5114444wmj.1.1579975934034; Sat, 25 Jan 2020 10:12:14 -0800 (PST) MIME-Version: 1.0 References: <20200125173950.GA19126@roeck-us.net> <20200125180613.GR25745@shell.armlinux.org.uk> In-Reply-To: <20200125180613.GR25745@shell.armlinux.org.uk> From: Ard Biesheuvel Date: Sat, 25 Jan 2020 19:12:02 +0100 Message-ID: Subject: Re: [PATCH] ARM: 8936/1: decompressor: avoid CP15 barrier instructions in v7 cache setup code To: Russell King - ARM Linux admin Cc: Guenter Roeck , linux-arm-kernel , Linux Kernel Mailing List , Marc Zyngier Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 25 Jan 2020 at 19:06, Russell King - ARM Linux admin wrote: > > On Sat, Jan 25, 2020 at 09:39:50AM -0800, Guenter Roeck wrote: > > Hi, > > > > On Fri, Nov 08, 2019 at 01:44:32PM +0100, Ard Biesheuvel wrote: > > > Commit e17b1af96b2afc38e684aa2f1033387e2ed10029 > > > > > > "ARM: 8857/1: efi: enable CP15 DMB instructions before cleaning the cache" > > > > > > added some explicit handling of the CP15BEN bit in the SCTLR system > > > register, to ensure that CP15 barrier instructions are enabled, even > > > if we enter the decompressor via the EFI stub. > > > > > > However, as it turns out, there are other ways in which we may end up > > > using CP15 barrier instructions without them being enabled. I.e., when > > > the decompressor startup code skips the cache_on() initially, we end > > > up calling cache_clean_flush() with the caches and MMU off, in which > > > case the CP15BEN bit in SCTLR may not be programmed either. And in > > > fact, cache_on() itself issues CP15 barrier instructions before actually > > > enabling them by programming the new SCTLR value (and issuing an ISB) > > > > > > Since all these routines are specific to v7, let's clean this up by > > > using the ordinary v7 barrier instructions in the v7 specific cache > > > handling routines, so that we never rely on the CP15 ones. This also > > > avoids the issue where a barrier is required between programming SCTLR > > > and using the CP15 barrier instructions, which would result in two > > > different kinds of barriers being used in the same function. > > > > > > Acked-by: Marc Zyngier > > > Signed-off-by: Ard Biesheuvel > > > Signed-off-by: Russell King > > > > This patch causes all qemu emulations for ARM1176 to fail hard (stall with > > no console output even with earlycon enabled). This affects witherspoon-bmc, > > ast2500-evb, romulus-bmc, and swift-bmc. It does not affect emulations > > for other CPU types, even with the same kernel configuration (such as > > ast2600-evb). > > Hmm, looks like we're going to have to drop 8936/1, 8941/1 and 8942/1 > in that case. > 8941 was intended as an alternative approach to 8936, as the latter is flawed, given that the v7 cache maintenance routines are shared with CPUID capable non-v7 CPUs such as the ARM1176. So it was never the intention for both to be applied. It should be sufficient to revert 8936. Apologies for the confusion.