From patchwork Fri Jul 14 13:48:34 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 107803 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp924158qge; Fri, 14 Jul 2017 06:48:54 -0700 (PDT) X-Received: by 10.84.177.36 with SMTP id w33mr16672978plb.302.1500040134708; Fri, 14 Jul 2017 06:48:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500040134; cv=none; d=google.com; s=arc-20160816; b=F9uxd/mz+QIzX3knPC/ReJRdsPaRGHKscO81622CsrClHyO2409q51klFPT63T37A8 k9sxcZyXlG7/v25Hl4BmAN+535Cj7XGFjlNt6syAWzcvvIcUQwMQ3EG0rXL0Ifz0JpaU DEnKzePHp6zR+ivrLEbBo+pqQpHbpUVoe7s1jny7MhCgnplK9BDrTFa8kUPwT1jFNMor CuRnVXg9l13LBLWLSPQw4Zjs0LBV0xJ/2ZGrpJtl0wgkW9i/uB82fU06SPHFCS3WwyIh LVLCmtmYe41XtosXsdkkbcO5tx1MziG7/tmFxOM+buAhSJRbB2aPLawW7yDaY+uT/oME +RGg== 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=YmnIwAOH/DiH8YQNWO30H7Ar9ZGA2i3jUVKj8Q1+Kkw=; b=KaBtuVXuLiPIF2di5iVO9VKgzU7tqsUDs+vkh9tmlolgQFDTMhm+xVzK+0/VoUqnsv UfaoyHKq7YpTnQPxgTW3Msz6bGKbDkBc6qpCxqcOFHtv/ReA6ZKNTl0W+uMYAaWbcW1w sPowP45TDd+1kXKK0/EWwTLz5sPyS3QrMHkNoWO7JeuaihHPMGlfLmA3kBRrpq2uNSVj AnYc0did36M2HfUVVtHBsG3um7RnNb5uN3lRDOzl6AbaTZmF31R7Su35tcrBNlPm63u7 Mh85DbJ7LRMpwK+5S2yWHJSYNiNrIUphHWp8aLhF5680Lpx2q0hDf5tEcEAoKjC1rdA9 exvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.b=cJph81wb; 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 v25si6516266pfg.68.2017.07.14.06.48.54; Fri, 14 Jul 2017 06:48:54 -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=cJph81wb; 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 S932070AbdGNNsx (ORCPT + 2 others); Fri, 14 Jul 2017 09:48:53 -0400 Received: from mail-wr0-f172.google.com ([209.85.128.172]:34150 "EHLO mail-wr0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753634AbdGNNsw (ORCPT ); Fri, 14 Jul 2017 09:48:52 -0400 Received: by mail-wr0-f172.google.com with SMTP id 77so67768768wrb.1 for ; Fri, 14 Jul 2017 06:48:51 -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=qhbPLlxZhJpwyTbZLBlB0MZX6D79cAlxUI/nOJAxmLE=; b=cJph81wb+BmfBsy1Oq7yx1E1Y4LcX8AZiWtOfyB7CJrfC279Kj/RNJvV9pf6AqGSvM Cfk+NwIbZiaDm0R1FmEvmBIOJOKg8hzahjO0GdifGTrZ01Gcv64aLBLkcf9tkA+15LWW 0I0w801qy6dB8jrbwYcsNz//CsN65LjX219f4= 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=qhbPLlxZhJpwyTbZLBlB0MZX6D79cAlxUI/nOJAxmLE=; b=CEhS/jTVe+Hv62cJtC+GvAoavbY7nFjWUHuV5JqzexRItT3lEwdv6GURI3fhnvOI4x /fF6FNs6qsYj/190pqBWDX3Tzq4+nP1mfqV8ig1/46Ki7cqlRPwtmHsrN5ulUy+5AWb0 VBgzOzm5oG6cwmBDvwHeYbIGfTHU8DnL3ZtHenfYn/X2PipSJ4IYr3DUxAMuX5NsasRW Ja4XARKmr0SoardXZB+/zkWWHj6R+/haMPVHbtBl1uNoS68T98Fm5zTMh6huKb/441CS v6WOwuUaH5eP7Dpg3xHMtTKQnym96I0DOIPqalo5okj8q2uSdFEb0dBe9avzgLRcSAvK 4wDw== X-Gm-Message-State: AIVw111P5RE5IlOII2CJ7Jpr1J9t2S5EgTvfawhCcAwbDTUf1KFfTVKZ mGGgvGQUy8id9UUP X-Received: by 10.223.170.138 with SMTP id h10mr4700680wrc.153.1500040130789; Fri, 14 Jul 2017 06:48:50 -0700 (PDT) Received: from localhost.localdomain ([154.145.198.181]) by smtp.gmail.com with ESMTPSA id j190sm2992493wmd.22.2017.07.14.06.48.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 06:48:49 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org Cc: linux-pci@vger.kernel.org, linux-fbdev@vger.kernel.org, matt@codeblueprint.co.uk, pjones@redhat.com, bhelgaas@google.com, b.zolnierkie@samsung.com, lorenzo.pieralisi@arm.com, Ard Biesheuvel Subject: [PATCH v3] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it Date: Fri, 14 Jul 2017 14:48:34 +0100 Message-Id: <20170714134834.14191-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 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 preprocessor conditional that makes it !X86 only. Reviewed-by: Peter Jones Acked-by: Bartlomiej Zolnierkiewicz Acked-by: Bjorn Helgaas Signed-off-by: Ard Biesheuvel --- v3: - at the request of Bjorn, record the struct pci_dev pointer as well, so that we can output something along the lines of pci 0000:02:01.0: BAR has moved, updating efifb address - fix missing line in commit log I will go ahead and queue this version in the EFI tree (unless anyone objects. drivers/video/fbdev/efifb.c | 31 ++++++++++++-------- 1 file changed, 18 insertions(+), 13 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..3293f95700fb 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -146,6 +146,10 @@ ATTRIBUTE_GROUPS(efifb); static bool pci_dev_disabled; /* FB base matches BAR of a disabled device */ +static struct pci_dev *efifb_pci_dev; /* dev with BAR covering the efifb */ +static struct resource *bar_resource; +static u64 bar_offset; + static int efifb_probe(struct platform_device *dev) { struct fb_info *info; @@ -200,6 +204,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) { + dev_info(&efifb_pci_dev->dev, + "BAR has moved, updating efifb 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,15 +375,13 @@ static struct platform_driver efifb_driver = { builtin_platform_driver(efifb_driver); -#if defined(CONFIG_PCI) && !defined(CONFIG_X86) - -static bool pci_bar_found; /* did we find a BAR matching the efifb base? */ +#if defined(CONFIG_PCI) -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; - pci_bar_found = true; + efifb_pci_dev = dev; pci_read_config_word(dev, PCI_COMMAND, &word); if (!(word & PCI_COMMAND_MEMORY)) { @@ -383,12 +392,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); } @@ -399,7 +404,7 @@ static void efifb_fixup_resources(struct pci_dev *dev) u64 size = screen_info.lfb_size; int i; - if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI) + if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI) return; if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) @@ -415,7 +420,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; } }