All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Aaron Lu <aaron.lu@intel.com>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Mika Westerberg <mika.westerberg@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: Mon, 11 Nov 2013 07:03:18 -0800	[thread overview]
Message-ID: <20131111150318.GB16112@kroah.com> (raw)
In-Reply-To: <1683079.zjqzsOAjXB@vostro.rjw.lan>

On Mon, Nov 11, 2013 at 02:45:39PM +0100, Rafael J. Wysocki wrote:
> On Monday, November 11, 2013 09:21:40 AM Lan Tianyu wrote:
> > On 2013年11月10日 08:58, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > 
> > > Modify struct acpi_dev_node to contain a pointer to struct device
> > > ambedded in the struct acpi_device associated with the given device
> > > object (that is, its ACPI companion device) instead of an ACPI handle
> > > corresponding to that struct acpi_device.  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 rationale for using a struct device pointer instead of a
> > > struct acpi_device one as the member of struct acpi_dev_node is
> > > that it allows device.h to avoid including linux/acpi.h which would
> > > introduce quite a bit of compilation overhead for stuff that doesn't
> > > care about ACPI.
> > > In turn, moving the macros to linux/acpi.h forces
> > > the stuff that does care about ACPI to include that file as
> > > appropriate anyway.
> > 
> > How about declaring "struct acpi_device" in the device.h? This can help
> > to use struct acpi_device without including linux/acpi.h.
> > 
> > struct iommu_ops and struct iommu_group have been used by the same way
> > in the device.h.
> 
> Yes, they are.  Well, that appears to work too.
> 
> Updated patch is appended.  It also contains some fixes for problems reported
> by the auto build system and it's been tested on x86-64 now, so it should be
> reasonably close to final.
> 
> Thanks,
> Rafael
> 
> 
> ---
> 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>

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
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

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Aaron Lu <aaron.lu@intel.com>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Mika Westerberg <mika.westerberg@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: Mon, 11 Nov 2013 07:03:18 -0800	[thread overview]
Message-ID: <20131111150318.GB16112@kroah.com> (raw)
In-Reply-To: <1683079.zjqzsOAjXB@vostro.rjw.lan>

On Mon, Nov 11, 2013 at 02:45:39PM +0100, Rafael J. Wysocki wrote:
> On Monday, November 11, 2013 09:21:40 AM Lan Tianyu wrote:
> > On 2013年11月10日 08:58, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > 
> > > Modify struct acpi_dev_node to contain a pointer to struct device
> > > ambedded in the struct acpi_device associated with the given device
> > > object (that is, its ACPI companion device) instead of an ACPI handle
> > > corresponding to that struct acpi_device.  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 rationale for using a struct device pointer instead of a
> > > struct acpi_device one as the member of struct acpi_dev_node is
> > > that it allows device.h to avoid including linux/acpi.h which would
> > > introduce quite a bit of compilation overhead for stuff that doesn't
> > > care about ACPI.
> > > In turn, moving the macros to linux/acpi.h forces
> > > the stuff that does care about ACPI to include that file as
> > > appropriate anyway.
> > 
> > How about declaring "struct acpi_device" in the device.h? This can help
> > to use struct acpi_device without including linux/acpi.h.
> > 
> > struct iommu_ops and struct iommu_group have been used by the same way
> > in the device.h.
> 
> Yes, they are.  Well, that appears to work too.
> 
> Updated patch is appended.  It also contains some fixes for problems reported
> by the auto build system and it's been tested on x86-64 now, so it should be
> reasonably close to final.
> 
> Thanks,
> Rafael
> 
> 
> ---
> 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>

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

  reply	other threads:[~2013-11-11 15:00 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 [this message]
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
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=20131111150318.GB16112@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=aaron.lu@intel.com \
    --cc=bhelgaas@google.com \
    --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=mika.westerberg@linux.intel.com \
    --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.