From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 150DEC433E0 for ; Mon, 8 Mar 2021 13:58:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CCDE9651DE for ; Mon, 8 Mar 2021 13:58:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231129AbhCHN5q (ORCPT ); Mon, 8 Mar 2021 08:57:46 -0500 Received: from mga02.intel.com ([134.134.136.20]:1940 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231355AbhCHN5O (ORCPT ); Mon, 8 Mar 2021 08:57:14 -0500 IronPort-SDR: Pwa/bL1bAo5fWRjaH9h1H2mveQFO8NwGxsf/CiKZXJxxHz8gfjOqDLKqZJOybkecKvf6YhRqVP ILcSlFOqQCjg== X-IronPort-AV: E=McAfee;i="6000,8403,9916"; a="175140516" X-IronPort-AV: E=Sophos;i="5.81,232,1610438400"; d="scan'208";a="175140516" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2021 05:57:13 -0800 IronPort-SDR: y7vlO1ZA2ifHMhH+r9TWzkrV9NvFjAt1sBk3WHBE5e1lqHdlk6qXWckWfrSUFCrRF3XTbMxTIE N5f/lPC1De+Q== X-IronPort-AV: E=Sophos;i="5.81,232,1610438400"; d="scan'208";a="437486815" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2021 05:57:07 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lJGNc-00ApWj-AU; Mon, 08 Mar 2021 15:57:04 +0200 Date: Mon, 8 Mar 2021 15:57:04 +0200 From: Andy Shevchenko To: "Rafael J. Wysocki" Cc: Daniel Scally , Tomasz Figa , Sakari Ailus , Rajmohan Mani , "Rafael J. Wysocki" , Len Brown , Mika Westerberg , Linus Walleij , Bartosz Golaszewski , Wolfram Sang , Lee Jones , Kieran Bingham , Laurent Pinchart , Hans de Goede , Mark Gross , Maximilian Luz , Robert Moore , Erik Kaneda , me@fabwu.ch, Linux Kernel Mailing List , ACPI Devel Maling List , "open list:GPIO SUBSYSTEM" , linux-i2c , Platform Driver , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" Subject: Re: [PATCH v3 1/6] ACPI: scan: Extend acpi_walk_dep_device_list() Message-ID: References: <20210222130735.1313443-1-djrscally@gmail.com> <20210222130735.1313443-2-djrscally@gmail.com> <615bad5e-6e68-43c9-dd0b-f26d2832d52f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, Mar 08, 2021 at 02:36:27PM +0100, Rafael J. Wysocki wrote: > On Sun, Mar 7, 2021 at 9:39 PM Andy Shevchenko > wrote: > > On Sun, Mar 7, 2021 at 3:36 PM Daniel Scally wrote: > > > On 22/02/2021 13:34, Andy Shevchenko wrote: > > > > On Mon, Feb 22, 2021 at 3:12 PM Daniel Scally wrote: > > > >> The acpi_walk_dep_device_list() is not as generalisable as its name > > > >> implies, serving only to decrement the dependency count for each > > > >> dependent device of the input. Extend the function to instead accept > > > >> a callback which can be applied to all the dependencies in acpi_dep_list. > > > >> Replace all existing calls to the function with calls to a wrapper, passing > > > >> a callback that applies the same dependency reduction. > > > > The code looks okay to me, if it was the initial idea, feel free to add > > > > Reviewed-by: Andy Shevchenko ... > > > >> +void acpi_dev_flag_dependency_met(acpi_handle handle) > > > > Since it's acpi_dev_* namespace, perhaps it should take struct acpi_device here? > > > > > > I can do this, but I avoided it because in most of the uses in the > > > kernel currently there's no struct acpi_device, they're just passing > > > ACPI_HANDLE(dev) instead, so I'd need to get the adev with > > > ACPI_COMPANION() in each place. It didn't seem worth it... > > It may not even be possible sometimes, because that function may be > called before creating all of the struct acpi_device objects (like in > the case of deferred enumeration). > > > > but happy to > > > do it if you'd prefer it that way? > > > > I see, let Rafael decide then. I'm not pushing here. > > Well, it's a matter of correctness. Looking at your above comment it is indeed. Thanks for clarification! But should we have acpi_dev_*() namespace for this function if it takes handle? For time being nothing better than following comes to my mind: __acpi_dev_flag_dependency_met() => __acpi_flag_device_dependency_met() acpi_dev_flag_dependency_met() => acpi_flag_device_dependency_met() -- With Best Regards, Andy Shevchenko From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7009613193008573363==" MIME-Version: 1.0 From: Andy Shevchenko Subject: [Devel] Re: [PATCH v3 1/6] ACPI: scan: Extend acpi_walk_dep_device_list() Date: Mon, 08 Mar 2021 15:57:04 +0200 Message-ID: In-Reply-To: CAJZ5v0ijOhT3PVm6-gqnqycE-YZhD00dGbtK1UEV5nfrOF5Obw@mail.gmail.com List-ID: To: devel@acpica.org --===============7009613193008573363== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Mar 08, 2021 at 02:36:27PM +0100, Rafael J. Wysocki wrote: > On Sun, Mar 7, 2021 at 9:39 PM Andy Shevchenko > wrote: > > On Sun, Mar 7, 2021 at 3:36 PM Daniel Scally wr= ote: > > > On 22/02/2021 13:34, Andy Shevchenko wrote: > > > > On Mon, Feb 22, 2021 at 3:12 PM Daniel Scally wrote: > > > >> The acpi_walk_dep_device_list() is not as generalisable as its name > > > >> implies, serving only to decrement the dependency count for each > > > >> dependent device of the input. Extend the function to instead acce= pt > > > >> a callback which can be applied to all the dependencies in acpi_de= p_list. > > > >> Replace all existing calls to the function with calls to a wrapper= , passing > > > >> a callback that applies the same dependency reduction. > > > > The code looks okay to me, if it was the initial idea, feel free to= add > > > > Reviewed-by: Andy Shevchenko ... > > > >> +void acpi_dev_flag_dependency_met(acpi_handle handle) > > > > Since it's acpi_dev_* namespace, perhaps it should take struct acpi= _device here? > > > > > > I can do this, but I avoided it because in most of the uses in the > > > kernel currently there's no struct acpi_device, they're just passing > > > ACPI_HANDLE(dev) instead, so I'd need to get the adev with > > > ACPI_COMPANION() in each place. It didn't seem worth it... > = > It may not even be possible sometimes, because that function may be > called before creating all of the struct acpi_device objects (like in > the case of deferred enumeration). > = > > > but happy to > > > do it if you'd prefer it that way? > > > > I see, let Rafael decide then. I'm not pushing here. > = > Well, it's a matter of correctness. Looking at your above comment it is indeed. Thanks for clarification! But should we have acpi_dev_*() namespace for this function if it takes han= dle? For time being nothing better than following comes to my mind: __acpi_dev_flag_dependency_met() =3D> __acpi_flag_device_dependency_met() acpi_dev_flag_dependency_met() =3D> acpi_flag_device_dependency_met() -- = With Best Regards, Andy Shevchenko --===============7009613193008573363==--