Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754855Ab2E2Rz2 (ORCPT ); Tue, 29 May 2012 13:55:28 -0400 Received: from mail-vc0-f174.google.com ([209.85.220.174]:36066 "EHLO mail-vc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754591Ab2E2RzZ convert rfc822-to-8bit (ORCPT ); Tue, 29 May 2012 13:55:25 -0400 MIME-Version: 1.0 In-Reply-To: References: <1337754877-19759-1-git-send-email-yinghai@kernel.org> <1337754877-19759-3-git-send-email-yinghai@kernel.org> <20120525043651.GA1391@google.com> <20120525193716.GA8817@google.com> Date: Tue, 29 May 2012 10:55:23 -0700 X-Google-Sender-Auth: 7MG0G_RSnoarj6L3DoUnNp3zqoo Message-ID: Subject: Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first From: Yinghai Lu To: Bjorn Helgaas Cc: Linus Torvalds , Steven Newbury , "H. Peter Anvin" , Andrew Morton , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2041 Lines: 56 On Fri, May 25, 2012 at 5:12 PM, Bjorn Helgaas wrote: > On Fri, May 25, 2012 at 5:10 PM, Yinghai Lu wrote: >> On Fri, May 25, 2012 at 2:55 PM, Bjorn Helgaas wrote: >>> I think we should fix this with a separate patch that removes >>> PCIBIOS_MAX_MEM_32 altogether, replacing this use with an explicit >>> 0xffffffff (or some other "max 32-bit value" symbol). ?I don't think >>> there's anything arch-specific about this. >>> >>> So I'd like to see two patches here: >>> ?1) Avoid allocating 64-bit regions for 32-bit BARs >>> ?2) Try to allocate regions above 4GB for 64-bit BARs >> >> Sure. please check updated two patches. > > I think the first one looks good. > > I'm curious about the second. ?Why did you add the IORESOURCE_MEM > test? ?That's doesn't affect the "start =" piece because > IORESOURCE_MEM is always set if IORESOURCE_MEM_64 is set. > > But it does affect the "end =" part. ?Previously we limited all I/O > and 32-bit mem BARs to the low 4GB. ?This patch makes it so we limit > 32-bit mem BARs to the low 4GB, but we don't limit I/O BARs. ?But I/O > BARs can only have 32 bits of address, so it seems like we should > limit them the same way as 32-bit mem BARs. ?So I expected something > like this: > > ? ?if (res->flags & IORESOURCE_MEM_64) { > ? ? ? ?start = (resource_size_t) (1ULL << 32); > ? ? ? ?end = PCI_MAX_RESOURCE; > ? ?} else { > ? ? ? ?start = 0; > ? ? ? ?end = PCI_MAX_RESOURCE_32; > ? ?} x86 are using 16bits. some others use 32 bits. #define IO_SPACE_LIMIT 0xffffffff ia64 and sparc are using 64bits. #define IO_SPACE_LIMIT 0xffffffffffffffffUL but pci only support 16bits and 32bits. maybe later we can add PCI_MAX_RESOURCE_16 to handle 16bits and 32bit io ports. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/