Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1803124pxb; Sun, 17 Jan 2021 23:38:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZ8eMmPcX+ueE3bwz3cLx66J+0OvoG59BkTihtsGcn6HH/nu4iX3R78PozkXiQlM9g9gzU X-Received: by 2002:a05:6402:144:: with SMTP id s4mr4041974edu.63.1610955496204; Sun, 17 Jan 2021 23:38:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610955496; cv=none; d=google.com; s=arc-20160816; b=RGVGpXxm4dYTBGwOibn5a8WvmmrMZfl7GbHRwK5VeM7bfVljlVguSCyj7i3ztJhsqw MzW/l3VpeEQONjNJcbGZ0nhAV2f/IO/bvV95SieV4kGHAUNMaH0Y2KaKsFyya6idg4iq 4VRFjZrwCv2oO4/c/WgO98nx31R2wc52lSmkC7UukdK+TVzwBXnepovyDRlJc2HRz3qX xfF0Cj7trOZgjvP2ZKBv3UB2bWBj/GU9T8iSYTYToK8smU+NbYKAY+gS11M9rxceP1lb 0XewlCy+fDhQ60bqxx+fZTZjjkJlF7RzmOder0Onk/md7En6+f6qzstCDkg6Zww1h7GO ZnVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=+dbXb4/pd5rw9QzQPw5HGl/Me9iabhhOg/G/AdFOgpU=; b=B1TkUD9RrocEv2BgMqFzNv3uxnbK3fKUgmyaaawRaaSlsL5m9xNly0XayzyWQ2bBzA 1OhB6ykbrvP28mZZ31AFHjqyykrwerbLPh6Gj6uL5M2VIF6mBgj+9jdM9bHlzMWU+0D+ azobtrdT/scXBzxaz6pHth4WHlvigdOJCnwsHdpffzenR5upFgkvc7fxWw0NfZYIlaYu U9Fv+itHbOkFW+idLBGmhebka1485QHnWBQ5tzsGm0l1i4sgCvcUTGryekgMnCMDIcGD pP3g1dM5S8t1C8d7KKJx+2lmpfLLsIev+MMvNndy89oUkS9aZIMcm8HZVUuDyBwWms0/ GF3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=pjKmGMVU; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s24si7483673ejd.135.2021.01.17.23.37.53; Sun, 17 Jan 2021 23:38:16 -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; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=pjKmGMVU; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732769AbhARHfK (ORCPT + 99 others); Mon, 18 Jan 2021 02:35:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731544AbhARHfE (ORCPT ); Mon, 18 Jan 2021 02:35:04 -0500 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58A38C061573; Sun, 17 Jan 2021 23:34:24 -0800 (PST) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 981712BB; Mon, 18 Jan 2021 08:34:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1610955260; bh=3ZDbWSNMk25Oq6QHRjrIbAXJOZHgOoobzPTgr2XKPX0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pjKmGMVUeqB7fHtO3ZvOZtPasArkDSapiHMXmCN+OmXSAXkrf712MWG4gTUqhjZAs kE5Wtylg5w5ZxvEGSChRKgkmJd9I+veyH6tsoRv+YqOERQH4ipBbH1QokGFFZSO69p YH0cWGnsS6Pj5Rj+Rh+ghS4P13OwPcJV3T/BO1Cc= Date: Mon, 18 Jan 2021 09:34:04 +0200 From: Laurent Pinchart To: Daniel Scally Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org, platform-driver-x86@vger.kernel.org, devel@acpica.org, rjw@rjwysocki.net, lenb@kernel.org, andy@kernel.org, mika.westerberg@linux.intel.com, linus.walleij@linaro.org, bgolaszewski@baylibre.com, wsa@kernel.org, lee.jones@linaro.org, hdegoede@redhat.com, mgross@linux.intel.com, robert.moore@intel.com, erik.kaneda@intel.com, sakari.ailus@linux.intel.com, andriy.shevchenko@linux.intel.com, kieran.bingham@ideasonboard.com Subject: Re: [PATCH v2 2/7] acpi: utils: Add function to fetch dependent acpi_devices Message-ID: References: <20210118003428.568892-1-djrscally@gmail.com> <20210118003428.568892-3-djrscally@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210118003428.568892-3-djrscally@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, Thank you for the patch. On Mon, Jan 18, 2021 at 12:34:23AM +0000, 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 function to parse all ACPI Devices and check if > the include the handle of the dependee device in their _DEP buffer. > > Signed-off-by: Daniel Scally > --- > Changes in v2: > - Used acpi_lpss_dep() as Andy suggested. > > drivers/acpi/utils.c | 34 ++++++++++++++++++++++++++++++++++ > include/acpi/acpi_bus.h | 2 ++ > 2 files changed, 36 insertions(+) > > diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c > index 78b38775f18b..ec6a2406a886 100644 > --- a/drivers/acpi/utils.c > +++ b/drivers/acpi/utils.c > @@ -831,6 +831,18 @@ bool acpi_lpss_dep(struct acpi_device *adev, acpi_handle handle) > return false; > } > > +static int acpi_dev_match_by_dep(struct device *dev, const void *data) > +{ > + struct acpi_device *adev = to_acpi_device(dev); > + const struct acpi_device *dependee = data; > + acpi_handle handle = dependee->handle; > + > + if (acpi_lpss_dep(adev, handle)) > + return 1; > + > + return 0; > +} > + I think I'd move this just before acpi_dev_get_next_dep_dev() to keep the two together. > /** > * acpi_dev_present - Detect that a given ACPI device is present > * @hid: Hardware ID of the device. > @@ -866,6 +878,28 @@ bool acpi_dev_present(const char *hid, const char *uid, s64 hrv) > } > EXPORT_SYMBOL(acpi_dev_present); > > +/** > + * acpi_dev_get_next_dep_dev - Return next ACPI device dependent on input dev Maybe acpi_dev_get_next_dependent_dev() ? "dep" could mean either dependent or dependency. > + * @adev: Pointer to the dependee device > + * @prev: Pointer to the previous dependent device (or NULL for first match) > + * > + * Return the next ACPI device which declares itself dependent on @adev in > + * the _DEP buffer. > + * > + * The caller is responsible to call put_device() on the returned device. > + */ > +struct acpi_device *acpi_dev_get_next_dep_dev(struct acpi_device *adev, > + struct acpi_device *prev) > +{ > + struct device *start = prev ? &prev->dev : NULL; > + struct device *dev; > + > + dev = bus_find_device(&acpi_bus_type, start, adev, acpi_dev_match_by_dep); Having to loop over all ACPI devices is quite inefficient, but if we need a reverse lookup, we don't really have a choice. We could create a reverse map, but I don't think it's worth it. > + > + return dev ? to_acpi_device(dev) : NULL; > +} > +EXPORT_SYMBOL(acpi_dev_get_next_dep_dev); I would have used EXPORT_SYMBOL_GPL. I'm not sure what the policy is in the ACPI subsystem, and it's also a personal choice. Reviewed-by: Laurent Pinchart > + > /** > * acpi_dev_get_next_match_dev - Return the next match of ACPI device > * @adev: Pointer to the previous acpi_device matching this @hid, @uid and @hrv > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h > index 02a716a0af5d..33deb22294f2 100644 > --- a/include/acpi/acpi_bus.h > +++ b/include/acpi/acpi_bus.h > @@ -683,6 +683,8 @@ 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); > > +struct acpi_device * > +acpi_dev_get_next_dep_dev(struct acpi_device *adev, struct acpi_device *prev); > struct acpi_device * > acpi_dev_get_next_match_dev(struct acpi_device *adev, const char *hid, const char *uid, s64 hrv); > struct acpi_device * -- Regards, Laurent Pinchart