Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp109157pxu; Tue, 1 Dec 2020 07:14:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJyO+68gjslgP3sOsXfmw88p3bvTuUgRmgH1nfNM8HQbXoisE7wfYiYsDxbEsalXM+JKQNLn X-Received: by 2002:a50:d6c6:: with SMTP id l6mr3532314edj.80.1606835666463; Tue, 01 Dec 2020 07:14:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606835666; cv=none; d=google.com; s=arc-20160816; b=Ema6NMKuK3Ha8w0SbXzNgTNXhykFMaIL5u8QE9Fcqm60nKbKNIMen+bNbAZVzLTZ5M x2CY2VDStx+T+PTvXiQ2JLEkqIWdBcMX5tQi9zgV54uAy3oLRliwviulhmKYewha3Q0e tdHzMi5eVwBHUaDeBcnonHlfNm8ZOOtq9KKtXcJjfa7BqsYUi0G5QDB2dq2/eUpPKpIG neZqQd8VJ8OFGpzuurNn6FfKGAUDko3cFu2Ar4NxtP2MGWOVWcSoD+g3VPTkkI6EdZCv D+MDfDMfEDJ8mvpQvEUp1+gZIK5HEd+11OHiOFOOZKKf8ut4Y0CwQzHhxzBo+xxqHilH cmFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=gMD6EM22ji/S3xwFj1BN7dzC7cA/UOc+xNliQ94beC0=; b=sZFCzNwu/BFbTnqedYIw/E/5+HJVFrbzV9DfXn0uubQJqOzbvhRQtRHW6+HbHMuocu 6DtwzwnjGyazmBxZkMAh06+/4KTCgWC2OcWbb931MeCRUOuIDxuOap04+OnaU7nf/I77 d3Z8jOIA2HTotQT+x4YyFh71XBQ3a661NJIVj+YA/UzFEjqm+1A0T0xTF6c0alH4Ur7z 1Uomu2eO19gRJYwTDrgqHNiXsliFqAO+DEeTGtZsu3cyRxw9ZRx5zU8dGHIVr3xpr5jE pqREIBzNRScoBRfZIcvJmmIts9XjgN6cwx++o9dTJ/CrL9slUt0OLEQzJprAwbFlHY9P ZQZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q19si75318ejt.514.2020.12.01.07.13.55; Tue, 01 Dec 2020 07:14:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390196AbgLAPLD (ORCPT + 99 others); Tue, 1 Dec 2020 10:11:03 -0500 Received: from mga09.intel.com ([134.134.136.24]:2314 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387678AbgLAPLD (ORCPT ); Tue, 1 Dec 2020 10:11:03 -0500 IronPort-SDR: cyCZegX4Q8P86CgvrjL5zo32f7NZ3c8PQjfyd0lbKC7vuRwgG0gT8Hh/poc1djlcXctK4iDF2N Kbu2Nr9VXZVg== X-IronPort-AV: E=McAfee;i="6000,8403,9822"; a="172999501" X-IronPort-AV: E=Sophos;i="5.78,384,1599548400"; d="scan'208";a="172999501" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2020 07:09:19 -0800 IronPort-SDR: RlyogqPQm/v07Bl/w7DaKQ+1EqQ55TIIGsAcJsPsGxpr8ZpFsm/ANdOg3KbkaZAy/vlY2lXXiU f/Wnrtqn3eyw== X-IronPort-AV: E=Sophos;i="5.78,384,1599548400"; d="scan'208";a="345492105" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2020 07:09:12 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1kk7IC-00BIQf-5v; Tue, 01 Dec 2020 17:10:12 +0200 Date: Tue, 1 Dec 2020 17:10:12 +0200 From: Andy Shevchenko To: Dan Scally Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org, linux-media@vger.kernel.org, devel@acpica.org, rjw@rjwysocki.net, lenb@kernel.org, gregkh@linuxfoundation.org, mika.westerberg@linux.intel.com, linus.walleij@linaro.org, bgolaszewski@baylibre.com, wsa@kernel.org, yong.zhi@intel.com, sakari.ailus@linux.intel.com, bingbu.cao@intel.com, tian.shu.qiu@intel.com, mchehab@kernel.org, robert.moore@intel.com, erik.kaneda@intel.com, pmladek@suse.com, rostedt@goodmis.org, sergey.senozhatsky@gmail.com, linux@rasmusvillemoes.dk, kieran.bingham+renesas@ideasonboard.com, jacopo+renesas@jmondi.org, laurent.pinchart+renesas@ideasonboard.com, jorhand@linux.microsoft.com, kitakar@gmail.com, heikki.krogerus@linux.intel.com Subject: Re: [PATCH 14/18] acpi: utils: Add function to fetch dependent acpi_devices Message-ID: <20201201151012.GG4077@smile.fi.intel.com> References: <20201130133129.1024662-1-djrscally@gmail.com> <20201130133129.1024662-15-djrscally@gmail.com> <20201130182354.GW4077@smile.fi.intel.com> <26d7fa3f-3552-90e0-1f64-5c39449dcdd7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26d7fa3f-3552-90e0-1f64-5c39449dcdd7@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 30, 2020 at 11:54:44PM +0000, Dan Scally wrote: > Hi Andy > > On 30/11/2020 18:23, Andy Shevchenko wrote: > > On Mon, Nov 30, 2020 at 01:31:25PM +0000, Daniel Scally wrote: > >> ACPI devices declare themselves dependent on other devices via the _DEP > >> buffer. Fetching the dependee from dependent is a matter of parsing > >> _DEP, but currently there's no method to fetch dependent from dependee. > >> Add one, so we can parse sensors dependent on a PMIC from the PMIC's > >> acpi_driver. > > Do I understand correctly that it's an existing table provided by firmware that > > (ab)uses _DEP in such way? Note, the specification doesn't tell we may use it > > in this way, OTOH I don't remember if it strictly forbids such use. > > > > So, please elaborate in the commit message why you need this and pint out to > > the 6.5.8 "_DEP (Operation Region Dependencies)" which clearly says about > > OpRegions and that part already supported by ACPI in the Linux, if I'm not > > mistaken, need to refresh my memory. > > > Laurent's reply is good explanation, but for example see my Lenovo Miix > 510's DSDT: > > > https://gist.githubusercontent.com/djrscally/e64d112180517352fa3392878b0f4a7d/raw/88b90b3ea4204fd7845257b6666fdade47cc2981/dsdt.dsl > > > Search OVTI2680 and OVTI5648 for the cameras. Both are dependent on > IN3472 devices (PMI0 and PMI1) which are the discrete type that we're > attempting to handle here. Yes, it seems since PMIC is kinda "power resource" (don't mix with real power resource as by ACPI specifications) and that's why they decided to include it into _DEP. So, it seems a de facto common practice. Thus, it would be nice to have the above in the commit message in some form. Can you do it? -- With Best Regards, Andy Shevchenko