From patchwork Thu May 16 21:31:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 164348 Delivered-To: patch@linaro.org Received: by 2002:a92:9e1a:0:0:0:0:0 with SMTP id q26csp1355451ili; Thu, 16 May 2019 14:32:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqyl6WH5Eg+n6XyPvX11vv20Yvj5JSL4mp8c+786Xorj50DDvOYKr28blkSk+IkwYt1mdEL5 X-Received: by 2002:a17:902:e091:: with SMTP id cb17mr52017984plb.222.1558042347476; Thu, 16 May 2019 14:32:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558042347; cv=none; d=google.com; s=arc-20160816; b=J+UPr2xRAmm23v5CB13ikQIjxMG9aP+pSHL4f/4n26B89WQ0pPlYrJ4tmOHQzb+ToS DoLl4eXXSaaF5bCYOQ5ScXfGAINyVzyBukSrriVH9Erj1RbMit33lRQdgqgsazFZFszZ lzkFSXMNPVxv7KmzthSwF2VXPt+YxLZuzvjsYQAl8+2xXAubFQ9PLVoGQKWYY0gHiWGE O6swIau3h7+ra2Ei57VhyRbexFhvU1rnqkdNEUPJTMfANrrqz7G3HMhPWXz9ngujT8WQ bHj5Ll9wP2aV5RAK7oXUa3nloEElJzuR0NEsFYSVdZbMihwomJE7Koj1O5MBMhMx+sHP saeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=u8GkOq3mFgmT114W9q0A9mveOj1yfbx4rAlQUC/tkPc=; b=tWT618WUADCAHXrQkR+waQnQ5huVAQoa1h0QHGRlBEYWu2CHAClGyJAGzSoj2H6zVx nO1PmJpGJTRL6t4WPAe/7wKzmztojpFP5JlAHJDwNX1rNg7c9+qWonsC5cjbtxqES130 THvoM8SnwL0/zboGUmt3zWJcgONFYS/tt9QVpROinSalJMP8du71Bw8YXDbYBwjq/5dG i6CjOUZSMtDGujYFoiTJpm0ib2lICyWJzvW9Sg8jVlVf6waj17tO8yXGk6MRWEIp694H 5PXtUj33SYDhbTc4bv600eY0NyKT0DxF7wWcvFelCDi0+YyrnGQgGtwdhurmqJkutiwP n37w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=r+7o95at; 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 i7si5803512plt.332.2019.05.16.14.32.27; Thu, 16 May 2019 14:32:27 -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=r+7o95at; 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 S1728668AbfEPVc0 (ORCPT + 30 others); Thu, 16 May 2019 17:32:26 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:53248 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727793AbfEPVcY (ORCPT ); Thu, 16 May 2019 17:32:24 -0400 Received: by mail-wm1-f66.google.com with SMTP id 198so5003830wme.3 for ; Thu, 16 May 2019 14:32: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:in-reply-to:references :mime-version:content-transfer-encoding; bh=u8GkOq3mFgmT114W9q0A9mveOj1yfbx4rAlQUC/tkPc=; b=r+7o95atwX8dZuEaXrHT3RNs2JbAxvK0UioLsku9KT5XxUcL/dUY4XAvA33SYj1rQt lv3ZhZejg+q39JWKLjynNLqayrtND0Dse1BayIx+h5gxRhk/UvoAteBiyWaSw92w8x4j NKUEd+pWdmhjZqslPcN6t4ZJe6vpy4TyHzUQEJpOqqa1HebJfu6qwCpImeJ3ftlhb+en bYMfZ7mlvE6Zui2nqnn7qH/x89TfcUOD3gavYtX3xQA/cyapCDpyTFidNvgGPWudNl9Q 6AnoPOKE7h6QnPaq9IuIWhGd6OAtXYloglkuWCz9LiPvyh0Ylec4U3OIQ5pu/LmxvGmK 6GaA== 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:mime-version:content-transfer-encoding; bh=u8GkOq3mFgmT114W9q0A9mveOj1yfbx4rAlQUC/tkPc=; b=aLW6S/MmYjLAPBik5wyqrdwxtuZh3PXgdGmfghOi/ewpGsl7sIsPC5HZNVFpJwJEoh TFGt2gMiwgqLL73GX/LEc1ratu7J4QNHJIQgB+obDOnKOYsq7ebCtlT0CRk1PGflyxti EL+bb7tw1L0nZypFro0zquAtPELc95qwqO+mDJ2seRibaZZZNKhd0a6O0xhCjUbJ+PV2 eq+tLHSUy3e3ueOmrTTQnYVPcFzFtiiKfU1ux817ETfZmF+RmaH8dMW23Z7BhzHQ3dXG LR9lmfhf4WmV7FYfoZJuxxgLzFfTCgiFmWSkZxvGn6b2KsjZkGwFZdb+FxdxKiklj73z rtZQ== X-Gm-Message-State: APjAAAWxoronDJV9V2CpPzhahQrc3si7gqAy42rqH4eSy61ghHZICblb RYFSY7bWxrEMQyoU+l0mvpZMqA== X-Received: by 2002:a05:600c:22c9:: with SMTP id 9mr11058445wmg.4.1558042343288; Thu, 16 May 2019 14:32:23 -0700 (PDT) Received: from sudo.home ([2a01:cb1d:112:6f00:55a9:76bd:5bf2:be83]) by smtp.gmail.com with ESMTPSA id e12sm6756988wrs.8.2019.05.16.14.32.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 14:32:22 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, Ingo Molnar , Thomas Gleixner Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org Subject: [PATCH 1/1] fbdev/efifb: ignore framebuffer memmap entries that lack any memory types Date: Thu, 16 May 2019 23:31:59 +0200 Message-Id: <20190516213159.3530-2-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190516213159.3530-1-ard.biesheuvel@linaro.org> References: <20190516213159.3530-1-ard.biesheuvel@linaro.org> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB") updated the EFI framebuffer code to use memory mappings for the linear framebuffer that are permitted by the memory attributes described by the EFI memory map for the particular region, if the framebuffer happens to be covered by the EFI memory map (which is typically only the case for framebuffers in shared memory). This is required since non-X86 systems may require cacheable attributes for memory mappings that are shared with other masters (such as GPUs), and this information cannot be described by the Graphics Output Protocol (GOP) EFI protocol itself, and so we rely on the EFI memory map for this. As reported by James, this breaks some x86 systems: [ 1.173368] efifb: probing for efifb [ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf800000 [ 1.173395] Trying to free nonexistent resource <00000000cf800000-00000000cf9d4bff> [ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5 The problem turns out to be that the memory map entry that describes the framebuffer has no memory attributes listed at all, and so we end up with a mem_flags value of 0x0. So work around this by ensuring that the memory map entry's attribute field has a sane value before using it to mask the set of usable attributes. Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...") Cc: # v4.19+ Cc: Peter Jones Reported-by: James Hilliard Tested-by: James Hilliard Signed-off-by: Ard Biesheuvel --- drivers/video/fbdev/efifb.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) -- 2.20.1 diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index 9e529cc2b4ff..9f39f0c360e0 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -477,8 +477,12 @@ static int efifb_probe(struct platform_device *dev) * If the UEFI memory map covers the efifb region, we may only * remap it using the attributes the memory map prescribes. */ - mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB; - mem_flags &= md.attribute; + md.attribute &= EFI_MEMORY_UC | EFI_MEMORY_WC | + EFI_MEMORY_WT | EFI_MEMORY_WB; + if (md.attribute) { + mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB; + mem_flags &= md.attribute; + } } if (mem_flags & EFI_MEMORY_WC) info->screen_base = ioremap_wc(efifb_fix.smem_start,