Hi Rafael, On 4/24/2017 7:01 PM, Rafael J. Wysocki wrote: > On Sat, Apr 22, 2017 at 12:48 AM, Sinan Kaya <okaya@xxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx > 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. -- 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