From: Daniel Scally <djrscally@gmail.com>
To: linux-acpi@vger.kernel.org, linux-clk@vger.kernel.org,
platform-driver-x86@vger.kernel.org
Cc: rafael@kernel.org, lenb@kernel.org, mturquette@baylibre.com,
sboyd@kernel.org, hdegoede@redhat.com, markgross@kernel.org,
robert.moore@intel.com
Subject: [PATCH v3 1/5] ACPI: scan: Add acpi_dev_get_next_consumer_dev()
Date: Thu, 22 Sep 2022 00:04:35 +0100 [thread overview]
Message-ID: <20220921230439.768185-2-djrscally@gmail.com> (raw)
In-Reply-To: <20220921230439.768185-1-djrscally@gmail.com>
In commit b83e2b306736 ("ACPI: scan: Add function to fetch dependent
of ACPI device") we added a means of fetching the first device to
declare itself dependent on another ACPI device in the _DEP method.
One assumption in that patch was that there would only be a single
consuming device, but this has not held.
Replace that function with a new function that fetches the next consumer
of a supplier device. Where no "previous" consumer is passed in, it
behaves identically to the original function.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Daniel Scally <djrscally@gmail.com>
---
Changes since v2:
- Separated adev_p and adev instead of relying on a cast (Rafael)
- Used a separate if block to check for adev == start in
acpi_dev_get_next_consumer_dev() (Rafael)
drivers/acpi/scan.c | 40 +++++++++++++++------
drivers/platform/x86/intel/int3472/common.c | 2 +-
include/acpi/acpi_bus.h | 4 ++-
3 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 42cec8120f18..12ac2f3ae5d2 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2235,9 +2235,22 @@ static int acpi_bus_attach(struct acpi_device *device, void *first_pass)
return 0;
}
-static int acpi_dev_get_first_consumer_dev_cb(struct acpi_dep_data *dep, void *data)
+static int acpi_dev_get_next_consumer_dev_cb(struct acpi_dep_data *dep, void *data)
{
- struct acpi_device *adev;
+ struct acpi_device **adev_p = data;
+ struct acpi_device *adev = *adev_p;
+
+ /*
+ * If we're passed a 'previous' consumer device then we need to skip
+ * any consumers until we meet the previous one, and then NULL @data
+ * so the next one can be returned.
+ */
+ if (adev) {
+ if (dep->consumer == adev->handle)
+ *adev_p = NULL;
+
+ return 0;
+ }
adev = acpi_bus_get_acpi_device(dep->consumer);
if (adev) {
@@ -2368,25 +2381,32 @@ bool acpi_dev_ready_for_enumeration(const struct acpi_device *device)
EXPORT_SYMBOL_GPL(acpi_dev_ready_for_enumeration);
/**
- * acpi_dev_get_first_consumer_dev - Return ACPI device dependent on @supplier
+ * acpi_dev_get_next_consumer_dev - Return the next adev dependent on @supplier
* @supplier: Pointer to the dependee device
+ * @start: Pointer to the current dependent device
*
- * Returns the first &struct acpi_device which declares itself dependent on
+ * Returns the next &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.
+ * If the returned adev is not passed as @start to this function, the caller is
+ * responsible for putting the reference to adev when it is no longer needed.
*/
-struct acpi_device *acpi_dev_get_first_consumer_dev(struct acpi_device *supplier)
+struct acpi_device *acpi_dev_get_next_consumer_dev(struct acpi_device *supplier,
+ struct acpi_device *start)
{
- struct acpi_device *adev = NULL;
+ struct acpi_device *adev = start;
acpi_walk_dep_device_list(supplier->handle,
- acpi_dev_get_first_consumer_dev_cb, &adev);
+ acpi_dev_get_next_consumer_dev_cb, &adev);
+
+ acpi_dev_put(start);
+
+ if (adev == start)
+ return NULL;
return adev;
}
-EXPORT_SYMBOL_GPL(acpi_dev_get_first_consumer_dev);
+EXPORT_SYMBOL_GPL(acpi_dev_get_next_consumer_dev);
/**
* acpi_bus_scan - Add ACPI device node objects in a given namespace scope.
diff --git a/drivers/platform/x86/intel/int3472/common.c b/drivers/platform/x86/intel/int3472/common.c
index 77cf058e4168..9db2bb0bbba4 100644
--- a/drivers/platform/x86/intel/int3472/common.c
+++ b/drivers/platform/x86/intel/int3472/common.c
@@ -62,7 +62,7 @@ int skl_int3472_get_sensor_adev_and_name(struct device *dev,
struct acpi_device *sensor;
int ret = 0;
- sensor = acpi_dev_get_first_consumer_dev(adev);
+ sensor = acpi_dev_get_next_consumer_dev(adev, NULL);
if (!sensor) {
dev_err(dev, "INT3472 seems to have no dependents.\n");
return -ENODEV;
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index e7d27373ff71..bf0886dca6eb 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -736,7 +736,9 @@ bool acpi_dev_hid_uid_match(struct acpi_device *adev, const char *hid2, const ch
void acpi_dev_clear_dependencies(struct acpi_device *supplier);
bool acpi_dev_ready_for_enumeration(const struct acpi_device *device);
-struct acpi_device *acpi_dev_get_first_consumer_dev(struct acpi_device *supplier);
+struct acpi_device *acpi_dev_get_next_consumer_dev(struct acpi_device *supplier,
+ struct acpi_device *start);
+
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
next prev parent reply other threads:[~2022-09-21 23:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 23:04 [PATCH v3 0/5] Add multiple-consumer support to int3472-tps68470 driver Daniel Scally
2022-09-21 23:04 ` Daniel Scally [this message]
2022-09-21 23:04 ` [PATCH v3 2/5] ACPI: bus: Add iterator for dependent devices Daniel Scally
2022-09-21 23:04 ` [PATCH v3 3/5] platform/x86: int3472: Support multiple clock consumers Daniel Scally
2022-09-22 8:49 ` Hans de Goede
2022-09-27 12:47 ` Andy Shevchenko
2022-09-27 12:48 ` Andy Shevchenko
2022-09-21 23:04 ` [PATCH v3 4/5] platform/x86: int3472: Support multiple gpio lookups in board data Daniel Scally
2022-09-21 23:04 ` [PATCH v3 5/5] platform/x86: int3472: Add board data for Surface Go2 IR camera Daniel Scally
2022-09-22 8:55 ` [PATCH v3 0/5] Add multiple-consumer support to int3472-tps68470 driver Hans de Goede
2022-09-22 9:07 ` Daniel Scally
2022-09-24 17:15 ` Rafael J. Wysocki
2022-09-25 9:23 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220921230439.768185-2-djrscally@gmail.com \
--to=djrscally@gmail.com \
--cc=hdegoede@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=mturquette@baylibre.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox