Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp773971ybt; Fri, 19 Jun 2020 13:25:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnUXALv59oidVDp5spoWKpZKYmQl64KOpbKkqgWhjGKDlIPucyikIZTDInuM27tubTFZJn X-Received: by 2002:aa7:d28d:: with SMTP id w13mr5169696edq.336.1592598323138; Fri, 19 Jun 2020 13:25:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592598323; cv=none; d=google.com; s=arc-20160816; b=Mz8r2+SO6b9Bnl4eEto9I8S69L7zwRRu6hTSUQCwY7pxbbjrTD63cs2/zOUqK2ixJf esIWjLXj3rdhePAIVCTgV8YtZkqfJymqJIyfOKDZXol+qrqhRpWTBaB9pcjLKtaepI2q UTMHJ112vbsNg5FlDGbK1ivtVBQgolj/E22QiB+QQUAAaEnS/rFHVn6TdRGOqpyprBzT s1z2IB6MuEyc0ShJZ09PdmG93xvX9c6w8IPjqUQAPkuZET9oj15pu8cbBXEm7auWq64D slWIRTkPCSBANPF980MtQKqakHRZGseUChsxQeB3hX1/5gsEdjPj98diWp5z35tzhcjA d0jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=MQinzbXSg7hKh2so812ukamFHDm+d1PCDVdmHulCvNY=; b=R18OemEARAQT0u6B6Iwl6Iyjn3xfgXY4pGkFg3gMO77gzp0oj8YI5TFScBhStrZuS8 XBGcciXOskBqM1XiTjBIuyKVJLmF882y98bDt5f1UZn3eFhkc5cF2ITrmYwnwKL8LdER IU1PwiEqyKzX3/uqaIcnoMegTXe6seC1YwJSw3CMgRmBA4qAYvhU6++7MLiCdwnz9lX8 /ZiU9aOu6WASU6wLc1NLUxQuzAuqSB4bsuAVCG2M+129Gds/R4Zwla2o2Ha12Y0YNt0K kr07PnNbpVmObqRbQYqi1LVvLJPD+8wzqcXbVRED0h1WPlYiQMrr91G+dGZVPIGHKU81 +UKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UM05FerQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dr2si5300038ejc.18.2020.06.19.13.25.01; Fri, 19 Jun 2020 13:25:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UM05FerQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388502AbgFSOwz (ORCPT + 99 others); Fri, 19 Jun 2020 10:52:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:46660 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389594AbgFSOwe (ORCPT ); Fri, 19 Jun 2020 10:52:34 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 20971217D8; Fri, 19 Jun 2020 14:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592578353; bh=7JtHJ0E/i7JKdT8A4ooJDTBHYUeVrUdH4UtPO+zE0/g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UM05FerQupYvdgoAKCNd3I8haeyjXjo7GjFGLm7kql7I7Hy9XVIj0+Pn8+qXre7bi oFmTTuO2rHA7EstRBTsKFJv7OQiQfIenUHEc02Ua+Ym+TW4oTn+F2MDhLmzypdxpHT 1pq3ykChNjmYfxorxmbQvVRnzfLYqh0sF7G9KvnQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Ellerman Subject: [PATCH 4.14 180/190] powerpc/64s: Dont let DT CPU features set FSCR_DSCR Date: Fri, 19 Jun 2020 16:33:45 +0200 Message-Id: <20200619141642.797975745@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200619141633.446429600@linuxfoundation.org> References: <20200619141633.446429600@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michael Ellerman commit 993e3d96fd08c3ebf7566e43be9b8cd622063e6d upstream. The device tree CPU features binding includes FSCR bit numbers which Linux is instructed to set by firmware. Whether that's a good idea or not, in the case of the DSCR the Linux implementation has a hard requirement that the FSCR_DSCR bit not be set by default. We use it to track when a process reads/writes to DSCR, so it must be clear to begin with. So if firmware tells us to set FSCR_DSCR we must ignore it. Currently this does not cause a bug in our DSCR handling because the value of FSCR that the device tree CPU features code establishes is only used by swapper. All other tasks use the value hard coded in init_task.thread.fscr. However we'd like to fix that in a future commit, at which point this will become necessary. Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200527145843.2761782-2-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/kernel/dt_cpu_ftrs.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/arch/powerpc/kernel/dt_cpu_ftrs.c +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c @@ -385,6 +385,14 @@ static int __init feat_enable_dscr(struc { u64 lpcr; + /* + * Linux relies on FSCR[DSCR] being clear, so that we can take the + * facility unavailable interrupt and track the task's usage of DSCR. + * See facility_unavailable_exception(). + * Clear the bit here so that feat_enable() doesn't set it. + */ + f->fscr_bit_nr = -1; + feat_enable(f); lpcr = mfspr(SPRN_LPCR);