Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756019Ab2B0WpH (ORCPT ); Mon, 27 Feb 2012 17:45:07 -0500 Received: from mail-we0-f174.google.com ([74.125.82.174]:44226 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755021Ab2B0WpD convert rfc822-to-8bit (ORCPT ); Mon, 27 Feb 2012 17:45:03 -0500 Authentication-Results: mr.google.com; spf=pass (google.com: domain of bhelgaas@google.com designates 10.216.139.165 as permitted sender) smtp.mail=bhelgaas@google.com; dkim=pass header.i=bhelgaas@google.com MIME-Version: 1.0 In-Reply-To: References: <1328425088-6562-1-git-send-email-yinghai@kernel.org> <1328425088-6562-10-git-send-email-yinghai@kernel.org> <1328738567.2903.45.camel@pasglop> <1328823358.2903.77.camel@pasglop> <20120223122536.6a2a7a6b@jbarnes-desktop> <20120224142430.58f5e5ef@jbarnes-desktop> From: Bjorn Helgaas Date: Mon, 27 Feb 2012 15:44:42 -0700 Message-ID: Subject: Re: [PATCH 09/24] PCI, powerpc: Register busn_res for root buses To: Yinghai Lu Cc: Jesse Barnes , Benjamin Herrenschmidt , Tony Luck , Dominik Brodowski , Andrew Morton , Linus Torvalds , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Paul Mackerras , linuxppc-dev@lists.ozlabs.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: 2886 Lines: 67 On Sat, Feb 25, 2012 at 12:47 AM, Yinghai Lu wrote: > On Fri, Feb 24, 2012 at 2:24 PM, Jesse Barnes wrote: >> On Thu, 23 Feb 2012 12:51:30 -0800 >> Bjorn Helgaas wrote: >>> 2) We already have a way to add resources to a root bus: the >>> pci_add_resource() used to add I/O port and MMIO apertures. ?I think >>> it'd be a lot simpler to just use that same interface for the bus >>> number aperture, e.g., >>> >>> ? ? pci_add_resource(&resources, hose->io_space); >>> ? ? pci_add_resource(&resources, hose->mem_space); >>> ? ? pci_add_resource(&resources, hose->busnr_space); >>> ? ? bus = pci_scan_root_bus(dev, next_busno, pci_ops, sysdata, &resources); >>> >>> This is actually a bit redundant, since "next_busno" should be the >>> same as hose->busnr_space->start. ?So if we adopted this approach, we >>> might want to eventually drop the "next_busno" argument. >> >> Yeah that would be nice, the call would certainly make more sense that >> way. > > no, I don't think so. > > using pci_add_resource will need to create dummy resource abut bus range. I don't see the problem here. The bus number aperture is a fundamental property of a host bridge, and any firmware or native bridge driver that tells you about a bridge but doesn't tell you the bus number aperture is just broken. Every arch already has struct resources for the MMIO and IO port regions available on the bus. ACPI already has a resource for the bus number range. It makes sense to me that the arch should supply a bus number resource. Conceptually, it's just like the MMIO and IO resources, so it makes sense to me that the code for bus numbers should look like the code for MMIO and IO ports. > there is lots of pci_scan_root_bus(), ?and those user does not bus end > yet before scan. > so could just hide pci_insert_busn_res in pci_scan_root_bus, and > update busn_res end there. pci_scan_child_bus() does NOT tell you the end of the bus number aperture, and we shouldn't pretend that it does. It might give you a lower bound on the end of the aperture (as long as you're willing to trust the current PCI config and you don't change anything). > other arch like x86, ia64, powerpc, sparc, will insert exact bus range > between pci_create_root_bus and > pci_scan_child_bus, will not need to update busn_res end. > > please check v7 of this patchset. > > ? ? ? ?git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-pci-busn-alloc I looked at your git tree, but I can't tell whether what's there is v7 or not and it's too much trouble to try to figure it out. Bjorn -- 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/