ACPI / driver core: Store a device pointer in struct acpi_dev_node

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.

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 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, it should help to reduce 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 can be obtained directly by applying
to_acpi_device() to the result of the ACPI_COMPANION() macro.
Finally, it 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>
Merge branch 'acpi-driver-core' into bleeding-edge

* acpi-driver-core: (94 commits)
  ACPI / driver core: Store a device pointer in struct acpi_dev_node
  Linux 3.12
  ipc, msg: forbid negative values for "msg{max,mnb,mni}"
  ARC: Incorrect mm reference used in vmalloc fault handler
  scripts/kallsyms: filter symbols not in kernel address space
  memcg: remove incorrect underflow check
  USB: serial: ftdi_sio: add id for Z3X Box device
  USB: Maintainers change for usb serial drivers
  Revert "USB: pl2303: restrict the divisor based baud rate encoding method to the "HX" chip type"
  Revert "usb: pl2303: fix+improve the divsor based baud rate encoding method"
  Revert "usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method"
  Revert "usb: pl2303: remove 500000 baud from the list of standard baud rates"
  Revert "usb: pl2303: move the two baud rate encoding methods to separate functions"
  Revert "usb: pl2303: increase the allowed baud rate range for the divisor based encoding method"
  Revert "usb: pl2303: also use the divisor based baud rate encoding method for baud rates < 115200 with HX chips"
  Revert "usb: pl2303: add two comments concerning the supported baud rates with HX chips"
  Revert "pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup()"
  Revert "pl2303: improve the chip type information output on startup"
  Revert "pl2303: improve the chip type detection/distinction"
  Revert "USB: pl2303: distinguish between original and cloned HX chips"
  ...