From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932784AbdEKNnT (ORCPT ); Thu, 11 May 2017 09:43:19 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:51070 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755723AbdEKNnQ (ORCPT ); Thu, 11 May 2017 09:43:16 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 05E4560798 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" Cc: Lukas Wunner , ACPI Devel Maling List , Timur Tabi , Len Brown , Linux Kernel Mailing List , "Abdulhamid, Harb" References: <1492813704-32280-1-git-send-email-okaya@codeaurora.org> <20170425070154.GC9999@wunner.de> <3f2c5bcc-3499-d5ef-6955-778979d25b08@codeaurora.org> <1874042.5bWzSJ73x0@aspire.rjw.lan> From: Sinan Kaya Message-ID: <0a368676-d01a-5ac8-179d-b6e7507fd500@codeaurora.org> Date: Thu, 11 May 2017 09:43:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <1874042.5bWzSJ73x0@aspire.rjw.lan> 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 Hi Rafael, On 5/10/2017 8:46 PM, Rafael J. Wysocki wrote: >> 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. > Something like _DEP would be needed. > > However, _DEP as specified is only about operation region dependencies, which > doesn't seem to be applicable here. > > That said, _DEP is used for general dependecies by firmware already, but it > would at least be good to send a proposal for a spec update regarding that > before mandating using _DEP for GED. OK. I'll reach out to Harb and let's see where the proposal goes. > >> 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. > _DEP doesn't mean a hard dependency AFAICS. It is about ordering, not about > presence, at least as specified currently. > >> 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. > No, it is not. Thanks for correction. Let me repeat with the correct terminology this time. Don't we have the same problem on GPE/SCI mechanism? An event that SCI is delivering may not be handled because the handler of the event is not present during OS boot? The SCI relationship would be: | SCI | <---> | Platform specific ACPI AML (_AEI) | <----> Vendor XYZ driver <----> Vendor I2C <----> ACPI GHES > > It is more of a generalization of the GPE/SCI mechanism in order to make it > possible to cover things different from GPIO (which already is covered by > _AEI). > >> How is this problem solved for EC as it has the same problem? > It doesn't. The EC relies on the GPE/SCI mechanism to be there and that is > always present. > > Thanks, > Rafael -- 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.