From patchwork Tue Jun 27 16:19:36 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 106455 Delivered-To: patch@linaro.org Received: by 10.140.101.48 with SMTP id t45csp1389935qge; Tue, 27 Jun 2017 09:19:59 -0700 (PDT) X-Received: by 10.98.28.71 with SMTP id c68mr6129769pfc.116.1498580399504; Tue, 27 Jun 2017 09:19:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498580399; cv=none; d=google.com; s=arc-20160816; b=1KBGDG02YnrwtvqFr8atUwwKMHqm7BePsBm9raslOzaFSyjNNeGcN/zbPUx70pygQb gNC5IrdbSUXK2nFQvkTIAqcD0hDIoaECKC3B+egbH4inDZoFlC9IlOug931TT/bWNcUd HhcdF5o67dRsQoMjT9KaZ8CKZKCaMTJwDYoIpaSVMsGef9En5GIlXE97jRD0BHqkthRf AVtNYkl4CIsN4T3wtF4/dfn2kvjfOZdgibnKCrg8kF5FY/oUbwjbYtLDrjz1UDWgUb91 EBIj8k49z3DjY89UOkKac2JrnHQlFT/oxZhhzFxhhl+f6RQW6+YxPDDJEpxbGV2zJzDb 3GzA== 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=7t5M9oB4njsF2ysmtlYgCZydNb+ELotdRcmFXEZfuJk=; b=RUVKBE+MrovH3XEMo2AvscflttX/OqFmENX5H5fP6OIAfGak96qDhVQyoleJkbdbeI am7+pDqDD6z0glRMo1Cd5eZv2CaJjb1cJsAYDVmZSKBN8J1dFLoB9mG/tYK2b2eahNWi v1lfPxBO0qw5n5V45LAtm+pngFkdMFnc3A0CKOsUYd6x7WsU9l9SpM0Z392N91iIDUQv zRNEuMifDkLhIeHKBRg8rA2Xx5WQZzpVk2efam2oHFmCr+d51IzjDO8b5PK4mcLtGukW PrCtu7P+EotQcQwIokx+fQw8e2rcp4sVhk1IKF58+svhKtKhfOJus0HJBMjcxWErnnoH c2AA== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.b=S/SP27ge; spf=pass (google.com: best guess record for domain of linux-fbdev-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-fbdev-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 p91si2360253plb.244.2017.06.27.09.19.59; Tue, 27 Jun 2017 09:19:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-fbdev-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=S/SP27ge; spf=pass (google.com: best guess record for domain of linux-fbdev-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-fbdev-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 S1751658AbdF0QTv (ORCPT + 2 others); Tue, 27 Jun 2017 12:19:51 -0400 Received: from mail-wr0-f173.google.com ([209.85.128.173]:36398 "EHLO mail-wr0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751513AbdF0QTs (ORCPT ); Tue, 27 Jun 2017 12:19:48 -0400 Received: by mail-wr0-f173.google.com with SMTP id c11so161876394wrc.3 for ; Tue, 27 Jun 2017 09:19:47 -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=hQ40Pok24Y1CYSvoYfGZsJoXKAIYnXk6WS6nnwbVqy4=; b=S/SP27ge1v2Tit1xoOZ5ki9zJXMDGQC4YQjo92yaBFLIFavcy2qoc3yc92YCZ1JKii 7hxKcKp65K3hKr/pjjTN2KlXVce7L8HBhi+qZTwKxVj1WnaPtyoLO0wvRpOqOtAR4GHq 7hWd+zAiu6Cq/JBYxlhvuhn4lUemOZ73t7no4= 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=hQ40Pok24Y1CYSvoYfGZsJoXKAIYnXk6WS6nnwbVqy4=; b=dzTSLVYhyipBPBdGMnBoHVvEzcUL2eQeVN/qbT3bW4CFb79yyoizRRgx37TMfwPkJV XBdulnyuHiRrsAbh+x68RUZap7MhqwQHTcaltKyHW/BTtxdQX2INoWvl5L4AkSN+uC8U qIG5A8iCOGq63CFsroSESf0s83oEv6NLfc0WNXOJtHV5470f0Hj0Zg2za/HcXVAH1HIk rGAzKEbMqloHzg5qx3D5hYxqqX9O5ChCtQZSo9DIV58HGEa7NkWKWUIbWJCYBOQ7LHPc e+TJSE9a/Mks0hNMdP0B5U1OBsXu+63yqiv8vawFjSCelW5rrn5IWlm+Lov8JWuU0QPB kAww== X-Gm-Message-State: AKS2vOxQG1PciVH6pKUdA1Dx2uTmiU+UVe2xxOJyzZtaZd5hTnwxRPtL nHgHVqlqsjutFxgDohg6gA== X-Received: by 10.223.177.129 with SMTP id q1mr17827377wra.82.1498580386487; Tue, 27 Jun 2017 09:19:46 -0700 (PDT) Received: from localhost.localdomain ([105.133.250.69]) by smtp.gmail.com with ESMTPSA id y2sm3520059wme.12.2017.06.27.09.19.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jun 2017 09:19:45 -0700 (PDT) From: Ard Biesheuvel To: linux-fbdev@vger.kernel.org, linux-efi@vger.kernel.org Cc: matt@codeblueprint.co.uk, b.zolnierkie@samsung.com, pjones@redhat.com, lorenzo.pieralisi@arm.com, bhelgaas@google.com, Ard Biesheuvel Subject: [PATCH] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it Date: Tue, 27 Jun 2017 16:19:36 +0000 Message-Id: <20170627161936.2301-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 Sender: linux-fbdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@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 the 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 --- drivers/video/fbdev/efifb.c | 24 ++++++++++++-------- 1 file changed, 15 insertions(+), 9 deletions(-) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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 b827a8113e26..6220de3e25d3 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_warn("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; } }