Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752141Ab2E3Q2L (ORCPT ); Wed, 30 May 2012 12:28:11 -0400 Received: from mail-lpp01m010-f46.google.com ([209.85.215.46]:62553 "EHLO mail-lpp01m010-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751527Ab2E3Q2I convert rfc822-to-8bit (ORCPT ); Wed, 30 May 2012 12:28:08 -0400 MIME-Version: 1.0 In-Reply-To: <4FC5CEF1.6000509@snewbury.org.uk> References: <1337754877-19759-1-git-send-email-yinghai@kernel.org> <20120525043651.GA1391@google.com> <20120525193716.GA8817@google.com> <4FC50E09.4000204@zytor.com> <4FC5CEF1.6000509@snewbury.org.uk> From: Bjorn Helgaas Date: Wed, 30 May 2012 10:27:45 -0600 Message-ID: Subject: Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first To: Steven Newbury Cc: Yinghai Lu , "H. Peter Anvin" , Linus Torvalds , Andrew Morton , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2280 Lines: 55 On Wed, May 30, 2012 at 1:40 AM, Steven Newbury wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 30/05/12 00:27, Bjorn Helgaas wrote: >> On Tue, May 29, 2012 at 2:40 PM, Yinghai Lu >> wrote: >>> On Tue, May 29, 2012 at 12:23 PM, Bjorn Helgaas >>> wrote: >>>> On Tue, May 29, 2012 at 12:17 PM, Yinghai Lu >>>> wrote: >>>>> On Tue, May 29, 2012 at 10:57 AM, H. Peter Anvin >>>>> wrote: >>>>>> On 05/29/2012 10:55 AM, Yinghai Lu wrote: > > *SNIP* > >>> >>> >>> ok, please check the version, that put back PCI_MAX_RESOURCE_32 >>> for io ports. >>> >>> also RFC to limit for 16 bit ioport handling. ?only help other >>> arches that does support 32bit ioports but have bridges only >>> support 16bit io ports. >> >> I don't understand this one at all. ?It looks like you mashed >> together at least two changes: (1) prefer I/O space above 64K if >> available, and (2) mark secondary bus resources with >> IORESOURCE_IO_32 when the P2P bridge I/O window address decode type >> is PCI_IO_RANGE_TYPE_32 and use that to limit allocations. >> >> I don't see the justification for (1). ?What problem does this >> solve? >> > I can potentially see this helping with hotplug, where a new device > has only 16 bit io ports, but if there's no space remaining under 64k > allocation would fail. ?Preferring above 64k means preserving that > limited resource. ?This is exactly equivalent to my original > motivation for preferring 64 bit PCI mem in order to preserve 32 bit > address space for hotplug devices without 64 bit BARs. You're right, the spec does allow the upper 16 bits of I/O BARs to be hardwired to zero (PCI spec rev 3.0, p. 226), so this part does make some sense. I don't think it applies to x86, since I don't think there's a way to generate an I/O access to anything above 64K, but it could help other arches. I'm inclined to be conservative and wait until we find a problem where a patch like this would help. -- 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/