From patchwork Tue Apr 11 16:33:12 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 749560 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3w2Xfv1CLMz9sNS for ; Wed, 12 Apr 2017 02:33:27 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="DXZLuqv5"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751951AbdDKQd0 (ORCPT ); Tue, 11 Apr 2017 12:33:26 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:35625 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752040AbdDKQdZ (ORCPT ); Tue, 11 Apr 2017 12:33:25 -0400 Received: by mail-wm0-f52.google.com with SMTP id w64so68308462wma.0 for ; Tue, 11 Apr 2017 09:33: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; bh=PMHY5H3N/odwgponJ6dVTbzPPbYHj5c94pcUqoy2P48=; b=DXZLuqv5cRFydfa749rLeqD6hlxmSQRAZ1ORR3AwTqTRgtSTuCZVMInhYiHl59CFGn 0wCspkJxzbFnU0/7a54QGSYwCB3iem+FExaLvfltpglM9zKhK5MMue4o4H4m2ikdVqRh qjy6Uf90Q4q+ns6CrZyWt+1d9pH4jE/iH7jaM= 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=PMHY5H3N/odwgponJ6dVTbzPPbYHj5c94pcUqoy2P48=; b=lxyrDWuQMH+zCbnJi5Ey5qo8lumJYjjla3gYugvDubBZjmynLk4ZupJ6aKesFnhVp3 XqGiCjd8pDDHR+LssfoUoBRNVqpHyp4aMk2FbcwTO0E7J0bgA9hTkNJ9Eicgzr6/1YVt tymCjWQUo02wTQ/R0/7xJeBckOpA798txFzIrO+8158NHEc6C99YFEAjsPHP37mF6aVE /das438XIrx3z5OXyl2xmeLSdDA/OFnII2khIwVfKWSaWRrPTI1B3tI+fb/GTKljlZjP ZAFefiNE6jEeNhzSvpEwXJydp7dPF3mtroWFkRwBnVb38YTVTlKPRIWuDSs1x8wTUbOK +ymg== X-Gm-Message-State: AN3rC/6U+alGjM09MjL8AiAG5HSR7poQHz4usP/Wf74ztKZ2vp8AmlDTitXEifSC1Z31pO+I X-Received: by 10.28.12.66 with SMTP id 63mr15813748wmm.47.1491928403234; Tue, 11 Apr 2017 09:33:23 -0700 (PDT) Received: from localhost.localdomain ([196.85.182.219]) by smtp.gmail.com with ESMTPSA id u145sm3125556wmu.1.2017.04.11.09.33.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 09:33:22 -0700 (PDT) From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org Cc: catalin.marinas@arm.com, will.deacon@arm.com, bhelgaas@google.com, lorenzo.pieralisi@arm.com, tn@semihalf.com, graeme.gregory@linaro.org, leif.lindholm@linaro.org, okaya@codeaurora.org, Ard Biesheuvel Subject: [PATCH 1/2] drivers: pci: do not disregard parent resources starting at 0x0 Date: Tue, 11 Apr 2017 17:33:12 +0100 Message-Id: <20170411163313.18577-2-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170411163313.18577-1-ard.biesheuvel@linaro.org> References: <20170411163313.18577-1-ard.biesheuvel@linaro.org> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Commit f44116ae8818 ("PCI: Remove pci_find_parent_resource() use for allocation") updated the logic that iterates over all bus resources and compares them to a given resource, in order to decide whether one is the parent of the latter. This change inadvertently causes pci_find_parent_resource() to disregard resources starting at address 0x0, resulting in an error such as the one below on ARM systems whose I/O window starts at 0x0. pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window] pci_bus 0000:00: root bus resource [io 0x0000-0xffff window] pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window] pci_bus 0000:00: root bus resource [bus 00-0f] pci 0000:00:01.0: PCI bridge to [bus 01] pci 0000:00:02.0: PCI bridge to [bus 02] pci 0000:00:03.0: PCI bridge to [bus 03] pci 0000:00:03.0: can't claim BAR 13 [io 0x0000-0x0fff]: no compatible bridge window pci 0000:03:01.0: can't claim BAR 0 [io 0x0000-0x001f]: no compatible bridge window While this never happens on x86, it is perfectly legal in general for a PCI MMIO or IO window to start at address 0x0, and it was supported in the code before commit f44116ae8818. So let's drop the test for res->start != 0; resource_contains() already checks whether [start, end) completely covers the resource, and so it should be redundant. Fixes: f44116ae8818 ("PCI: Remove pci_find_parent_resource() use for allocation") Signed-off-by: Ard Biesheuvel --- drivers/pci/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 7904d02ffdb9..53a41b1f7ef7 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -454,7 +454,7 @@ struct resource *pci_find_parent_resource(const struct pci_dev *dev, pci_bus_for_each_resource(bus, r, i) { if (!r) continue; - if (res->start && resource_contains(r, res)) { + if (resource_contains(r, res)) { /* * If the window is prefetchable but the BAR is