Date: Tue, 24 May 2005 18:58:56 +0400
From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
To: Andi Kleen <ak@suse.de>
Cc: Rajesh Shah <rajesh.shah@intel.com>, len.brown@intel.com, akpm@osdl.org,
       linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
       acpi-devel@lists.sourceforge.net
Subject: Re: [patch 2/2] x86_64: Collect host bridge resources
Message-ID: <20050524185856.A7639@jurassic.park.msu.ru>
References: <20050521004239.581618000@csdlinux-1> <20050521004506.842235000@csdlinux-1> <20050523161507.GN16164@wotan.suse.de> <20050523175706.A12032@unix-os.sc.intel.com> <20050524120527.GB15326@wotan.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20050524120527.GB15326@wotan.suse.de>; from ak@suse.de on Tue, May 24, 2005 at 02:05:27PM +0200
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 896
Lines: 22

On Tue, May 24, 2005 at 02:05:27PM +0200, Andi Kleen wrote:
> How about you allocate an extended structure with kmalloc in this case?

This would lead to quite a few changes in the PCI subsystem.
Looks good as a long-term solution though.

> Or if it is only 6 ranges max (it is not, is it?) you could extend
> the array.
> 
> I doubt this information will need *that* much memory, so it should
> be reasonable to just teach the PCI subsystem about it.

Agreed. As a bonus, extending the PCI_BUS_NUM_RESOURCES to 6 would
cleanly resolve problems with "transparent" PCI bridges - the bus
might have 3 "native" + 3 parent bus ranges in that case.

Ivan.
-
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/