Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1951535AbdDYQYa (ORCPT ); Tue, 25 Apr 2017 12:24:30 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:44486 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S980644AbdDYQYW (ORCPT ); Tue, 25 Apr 2017 12:24:22 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 56346600B9 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: Lukas Wunner Cc: ACPI Devel Maling List , Timur Tabi , "Rafael J. Wysocki" , Len Brown , Linux Kernel Mailing List References: <1492813704-32280-1-git-send-email-okaya@codeaurora.org> <3f0f2853-d2e5-be32-2bde-47e72c51a0a6@codeaurora.org> <20170425070154.GC9999@wunner.de> From: Sinan Kaya Message-ID: <3f2c5bcc-3499-d5ef-6955-778979d25b08@codeaurora.org> Date: Tue, 25 Apr 2017 12:24:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170425070154.GC9999@wunner.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3022 Lines: 81 On 4/25/2017 3:01 AM, Lukas Wunner 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. > > Would it be possible to solve this by just returning -EPROBE_DEFER from the > ->probe hook if the devices you depend on are not bound yet? > I'm not sure. > Alternatively, would it be possible to solve it with a struct device_link? I wasn't aware of device_link concept. This is something that I will keep in my mind when I'm dealing with producer/consumer problems with known device driver instances. It looked very useful. Here is how the overall relationship between drivers. | GED | <---> | Platform specific ACPI AML | <----> Vendor GPIO <----> Vendor I2C <----> ACPI GHES <----> Some other driver The problem with Generic Event Device (GED) is that it produces event notification facility to the platform specific AML code and GED doesn't have any idea about the consumers of these interrupts or what platform AML does. GED only sees the interrupts that it needs to register and knows the ASL code it needs to execute when that interrupt happens. It is possible for AML code not to use any of these drivers or require some arbitrary driver as well as vendor specific drivers. It is totally up to the firmware to decide what to do with this event. My proposal was to require platform AML code to indicate the dependencies between GED and drivers on the right side of the picture via _DEP as this cannot be done via normal kernel mechanisms. This approach might work in general. However, it also has its own caveats. All of these drivers on the right side are unrelated to each other. Some operating system can implement a subset of these drivers. If I include the dependencies, GED will never load for partial driver situations. This is also a deal breaker. Why would you break some other feature if your OS doesn't support RAS as an example? Given all these lose bindings and no driver association, where do we go from here? I consider GED as a light version of Embedded controller (EC) implementation. How is this problem solved for EC as it has the same problem? > > Thanks, > > Lukas > -- 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.