ACPI / memory-hotplug: add memory offline code to acpi_memory_device_remove()

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

In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be called.
acpi_memory_device_remove() will also be called when we unbind the
memory device from the driver acpi_memhotplug or a driver initialization
fails.

acpi_memory_disable_device() has already implemented a code which
offlines memory and releases acpi_memory_info struct. But
acpi_memory_device_remove() has not implemented it yet.

So the patch move offlining memory and releasing acpi_memory_info struct
codes to a new function acpi_memory_remove_memory(). And it is used by both
acpi_memory_device_remove() and acpi_memory_disable_device().

Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
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 / memhotplug: 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>
ACPI / memhotplug: don't allow to eject the memory device if it is being used

We eject the memory device even if it is in use.  It is very dangerous,
and it will cause the kernel to be panicked.

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: bind the memory device when the driver is being loaded

We had introduced acpi_hotmem_initialized to avoid strange add_memory fail
message.  But the memory device may not be used by the kernel, and the
device should be bound when the driver is being loaded.  Remove
acpi_hotmem_initialized to allow that the device can be bound when the
driver is being loaded.

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: create _SUN sysfs file

_SUN method provides the slot unique-ID in the ACPI namespace. And The value
is written in Advanced Configuration and Power Interface Specification as
follows:

"The _SUN value is required to be unique among the slots ofthe same type.
It is also recommended that this number match the slot number printed on
the physical slot whenever possible."

So if we can know the value, we can identify the physical position of the
slot in the system.

The patch creates "sun" file in sysfs for identifying physical position
of the slot.

Signed-off-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>
Revert "ACPI / x86: Add quirk for "CheckPoint P-20-00" to not use bridge _CRS_ info"

This reverts commit 0a290ac4252c85205cb924ff7f6da10cfd20fb01 on
the basis of the following comment from Bjorn Helgaas:

  Here's my reasoning: this is a CheckPoint product, and it looks
  like an appliance, not really a general-purpose machine.  The issue
  has apparently been there from day one, and the kernel shipped on
  the machine complains noisily about the issue, but apparently
  nobody bothered to investigate it.

  This corruption will clearly break other ACPI-related things.  We
  can sort of work around this one (though the workaround does
  prevent us from doing any PCI resource reassignment), but we have
  no idea what the other lurking ACPI issues are (and we have no
  assurance that *only* ACPI things are broken -- maybe the
  memory corruption affects other unknown things).  It may take
  significant debugging effort to identify the next problem.

  The only report I've seen (this one) is apparently from a
  CheckPoint employee, so it's not clear that anybody else is trying
  to run upstream Linux on it.  Being a CheckPoint employee, [...]
  is probably in a position to get the BIOS fixed.

  You might still be able to convince me, but it seems like the
  benefit to a quirk for this platform is small, and it does cost
  everybody else something in code size and complexity.

References: https://bugzilla.kernel.org/show_bug.cgi?id=47981#c36
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / battery: Correct battery capacity values on Thinkpads

Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.

The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong.  Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected.  Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS).  No such update is available
for the 2010 models, so those still need this patch.

Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect.  The values reported in mAh are *always* wrong.  This does
not appear to be a kernel regression; I believe that the values were
never reported correctly.  I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.

Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem.  Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:

present:                 yes
design capacity:         2886 mAh
last full capacity:      2909 mAh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 145 mAh
design capacity low:     13 mAh
cycle count:              0
capacity granularity 1:  1 mAh
capacity granularity 2:  1 mAh
model number:            42T4899
serial number:           21064
battery type:            LION
OEM info:                SANYO

Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:

present:                 yes
design capacity:         28860 mWh
last full capacity:      29090 mWh
battery technology:      rechargeable
design voltage:          14800 mV
design capacity warning: 1454 mWh
design capacity low:     200 mWh
cycle count:              0
capacity granularity 1:  1 mWh
capacity granularity 2:  1 mWh
model number:            42T4899
serial number:           21064
battery type:            LION
OEM info:                SANYO

Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.

My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.

My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage".  The patch also has
code to figure out if it should be activated or not.  It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).

I've been using this patch for close to a year on several systems
without any problems.

References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>