From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Mika Westerberg <mika.westerberg@linux.intel.com>,
Darren Hart <dvhart@infradead.org>
Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH 2/4] ACPI / scan: Simplify acpi_match_device()
Date: Thu, 09 Apr 2015 02:20:51 +0200 [thread overview]
Message-ID: <1745204.4cEygKHaXn@vostro.rjw.lan> (raw)
In-Reply-To: <4378053.gHTT51U7FJ@vostro.rjw.lan>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Redefine acpi_companion_match() to return an ACPI device object
pointer instead of a bool and use it to remove some redundant code
from acpi_match_device().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/scan.c | 30 +++++++++++-------------------
1 file changed, 11 insertions(+), 19 deletions(-)
Index: linux-pm/drivers/acpi/scan.c
===================================================================
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -194,7 +194,8 @@ static int create_modalias(struct acpi_d
*
* Check if the given device has an ACPI companion and if that companion has
* a valid list of PNP IDs, and if the device is the first (primary) physical
- * device associated with it.
+ * device associated with it. Return the companion pointer if that's the case
+ * or NULL otherwise.
*
* If multiple physical devices are attached to a single ACPI companion, we need
* to be careful. The usage scenario for this kind of relationship is that all
@@ -208,31 +209,31 @@ static int create_modalias(struct acpi_d
* resources available from it but they will be matched normally using functions
* provided by their bus types (and analogously for their modalias).
*/
-static bool acpi_companion_match(const struct device *dev)
+static struct acpi_device *acpi_companion_match(const struct device *dev)
{
struct acpi_device *adev;
- bool ret;
adev = ACPI_COMPANION(dev);
if (!adev)
- return false;
+ return NULL;
if (list_empty(&adev->pnp.ids))
- return false;
+ return NULL;
mutex_lock(&adev->physical_node_lock);
if (list_empty(&adev->physical_node_list)) {
- ret = false;
+ adev = NULL;
} else {
const struct acpi_device_physical_node *node;
node = list_first_entry(&adev->physical_node_list,
struct acpi_device_physical_node, node);
- ret = node->dev == dev;
+ if (node->dev != dev)
+ adev = NULL;
}
mutex_unlock(&adev->physical_node_lock);
- return ret;
+ return adev;
}
/*
@@ -908,7 +909,7 @@ static const struct acpi_device_id *__ac
* If the device is not present, it is unnecessary to load device
* driver for it.
*/
- if (!device->status.present)
+ if (!device || !device->status.present)
return NULL;
for (id = ids; id->id[0]; id++)
@@ -933,16 +934,7 @@ static const struct acpi_device_id *__ac
const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
const struct device *dev)
{
- struct acpi_device *adev;
- acpi_handle handle = ACPI_HANDLE(dev);
-
- if (!ids || !handle || acpi_bus_get_device(handle, &adev))
- return NULL;
-
- if (!acpi_companion_match(dev))
- return NULL;
-
- return __acpi_match_device(adev, ids);
+ return __acpi_match_device(acpi_companion_match(dev), ids);
}
EXPORT_SYMBOL_GPL(acpi_match_device);
next prev parent reply other threads:[~2015-04-08 23:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 0:18 [PATCH 0/4] ACPI / scan: Clean up the handling of the PRP0001 device ID Rafael J. Wysocki
2015-04-09 0:19 ` [PATCH 1/4] ACPI / scan: Generalize of_compatible matching Rafael J. Wysocki
2015-04-09 0:20 ` Rafael J. Wysocki [this message]
2015-04-09 0:21 ` [PATCH 3/4] ACPI / scan: Take PRP0001 in _CID lists into account too Rafael J. Wysocki
2015-04-09 1:28 ` [Update][PATCH 3/4] ACPI / scan: Take the PRP0001 position in the list of IDs into account Rafael J. Wysocki
2015-04-09 0:22 ` [PATCH 4/4] ACPI / scan: Rework modalias creation when "compatible" is present Rafael J. Wysocki
2015-04-09 12:27 ` Mika Westerberg
2015-04-09 17:39 ` Rafael J. Wysocki
2015-04-09 21:13 ` [update][PATCH " Rafael J. Wysocki
2015-04-10 8:12 ` Mika Westerberg
2015-04-10 12:34 ` Rafael J. Wysocki
2015-04-10 12:29 ` Mika Westerberg
2015-04-10 14:20 ` Rafael J. Wysocki
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=1745204.4cEygKHaXn@vostro.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=dvhart@infradead.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
/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;
as well as URLs for NNTP newsgroup(s).