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=-9.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 CA091C43381 for ; Mon, 8 Mar 2021 13:37:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9C08F65204 for ; Mon, 8 Mar 2021 13:37:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229701AbhCHNhO (ORCPT ); Mon, 8 Mar 2021 08:37:14 -0500 Received: from mail-ot1-f41.google.com ([209.85.210.41]:38646 "EHLO mail-ot1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230075AbhCHNgn (ORCPT ); Mon, 8 Mar 2021 08:36:43 -0500 Received: by mail-ot1-f41.google.com with SMTP id a17so9177466oto.5; Mon, 08 Mar 2021 05:36:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3SC+dThWdkkdkAOzaSbWtrlTJ9uPyl9VXsnQJro4+zQ=; b=Z9POlgOuy793D5BTuqYmhgpFlOHnU98IJxVI8ua8ZoyLjF66pFS4goo6Ue55mTB5ki 4OZMjUeg1jnvFGMNMyKzu6afF4c1p3Gw+u5Q3MOddDWB9X7JOw2ltKe9PRKwLBL9odiv y73xIUt2ZBWk3OuzLxSZ+mn0S/1o+1GQIzN8FHiSb9RifbdWl7VJtn+hL9IhNFlWaC9+ /5Fqdwh6JNAqWWyI53tfh5tG/rxKYURwCznBfhunDDM4XDDLI/F8JnEwHWo/oMzU8N4X pFc3IyTgJHEiFAsOSM934at6bodX0dthqz6kWup1BFfMZD3xBPx0pJVTd57S28HZ1Aqw NIRA== X-Gm-Message-State: AOAM532rgzPr7QDsiIvk69OSdQommAsE42WW48bPTH+QF2aal4aVatqB BsWWRX9JBENuoHx7LQhdT7ypultRc6OmgvsQTd4= X-Google-Smtp-Source: ABdhPJyy6ZpakLDXyR3Oyk57jV9FGupiJLAQnH75QbMy9JuTsZHE14IlWkvw4HT+2ZoGrY9c8JoAUD0rFxSpfGAfb7Q= X-Received: by 2002:a05:6830:1e03:: with SMTP id s3mr9299001otr.321.1615210602629; Mon, 08 Mar 2021 05:36:42 -0800 (PST) MIME-Version: 1.0 References: <20210222130735.1313443-1-djrscally@gmail.com> <20210222130735.1313443-2-djrscally@gmail.com> <615bad5e-6e68-43c9-dd0b-f26d2832d52f@gmail.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Mon, 8 Mar 2021 14:36:27 +0100 Message-ID: Subject: Re: [PATCH v3 1/6] ACPI: scan: Extend acpi_walk_dep_device_list() To: Andy Shevchenko , Daniel Scally Cc: Andy Shevchenko , 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)" , "Rafael J . Wysocki" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org 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 > > > > > > Thank you! > > > > > > >> + */ > > >> +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.