ACPI / PM: Fix build problem when CONFIG_ACPI or CONFIG_PM is not set

Commit e5cc8ef (ACPI / PM: Provide ACPI PM callback routines for
subsystems) introduced a build problem occuring if CONFIG_ACPI is
unset or CONFIG_PM is unset and errno.h is not included before
acpi.h, because in that case ENODEV used in acpi.h is undefined.

Fix the issue by making acpi.h include errno.h.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'acpi-dev-pm-next' into linux-next

* acpi-dev-pm-next:
  ACPI / PM: Fix build problem when CONFIG_ACPI or CONFIG_PM is not set
ACPI / memory-hotplug: introduce a mutex lock to protect the list in acpi_memory_device

The memory device can be removed by 2 ways:
 1. send eject request by SCI
 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject

This 2 events may happen at the same time, so we may touch
acpi_memory_device.res_list at the same time. This patch
introduce a lock to protect this list.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / memory-hotplug: deal with eject request in hotplug queue

The memory device can be removed by 2 ways:
 1. send eject request by SCI
 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject

We handle the 1st case in the module acpi_memhotplug, and handle
the 2nd case in ACPI eject notification. This 2 events may happen
at the same time, so we may touch acpi_memory_device.res_list at
the same time. This patch reimplements memory-hotremove support
through an ACPI eject notification. Now the memory device is
offlined and hotremoved only in the function acpi_memory_device_remove()
which is protected by device_lock().

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / memhotplug: fix memory leak when memory device is unbound from acpi_memhotplug

We allocate memory to store acpi_memory_info, so we should free it before
freeing mem_device.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / memhotplug: free memory device if acpi_memory_enable_device() failed

If acpi_memory_enable_device() fails, acpi_memory_enable_device() will
return a non-zero value, which means we fail to bind the memory device to
this driver.  So we should free memory device before
acpi_memory_device_add() returns.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'acpi-general-next' into linux-next

* acpi-general-next:
  ACPI / memhotplug: free memory device if acpi_memory_enable_device() failed
  ACPI / memhotplug: fix memory leak when memory device is unbound from acpi_memhotplug
  ACPI / memory-hotplug: deal with eject request in hotplug queue
  ACPI / memory-hotplug: introduce a mutex lock to protect the list in acpi_memory_device