From patchwork Tue Mar 21 19:16:50 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 95672 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp1595951qgd; Tue, 21 Mar 2017 12:19:35 -0700 (PDT) X-Received: by 10.99.39.194 with SMTP id n185mr38971878pgn.24.1490123975125; Tue, 21 Mar 2017 12:19:35 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a21si22278898pgg.148.2017.03.21.12.19.35; Tue, 21 Mar 2017 12:19:35 -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 S1757095AbdCUTRQ (ORCPT + 2 others); Tue, 21 Mar 2017 15:17:16 -0400 Received: from mail-wr0-f182.google.com ([209.85.128.182]:34752 "EHLO mail-wr0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757160AbdCUTQ6 (ORCPT ); Tue, 21 Mar 2017 15:16:58 -0400 Received: by mail-wr0-f182.google.com with SMTP id l37so118211269wrc.1 for ; Tue, 21 Mar 2017 12:16:57 -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; bh=nEPkurv0NyPvqnkMeMhcrNy8s7tltNatgxF3JSgerE8=; b=JwlofGHCrOxRgKWeUhQvNFkfA6rtAKRtCk+gwOHkfMfIJ1x+Y91Cw4Up4OcdrExdAk kGCR2ITvyn85zbrKomPtAggGJ2sUIIboalko0fu2SsB8zbVrPITT0YrYbZiadPpnNyFM BY5he7M22L6mzHE/xjnE/sIqr3OzeeGRobRCY= 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; bh=nEPkurv0NyPvqnkMeMhcrNy8s7tltNatgxF3JSgerE8=; b=E7h3YeeCslfpW2CeAF9UvxVULpiPvIOkenDBZIgiNZtX6SKD5y4CZ7HBkFHkFeX3oq GwcC81Yzp8osW8XXnvZimAJKPlf1Nc/YrevNO9SPf9WB0bfQzRrFu17+dWrDdQaKw6Vs zYOzpJ59oMFTcv5g0TjpUeAx6O16K3E6lqCiAbJ1CTZ+njaLHzRXwsGdAVWaT39Zc6az PWPWDOWfC7taGJm5Npw7Tfg+v6IixCru9Aef7PKLXpEmagM7zj3zjzWUfZBGDu/yDIWR 4gt4DWwDDXHDZ9SI9nGoh3nP6Zl3k3iQAXNbNyR0YN10ygNYnd6FmtUnBNcFvy1+bAgh vF0w== X-Gm-Message-State: AFeK/H1rBm5XkQo7Bg+NmMMx4zqq6V99FnVeL16wgB/6XNZMnVjZW5+0xB3SqZOJsmbXoIaJ X-Received: by 10.223.131.3 with SMTP id 3mr32821306wrd.153.1490123816274; Tue, 21 Mar 2017 12:16:56 -0700 (PDT) Received: from localhost.localdomain ([105.144.191.163]) by smtp.gmail.com with ESMTPSA id j24sm20662938wrd.36.2017.03.21.12.16.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Mar 2017 12:16:55 -0700 (PDT) From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org, linux-efi@vger.kernel.org Cc: matt@codeblueprint.co.uk, pjones@redhat.com, lorenzo.pieralisi@arm.com, bhelgaas@google.com, hanjun.guo@linaro.org, heyi.guo@linaro.org, linux-pci@vger.kernel.org, Ard Biesheuvel Subject: [PATCH v2] efifb: avoid reconfiguration of BAR that covers the framebuffer Date: Tue, 21 Mar 2017 19:16:50 +0000 Message-Id: <1490123810-12383-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 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 quirk to the EFI fb driver to find the BAR associated with the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so that the PCI core will leave it alone. Signed-off-by: Ard Biesheuvel --- As it turns out, setting the IORESOURCE_PCI_FIXED flag is not sufficient to make the PCI core leave the BARs alone, so instead, the BAR resource is claimed in the quirk handler. As suggested by Lorenzo, a check is added that the device has memory decoding enabled, and if it doesn't, no attempt is made to use the EFI framebuffer. drivers/video/fbdev/efifb.c | 58 +++++++++++++++++++- 1 file changed, 57 insertions(+), 1 deletion(-) -- 2.7.4 -- 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..eeeaf78c4a5b 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include