From patchwork Tue Apr 4 16:02:38 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 96740 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp263272qgd; Tue, 4 Apr 2017 09:03:34 -0700 (PDT) X-Received: by 10.98.155.28 with SMTP id r28mr24016468pfd.212.1491321814919; Tue, 04 Apr 2017 09:03:34 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1si7404096pge.59.2017.04.04.09.03.34; Tue, 04 Apr 2017 09:03:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-efi-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754906AbdDDQDU (ORCPT + 2 others); Tue, 4 Apr 2017 12:03:20 -0400 Received: from mail-wr0-f169.google.com ([209.85.128.169]:33946 "EHLO mail-wr0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754872AbdDDQDS (ORCPT ); Tue, 4 Apr 2017 12:03:18 -0400 Received: by mail-wr0-f169.google.com with SMTP id t20so14490955wra.1 for ; Tue, 04 Apr 2017 09:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=e6M+xugzcovcCd7APfm4cWPF+lU826rBLm5qBqVxvYs=; b=awIRBt8tkm9yYvSXCBDR0RY7UD76RC79k35gd0+wibkQm25QsZYQJrTCMFZGkQxrzQ 0pFyGtFxdEB0i4lCaMZ5OZBa75HoQh0fNnLqYL+vYd+UfDuBJ/1HSqzQ0XVetQPWLXvS nFkxDqd/SOamIUPWA1hAYp2WV1eTVhyECggBs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=e6M+xugzcovcCd7APfm4cWPF+lU826rBLm5qBqVxvYs=; b=PRQqGYPfDh6yUecfMVl5QukLgq0ATbMgCBa/Yh32AtOPrTUlgeZSbI5ft72WxYcMxh cybC0WTqZs5L3lu4xStauz83Gcdy/uNjJwpXMA6X1ID2y78Rx+A5VlxVkQNy3LxiwcPL Crq+1KVaQt9mlY5ifF0KZXMCx8azSRXU7DtrgjRUGVBkAT2Tx6qBWHwJFvxHPY+VwgDY x6an12dQHnO6D8bKoAYN/ZNHvO1Rm+zuR0xAnJ7K5c0X1Ts/gYxt5yWkAyoUiHJHiZyM ot4O5WYj9FSUfNfsNNhEgIuvrYW3sE+eoLrEOpm9mj49Xee2hojZEgLTOIirt8PIvyMY CdPQ== X-Gm-Message-State: AFeK/H3MnXDbxlkTRPfMN+FJposU6UNN55ENRwBe+vQQczT4xhlw5HaTfNksnX0tASsVTex9 X-Received: by 10.223.165.8 with SMTP id i8mr19926560wrb.66.1491321796651; Tue, 04 Apr 2017 09:03:16 -0700 (PDT) Received: from localhost.localdomain ([160.163.145.113]) by smtp.gmail.com with ESMTPSA id z88sm19686465wrb.1.2017.04.04.09.03.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 09:03:15 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, Ingo Molnar , Thomas Gleixner , "H . Peter Anvin" Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org Subject: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Date: Tue, 4 Apr 2017 17:02:38 +0100 Message-Id: <20170404160245.27812-5-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170404160245.27812-1-ard.biesheuvel@linaro.org> References: <20170404160245.27812-1-ard.biesheuvel@linaro.org> Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On UEFI systems, the PCI subsystem is enumerated by the firmware, and if a graphical framebuffer is exposed by a PCI device, its base address and size are exposed to the OS via the Graphics Output Protocol (GOP). On arm64 PCI systems, the entire PCI hierarchy is reconfigured from scratch at boot. This may result in the GOP framebuffer address to become stale, if the BAR covering the framebuffer is modified. This will cause the framebuffer to become unresponsive, and may in some cases result in unpredictable behavior if the range is reassigned to another device. So add a non-x86 quirk to the EFI fb driver to find the BAR associated with the GOP base address, and claim the BAR resource so that the PCI core will not move it. Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...") Cc: # v4.7+ Cc: Matt Fleming Cc: Peter Jones Signed-off-by: Ard Biesheuvel --- drivers/video/fbdev/efifb.c | 66 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 65 insertions(+), 1 deletion(-) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index 8c4dc1e1f94f..758960b6aec9 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include