From patchwork Tue Apr 11 08:43:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 97222 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp1708314qgd; Tue, 11 Apr 2017 01:43:38 -0700 (PDT) X-Received: by 10.84.241.14 with SMTP id a14mr72177164pll.117.1491900218339; Tue, 11 Apr 2017 01:43:38 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r63si16196898plb.129.2017.04.11.01.43.38; Tue, 11 Apr 2017 01:43:38 -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; 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 S1753719AbdDKIna (ORCPT + 2 others); Tue, 11 Apr 2017 04:43:30 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:37030 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751427AbdDKIn1 (ORCPT ); Tue, 11 Apr 2017 04:43:27 -0400 Received: by mail-wm0-f52.google.com with SMTP id u2so55278576wmu.0 for ; Tue, 11 Apr 2017 01:43:26 -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=f9A28CiDNro7VUQyOYTO25PAauuqBVevjzPwIozjECA=; b=KB4QCgCSGzzCbZh43VdyBk1ddsizqbgSDmxgzs5x0p9kwDnw4HyEHrRr876ICe2yjk J4EjMoKR9uWqTTq/QStVepjouE0l4dtjqrOFCUw+hPtqe/p76dXEWGwdpLEfHy3GeTkl 08vsMW84iSot1VMsgbbQDBcM2OTgJZMwMN9/k= 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=f9A28CiDNro7VUQyOYTO25PAauuqBVevjzPwIozjECA=; b=EvdPWVxVGIYPOTtgA9PZy+uwCHpLgxc/OVXmRImjkijPZ6FKsZG/Py+YzsfdGou9ia L2FMfQh0EXLb/hl7IllMgfEMwEls1PwMTHwqolrSXv5hoxfaxDf1v/UbawOl8D+0BvfG anVig6DqYFAPxV6hJpu+AnSxCNa6/X2ANv70+l4M7eQ96quXmwxpx7id48c2XiUQWD0I pwJeCKT1GOHUsQzosiPIEUfPTQHZc99rVL5sqlFC2BqSmiw1iOG9inEG+FJgCAhi/tDF bP/nREaFoc5iwvXI695wjp61jbDV30AzhQfzIQ4DFSyIADua/9wbCoT8U6sdIYnqWrw3 8TIw== X-Gm-Message-State: AN3rC/5Vtth7YjXUnZB8vTO7lnQk4AT9Fg00pSPwOR2M0JLZu3qktadH 2UHlCa4IvLge04LqUQvwdQ== X-Received: by 10.28.195.7 with SMTP id t7mr12616977wmf.62.1491900205878; Tue, 11 Apr 2017 01:43:25 -0700 (PDT) Received: from localhost.localdomain ([196.85.182.219]) by smtp.gmail.com with ESMTPSA id e21sm1557466wma.5.2017.04.11.01.43.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Apr 2017 01:43:25 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, linux-fbdev@vger.kernel.org, pjones@redhat.com, lorenzo.pieralisi@arm.com, b.zolnierkie@samsung.com, matt@codeblueprint.co.uk, okaya@codeaurora.org, Ard Biesheuvel Subject: [PATCH] efifb: arm/arm64: validate fb BAR instead of claiming it Date: Tue, 11 Apr 2017 09:43:18 +0100 Message-Id: <1491900198-26187-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 Sender: linux-fbdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org Claiming the BAR that matches the framebuffer base address in a PCI header fixup quirk only works as expected when the PCI device is on bus 0. If not, it will produce the following error: pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]: no compatible bridge window pci 0000:01:01.0: BAR 0: failed to claim resource for efifb! Since claiming the entire path up to the root is non-trivial at this point, and also undesirable given that we have no way of making sure that the existing configuration is sound, let's not claim anything at all, and simply record the resource so we can check that it did not move when the EFI fb driver is probed. Signed-off-by: Ard Biesheuvel --- drivers/video/fbdev/efifb.c | 23 +++++++++++++++----- 1 file changed, 17 insertions(+), 6 deletions(-) -- 2.7.4 -- 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..21d635ef5be2 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -146,6 +146,8 @@ ATTRIBUTE_GROUPS(efifb); static bool pci_dev_disabled; /* FB base matches BAR of a disabled device */ +static struct resource *pci_dev_bar_resource; + static int efifb_probe(struct platform_device *dev) { struct fb_info *info; @@ -179,6 +181,20 @@ static int efifb_probe(struct platform_device *dev) } printk(KERN_INFO "efifb: probing for efifb\n"); + if (pci_dev_bar_resource) { + u64 base = screen_info.lfb_base; + u64 size = screen_info.lfb_size; + + if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) + base |= (u64)screen_info.ext_lfb_base << 32; + + if (pci_dev_bar_resource->start > base || + pci_dev_bar_resource->end < base + size - 1) { + pr_err("efifb: PCI BAR has moved, disabling ...\n"); + return -ENODEV; + } + } + /* just assume they're all unset if any are */ if (!screen_info.blue_size) { screen_info.blue_size = 8; @@ -383,12 +399,7 @@ 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; - } + pci_dev_bar_resource = dev->resource + idx; dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx); }