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=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,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 C9048C43461 for ; Thu, 20 May 2021 18:55:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9F8AD61279 for ; Thu, 20 May 2021 18:55:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232651AbhETS5D (ORCPT ); Thu, 20 May 2021 14:57:03 -0400 Received: from mail-ot1-f54.google.com ([209.85.210.54]:39698 "EHLO mail-ot1-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232552AbhETS5C (ORCPT ); Thu, 20 May 2021 14:57:02 -0400 Received: by mail-ot1-f54.google.com with SMTP id d25-20020a0568300459b02902f886f7dd43so15797952otc.6; Thu, 20 May 2021 11:55:25 -0700 (PDT) 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=4rhnX4Y+eZgYOMeyuWthaw1sadq3182LEXhMCXR+I6M=; b=Ox12Gt4p+9D9IeqnlOQzBVY3G+Z9rnqhAALu13dVJdmnO3p4bOHcYI+CRoOEK2rJsv kDMVNZHrTtdLoIRSR3aoFoGshwkrP4LXRdw/zceoZLf87d5/aCZB9fUL6DH93uqTtNeN 8V5IESWgbltXVpRal1e1vH1nJRk91qMu48rZaHvw2MnfdkSI8fHJDMgbpoeFmtX9EJCN mO8RxxU+LKQwwXUAsy/TAbabG0aRnmzuQ2zmdr2LviJ1BxjME9qthaiTwQyz+yUSnYXd j2GfMrWTCoKpJidny2vXnJzYmDhy608BonzSwxBzY2rQvNRzWlcKVJ0x2q9ZdxDzEslz fvQA== X-Gm-Message-State: AOAM530AnUCz5ZXBVtvif+yPa50qfkONAUpPoSGVU8ss0yIP2u3shdK8 R9cVROFQzPGA89UAVbuw3DZnO8q/0KvPfKY4rWg= X-Google-Smtp-Source: ABdhPJxv0ky80jFTVK8qLg50KX4XfRpIa0/2SCS8joVGuRdFlpjMA6BtV5bOxJTGoCZsnR1EqkSxRlQFmPk5Kra/dTM= X-Received: by 2002:a9d:5a7:: with SMTP id 36mr5059433otd.321.1621536925339; Thu, 20 May 2021 11:55:25 -0700 (PDT) MIME-Version: 1.0 References: <20210520140928.3252671-1-djrscally@gmail.com> <20210520140928.3252671-3-djrscally@gmail.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 20 May 2021 20:55:14 +0200 Message-ID: Subject: Re: [PATCH v4 2/8] ACPI: scan: Add function to fetch dependent of acpi device To: Daniel Scally Cc: "Rafael J . Wysocki" , Andy Shevchenko , Wolfram Sang , Lee Jones , Hans de Goede , Maximilian Luz , Linux Kernel Mailing List , ACPI Devel Maling List , Linux ARM , "open list:GPIO SUBSYSTEM" , linux-i2c , Platform Driver , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" , Len Brown , Mika Westerberg , Russell King , Linus Walleij , Bartosz Golaszewski , Mark Gross , Robert Moore , Erik Kaneda , Laurent Pinchart , Kieran Bingham , Andy Shevchenko Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Thu, May 20, 2021 at 8:33 PM Rafael J. Wysocki wrote: > > On Thu, May 20, 2021 at 4:11 PM Daniel Scally wrote: > > > > In some ACPI tables we encounter, devices use the _DEP method to assert > > a dependence on other ACPI devices as opposed to the OpRegions that the > > specification intends. We need to be able to find those devices "from" > > the dependee, so add a callback and a wrapper to walk over the > > acpi_dep_list and return the dependent ACPI device. > > > > Reviewed-by: Andy Shevchenko > > Signed-off-by: Daniel Scally > > --- > > Changes since v3: > > > > Both new functions were renamed. > > > > drivers/acpi/scan.c | 38 ++++++++++++++++++++++++++++++++++++++ > > include/acpi/acpi_bus.h | 1 + > > 2 files changed, 39 insertions(+) > > > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > > index 195635c3462b..1a76fbdfa669 100644 > > --- a/drivers/acpi/scan.c > > +++ b/drivers/acpi/scan.c > > @@ -2105,6 +2105,21 @@ static void acpi_bus_attach(struct acpi_device *device, bool first_pass) > > device->handler->hotplug.notify_online(device); > > } > > > > +static int acpi_return_dep_dev(struct acpi_dep_data *dep, void *data) > > What about calling this acpi_get_first_consumer_cb()? Or acpi_dev_get_first_consumer_dev_cb() if you want to be super-precise? > > > +{ > > + struct acpi_device *adev; > > + int ret; > > + > > + ret = acpi_bus_get_device(dep->consumer, &adev); > > + if (ret) > > + /* If we don't find an adev then we want to continue parsing */ > > + return 0; > > + > > + *(struct acpi_device **)data = adev; > > And it can do the get_device() here, can't it? > > So maybe use acpi_bus_get_acpi_device() instead of > acpi_bus_get_device()? Would be simpler. > > > + > > + return 1; > > +} > > + > > static int acpi_scan_clear_dep(struct acpi_dep_data *dep, void *data) > > { > > struct acpi_device *adev; > > @@ -2168,6 +2183,29 @@ void acpi_dev_clear_dependencies(struct acpi_device *supplier) > > } > > EXPORT_SYMBOL_GPL(acpi_dev_clear_dependencies); > > > > +/** > > + * acpi_dev_get_dependent_dev - Return ACPI device dependent on @supplier > > And what about calling this acpi_get_first_consumer() ? Or acpi_dev_get_first_consumer_dev() (in analogy with the above)? > > + * @supplier: Pointer to the dependee device > > + * > > + * Returns the first &struct acpi_device which declares itself dependent on > > + * @supplier via the _DEP buffer, parsed from the acpi_dep_list. > > + * > > + * The caller is responsible for putting the reference to adev when it is no > > + * longer needed. > > + */ > > +struct acpi_device *acpi_dev_get_dependent_dev(struct acpi_device *supplier) > > +{ > > + struct acpi_device *adev = NULL; > > + > > + acpi_walk_dep_device_list(supplier->handle, acpi_return_dep_dev, &adev); > > + > > + if (adev) > > + get_device(&adev->dev); > > + > > + return adev; > > +} > > +EXPORT_SYMBOL_GPL(acpi_dev_get_dependent_dev); > > + > > /** > > * acpi_bus_scan - Add ACPI device node objects in a given namespace scope. > > * @handle: Root of the namespace scope to scan. > > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h > > index 0b2c4f170f4d..68d378207704 100644 > > --- a/include/acpi/acpi_bus.h > > +++ b/include/acpi/acpi_bus.h > > @@ -692,6 +692,7 @@ static inline bool acpi_device_can_poweroff(struct acpi_device *adev) > > bool acpi_dev_hid_uid_match(struct acpi_device *adev, const char *hid2, const char *uid2); > > > > void acpi_dev_clear_dependencies(struct acpi_device *supplier); > > +struct acpi_device *acpi_dev_get_dependent_dev(struct acpi_device *supplier); > > struct acpi_device * > > acpi_dev_get_next_match_dev(struct acpi_device *adev, const char *hid, const char *uid, s64 hrv); > > struct acpi_device * > > -- > > 2.25.1 > > 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=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,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 CBABCC433B4 for ; Thu, 20 May 2021 18:57:28 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4402060551 for ; Thu, 20 May 2021 18:57:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4402060551 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7OkwtWGTq+Fk7UKmt+dAtYyogsB9d/n8QeeFgG8zdHI=; b=bGG9jQ7CgvyURlBVUUvkLoFLoI 0IoF0R03jptrBwgvwFRwabNg3jQZQ9K0bEXK0xw0pb5b1a0nRLag1LKW97uX8EIKKwiJ8GOztRyYF mdNXY4jYHdv0Ia6bgx3UqKK+g0n7gfHQLazhup5kbaC20tcXVpLPV8iohrpw9cfgwJWUUZP2qag2Y 4SVTNOz9+Ps/rlG9E45/+IQbODpLgBYrThhXE+PoO6zY89TgNAt0pWkH9PsjleI/S6hmAs6kFuFMU ZRPd+ezEoHrdWmkIun+cw/3Yd395kuShGkOxLVfjnufov6+F/De9t5UT9Pb7mDfdq3Ao7myTdD16W 9CkBHreA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ljnpZ-002NVu-Bb; Thu, 20 May 2021 18:55:37 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ljnpT-002NUv-2g for linux-arm-kernel@desiato.infradead.org; Thu, 20 May 2021 18:55:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=4rhnX4Y+eZgYOMeyuWthaw1sadq3182LEXhMCXR+I6M=; b=kSR0p2OB215xsQYh/MzePs1MBe YSG5hfEgj1tRJcnBHPKHPh5QwKjhWe83Y1XKUxEwVtArr7J3L5lMog1ihloJZfz7eSzCXdoDmsdVU rCyPf1gedowsSGTTJa3MO19NfKUJdBXMLj9Etbezz58/Yi2ipLMVdaSpyKEUV/h+QBkiM+mHs+ss9 l29G/NNw4LPDwOBoDlfLWnXWW5xqeqRe7CRDRGU0KxzD5yWYyDnYtHBZaQewitj5UWGXgsDzItLxG 6PBrDs/7vvxsUEQ9vVPthWyry14CAUiiJoN1LNxp73phnQuIrNZxaKLxAdAhbWvir0wnwWFrwXZfO XTG+YDiQ==; Received: from mail-ot1-f54.google.com ([209.85.210.54]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ljnpQ-00GaZi-7T for linux-arm-kernel@lists.infradead.org; Thu, 20 May 2021 18:55:29 +0000 Received: by mail-ot1-f54.google.com with SMTP id d3-20020a9d29030000b029027e8019067fso15748728otb.13 for ; Thu, 20 May 2021 11:55:25 -0700 (PDT) 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=4rhnX4Y+eZgYOMeyuWthaw1sadq3182LEXhMCXR+I6M=; b=gJYPlfoj+5YjJiemAE+7HjNeJ+6R7YEmesXLsPYHzDGQeqedao0xkr0GLUwukfm2CT gM/mzWYcAAriIX47ghWLQ1+sRBQcVdVG5U6VPrANsjnL9ktvAyd5+GKRLDFu/gjlRNyA pc+aP2W5pl0JYyGeltJfoTwDissRECzElmtYkhZ24bFaJY5qeR0C0qA/8oW8fjKlHPs2 /Di+qScRuO7cF+2to2Rucp98ptoKVzCSuCHrguJ9zAnUQENkRfzXSRd33FwISLYGYrDH I4qN8affeulq/KdQYsDXL5SdG1Or5P35UiTGgN22PD/9buqNX2O3nK4OKDk1Nw3Fcuxe HOCA== X-Gm-Message-State: AOAM532LK1EuSy0StHewy9DrYhM5JXjZUjadyPpPF/lcSnSzyQ75pT9j GxIlNRF0NbQQYF4mIRXdooIEZl+ZvEPtIM3G7Co= X-Google-Smtp-Source: ABdhPJxv0ky80jFTVK8qLg50KX4XfRpIa0/2SCS8joVGuRdFlpjMA6BtV5bOxJTGoCZsnR1EqkSxRlQFmPk5Kra/dTM= X-Received: by 2002:a9d:5a7:: with SMTP id 36mr5059433otd.321.1621536925339; Thu, 20 May 2021 11:55:25 -0700 (PDT) MIME-Version: 1.0 References: <20210520140928.3252671-1-djrscally@gmail.com> <20210520140928.3252671-3-djrscally@gmail.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Thu, 20 May 2021 20:55:14 +0200 Message-ID: Subject: Re: [PATCH v4 2/8] ACPI: scan: Add function to fetch dependent of acpi device To: Daniel Scally Cc: "Rafael J . Wysocki" , Andy Shevchenko , Wolfram Sang , Lee Jones , Hans de Goede , Maximilian Luz , Linux Kernel Mailing List , ACPI Devel Maling List , Linux ARM , "open list:GPIO SUBSYSTEM" , linux-i2c , Platform Driver , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" , Len Brown , Mika Westerberg , Russell King , Linus Walleij , Bartosz Golaszewski , Mark Gross , Robert Moore , Erik Kaneda , Laurent Pinchart , Kieran Bingham , Andy Shevchenko X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210520_115528_287460_F134956F X-CRM114-Status: GOOD ( 34.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, May 20, 2021 at 8:33 PM Rafael J. Wysocki wrote: > > On Thu, May 20, 2021 at 4:11 PM Daniel Scally wrote: > > > > In some ACPI tables we encounter, devices use the _DEP method to assert > > a dependence on other ACPI devices as opposed to the OpRegions that the > > specification intends. We need to be able to find those devices "from" > > the dependee, so add a callback and a wrapper to walk over the > > acpi_dep_list and return the dependent ACPI device. > > > > Reviewed-by: Andy Shevchenko > > Signed-off-by: Daniel Scally > > --- > > Changes since v3: > > > > Both new functions were renamed. > > > > drivers/acpi/scan.c | 38 ++++++++++++++++++++++++++++++++++++++ > > include/acpi/acpi_bus.h | 1 + > > 2 files changed, 39 insertions(+) > > > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > > index 195635c3462b..1a76fbdfa669 100644 > > --- a/drivers/acpi/scan.c > > +++ b/drivers/acpi/scan.c > > @@ -2105,6 +2105,21 @@ static void acpi_bus_attach(struct acpi_device *device, bool first_pass) > > device->handler->hotplug.notify_online(device); > > } > > > > +static int acpi_return_dep_dev(struct acpi_dep_data *dep, void *data) > > What about calling this acpi_get_first_consumer_cb()? Or acpi_dev_get_first_consumer_dev_cb() if you want to be super-precise? > > > +{ > > + struct acpi_device *adev; > > + int ret; > > + > > + ret = acpi_bus_get_device(dep->consumer, &adev); > > + if (ret) > > + /* If we don't find an adev then we want to continue parsing */ > > + return 0; > > + > > + *(struct acpi_device **)data = adev; > > And it can do the get_device() here, can't it? > > So maybe use acpi_bus_get_acpi_device() instead of > acpi_bus_get_device()? Would be simpler. > > > + > > + return 1; > > +} > > + > > static int acpi_scan_clear_dep(struct acpi_dep_data *dep, void *data) > > { > > struct acpi_device *adev; > > @@ -2168,6 +2183,29 @@ void acpi_dev_clear_dependencies(struct acpi_device *supplier) > > } > > EXPORT_SYMBOL_GPL(acpi_dev_clear_dependencies); > > > > +/** > > + * acpi_dev_get_dependent_dev - Return ACPI device dependent on @supplier > > And what about calling this acpi_get_first_consumer() ? Or acpi_dev_get_first_consumer_dev() (in analogy with the above)? > > + * @supplier: Pointer to the dependee device > > + * > > + * Returns the first &struct acpi_device which declares itself dependent on > > + * @supplier via the _DEP buffer, parsed from the acpi_dep_list. > > + * > > + * The caller is responsible for putting the reference to adev when it is no > > + * longer needed. > > + */ > > +struct acpi_device *acpi_dev_get_dependent_dev(struct acpi_device *supplier) > > +{ > > + struct acpi_device *adev = NULL; > > + > > + acpi_walk_dep_device_list(supplier->handle, acpi_return_dep_dev, &adev); > > + > > + if (adev) > > + get_device(&adev->dev); > > + > > + return adev; > > +} > > +EXPORT_SYMBOL_GPL(acpi_dev_get_dependent_dev); > > + > > /** > > * acpi_bus_scan - Add ACPI device node objects in a given namespace scope. > > * @handle: Root of the namespace scope to scan. > > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h > > index 0b2c4f170f4d..68d378207704 100644 > > --- a/include/acpi/acpi_bus.h > > +++ b/include/acpi/acpi_bus.h > > @@ -692,6 +692,7 @@ static inline bool acpi_device_can_poweroff(struct acpi_device *adev) > > bool acpi_dev_hid_uid_match(struct acpi_device *adev, const char *hid2, const char *uid2); > > > > void acpi_dev_clear_dependencies(struct acpi_device *supplier); > > +struct acpi_device *acpi_dev_get_dependent_dev(struct acpi_device *supplier); > > struct acpi_device * > > acpi_dev_get_next_match_dev(struct acpi_device *adev, const char *hid, const char *uid, s64 hrv); > > struct acpi_device * > > -- > > 2.25.1 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============2114060720471221757==" MIME-Version: 1.0 From: Rafael J. Wysocki Subject: [Devel] Re: [PATCH v4 2/8] ACPI: scan: Add function to fetch dependent of acpi device Date: Thu, 20 May 2021 20:55:14 +0200 Message-ID: In-Reply-To: CAJZ5v0hoDswjr+7r4uf6jZvV3t+-UDtEA0V7A_MvdT_34XrbJA@mail.gmail.com List-ID: To: devel@acpica.org --===============2114060720471221757== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, May 20, 2021 at 8:33 PM Rafael J. Wysocki wro= te: > > On Thu, May 20, 2021 at 4:11 PM Daniel Scally wro= te: > > > > In some ACPI tables we encounter, devices use the _DEP method to assert > > a dependence on other ACPI devices as opposed to the OpRegions that the > > specification intends. We need to be able to find those devices "from" > > the dependee, so add a callback and a wrapper to walk over the > > acpi_dep_list and return the dependent ACPI device. > > > > Reviewed-by: Andy Shevchenko > > Signed-off-by: Daniel Scally > > --- > > Changes since v3: > > > > Both new functions were renamed. > > > > drivers/acpi/scan.c | 38 ++++++++++++++++++++++++++++++++++++++ > > include/acpi/acpi_bus.h | 1 + > > 2 files changed, 39 insertions(+) > > > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > > index 195635c3462b..1a76fbdfa669 100644 > > --- a/drivers/acpi/scan.c > > +++ b/drivers/acpi/scan.c > > @@ -2105,6 +2105,21 @@ static void acpi_bus_attach(struct acpi_device *= device, bool first_pass) > > device->handler->hotplug.notify_online(device); > > } > > > > +static int acpi_return_dep_dev(struct acpi_dep_data *dep, void *data) > > What about calling this acpi_get_first_consumer_cb()? Or acpi_dev_get_first_consumer_dev_cb() if you want to be super-precise? > > > +{ > > + struct acpi_device *adev; > > + int ret; > > + > > + ret =3D acpi_bus_get_device(dep->consumer, &adev); > > + if (ret) > > + /* If we don't find an adev then we want to continue pa= rsing */ > > + return 0; > > + > > + *(struct acpi_device **)data =3D adev; > > And it can do the get_device() here, can't it? > > So maybe use acpi_bus_get_acpi_device() instead of > acpi_bus_get_device()? Would be simpler. > > > + > > + return 1; > > +} > > + > > static int acpi_scan_clear_dep(struct acpi_dep_data *dep, void *data) > > { > > struct acpi_device *adev; > > @@ -2168,6 +2183,29 @@ void acpi_dev_clear_dependencies(struct acpi_dev= ice *supplier) > > } > > EXPORT_SYMBOL_GPL(acpi_dev_clear_dependencies); > > > > +/** > > + * acpi_dev_get_dependent_dev - Return ACPI device dependent on @suppl= ier > > And what about calling this acpi_get_first_consumer() ? Or acpi_dev_get_first_consumer_dev() (in analogy with the above)? > > + * @supplier: Pointer to the dependee device > > + * > > + * Returns the first &struct acpi_device which declares itself depende= nt on > > + * @supplier via the _DEP buffer, parsed from the acpi_dep_list. > > + * > > + * The caller is responsible for putting the reference to adev when it= is no > > + * longer needed. > > + */ > > +struct acpi_device *acpi_dev_get_dependent_dev(struct acpi_device *sup= plier) > > +{ > > + struct acpi_device *adev =3D NULL; > > + > > + acpi_walk_dep_device_list(supplier->handle, acpi_return_dep_dev= , &adev); > > + > > + if (adev) > > + get_device(&adev->dev); > > + > > + return adev; > > +} > > +EXPORT_SYMBOL_GPL(acpi_dev_get_dependent_dev); > > + > > /** > > * acpi_bus_scan - Add ACPI device node objects in a given namespace s= cope. > > * @handle: Root of the namespace scope to scan. > > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h > > index 0b2c4f170f4d..68d378207704 100644 > > --- a/include/acpi/acpi_bus.h > > +++ b/include/acpi/acpi_bus.h > > @@ -692,6 +692,7 @@ static inline bool acpi_device_can_poweroff(struct = acpi_device *adev) > > bool acpi_dev_hid_uid_match(struct acpi_device *adev, const char *hid2= , const char *uid2); > > > > void acpi_dev_clear_dependencies(struct acpi_device *supplier); > > +struct acpi_device *acpi_dev_get_dependent_dev(struct acpi_device *sup= plier); > > struct acpi_device * > > acpi_dev_get_next_match_dev(struct acpi_device *adev, const char *hid,= const char *uid, s64 hrv); > > struct acpi_device * > > -- > > 2.25.1 > > --===============2114060720471221757==--