Add support for the ACPI_NFIT_MEM_MAP_FAILED ("map_fail") and
ACPI_NFIT_MEM_HEALTH_ENABLED ("smart_notify") health state flags. The
"map_fail" flag identifies DIMMs that were not mapped into one or more
physical address ranges. The "health_notify" flag indicates whether
platform firmware will send notifications when there is new SMART health
data to consume.
Acked-by: NToshi Kani <toshi.kani@hpe.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Calls to acpi_get_table() must be paired with acpi_put_table() to undo
the mapping established by acpi_tb_acquire_table().

It turns out this has no effect in practice since the NFIT will already
be mapped to support the /sys/firmware/acpi/tables/NFIT attribute in
sysfs.

Fixes: 6b11d1d6 ("ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() users")
Cc: Lv Zheng <lv.zheng@intel.com>
Reported-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The newline in MODULE_PARM_DESC causes modinfo to print the parameter
data type on a separate line, which is different from all the other
module parameters and could potentially cause a problem for someone
parsing the output of modinfo.
Signed-off-by: NLinda Knippers <linda.knippers@hpe.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Provide the ability to request a default DSM family. If it is not
supported, then fall back to the normal discovery order.

This is helpful for testing platforms that support multiple DSM
families.  It will also allow administrators to request the DSM family
that their management tools support, which may not be the first one
found using the current discovery order.
Signed-off-by: NLinda Knippers <linda.knippers@hpe.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

As it is today, we can't enable or test new NVDIMM management functions
provided by new firmware and tools without changing the kernel.  We also
can't prevent documented DSM functions from being called in the case of
buggy firmware.  This patch provides a module parameter that overrides
the DSM function mask that is built into the kernel.

If the "disable_vendor_specific" module parameter is also used we ignore
the new parameter.
Signed-off-by: NLinda Knippers <linda.knippers@hpe.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

While reviewing the -stable patch for commit 86ef58a4 "nfit,
libnvdimm: fix interleave set cookie calculation" Ben noted:

    "This is returning an int, thus it's effectively doing a 32-bit
     comparison and not the 64-bit comparison you say is needed."

Update the compare operation to be immune to this integer demotion problem.

Cc: <stable@vger.kernel.org>
Cc: Nicholas Moulin <nicholas.w.moulin@linux.intel.com>
Fixes: 86ef58a4 ("nfit, libnvdimm: fix interleave set cookie calculation")
Reported-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

For Qualcomm Technologies QDF2400 SOCs that are affected by erratum E44,
the ACPI oem_revision field is actually set to 1, not 0.

Fixes: d8a4995b ("tty: pl011: Work around QDF2400 E44 stuck BUSY bit")
Tested-by: NManoj Iyer <manoj.iyer@canonical.com>
Signed-off-by: NTimur Tabi <timur@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The check for duplicate processor ids happens at boot time based on the
ACPI table contents, but the final sanity checks for a processor happen
at hotplug time.

At hotplug time, where the physical information is available, which might
differ from the ACPI table information, a check for duplicate processor
ids is missing.

Add it to the hotplug checks and rename the function so it better
reflects its purpose.
Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
Tested-by: NXiaolong Ye <xiaolong.ye@intel.com>
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: guzheng1@huawei.com
Cc: izumi.taku@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1488528147-2279-6-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

ACPI allows to declare processors either with the PROCESSOR or with the
DEVICE operator. The current implementation handles only the PROCESSOR
operator.

On a system which uses the DEVICE operator for processor enumeration the
evaluation fails.

Check for the ACPI type of the ACPI handle and evaluate PROCESSOR and
DEVICE types separately.
Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
Tested-by: NXiaolong Ye <xiaolong.ye@intel.com>
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: guzheng1@huawei.com
Cc: izumi.taku@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1488528147-2279-5-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Revert: 8ad893fa ("x86/acpi: Enable MADT APIs to return disabled apicids")

Remove the leftovers of the boot time 'cpuid <-> nodeid' mapping approach.
Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
Tested-by: NXiaolong Ye <xiaolong.ye@intel.com>
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: guzheng1@huawei.com
Cc: izumi.taku@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1488528147-2279-3-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

Revert: dc6db24d ("x86/acpi: Set persistent cpuid <-> nodeid mapping when booting")

The mapping of "cpuid <-> nodeid" is established at boot time via ACPI
tables to keep associations of workqueues and other node related items
consistent across cpu hotplug.

But, ACPI tables are unreliable and failures with that boot time mapping
have been reported on machines where the ACPI table and the physical
information which is retrieved at actual hotplug is inconsistent.

Revert the mapping implementation so it can be replaced with a less error
prone approach.
Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
Tested-by: NXiaolong Ye <xiaolong.ye@intel.com>
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: guzheng1@huawei.com
Cc: izumi.taku@jp.fujitsu.com
Cc: lenb@kernel.org
Link: http://lkml.kernel.org/r/1488528147-2279-2-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

We are going to move scheduler ABI details to <uapi/linux/sched/types.h>,
which will be used from a number of .c files.

Create empty placeholder header that maps to <linux/types.h>.

Include the new header in the files that are going to need it.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

We are going to split <linux/sched/clock.h> out of <linux/sched.h>, which
will have to be picked up from other headers and .c files.

Create a trivial placeholder <linux/sched/clock.h> file that just
maps to <linux/sched.h> to make this patch obviously correct and
bisectable.

Include the new header in the files that are going to need it.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

The hot removal of IOAPIC is handling PCI and ACPI removal in one go. That
only works when the PCI drivers released the interrupt resources, but
breaks when a IOAPIC interrupt is still associated to a PCI device.

The new pcibios_release_device() callback allows to solve that problem by
splitting the removal into two steps:

1) PCI removal:

   Release all PCI resources including eventually not yet released IOAPIC
   interrupts via the new pcibios_release_device() callback.

2) ACPI removal:

   After release of all PCI resources the ACPI resources can be released
   without issue.

[ tglx: Rewrote changelog ]
Signed-off-by: NRui Wang <rui.y.wang@intel.com>
Cc: tony.luck@intel.com
Cc: linux-pci@vger.kernel.org
Cc: rjw@rjwysocki.net
Cc: linux-acpi@vger.kernel.org
Cc: fengguang.wu@intel.com
Cc: helgaas@kernel.org
Cc: kbuild-all@01.org
Cc: bhelgaas@google.com
Link: http://lkml.kernel.org/r/1488288869-31290-3-git-send-email-rui.y.wang@intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

The interleave-set cookie is a sum that sanity checks the composition of
an interleave set has not changed from when the namespace was initially
created.  The checksum is calculated by sorting the DIMMs by their
location in the interleave-set. The comparison for the sort must be
64-bit wide, not byte-by-byte as performed by memcmp() in the broken
case.

Fix the implementation to accept correct cookie values in addition to
the Linux "memcmp" order cookies, but only allow correct cookies to be
generated going forward. It does mean that namespaces created by
third-party-tooling, or created by newer kernels with this fix, will not
validate on older kernels. However, there are a couple mitigating
conditions:

    1/ platforms with namespace-label capable NVDIMMs are not widely
       available.

    2/ interleave-sets with a single-dimm are by definition not affected
       (nothing to sort). This covers the QEMU-KVM NVDIMM emulation case.

The cookie stored in the namespace label will be fixed by any write the
namespace label, the most straightforward way to achieve this is to
write to the "alt_name" attribute of a namespace in sysfs.

Cc: <stable@vger.kernel.org>
Fixes: eaf96153 ("libnvdimm, nfit: add interleave-set state-tracking infrastructure")
Reported-by: NNicholas Moulin <nicholas.w.moulin@linux.intel.com>
Tested-by: NNicholas Moulin <nicholas.w.moulin@linux.intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Fix typos and add the following to the scripts/spelling.txt:

  overrided||overridden

Link: http://lkml.kernel.org/r/1481573103-11329-22-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix typos and add the following to the scripts/spelling.txt:

  intialization||initialization

The "inintialization" in drivers/acpi/spcr.c is a different pattern but
I fixed it as well in this commit.

Link: http://lkml.kernel.org/r/1481573103-11329-16-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix typos and add the following to the scripts/spelling.txt:

  an union||a union

Link: http://lkml.kernel.org/r/1481573103-11329-5-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It was reported that on some machines, there is overlap between ACPI
NVS area and BERT address range.  This appears reasonable because BERT
contents need to be non-volatile across reboot.  But this will cause
resources conflict in current Linux kernel implementation because the
ACPI NVS area is marked as busy.  The resource conflict is fixed via
excluding the ACPI NVS area when requesting IO resources for BERT.
When accessing the BERT contents, the whole BERT address range will be
ioremapped and accessed.
Reported-and-tested-by: NHans Kristian Rosbach <hansr@raskesider.no>
Signed-off-by: NYing Huang <ying.huang@intel.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a
custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the
BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1
and 2400v1 SoCs.Checking that the Transmit FIFO Empty (TXFE) bit is 0,
instead of checking that the BUSY bit is 1, works around the issue.

To facilitate this substitution of flags and values, introduce
vendor-specific inversion of Feature Register bits when UART AMBA Port
(UAP) data is available. For the earlycon case, prior to UAP availability,
implement alternative putc and early_write functions.

Similar to what how ARMv8 ACPI PCI quirks are detected during MCFG parsing,
check the OEM fields of the Serial Port Console Redirection (SPCR) ACPI
table to determine if the current platform is known to be affected by the
erratum.
Signed-off-by: NChristopher Covington <cov@codeaurora.org>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Acked-by: NTimur Tabi <timur@codeaurora.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On x86 we do not have devicetree to link the PWM controller and
the display controller together. So someone needs to call
pwm_add_table() to create the link, so that the i915 driver's
pwm_get(dev, "pwm_backlight") call returns the lpss' pwm0.

The PWM subsystem does not want to have pwm_add_table() calls
directly in PWM drivers (this leads to probe ordering issues),
so lets do it here since the acpi-lpss code is always builtin.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

Rename the function to iommu_ops_from_fwnode(), because that
is what the function actually does. The new name is much
more descriptive about what the function does.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

ipmi_create_user() now takes the user handlers as const, make
it const in the ACPI IPMI code.

Cc: linux-acpi@vger.kernel.org
Cc: Zhao Yakui <yakui.zhao@intel.com>
Cc: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>

ACPICA commit 43e04e75a9849072a1557b674004d8093bddb9ef

Remove the bit width of the compiler that generated the tool
from the tool signon. This was confusing and unnecessary.

Changed the iASL signon to add "disassembler" to the name.

Link: https://github.com/acpica/acpica/commit/43e04e75Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 16577e5265923f4999b4d2c0addb2343b18135e1

Affects all files.

Link: https://github.com/acpica/acpica/commit/16577e52Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We may or may not have all possible CPUs in MADT on boot but in any
case we're overwriting x86_cpu_to_acpiid mapping with U32_MAX when
acpi_register_lapic() is called again on the CPU hotplug path:

acpi_processor_hotadd_init()
  -> acpi_map_cpu()
    -> acpi_register_lapic()

As we have the required acpi_id information in acpi_processor_hotadd_init()
propagate it to acpi_map_cpu() to always keep x86_cpu_to_acpiid
mapping valid.
Reported-by: NAndrew Jones <drjones@redhat.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When using devicetree stuff like i2c_client.name or spi_device.modalias
is initialized to the first DT compatible id with the vendor prefix
stripped. Since some drivers rely on this try to replicate it when using
ACPI with DT ids.
Signed-off-by: NDan O'Donovan <dan@emutex.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The function iort_add_smmu_platform_device() accidentally returns 0
(ie PTR_ERR(pdev) where pdev == NULL) if platform_device_alloc() fails;
fix the bug by returning a proper error value.

Fixes: 846f0e9e ("ACPI/IORT: Add support for ARM SMMU platform devices creation")
Acked-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
[lorenzo.pieralisi@arm.com: improved commit log]
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Commit 618f535a ("ACPI/IORT: Add single mapping function")
introduced a function (iort_node_get_id()) to retrieve ids for IORT
named components.

The iort_node_get_id() takes an index as input to refer to a specific
mapping entry in the named component IORT node mapping array.

For a mapping entry at a given index, iort_node_get_id() should return
the id value (through the id_out function parameter) and the IORT node
output_reference (through function return value) the given mapping entry
refers to.

Technically output_reference values may differ for different map
entries, (see diagram below - mapped id values may refer to different eg
IORT SMMU nodes; the kernel may not be able to handle different
output_reference values for a given named component but the IORT kernel
layer should still report the IORT mappings as reported by firmware) but
current code in iort_node_get_id() fails to use the index function
parameter to return the correct output_reference value (ie it always
returns the output_reference value of the first entry in the mapping
array whilst using the index correctly to retrieve the id value from the
respective entry).

	|----------------------|
	|     named component  |
	|----------------------|
	|      map entry[0]    |
	|----------------------|
	|       id value       |
	| output_reference----------------> eg SMMU 1
	|----------------------|
	|      map entry[1]    |
	|----------------------|
	|       id value       |
	| output_reference----------------> eg SMMU 2
	|----------------------|
		    .
		    .
		    .
	|----------------------|
	|      map entry[N]    |
	|----------------------|
	|       id value       |
	| output_reference----------------> eg SMMU 1
	|----------------------|

Consequently the iort_node_get_id() function always returns the IORT
node pointed at by the output_reference value of the first named
component mapping array entry, irrespective of the index parameter,
which is a bug.

Update the map array entry pointer computation in iort_node_get_id() to
take into account the index value, fixing the issue.

Fixes: 618f535a ("ACPI/IORT: Add single mapping function")
Reported-by: NHanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Sinan Kaya <okaya@codeaurora.org>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: Nate Watterson <nwatters@codeaurora.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

acpi_processor_ppc_notifier() can live without using CPUFREQ_START
(which is gonna be removed soon), as it is only used while setting
ignore_ppc to 0. This can be done with the help of "ignore_ppc < 0"
check alone. The notifier function anyway ignores all events except
CPUFREQ_ADJUST and dropping CPUFREQ_START wouldn't harm at all.

Once CPUFREQ_START event is removed from the cpufreq core,
acpi_processor_ppc_notifier() will get called only for CPUFREQ_NOTIFY or
CPUFREQ_ADJUST event. Drop the return statement from the first if block
to make sure we don't ignore any such events.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We queue an on-stack work item to 'nfit_wq' and wait for it to complete
as part of a 'flush_probe' request. However, if the user cancels the
wait we need to make sure the item is flushed from the queue otherwise
we are leaving an out-of-scope stack address on the work list.

 BUG: unable to handle kernel paging request at ffffbcb3c72f7cd0
 IP: [<ffffffffa9413a7b>] __list_add+0x1b/0xb0
 [..]
 RIP: 0010:[<ffffffffa9413a7b>]  [<ffffffffa9413a7b>] __list_add+0x1b/0xb0
 RSP: 0018:ffffbcb3c7ba7c00  EFLAGS: 00010046
 [..]
 Call Trace:
  [<ffffffffa90bb11a>] insert_work+0x3a/0xc0
  [<ffffffffa927fdda>] ? seq_open+0x5a/0xa0
  [<ffffffffa90bb30a>] __queue_work+0x16a/0x460
  [<ffffffffa90bbb08>] queue_work_on+0x38/0x40
  [<ffffffffc0cf2685>] acpi_nfit_flush_probe+0x95/0xc0 [nfit]
  [<ffffffffc0cf25d0>] ? nfit_visible+0x40/0x40 [nfit]
  [<ffffffffa9571495>] wait_probe_show+0x25/0x60
  [<ffffffffa9546b30>] dev_attr_show+0x20/0x50

Fixes: 7ae0fa43 ("nfit, libnvdimm: async region scrub workqueue")
Cc: <stable@vger.kernel.org>
Reviewed-by: NVishal Verma <vishal.l.verma@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

ACPI extended IRQ resources may contain a ResourceSource to specify
an alternate interrupt controller. Introduce acpi_irq_get and use it
to implement ResourceSource/IRQ domain mapping.

The new API is similar to of_irq_get and allows re-initialization
of a platform resource from the ACPI extended IRQ resource, and
provides proper behavior for probe deferral when the domain is not
yet present when called.
Acked-by: NRafael J. Wysocki <rafael@kernel.org>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NAgustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

ACPI extended IRQ resources may contain a Resource Source field to specify
an alternate interrupt controller, attempting to map them as GSIs is
incorrect, so just disable the platform resource.

Since this field is currently ignored, we make this change conditional
on CONFIG_ACPI_GENERIC_GSI to keep the current behavior on x86 platforms,
in case some existing ACPI tables are using this incorrectly.
Acked-by: NRafael J. Wysocki <rafael@kernel.org>
Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
Tested-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NAgustin Vega-Frias <agustinv@codeaurora.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>

Before invoking the arch specific handler, efi_mem_reserve() reserves
the given memory region through memblock.

efi_bgrt_init() will call efi_mem_reserve() after mm_init(), at which
time memblock is dead and should not be used anymore.

The EFI BGRT code depends on ACPI initialization to get the BGRT ACPI
table, so move parsing of the BGRT table to ACPI early boot code to
ensure that efi_mem_reserve() in EFI BGRT code still use memblock safely.
Tested-by: NBhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: NDave Young <dyoung@redhat.com>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-acpi@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1485868902-20401-9-git-send-email-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

In commit 821d6f03 (ACPI / sleep: Do not save NVS for new machines to
accelerate S3), to optimize S3 suspend/resume speed, code is introduced
to ignore NVS memory saving during S3 for all the platforms later than
2012.

But, Lenovo G50-45, a platform released in 2015, still needs NVS memory
saving during S3. A quirk is introduced for this platform.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=189431Tested-by: NPrzemek <soprwa@gmail.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
[ rjw: Drop unnecessary code ]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The pr_warn message has a malformed newline escape, add in the
missing \
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The mode is buggy, and lid_init__state=open is more useful than this
mode, so this patch makes it deprecated.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

More and more platforms need the button.lid_init_state=open quirk. This
patch sets it the default behavior.

If a platform doesn't send lid open event or lid open event is lost due to
the underlying system problems, then we can compare various combinations:
1. systemd/acpid is used to suspend system or not, systemd has a special
   logic forcing open event after resuming;
2. _LID returns a cached value or not.

The result is as follows:

 1. lid_init_state=method
   1. cached
      1. resumed by lid:
         (x) event=close
         (x) systemd=suspends again
         (x) acpid=suspends again
         (x) state=close
      2. resumed by other:
         (o) event=close
         (x) systemd=suspends again
         (x) acpid=suspends again
         (o) state=close
   2. non-cached
      1. resumed by lid:
         (o) event=open
         (o) systemd=resumes
         (o) acpid=resumes
         (o) state=open
      2. resumed by other:
         (o) event=close
         (x) systemd=suspends again
         (x) acpid=suspends again
         (o) state=close
 2. lid_init_state=open
   1. cached
      1. resumed by lid:
         (o) event=open
         (o) systemd=resumes
         (o) acpid=resumes
         (x) state=close
      2. resumed by other:
         (x) event=open
         (o) systemd=resumes
         (o) acpid=resumes
         (o) state=close
   2. non-cached
      1. resumed by lid:
         (o) event=open
         (o) systemd=resumes
         (o) acpid=resumes
         (o) state=open
      2. resumed by other:
         (x) event=open
         (o) systemd=resumes
         (o) acpid=resumes
         (o) state=close
 3. lid_init_state=ignore
   1. cached
      1. resumed by lid:
         (o) event=none
         (x) systemd=suspends again
         (o) acpid=resumes
         (x) state=close
      2. resumed by other:
         (o) event=none
         (x) systemd=suspends again
         (o) acpid=resumes
         (o) state=close
   2. non-cached
      1. resumed by lid:
         (o) event=none
         (x) systemd=suspends again
         (o) acpid=resumes
         (o) state=open
      2. resumed by other:
         (o) event=none
         (x) systemd=suspends again
         (o) acpid=resumes
         (o) state=close

As a conclusion:
 1. With systemd changed, lid_init_state=ignore has only one problem and the
    problem comes from an underlying issue, not userspace and kernel lid
    handling.
 2. Without systemd changed, lid_init_state=open can be the default
    behavior as the pass ratio is not much worse than lid_init_state=ignore.
 3. lid_init_state=method is buggy, we can have a separate patch to make it
    deprectated.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=187271Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When GPE is not enabled, it is not efficient to use the wait polling mode
as it introduces an unexpected scheduler delay.
So before the GPE handler is installed, this patch uses busy polling mode
for all EC(s) and the logic can be applied to non boot EC(s) during the
suspend/resume process.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=191561Tested-by: NJakobus Schurz <jakobus.schurz@gmail.com>
Tested-by: NChen Yu <yu.c.chen@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

IRQ polling logic has been implemented to drain the post-boot/resume
EC events:

 1. Triggered by the following code, invoked from acpi_ec_enable_event():

	if (!test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags))
		advance_transaction(ec);

 2. Drained by the following code, invoked after acpi_ec_complete_query():

	if (status & ACPI_EC_FLAG_SCI)
		acpi_ec_submit_query(ec);

This facility is safer than the old CLEAR_ON_RESUME quirk as the
CLEAR_ON_RESUME quirk sends EC query commands unconditionally. The
behavior is apparently not suitable for firmware that requires
QUERY_HANDSHAKE quirk. Though the QUERY_HANDSHAKE quirk isn't used
now because of the improvement done in the EC transaction state
machine (ec_event_clearing=QUERY), it is the proof that we cannot
send EC query command unconditionally.

So it's time to delete the out-dated CLEAR_ON_RESUME quirk to let the
users to try the newer approach.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=191211Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>