Re: [patch 2/2] x86_64: Collect host bridge resources

[Rajesh Shah <rajesh.shah@intel.com>]

On Mon, May 23, 2005 at 06:15:07PM +0200, Andi Kleen wrote:
> On Fri, May 20, 2005 at 05:42:41PM -0700, rajesh.shah@intel.com wrote:
> > This patch reads and stores host bridge resources reported by
> > ACPI BIOS for x86_64 systems. This is needed since ACPI hotplug
> > code now uses the PCI core for resource management. This patch
> > simply adds the boot parameter (acpi=root_resources) to enable
> > the functionality that is implemented in arch/i386.
> > 
> 
> This means all hot plug users have to pass this strange parameter?
> That does not sound very user friendly. Especially since you usually
> only need pci hotplug in emergencies, and then you likely didnt pass it.
> 
> Cant you find a way to do this without parameters? Any reason
> to not make it default?
> 
I found several systems in which the host bridge was decoding 6+
resource ranges. In the pci_bus structure, I only have room for 4,
so I'm forced to drop some ranges that are in fact being passed
down. For such cases, if I enable this by default, I see boot time
failures for devices that attempted to claim these dropped resources.
These devices were otherwise properly configured by BIOS, and work
fine with today's (incorrect) assumption that all host bridges
decode all unclaimed resources. I didn't want the patch to break
existing systems, hence the boot parameter.

Another option I'd thought of but never really pursued was to
implement this as a late_initcall. I'll look into that some more.
In that case, we'd continue to think that all host bridges decode
all unclaimed resources at boot time and depend on BIOS to program
resources for boot time devices correctly. Later, we'd collect the
more accurate host bridge resource picture to make hotplug work
correctly. Kind of hackish, but I can't think of another way to
avoid the boot parameter.

Rajesh

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