Hi Rafael,
On 4/24/2017 7:01 PM, Rafael J. Wysocki wrote:
> On Sat, Apr 22, 2017 at 12:48 AM, Sinan Kaya <[email protected]> wrote:
>> On 4/21/2017 6:43 PM, Rafael J. Wysocki wrote:
>>>> +late_initcall(ged_init);
>>> Does this fix the problem?
>>>
>>> What about if the module in question is loaded after running late_initcalls?
>>
>> This fixed the issue for me where I had dependencies for QUP I2C driver and
>> GHES
>> drivers. Both of them are modules and get probed via normal module execution
>> path.
>>
>> However, I'm open to improvements. Do you have a better suggestion? I can
>> try
>> to add some _DEP stuff if it is present, but I remember Linux doesn't like
>> _DEP
>> stuff too much.
>
> My point is that nothing guarantees a specific ordering or timing of
> module loading in general, so moving stuff to different initcall
> levels does not really help 100% of the time.
>
I was thinking about this today. I agree that this is not a complete solution.
I'm interested in drivers that are either built-in or present in the initramfs.
Drivers that participate in GED work are considered essential drivers. I expect
these essential drivers to be present in early boot phase.
I can certainly improve the commit message.
As long as the drivers are built-in or available in initramfs, I expect this to
work.
I want to focus on this use case.
static char *initcall_level_names[] __initdata = {
"early",
"core",
"postcore",
"arch",
"subsys",
"fs",
"device",
"late",
};
static void __init do_initcall_level(int level)
{
...
for (fn = initcall_levels[level]; fn < initcall_levels[level+1]; fn++)
do_one_initcall(*fn);
}
Given these constraints, doesn't this guarantee the order of initialization for
built-in and
initramfs modules?
Of course, this won't also play nice with another driver module that requires
late_init.
Maybe, this is 1% of the case.
If the driver gets pulled in from the rootfs via modules.conf, then this will
definitely
not work as you indicated.
My proposal is to explore the presence of _DEP to reach to %100. Here is an
example
GED OBJECT
{
Name(_DEP, "Some other object")
}
I see that ACPI core checks the presence of _DEP value in
acpi_device_dep_initialize()
and it won't load the GED driver until dependencies are met if I got it right.
acpi_walk_dep_device_list() gets called from external drivers that need to
unblock
the dependent object. acpi_gpiochip_add() seems to take care of this for GPIO.
i2c_acpi_install_space_handler() seems to take care of this for I2C.
We can potentially add acpi_walk_dep_device_list() to GHES driver for
completeness.
Then, all FW needs to do is set up a dependency from GED object to its required
objects.
Please let me know if I'm missing something.
> Thanks,
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
