From patchwork Wed Dec 9 09:39:55 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 40716 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id E0A4EB6F0F for ; Wed, 9 Dec 2009 20:39:59 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752877AbZLIJjv (ORCPT ); Wed, 9 Dec 2009 04:39:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752811AbZLIJju (ORCPT ); Wed, 9 Dec 2009 04:39:50 -0500 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:53722 "EHLO sunset.davemloft.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752574AbZLIJjt (ORCPT ); Wed, 9 Dec 2009 04:39:49 -0500 Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net (Postfix) with ESMTP id 1AA2D24C6E2; Wed, 9 Dec 2009 01:39:56 -0800 (PST) Date: Wed, 09 Dec 2009 01:39:55 -0800 (PST) Message-Id: <20091209.013955.262196704.davem@davemloft.net> To: pat@computer-refuge.org Cc: rdreier@cisco.com, sparclinux@vger.kernel.org, linux-rdma@vger.kernel.org Subject: Re: Sun V880 + Infiniband? From: David Miller In-Reply-To: <200912030144.18971.pat@computer-refuge.org> References: <20091202.144255.137848873.davem@davemloft.net> <200912030144.18971.pat@computer-refuge.org> X-Mailer: Mew version 6.2 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org From: Patrick Finnegan Date: Thu, 3 Dec 2009 01:44:18 -0500 > On Wednesday 02 December 2009, David Miller wrote: >> If there's something Linux isn't doing right, those dumps will help >> me spot it. > > Thanks again! Please give this patch a try: sparc64: Fix overly strict range type matching for PCI devices. When we are trying to see if a range property entry applies to a given address, we are overly strict about the type. We should only allow I/O ranges for I/O addresses, and only allow CONFIG space ranges for CONFIG space address. However for MEM ranges, they come in 32-bit and 64-bit flavors. And a lack of an exact match is OK if the range is 32-bit and the address is 64-bit. We can assign a 64-bit address properly into a 32-bit parent range just fine. So allow it. Reported-by: Patrick Finnegan Signed-off-by: David S. Miller --- arch/sparc/kernel/of_device_64.c | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c index 881947e..0a6f2d1 100644 --- a/arch/sparc/kernel/of_device_64.c +++ b/arch/sparc/kernel/of_device_64.c @@ -104,9 +104,19 @@ static int of_bus_pci_map(u32 *addr, const u32 *range, int i; /* Check address type match */ - if ((addr[0] ^ range[0]) & 0x03000000) - return -EINVAL; + if (!((addr[0] ^ range[0]) & 0x03000000)) + goto type_match; + + /* Special exception, we can map a 64-bit address into + * a 32-bit range. + */ + if ((addr[0] & 0x03000000) == 0x03000000 && + (range[0] & 0x03000000) == 0x02000000) + goto type_match; + + return -EINVAL; +type_match: if (of_out_of_range(addr + 1, range + 1, range + na + pna, na - 1, ns)) return -EINVAL;