]> git.hungrycats.org Git - linux/commit
[PATCH] PCI: Reorder some initialization code to allow resources to be proper allocated.
authorLi Shaohua <shaohua.li@intel.com>
Wed, 6 Oct 2004 04:50:52 +0000 (21:50 -0700)
committerGreg Kroah-Hartman <greg@kroah.com>
Wed, 6 Oct 2004 04:50:52 +0000 (21:50 -0700)
commit8482ee7ef1f261d87c48e1363b56835d39b8dd2b
treedaee7cc423944dfe150ac820aac226bbac24fc51
parent6e3a09975dfe7d648f8099a7b1142430418f381f
[PATCH] PCI: Reorder some initialization code to allow resources to be proper allocated.

On Tuesday, August 31, 2004, Linus Torvalds wrote:
> That list per se obviously looks ok by me, although I'd worry that some
> other fs_initcall depends on the ACPI stuff having been run (ie while the
> abover ordering is great, I worry that some _other_ part doesn't fit in
> the above ordering). Doing a quick check finds "chr_dev_init()", for
> example, which will do fbmem_init(), which might depend on the ACPI/PnP
> stuff having run already.
>
> So it _might_ be safer to make this ordering more explicit, rather than

Yes, I agree. The problem is there isn't a straightforward method for
it. It possibly is hard to get it.

> depending on the different phases of the initcalls. But I'd happily be
> proven wrogn with some simple argument for why this is guaranteed to be
> ok.. For example, maybe ACPI and PnP is linked before chr/mem.c, in which
> case it should all be ok.

Original PCI assign resources code is the last 'subsys_initcall'
according to the makefile, so move some code of it to 'fs_initcall'
(just below 'subsystem_initcall') should be ok. As you said, ACPI and
PnP is linked before chr/mem.c. The method requires all other
'fs_initcall' don't touch PCI resources, since
'pcibios_assign_resources' is a 'fs_initcall' and maybe don't run, but
it looks ok currently. Again, I will be appreciated if we can find a
solution to make the ordering explicit.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
arch/i386/pci/i386.c
drivers/acpi/motherboard.c
drivers/pnp/system.c