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: 9637411 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 694A86020B for ; Tue, 21 Mar 2017 19:19:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5813B27165 for ; Tue, 21 Mar 2017 19:19:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4B6B42840E; Tue, 21 Mar 2017 19:19:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C7C8D27165 for ; Tue, 21 Mar 2017 19:19:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757663AbdCUTRQ (ORCPT ); Tue, 21 Mar 2017 15:17:16 -0400 Received: from mail-wr0-f171.google.com ([209.85.128.171]:34754 "EHLO mail-wr0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757668AbdCUTQ6 (ORCPT ); Tue, 21 Mar 2017 15:16:58 -0400 Received: by mail-wr0-f171.google.com with SMTP id l37so118211324wrc.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=oxfgYRrLXFt5z+/Hvau9w7D9awFQflu2G0VjC5vb5cbr4uxyfE5gSeLdz9Moh6Pq15 uFbBdHz0qMg5Chniu0OjN2cDj5GWPrJgE3FXukwCngIT4lUPpylWefiKsNM7r9oFh4rx wkPtVB+adH5NhKNBNjcF0vIp0FmephpBopXI/Xlha50NgBggQb02wUX9ZSP2tHjDrZgl D4uS0AR78MnQi0emavsBJuezVkMGrEDlPRY9RwYQI0eMwNUz3ULSsTJaLjfGQMHlzusY eWiPaJSqacIhNm0mgf7TWdQtN4q49J6nKJIUNEhLYG/6Oh1mCwNDXTa5+IAs0+gVQg74 dsVQ== X-Gm-Message-State: AFeK/H2RcaVlDn9McqrB1jdqP3zzWeOY9zWDLYtO7IW1t6ft3qizSeyIwScNgknLm0osP6xG 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-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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(-) 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