From patchwork Mon Jul 10 21:13:05 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 107330 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp3952586qge; Mon, 10 Jul 2017 14:13:26 -0700 (PDT) X-Received: by 10.99.127.23 with SMTP id a23mr16637710pgd.47.1499721206627; Mon, 10 Jul 2017 14:13:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499721206; cv=none; d=google.com; s=arc-20160816; b=tQeSgsom6nh2snZ+hsbx4XrDppdX3+mMxGXjxBP/PeBvS2znLObRJzHAgsS8EppUl1 LizYVd3Xja0R7VudnHGFeeWE5Bp9B3EIZbtrATdJQZtFTr0wd27V/1cidm4Ml/XN2tED fyc5UhMyjtTNHaEprTUGpYoYWvJfMRbfprNMk/NqrZZFqqeigaQbzQcaMICGpJvsp8dP 48jblCEJDhzVCxiZk7+xm+Ue47X18rD9+8ZHuFRsYMCeVcL/9GrYaUrifGKzzx2ZopS0 CXdOoNRr4EQmBJLtnu8nJ2YyHUNyQnwgq/vrl9WUBcY2PFGBfRtEVBxLk8oZiwqk6aqe bnIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=IvVCGyK+ze7uWyuY8NPW7x2ioOJOXfZHwFLq8VyYEqI=; b=VYi0U4EX2bBniTT2mGm+ev4Ms3J9ApyH9TgAhroeP7obmTqRMdon/XKXXVaEIm5Yfn njQFCbXRQUW9cSd6mihQd6K86K6SZ2jjLhklGr++WaByII3qnU1nuFYfrwtUu8kl2Jk3 5KEUp98mC190F7mt5lwuyGrRi9bRNTL5pCtp2Hkv/nAM3PMHQanAEUKISaiVgWD4TyGj S3Ojuk4Q1AIkXiMeC7q3ACNvifuHKk/fjcRouyMoodc8K88ZgWqLtoZpOUy40R8g/q23 iG18KcwyzzNBpxLoH0FEnhDswa8w+mOblTEyGQ4Z2/RslsAKAp/GV+yDG217lXv82XdD 8rxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.b=M2A2aCDY; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q3si8610405pgf.182.2017.07.10.14.13.26; Mon, 10 Jul 2017 14:13:26 -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 header.b=M2A2aCDY; 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 S1754332AbdGJVNZ (ORCPT + 2 others); Mon, 10 Jul 2017 17:13:25 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:33351 "EHLO mail-wr0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752191AbdGJVNZ (ORCPT ); Mon, 10 Jul 2017 17:13:25 -0400 Received: by mail-wr0-f176.google.com with SMTP id r103so155902206wrb.0 for ; Mon, 10 Jul 2017 14:13:24 -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=Xb+W1+RYv1Js0fYV2capmE8rGL86L56xTe15GopjpBE=; b=M2A2aCDYK44J+a71rR6977sVK2Rah99DLHsa0uUkXXUFH9GrXaH+ZNiDnTRWpGSMkI DE3ARI07TNVGd8J70znsEO41isGycB4eZWsRaQfOQ7Mal5ONuuWUCN/NSh3IlpHCbQl9 it5U8NzI+DLaoOlavE10xwHNmz+a6O/vNO2uk= 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=Xb+W1+RYv1Js0fYV2capmE8rGL86L56xTe15GopjpBE=; b=QlbagNEzC9kQU2StuRU1MVVDPc9BT9CUh9DjjTtlYV7FIMd+Iq8+KzRZMp1T/GErPv 4n6oBpEg2KEtWJrRDBmOJGuO3FAgRIX7R3920rOGSVqkzuTL3ZBygWaeJlon8fRV2dNu MtKg/Lb2KUnfECUvqCM1XCUngUDbsXhHW3krdorjbBd8yQMGhjtoOLWoq83NrkeCVVZI WEL5oFJZ53KxPIeriV6lkceebCND5UhnMGEuLNGptlMzouT8bx5V2A/2QSRA19k3eFsE jeBP9UO830MBE1F61IBUiM0KQtOPltFmlfkiHmt1BFH+V0uLvpc35mgVK6Ob7VVJF5R3 jkUg== X-Gm-Message-State: AIVw111gKLme35hJNb/m4qyK/1sInxhujVdRsqLgVs/C0SjcnCinV9QQ IRZrORwl1XZ402sW X-Received: by 10.28.113.214 with SMTP id d83mr9080680wmi.62.1499721203501; Mon, 10 Jul 2017 14:13:23 -0700 (PDT) Received: from localhost.localdomain ([154.149.70.241]) by smtp.gmail.com with ESMTPSA id 185sm9526584wmn.33.2017.07.10.14.13.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 14:13:22 -0700 (PDT) From: Ard Biesheuvel To: linux-pci@vger.kernel.org, bhelgaas@google.com, pjones@redhat.com Cc: linux-fbdev@vger.kernel.org, linux-efi@vger.kernel.org, matt@codeblueprint.co.uk, b.zolnierkie@samsung.com, lorenzo.pieralisi@arm.com, Ard Biesheuvel Subject: [PATCH v2] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it Date: Mon, 10 Jul 2017 22:13:05 +0100 Message-Id: <20170710211305.6475-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.11.0 Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On UEFI systems, the firmware may expose a Graphics Output Protocol (GOP) instance to which the efifb driver attempts to attach in order to provide a minimal, unaccelerated framebuffer. The GOP protocol itself is not very sophisticated, and only describes the offset and size of the framebuffer in memory, and the pixel format. If the GOP framebuffer is provided by a PCI device, it will have been configured and enabled by the UEFI firmware, and the GOP protocol will simply point into a live BAR region. However, the GOP protocol itself does not describe this relation, and so we have to take care not to reconfigure the BAR without taking efifb's dependency on it into account. Commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers the framebuffer") attempted to do so by claiming the BAR resource early on, which prevents the PCI resource allocation routines from changing it. However, it turns out that this only works if the PCI device is not behind any bridges, since the bridge resources need to be claimed first. So instead, allow the BAR to be moved, but make the efifb driver deal with that gracefully. So record the resource that covers the BAR early on, and if it turns out to have moved by the time we probe the efifb driver, update the framebuffer address accordingly. While this is less likely to occur on x86, given that the firmware's PCI resource allocation is more likely to be preserved, this is a worthwhile sanity check to have in place, and so let's remove the Signed-off-by: Ard Biesheuvel --- v2: - use pr_info() not pr_warn() for non-error condition drivers/video/fbdev/efifb.c | 24 ++++++++++++-------- 1 file changed, 15 insertions(+), 9 deletions(-) -- 2.11.0 -- 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 Signed-off-by: Peter Jones Acked-by: Bjorn Helgaas diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index ff01bed7112f..0dd7e5eb051f 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -146,6 +146,9 @@ ATTRIBUTE_GROUPS(efifb); static bool pci_dev_disabled; /* FB base matches BAR of a disabled device */ +static struct resource *bar_resource; +static u64 bar_offset; + static int efifb_probe(struct platform_device *dev) { struct fb_info *info; @@ -200,6 +203,13 @@ static int efifb_probe(struct platform_device *dev) efifb_fix.smem_start |= ext_lfb_base; } + if (bar_resource && + bar_resource->start + bar_offset != efifb_fix.smem_start) { + + pr_info("efifb: PCI BAR has moved, updating fb address\n"); + efifb_fix.smem_start = bar_resource->start + bar_offset; + } + efifb_defined.bits_per_pixel = screen_info.lfb_depth; efifb_defined.xres = screen_info.lfb_width; efifb_defined.yres = screen_info.lfb_height; @@ -364,11 +374,11 @@ static struct platform_driver efifb_driver = { builtin_platform_driver(efifb_driver); -#if defined(CONFIG_PCI) && !defined(CONFIG_X86) +#if defined(CONFIG_PCI) static bool pci_bar_found; /* did we find a BAR matching the efifb base? */ -static void claim_efifb_bar(struct pci_dev *dev, int idx) +static void record_efifb_bar_resource(struct pci_dev *dev, int idx, u64 offset) { u16 word; @@ -383,12 +393,8 @@ static void claim_efifb_bar(struct pci_dev *dev, int idx) return; } - if (pci_claim_resource(dev, idx)) { - pci_dev_disabled = true; - dev_err(&dev->dev, - "BAR %d: failed to claim resource for efifb!\n", idx); - return; - } + bar_resource = &dev->resource[idx]; + bar_offset = offset; dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx); } @@ -415,7 +421,7 @@ static void efifb_fixup_resources(struct pci_dev *dev) continue; if (res->start <= base && res->end >= base + size - 1) { - claim_efifb_bar(dev, i); + record_efifb_bar_resource(dev, i, base - res->start); break; } }