From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Lan Tianyu <tianyu.lan@intel.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Aaron Lu <aaron.lu@intel.com>,
Jarkko Nikula <jarkko.nikula@linux.intel.com>,
"Luck, Tony" <tony.luck@intel.com>
Subject: Re: [PATCH] ACPI / driver core: Store a device pointer in struct acpi_dev_node
Date: Tue, 12 Nov 2013 11:24:02 +0200 [thread overview]
Message-ID: <20131112092402.GO22916@intel.com> (raw)
In-Reply-To: <1683079.zjqzsOAjXB@vostro.rjw.lan>
On Mon, Nov 11, 2013 at 02:45:39PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Subject: ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
>
> Modify struct acpi_dev_node to contain a pointer to struct acpi_device
> associated with the given device object (that is, its ACPI companion
> device) instead of an ACPI handle corresponding to it. Introduce two
> new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
> ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
> ACPI_HANDLE() macro to take the above changes into account.
> Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
> use ACPI_COMPANION_SET() instead. For some of them who used to
> pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
> introduce a helper routine acpi_preset_companion() doing an
> equivalent thing.
>
> The main motivation for doing this is that there are things
> represented by struct acpi_device objects that don't have valid
> ACPI handles (so called fixed ACPI hardware features, such as
> power and sleep buttons) and we would like to create platform
> device objects for them and "glue" them to their ACPI companions
> in the usual way (which currently is impossible due to the
> lack of valid ACPI handles). However, there are more reasons
> why it may be useful.
>
> First, struct acpi_device pointers allow of much better type checking
> than void pointers which are ACPI handles, so it should be more
> difficult to write buggy code using modified struct acpi_dev_node
> and the new macros. Second, the change should help to reduce (over
> time) the number of places in which the result of ACPI_HANDLE() is
> passed to acpi_bus_get_device() in order to obtain a pointer to the
> struct acpi_device associated with the given "physical" device,
> because now that pointer is returned by ACPI_COMPANION() directly.
> Finally, the change should make it easier to write generic code that
> will build both for CONFIG_ACPI set and unset without adding explicit
> compiler directives to it.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
I tested this on Haswell as well and it works fine with ACPI enumerated
platform, I2C and SPI devices.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> (on Haswell)
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
next prev parent reply other threads:[~2013-11-12 9:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-10 0:58 [PATCH] ACPI / driver core: Store a device pointer in struct acpi_dev_node Rafael J. Wysocki
2013-11-10 15:16 ` Greg Kroah-Hartman
2013-11-11 1:21 ` Lan Tianyu
2013-11-11 13:45 ` Rafael J. Wysocki
2013-11-11 15:03 ` Greg Kroah-Hartman
2013-11-11 15:03 ` Greg Kroah-Hartman
2013-11-11 21:56 ` Rafael J. Wysocki
2013-11-11 21:56 ` Rafael J. Wysocki
2013-11-12 9:24 ` Mika Westerberg [this message]
2013-11-12 14:20 ` Rafael J. Wysocki
2013-11-13 6:57 ` Aaron Lu
2013-11-13 23:25 ` [PATCH 0/2] ACPI: Additional changes on top of "ACPI / driver core: Store a device pointer in struct acpi_dev_node" Rafael J. Wysocki
2013-11-13 23:26 ` [PATCH 1/2] ACPI: Eliminate the DEVICE_ACPI_HANDLE() macro Rafael J. Wysocki
2013-11-14 2:44 ` Greg Kroah-Hartman
2013-11-13 23:26 ` [PATCH 2/2] ACPI / bind: Use (put|get)_device() on ACPI device objects too Rafael J. Wysocki
2013-11-14 2:43 ` Greg Kroah-Hartman
2013-11-14 7:20 ` Lan Tianyu
2013-11-14 7:20 ` Lan Tianyu
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=20131112092402.GO22916@intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=aaron.lu@intel.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=jarkko.nikula@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=tianyu.lan@intel.com \
--cc=tony.luck@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 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.