From: Lukas Wunner <lukas at wunner.de>
To: devel@acpica.org
Subject: [Devel] [PATCH v2 0/2] Add acpi_dev_present
Date: Wed, 25 Nov 2015 21:19:55 +0100 [thread overview]
Message-ID: <cover.1448480385.git.lukas@wunner.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]
Hi,
On Tue, Nov 24, 2015 at 12:40:51 +0800, Hanjun Guo wrote:
> I think those IDs already cached, in acpi_init_device_object(),
> INIT_LIST_HEAD(&device->pnp.ids);
> ...
> acpi_set_pnp_ids(handle, &device->pnp, type);
> please see API acpi_device_hid(), so I think you can introduce a API with
> acpi_device and HID passed as arguments in scan.c
Thank you for your feedback, I've reworked the patch to iterate over
acpi_bus_id_list instead of walking the namespace.
An alternative approach would have been to traverse the acpi_device
tree but it would have been more code. If you would prefer that over
the solution I've settled on please let me know. It would be useful
for stuff like this to have a function that traverses the acpi_device
tree and invokes a callback for each node, à la acpi_ns_walk_namespace().
Does such a thing exist already? If so I've missed it.
> Will those drivers be loaded before the acpi namespace is scanned?
I verified that all 7 existing users invoke the new API from initcall
level "device". The bus is scanned in initcall level "subsystem",
i.e. earlier. So we're on the safe side here. I added a note in the
kernel-doc that the function may not be called from a subsys_initcall()
or earlier, this will hopefully make it foolproof. (If you feel this is
over the top then just leave it out if/when merging.)
On Tue, Nov 24, 2015 at 15:22:18 +0100, Rafael J. Wysocki wrote:
> I'd prefer that to go to utils.c to be honest, even if the namespace
> needs to be walked.
Done. Since this is not part of ACPICA, would it be okay to merge via
ASoC as requested by Mark Brown?
I've pushed the new version of the series to GitHub for more convenient
reviewing. All driver patches except the one for Mark have acks now:
https://github.com/l1k/linux/commits/acpi_dev_present
Thanks,
Lukas
Lukas Wunner (2):
ACPI / scan: Fix acpi_bus_id_list bookkeeping
ACPI / utils: Add acpi_dev_present()
drivers/acpi/internal.h | 8 ++++++++
drivers/acpi/scan.c | 22 +++++++++++++++-------
drivers/acpi/utils.c | 31 +++++++++++++++++++++++++++++++
include/acpi/acpi_bus.h | 2 ++
4 files changed, 56 insertions(+), 7 deletions(-)
--
1.8.5.2 (Apple Git-48)
WARNING: multiple messages have this Message-ID (diff)
From: Lukas Wunner <lukas@wunner.de>
To: linux-acpi@vger.kernel.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>
Cc: devel@acpica.org, Hanjun Guo <guohanjun@huawei.com>,
Robert Moore <robert.moore@intel.com>,
Mark Brown <broonie@kernel.org>,
Hui Wang <hui.wang@canonical.com>,
Darren Hart <dvhart@infradead.org>
Subject: [PATCH v2 0/2] Add acpi_dev_present
Date: Wed, 25 Nov 2015 21:19:55 +0100 [thread overview]
Message-ID: <cover.1448480385.git.lukas@wunner.de> (raw)
Hi,
On Tue, Nov 24, 2015 at 12:40:51 +0800, Hanjun Guo wrote:
> I think those IDs already cached, in acpi_init_device_object(),
> INIT_LIST_HEAD(&device->pnp.ids);
> ...
> acpi_set_pnp_ids(handle, &device->pnp, type);
> please see API acpi_device_hid(), so I think you can introduce a API with
> acpi_device and HID passed as arguments in scan.c
Thank you for your feedback, I've reworked the patch to iterate over
acpi_bus_id_list instead of walking the namespace.
An alternative approach would have been to traverse the acpi_device
tree but it would have been more code. If you would prefer that over
the solution I've settled on please let me know. It would be useful
for stuff like this to have a function that traverses the acpi_device
tree and invokes a callback for each node, à la acpi_ns_walk_namespace().
Does such a thing exist already? If so I've missed it.
> Will those drivers be loaded before the acpi namespace is scanned?
I verified that all 7 existing users invoke the new API from initcall
level "device". The bus is scanned in initcall level "subsystem",
i.e. earlier. So we're on the safe side here. I added a note in the
kernel-doc that the function may not be called from a subsys_initcall()
or earlier, this will hopefully make it foolproof. (If you feel this is
over the top then just leave it out if/when merging.)
On Tue, Nov 24, 2015 at 15:22:18 +0100, Rafael J. Wysocki wrote:
> I'd prefer that to go to utils.c to be honest, even if the namespace
> needs to be walked.
Done. Since this is not part of ACPICA, would it be okay to merge via
ASoC as requested by Mark Brown?
I've pushed the new version of the series to GitHub for more convenient
reviewing. All driver patches except the one for Mark have acks now:
https://github.com/l1k/linux/commits/acpi_dev_present
Thanks,
Lukas
Lukas Wunner (2):
ACPI / scan: Fix acpi_bus_id_list bookkeeping
ACPI / utils: Add acpi_dev_present()
drivers/acpi/internal.h | 8 ++++++++
drivers/acpi/scan.c | 22 +++++++++++++++-------
drivers/acpi/utils.c | 31 +++++++++++++++++++++++++++++++
include/acpi/acpi_bus.h | 2 ++
4 files changed, 56 insertions(+), 7 deletions(-)
--
1.8.5.2 (Apple Git-48)
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2015-11-25 20:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 20:19 Lukas Wunner [this message]
2015-11-25 20:19 ` [PATCH v2 0/2] Add acpi_dev_present Lukas Wunner
2015-11-25 20:19 ` [Devel] [PATCH v2 2/2] ACPI / utils: Add acpi_dev_present() Lukas Wunner
2015-11-25 20:19 ` Lukas Wunner
2015-11-30 8:27 ` Hanjun Guo
2015-12-01 12:58 ` [Devel] " Lukas Wunner
2015-12-01 12:58 ` Lukas Wunner
2015-12-02 8:26 ` Hanjun Guo
2015-11-25 20:19 ` [Devel] [PATCH v2 1/2] ACPI / scan: Fix acpi_bus_id_list bookkeeping Lukas Wunner
2015-11-25 20:19 ` Lukas Wunner
2015-11-30 6:27 ` Hanjun Guo
2015-11-30 8:14 ` Hanjun Guo
2015-12-01 13:08 ` [Devel] " Lukas Wunner
2015-12-01 13:08 ` Lukas Wunner
2015-12-02 8:56 ` Hanjun Guo
2015-12-06 21:09 ` [Devel] " Lukas Wunner
2015-12-06 21:09 ` Lukas Wunner
2015-12-07 1:39 ` 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=cover.1448480385.git.lukas@wunner.de \
--to=devel@acpica.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.