Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S979305AbdDXXdX (ORCPT ); Mon, 24 Apr 2017 19:33:23 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:41962 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S978746AbdDXXdO (ORCPT ); Mon, 24 Apr 2017 19:33:14 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org C49C261306 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH] ACPI / GED: use late init to allow other drivers init To: "Rafael J. Wysocki" References: <1492813704-32280-1-git-send-email-okaya@codeaurora.org> Cc: ACPI Devel Maling List , Timur Tabi , "Rafael J. Wysocki" , Len Brown , Linux Kernel Mailing List From: Sinan Kaya Message-ID: <3f0f2853-d2e5-be32-2bde-47e72c51a0a6@codeaurora.org> Date: Mon, 24 Apr 2017 19:33:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3270 Lines: 94 Hi Rafael, On 4/24/2017 7:01 PM, Rafael J. Wysocki wrote: > On Sat, Apr 22, 2017 at 12:48 AM, Sinan Kaya 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@vger.kernel.org > 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.