From patchwork Fri Aug 18 19:49:40 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 110434 Delivered-To: patch@linaro.org Received: by 10.140.95.78 with SMTP id h72csp1343811qge; Fri, 18 Aug 2017 12:50:26 -0700 (PDT) X-Received: by 10.99.98.193 with SMTP id w184mr9481413pgb.358.1503085826231; Fri, 18 Aug 2017 12:50:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1503085826; cv=none; d=google.com; s=arc-20160816; b=yMzvOWCcG557pBzCw3NYEAat+HeaigIkvxhfaIwi3Whhg03lvB4iUbDJDw0YGkcGer mR19JHlGjFaLdcp8RnJqkxlbFU7364dnEYh/hIJKWnmwBKpE2Sa+kfhpxQtee399gvbX qkhYOSWHoK38kX5SEpDTtmBiUd6u2uzWrsSpVTOEGAh4G4z8jrhmcsjdGLeTSRHaJ8UU zC18Qe21q7c0D4y4GUPbj1Qs/7S+vhVcDxDpZ+8LfU6pVCDj+fuMo1ybkCuyMtlhnDgW 8+WS3rcb7N5mr/KuyKWD7ePiAbChSE4hJYu/xtoXXQwtjOzzjOgToUwGrU3DKF0k4Mo5 n4Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=mWBui8nQ13i4pSyHO99kXXh9ZBaxA44tSJsyNwftcS8=; b=jT/J8uxLcOty3RmAAwZtrdaYr79R7xhqm0j9T2xJpCuN2bDf1v2hvZBLoYqN6Nlsie t+SD8frualG5Pg3OrjKLPXz6xinvQrrcZaRO8TATy/IMNiNQ3bswZ9z/70Wrlph0hNS1 vCNwAYWyGzJz5iOg5S/lwcgKnZBjEVPLwqNHMZzmptxKRlAm5xg0Dn05YOKPbIQTvCb5 kj1LQYq9O/CqU3N4iPbTXiYV7L/eTJTSdlgkqKmO/jK4bJefI5tFc0p9iqUcJ7aLE6xo 2xt2KGVPYklRLq8O3mMwgVzFOxywVRVp1DTw8YVXawsElGFEtG4WMgHOmcL7iwBYmySy M2Qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=U2P9tsrF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (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 x66si4067940pfb.38.2017.08.18.12.50.25; Fri, 18 Aug 2017 12:50:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=U2P9tsrF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752516AbdHRTuW (ORCPT + 26 others); Fri, 18 Aug 2017 15:50:22 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:35403 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752320AbdHRTuS (ORCPT ); Fri, 18 Aug 2017 15:50:18 -0400 Received: by mail-wm0-f48.google.com with SMTP id m85so7249774wma.0 for ; Fri, 18 Aug 2017 12:50:18 -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:in-reply-to:references; bh=mWBui8nQ13i4pSyHO99kXXh9ZBaxA44tSJsyNwftcS8=; b=U2P9tsrFHStxeutXQtfr2QJikX4anATrE/NbeB5CDwrhr2LPvFvgwbBGLB0MYd6N+x vlafydUcqhYvwqNF1vp6Syp7G5ErEvNgs4r1XeR477HYiaz7WwJtyIlFPA8BFqfC7khU lDXHF20geIOMpzGt6V7JQQBPAQwyBZCpZev0I= 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:in-reply-to :references; bh=mWBui8nQ13i4pSyHO99kXXh9ZBaxA44tSJsyNwftcS8=; b=OZZau84VtFiwYKQoTyxJfBMccCZjzkBjlSD3ybowRnV5Cgs7JiYUZEbHhdx8aNcb/M fUWjH22nFTNYcgSX3vTMrGCWDWujSbjBr767I6jzDUDve1OJTM7zsQl6t3VL0ceL1Lgc jxlHeWkDqjadM1pI8qgzlXwCMbNKFGDMTviwkzbdD8doSzQZ/9GTW3auyeVjRYjBHeCL EQsgb0OKyOzW5kFteG/IJVCNLeWUoHrzNjUGQILE/+/x2HckEq8CBe0HyP2z8l6rYCQQ q/YH77wWRV/AZ4NDaxtXy8aeWQyaHVqwpjpg1JEAZdKCoqT32lC1C90B6AcRozPaS6lP 61bw== X-Gm-Message-State: AHYfb5iVFtbT5rL9xlmi/r84JxM5LIOvLLQn8KZuxWXUGBDCuoiuExL7 9vS7oSRdTIoviiqh X-Received: by 10.28.232.8 with SMTP id f8mr2352155wmh.24.1503085817392; Fri, 18 Aug 2017 12:50:17 -0700 (PDT) Received: from localhost.localdomain ([154.146.161.128]) by smtp.gmail.com with ESMTPSA id k29sm5571168wrk.56.2017.08.18.12.50.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 12:50:16 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, Ingo Molnar , Thomas Gleixner , "H . Peter Anvin" Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, Matt Fleming Subject: [PATCH 07/14] drivers/fbdev: efifb: allow BAR to be moved instead of claiming it Date: Fri, 18 Aug 2017 20:49:40 +0100 Message-Id: <20170818194947.19347-8-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170818194947.19347-1-ard.biesheuvel@linaro.org> References: <20170818194947.19347-1-ard.biesheuvel@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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. Cc: Matt Fleming Reviewed-by: Peter Jones Acked-by: Bartlomiej Zolnierkiewicz Acked-by: Bjorn Helgaas Signed-off-by: Ard Biesheuvel --- drivers/video/fbdev/efifb.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) -- 2.11.0 diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index ff01bed7112f..994b5f3a4d73 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; } }