Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932570Ab2BJXkz (ORCPT ); Fri, 10 Feb 2012 18:40:55 -0500 Received: from mail-yx0-f174.google.com ([209.85.213.174]:42624 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754665Ab2BJXky convert rfc822-to-8bit (ORCPT ); Fri, 10 Feb 2012 18:40:54 -0500 MIME-Version: 1.0 In-Reply-To: <20120210125150.3353237c@jbarnes-desktop> References: <1328425088-6562-1-git-send-email-yinghai@kernel.org> <1328425088-6562-2-git-send-email-yinghai@kernel.org> <20120210125150.3353237c@jbarnes-desktop> Date: Fri, 10 Feb 2012 15:40:53 -0800 X-Google-Sender-Auth: iwkLtEfqRmPf2qI30xg0axcb790 Message-ID: Subject: Re: [PATCH 01/24] PCI: Add iobusn_resource From: Yinghai Lu To: Jesse Barnes Cc: Bjorn Helgaas , Benjamin Herrenschmidt , Tony Luck , Dominik Brodowski , Andrew Morton , Linus Torvalds , Greg Kroah-Hartman , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@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: 2404 Lines: 55 On Fri, Feb 10, 2012 at 12:51 PM, Jesse Barnes wrote: > On Mon, 6 Feb 2012 10:55:14 -0800 > Yinghai Lu wrote: > >> On Mon, Feb 6, 2012 at 10:48 AM, Bjorn Helgaas wrote: >> >> +struct resource iobusn_resource = { >> >> + ? ? ? .name ? = "PCI busn", >> >> + ? ? ? .start ?= 0, >> >> + ? ? ? .end ? ?= 0xffffff, >> >> + ? ? ? .flags ?= IORESOURCE_BUS, >> >> +}; >> > >> > I'm not sure this should be global. ?iomem_resource and >> > ioport_resource *are* really global, because they refer to processor >> > address space that is the same for everybody. ?But PCI bus numbers are >> > specific to PCI. ?Some machines don't have PCI at all, and there are >> > different bus architectures to which this doesn't apply. >> >> that does not hurt them. > > Yes but it's superfluous and confusing if you're porting to a new arch > or looking at changes in generic code that may affect you. > >> > The 0-0xffffff range is misleading because it includes both the domain >> > and the bus number, and it's meaningless to allocate ranges that cross >> > domain boundaries. ?For example, [bus 0x0000f0-0x000120] includes bus >> > numbers from domain 0000 and domain 0001, which doesn't make any sense >> > because a bus can only be in one domain. >> >> allocation code will make sure it will be cross the boundary for domain. > > But that means everyone reading it will do a double take, have to dig > into the implementation, and only then say "ah yeah ok it looks > correct" rather than it being obvious from the fact that the resource > is tracked on a per-domain basis. > >> > I think it would make more sense to keep this bus number resource in a >> > per-host bridge structure. ?Then we wouldn't need to include the >> > domain number at all because the host bridge determines the domain. >> >> not sure. insert the all busn_res of all peer root buses into one >> global iobusn_resource >> looks more simple. > > In what sense? ?Simpler in the sense of your current implementation, > but not simpler at all to someone just reading the code... ok, will check if i could drop iobusn_resource. 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/