On Wednesday 25 March 2009 01:29:33 pm Yinghai Lu wrote:
> Bjorn Helgaas wrote:
> > If I understand you correctly, you're raising a style issue, and
> > there's no functional problem either way. Right?
>
> besides that, some last_calls are merged to direct call.
> wonder if those calling could depend on pci_acpi_init etc.
Can you be specific? I can't do much with vague wondering.
I changed the following initcalls from subsys_initcall to direct calls:
ACPI: call acpi_scan_init() explicitly rather than as initcall
ACPI: call acpi_ec_init() explicitly rather than as initcall
ACPI: call acpi_power_init() explicitly rather than as initcall
ACPI: call acpi_system_init() explicitly rather than as initcall
ACPI: call acpi_debug_init() explicitly rather than as initcall
pci_acpi_init() is called from pci_subsys_init(), which is also a
subsys_initcall, but it's in arch/x86.
In the current tree (before my patches) all the ACPI subsys_initcalls
are done before any of the arch/x86 subsys_initcalls. So changing the
ACPI subsys_initcalls to direct calls should not change the order with
respect to pci_acpi_init().
This one changed from an arch_initcall to a direct call:
ACPI: call init_acpi_device_notify() explicitly rather than as initcall
In that case, init_acpi_device_notify() happens before pci_acpi_init()
whether it's an arch_initcall or a direct call. So this shouldn't be
a problem either.
These two changed from late_initcalls to direct calls:
ACPI: call acpi_sleep_proc_init() explicitly rather than as initcall
ACPI: call acpi_wakeup_device_init() explicitly rather than as initcall
These two did change order with respect to pci_acpi_init(). As
late_initcalls, they happened after pci_acpi_init(). As direct calls,
they happen before pci_acpi_init().
However, I do not see any dependency of either one on pci_acpi_init(),
so I don't think it makes any difference. Do you?
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
