Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033985AbdD1CcT (ORCPT ); Thu, 27 Apr 2017 22:32:19 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:47672 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935593AbdD1CcL (ORCPT ); Thu, 27 Apr 2017 22:32:11 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 18FB4611F1 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> <3f2c5bcc-3499-d5ef-6955-778979d25b08@codeaurora.org> From: Sinan Kaya Message-ID: <5c77c025-e3a4-f317-e7bc-f76e19ed2b12@codeaurora.org> Date: Thu, 27 Apr 2017 22:32:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <3f2c5bcc-3499-d5ef-6955-778979d25b08@codeaurora.org> 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: 3567 Lines: 88 On 4/25/2017 12:24 PM, Sinan Kaya wrote: > 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? > This recommendation came from Timur. I wanted to see how everybody feels about it. When GED driver makes an AML call and the driver on the right side of the picture is not present, GED driver gets an ACPI error return code. GED driver can potentially reschedule the AML call to be retried in 30 seconds. Repeat this 5 times. If nobody handles the event, disable the interrupt. Let me know what you think. -- 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.