Was acpi_gbl_parse_table_as_term_list, changed to:
acpi_gbl_execute_tables_as_methods.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Fixing the ACPI_ERROR_NAMESPACE macros created an "unused variable"
compile error when ACPI_NO_ERROR_MESSAGES was defined. This commit
also fixes the above compilation errors by surrounding variables
meant for debugging inside a new ACPI_ERROR_ONLY macro.
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Changes the option to ignore package resolution errors into
a runtime option.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As the documentatuon above its declaration indicates, acpi_get_object_info()
is intended for early probe usage and as such should not call any methods
which may rely on op_regions, before this commit it was also calling _STA,
which on some systems does rely on op_regions.

Calling _STA before things are ready leads to errors such as these
(under Linux, on some hardware):

[    0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c)
               [generic_serial_bus] (20170831/evregion-166)
[    0.123601] ACPI Error: Region generic_serial_bus (ID=9) has no handler
               (20170831/exfldio-299)
[    0.123618] ACPI Error: Method parse/execution failed
               \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550)

End 2015 support for the _SUB method was removed for exactly the same
reason. Removing current_status from struct acpi_device_info only has a limited
impact. Within ACPICA it is only used by 2 debug messages, both
of which are modified to no longer print it with this commit.

Outside of ACPICA, there was one user in Linux, which has been patched to
no longer use current_status in Torvald's current master.

I've not checked if free_BSD or others are using the current_status field.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The implementation previously ignored null strings (""), but
these could be important, especially for debug.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Fixes a single-object memory leak on a store-to-reference method
invocation. ACPICA BZ 1439.
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

After being enabled for the first time, the GPEs may have STS bits already
set. Setting EN bits is not sufficient to trigger the GPEs again, so this
patch polls GPEs after enabling them for the first time.
This is a cleaner version on top of the "GPE clear" fix generated according
to Mika's report and Rafael's original Linux based fix. Based on Linux
commit originated from Rafael J. Wysocki, fixed by Lv Zheng.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is a risk that a GPE method/handler may be invoked twice. Let's
consider a case, both GPE0(RAW_HANDLER) and GPE1(_Exx) is triggered.
 =======================================+=============================
 IRQ handler (top-half)                 |IRQ polling
 =======================================+=============================
 acpi_ev_detect_gpe()                   |
   LOCK()                               |
   READ (GPE0-7 enable/status registers)|
   ^^^^^^^^^^^^ROOT CAUSE^^^^^^^^^^^^^^^|
   Walk GPE0                            |
     UNLOCK()                           |LOCK()
     Invoke GPE0 RAW_HANDLER            |READ (GPE1 enable/status bit)
                                        |acpi_ev_gpe_dispatch(irq=false)
                                        |  CLEAR (GPE1 enable bit)
                                        |  CLEAR (GPE1 status bit)
     LOCK()                             |UNLOCK()
   Walk GPE1                            +=============================
     acpi_ev_gpe_dispatch(irq=true)     |IRQ polling (defer)
       CLEAR (GPE1 enable bit)          +=============================
       CLEAR (GPE1 status bit)          |acpi_ev_async_execute_gpe_method()
   Walk others                          |  Evaluate GPE1 _Exx
   fi                                   |  acpi_ev_async_enable_gpe()
   UNLOCK()                             |    LOCK()
 =======================================+    SET (GPE enable bit)
 IRQ handler (bottom-half)              |    UNLOCK()
 =======================================+
 acpi_ev_async_execute_gpe_method()     |
   Evaluate GPE1 _Exx                   |
   acpi_ev_async_enable_gpe()           |
     LOCK()                             |
     SET (GPE1 enable bit)              |
     UNLOCK()                           |
 =======================================+=============================

If acpi_ev_detect_gpe() is only invoked from the IRQ context, there won't be
more than one _Lxx/_Exx evaluations for one status bit flagging if the IRQ
handlers controlled by the underlying IRQ chip/driver (ex. APIC) are run in
serial. Note that, this is a known potential gap and we had an approach,
locking entire non-raw-handler processes in the top-half IRQ handler and
handling all raw-handlers out of the locked loop to be friendly to those
IRQ chip/driver. But the approach is too complicated while the issue is not
so real, thus ACPICA treated such issue (if any) as a parallelism/quality
issue of the underlying IRQ chip/driver to stop putting it on the radar.
Bug in link #1 is suspiciously reflecting the same cause, and if so, it can
also be fixed by this simpler approach.

But it will be no excuse an ACPICA problem now if ACPICA starts to poll
IRQs itself. In the changed scenario, _Exx will be evaluated from the task
context due to new ACPICA provided "polling after enabling GPEs" mechanism.
And the above figure uses edge-triggered GPEs demonstrating the possibility
of evaluating _Exx twice for one status bit flagging.

As a conclusion, there is now an increased chance of evaluating _Lxx/_Exx
more than once for one status bit flagging.

However this is still not a real problem if the _Lxx/_Exx checks the
underlying hardware IRQ reasoning and finally just changes the 2nd and the
follow-up evaluations into no-ops. Note that _Lxx should always be written
in this way as a level-trigger GPE could have it's status wrongly
duplicated by the underlying IRQ delivery mechanisms. But _Exx may have
very low quality BIOS by BIOS to trigger real issues. For example, trigger
duplicated button notifications.

To solve this issue, we need to stop reading a bunch of enable/status
register bits, but read only one GPE's enable/status bit. And GPE status
register's W1C nature ensures that acknowledging one GPE won't affect
another GPEs' status bits. Thus the hardware GPE architecture has already
provided us with the mechanism of implementing such parallelism.

So we can lock around one GPE handling process to achieve the parallelism:
1. If we can incorporate GPE enable bit check in detection and ensure the
   atomicity of the following process (top-half IRQ handler):
    READ (enable/status bit)
    if (enabled && raised)
      CLEAR (enable bit)
   and handle the GPE after this process, we can ensure that we will only
   invoke GPE handler once for one status bit flagging.
2. In addtion for edge-triggered GPEs, if we can ensure the atomicity of
   the following process (top-half IRQ handler):
    READ (enable/status bit)
    if (enabled && raised)
      CLEAR (enable bit)
      CLEAR (status bit)
   and handle the GPE after this process, we can ensure that we will only
   invoke GPE handler once for one status bit flagging.

By doing a cleanup in this way, we can remove duplicate GPE handling code
and ensure that all logics are collected in 1 function. And the function
will be safe for both IRQ interrupt and IRQ polling, and will be safe for
us to release and re-acquire acpi_gbl_gpe_lock at any time rather than raw
handler only during the top-half IRQ handler. Lv Zheng.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=196703 [#1]
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Unconditionally clearing ACPI IRQs during suspend/resume can lead to
unexpected IRQ losts. This patch fixes this issue by removing such IRQ
clearing code.

If this patch triggers regression, the regression should be in the GPE
handlers that cannot correctly determine some spurious triggered events as
no-ops. Please report any regression related to this commit to the ACPI
component on kernel bugzilla. Lv Zheng.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=196249Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Reported-and-tested-by: NEric Bakula-Davis <ericbakuladavis@gmail.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

I found an ACPI cache leak in ACPI early termination and boot continuing case.

When early termination occurs due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.

Boot log of ACPI operand cache leak is as follows:
>[    0.464168] ACPI: Added _OSI(Module Device)
>[    0.467022] ACPI: Added _OSI(Processor Device)
>[    0.469376] ACPI: Added _OSI(3.0 _SCP Extensions)
>[    0.471647] ACPI: Added _OSI(Processor Aggregator Device)
>[    0.477997] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174)
>[    0.482706] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461)
>[    0.487503] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
>[    0.492136] ACPI Error: Method parse/execution failed [\_SB._INI] (Node ffff88021710a618), AE_AML_INTERNAL (20170303/psparse-543)
>[    0.497683] ACPI: Interpreter enabled
>[    0.499385] ACPI: (supports S0)
>[    0.501151] ACPI: Using IOAPIC for interrupt routing
>[    0.503342] ACPI Error: Null stack entry at ffff880215c0aad8 (20170303/exresop-174)
>[    0.506522] ACPI Exception: AE_AML_INTERNAL, While resolving operands for [opcode_name unavailable] (20170303/dswexec-461)
>[    0.510463] ACPI Error: Method parse/execution failed [\DBG] (Node ffff88021710ab40), AE_AML_INTERNAL (20170303/psparse-543)
>[    0.514477] ACPI Error: Method parse/execution failed [\_PIC] (Node ffff88021710ab18), AE_AML_INTERNAL (20170303/psparse-543)
>[    0.518867] ACPI Exception: AE_AML_INTERNAL, Evaluating _PIC (20170303/bus-991)
>[    0.522384] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[    0.524597] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[    0.526795] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006
>[    0.529668] Call Trace:
>[    0.530811]  ? dump_stack+0x5c/0x81
>[    0.532240]  ? kmem_cache_destroy+0x1aa/0x1c0
>[    0.533905]  ? acpi_os_delete_cache+0xa/0x10
>[    0.535497]  ? acpi_ut_delete_caches+0x3f/0x7b
>[    0.537237]  ? acpi_terminate+0xa/0x14
>[    0.538701]  ? acpi_init+0x2af/0x34f
>[    0.540008]  ? acpi_sleep_proc_init+0x27/0x27
>[    0.541593]  ? do_one_initcall+0x4e/0x1a0
>[    0.543008]  ? kernel_init_freeable+0x19e/0x21f
>[    0.546202]  ? rest_init+0x80/0x80
>[    0.547513]  ? kernel_init+0xa/0x100
>[    0.548817]  ? ret_from_fork+0x25/0x30
>[    0.550587] vgaarb: loaded
>[    0.551716] EDAC MC: Ver: 3.0.0
>[    0.553744] PCI: Probing PCI hardware
>[    0.555038] PCI host bridge to bus 0000:00
> ... Continue to boot and log is omitted ...

I analyzed this memory leak in detail and found acpi_ns_evaluate() function
only removes Info->return_object in AE_CTRL_RETURN_VALUE case. But, when errors
occur, the status value is not AE_CTRL_RETURN_VALUE, and Info->return_object is
also not null. Therefore, this causes acpi operand memory leak.

This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.

I made a patch to fix ACPI operand cache leak.
Signed-off-by: NSeunghun Han <kkamagui@gmail.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 6e3468837f9f32f64c7d0a6e20bf0d2579411d43

Version 20180209.

Link: https://github.com/acpica/acpica/commit/6e346883Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit a6c3c725c44dd44ad9d3f2b2a64351fdbe6e0014

For the kernel-resident ACPICA, optionally be silent about the
NOT_FOUND case. Although this is potentially a serious problem,
it can generate a lot of noise/errors on platforms whose
firmware carries around a bunch of unused Package objects.
To disable these errors, define ACPI_IGNORE_PACKAGE_RESOLUTION_ERRORS
in the OS-specific header.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=198167
Link: https://github.com/acpica/acpica/commit/a6c3c725Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7

This change completes the integration of the recent changes to
package object handling with the module-level code support.

For acpi_exec, the -ep flag is removed.

This change allows table load to behave as if it were a method
invocation. Before this, the definition block definition below would
have loaded all named objects at the root scope. After loading, it
would execute the if statements at the root scope.

DefinitionBlock (...)
{
  Name(OBJ1, 0)

  if (1)
  {
    Device (DEV1)
    {
      Name (_HID,0x0)
    }
  }
  Scope (DEV1)
  {
    Name (OBJ2)
  }
}

The above code would load OBJ1 to the namespace, defer the execution
of the if statement and attempt to add OBJ2 within the scope of DEV1.
Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error.
After this error is emitted, the if block is invoked and DEV1 and its
_HID is added to the namespace.

This commit changes the behavior to execute the if block in place
rather than deferring it until all tables are loaded. The new
behavior is as follows: insert OBJ1 in the namespace, invoke the if
statement and add DEV1 and its _HID to the namespace, add OBJ2 to the
scope of DEV1.

Bug report links:
Link: https://bugs.acpica.org/show_bug.cgi?id=963
Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196165
Link: https://bugzilla.kernel.org/show_bug.cgi?id=192621
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197207
Link: https://bugzilla.kernel.org/show_bug.cgi?id=198051
Link: https://bugzilla.kernel.org/show_bug.cgi?id=198515

ACPICA repo:
Link: https://github.com/acpica/acpica/commit/8faf6fcaTested-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 0e44fee13434766ebbb4d156e3ed45604508d7c3

This reverts commit e1342c9f2dde37a67e916099658b65984ef8a434.
Implicit conversion should in fact be disabled for the "explicit
conversion" operators. This is stated in the ACPI specification.
The operators affected are:
to_integer
to_string
to_buffer
to_decimal_string
to_hex_string
to_BCD
from_BCD

Link: https://github.com/acpica/acpica/commit/0e44fee1Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 3a08436fe3bff297a6de162252964e955946c7d3

Improve/simplify some of the debug messages.

Link: https://github.com/acpica/acpica/commit/3a08436fSigned-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit 0787fda3b224a78369e26ac6046658beb2b64c12

Clarify error when an attempt is made to evaluate things like
devices, events, etc. -- these objects have no data and cannot
be "evaluated".

Link: https://github.com/acpica/acpica/commit/0787fda3Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPICA commit a025731aec31745b775f7bdcd850c57d0a08298d

Split/restructure:
Table headers (actbl1*.h)
disassembler table info files (dmtbinfo*.c)
disassembler table dump files (dmtbdump*.c)

Adds 6 new files.

Link: https://github.com/acpica/acpica/commit/a025731aSigned-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull x86 Kconfig fixes from Thomas Gleixner:
 "Three patchlets to correct HIGHMEM64G and CMPXCHG64 dependencies in
  Kconfig when CPU selections are explicitely set to M586 or M686"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig
  x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group
  x86/Kconfig: Add missing i586-class CPUs to the X86_CMPXCHG64 Kconfig group

Pull perf updates from Thomas Gleixner:
 "Perf tool updates and kprobe fixes:

   - perf_mmap overwrite mode fixes/overhaul, prep work to get 'perf
     top' using it, making it bearable to use it in large core count
     systems such as Knights Landing/Mill Intel systems (Kan Liang)

   - s/390 now uses syscall.tbl, just like x86-64 to generate the
     syscall table id -> string tables used by 'perf trace' (Hendrik
     Brueckner)

   - Use strtoull() instead of home grown function (Andy Shevchenko)

   - Synchronize kernel ABI headers, v4.16-rc1 (Ingo Molnar)

   - Document missing 'perf data --force' option (Sangwon Hong)

   - Add perf vendor JSON metrics for ARM Cortex-A53 Processor (William
     Cohen)

   - Improve error handling and error propagation of ftrace based
     kprobes so failures when installing kprobes are not silently
     ignored and create disfunctional tracepoints"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (27 commits)
  kprobes: Propagate error from disarm_kprobe_ftrace()
  kprobes: Propagate error from arm_kprobe_ftrace()
  Revert "tools include s390: Grab a copy of arch/s390/include/uapi/asm/unistd.h"
  perf s390: Rework system call table creation by using syscall.tbl
  perf s390: Grab a copy of arch/s390/kernel/syscall/syscall.tbl
  tools/headers: Synchronize kernel ABI headers, v4.16-rc1
  perf test: Fix test trace+probe_libc_inet_pton.sh for s390x
  perf data: Document missing --force option
  perf tools: Substitute yet another strtoull()
  perf top: Check the latency of perf_top__mmap_read()
  perf top: Switch default mode to overwrite mode
  perf top: Remove lost events checking
  perf hists browser: Add parameter to disable lost event warning
  perf top: Add overwrite fall back
  perf evsel: Expose the perf_missing_features struct
  perf top: Check per-event overwrite term
  perf mmap: Discard legacy interface for mmap read
  perf test: Update mmap read functions for backward-ring-buffer test
  perf mmap: Introduce perf_mmap__read_event()
  perf mmap: Introduce perf_mmap__read_done()
  ...

Pull irq updates from Thomas Gleixner:
 "A small set of updates mostly for irq chip drivers:

   - MIPS GIC fix for spurious, masked interrupts

   - fix for a subtle IPI bug in GICv3

   - do not probe GICv3 ITSs that are marked as disabled

   - multi-MSI support for GICv2m

   - various small cleanups"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqdomain: Re-use DEFINE_SHOW_ATTRIBUTE() macro
  irqchip/bcm: Remove hashed address printing
  irqchip/gic-v2m: Add PCI Multi-MSI support
  irqchip/gic-v3: Ignore disabled ITS nodes
  irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
  irqchip/gic-v3: Change pr_debug message to pr_devel
  irqchip/mips-gic: Avoid spuriously handling masked interrupts

Pull core fix from Thomas Gleixner:
 "A small fix which adds the missing for_each_cpu_wrap() stub for the UP
  case to avoid build failures"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  cpumask: Make for_each_cpu_wrap() available on UP as well

Pull block fixes from Jens Axboe:

 - NVMe pull request from Keith, with fixes all over the map for nvme.
   From various folks.

 - Classic polling fix, that avoids a latency issue where we still end
   up waiting for an interrupt in some cases. From Nitesh Shetty.

 - Comment typo fix from Minwoo Im.

* tag 'for-linus-20180217' of git://git.kernel.dk/linux-block:
  block: fix a typo in comment of BLK_MQ_POLL_STATS_BKTS
  nvme-rdma: fix sysfs invoked reset_ctrl error flow
  nvmet: Change return code of discard command if not supported
  nvme-pci: Fix timeouts in connecting state
  nvme-pci: Remap CMB SQ entries on every controller reset
  nvme: fix the deadlock in nvme_update_formats
  blk: optimization for classic polling
  nvme: Don't use a stack buffer for keep-alive command
  nvme_fc: cleanup io completion
  nvme_fc: correct abort race condition on resets
  nvme: Fix discard buffer overrun
  nvme: delete NVME_CTRL_LIVE --> NVME_CTRL_CONNECTING transition
  nvme-rdma: use NVME_CTRL_CONNECTING state to mark init process
  nvme: rename NVME_CTRL_RECONNECTING state to NVME_CTRL_CONNECTING

Pull MMC fixes from Ulf Hansson:

 - meson-gx: Revert to earlier tuning process

 - bcm2835: Don't overwrite max frequency unconditionally

* tag 'mmc-v4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: bcm2835: Don't overwrite max frequency unconditionally
  Revert "mmc: meson-gx: include tx phase in the tuning process"

Pull mtd fixes from Boris Brezillon:

 - add missing dependency to NAND_MARVELL Kconfig entry

 - use the appropriate OOB layout in the VF610 driver

* tag 'mtd/fixes-for-4.16-rc2' of git://git.infradead.org/linux-mtd:
  mtd: nand: MTD_NAND_MARVELL should depend on HAS_DMA
  mtd: nand: vf610: set correct ooblayout

Pull powerpc fixes from Michael Ellerman:
 "The main attraction is a fix for a bug in the new drmem code, which
  was causing an oops on boot on some versions of Qemu.

  There's also a fix for XIVE (Power9 interrupt controller) on KVM, as
  well as a few other minor fixes.

  Thanks to: Corentin Labbe, Cyril Bur, Cédric Le Goater, Daniel Black,
  Nathan Fontenot, Nicholas Piggin"

* tag 'powerpc-4.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/pseries: Check for zero filled ibm,dynamic-memory property
  powerpc/pseries: Add empty update_numa_cpu_lookup_table() for NUMA=n
  powerpc/powernv: IMC fix out of bounds memory access at shutdown
  powerpc/xive: Use hw CPU ids when configuring the CPU queues
  powerpc: Expose TSCR via sysfs only on powernv

Pull arm64 fixes from Catalin Marinas:
 "The bulk of this is the pte accessors annotation to READ/WRITE_ONCE
  (we tried to avoid pushing this during the merge window to avoid
  conflicts)

   - Updated the page table accessors to use READ/WRITE_ONCE and prevent
     compiler transformation that could lead to an apparent loss of
     coherency

   - Enabled branch predictor hardening for the Falkor CPU

   - Fix interaction between kpti enabling and KASan causing the
     recursive page table walking to take a significant time

   - Fix some sparse warnings"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: cputype: Silence Sparse warnings
  arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables
  arm64: proc: Set PTE_NG for table entries to avoid traversing them twice
  arm64: Add missing Falkor part number for branch predictor hardening

Pull xen fixes from Juergen Gross:

 - fixes for the Xen pvcalls frontend driver

 - fix for booting Xen pv domains

 - fix for the xenbus driver user interface

* tag 'for-linus-4.16a-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  pvcalls-front: wait for other operations to return when release passive sockets
  pvcalls-front: introduce a per sock_mapping refcount
  x86/xen: Calculate __max_logical_packages on PV domains
  xenbus: track caller request id

Passive sockets can have ongoing operations on them, specifically, we
have two wait_event_interruptable calls in pvcalls_front_accept.

Add two wake_up calls in pvcalls_front_release, then wait for the
potential waiters to return and release the sock_mapping refcount.
Signed-off-by: NStefano Stabellini <stefano@aporeto.com>
Acked-by: NJuergen Gross <jgross@suse.com>
Signed-off-by: NJuergen Gross <jgross@suse.com>

Introduce a per sock_mapping refcount, in addition to the existing
global refcount. Thanks to the sock_mapping refcount, we can safely wait
for it to be 1 in pvcalls_front_release before freeing an active socket,
instead of waiting for the global refcount to be 1.
Signed-off-by: NStefano Stabellini <stefano@aporeto.com>
Acked-by: NJuergen Gross <jgross@suse.com>
Signed-off-by: NJuergen Gross <jgross@suse.com>

The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.

Calculate __max_logical_packages for PV domains.

Fixes: b4c0a732 ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Tested-and-reported-by: NSimon Gaiser <simon@invisiblethingslab.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Dou Liyang <douly.fnst@cn.fujitsu.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: xen-devel@lists.xenproject.org
Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: NJuergen Gross <jgross@suse.com>

Commit fd8aa909 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses") optimized xenbus concurrent accesses but in doing so
broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in
charge of xenbus message exchange with the correct header and body. Now,
after the mentioned commit the replies received by application will no
longer have the header req_id echoed back as it was on request (see
specification below for reference), because that particular field is being
overwritten by kernel.

struct xsd_sockmsg
{
  uint32_t type;  /* XS_??? */
  uint32_t req_id;/* Request identifier, echoed in daemon's response.  */
  uint32_t tx_id; /* Transaction id (0 if not related to a transaction). */
  uint32_t len;   /* Length of data following this. */

  /* Generally followed by nul-terminated string(s). */
};

Before there was only one request at a time so req_id could simply be
forwarded back and forth. To allow simultaneous requests we need a
different req_id for each message thus kernel keeps a monotonic increasing
counter for this field and is written on every request irrespective of
userspace value.

Forwarding again the req_id on userspace requests is not a solution because
we would open the possibility of userspace-generated req_id colliding with
kernel ones. So this patch instead takes another route which is to
artificially keep user req_id while keeping the xenbus logic as is. We do
that by saving the original req_id before xs_send(), use the private kernel
counter as req_id and then once reply comes and was validated, we restore
back the original req_id.

Cc: <stable@vger.kernel.org> # 4.11
Fixes: fd8aa909 ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Reported-by: NBhavesh Davda <bhavesh.davda@oracle.com>
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Reviewed-by: NJuergen Gross <jgross@suse.com>
Signed-off-by: NJuergen Gross <jgross@suse.com>

Sparse makes a fair bit of noise about our MPIDR mask being implicitly
long - let's explicitly describe it as such rather than just relying on
the value forcing automatic promotion.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

Pull dma-mapping fixes from Christoph Hellwig:
 "A few dma-mapping fixes for the fallout from the changes in rc1"

* tag 'dma-mapping-4.16-2' of git://git.infradead.org/users/hch/dma-mapping:
  powerpc/macio: set a proper dma_coherent_mask
  dma-mapping: fix a comment typo
  dma-direct: comment the dma_direct_free calling convention
  dma-direct: mark as is_phys
  ia64: fix build failure with CONFIG_SWIOTLB

In many cases, page tables can be accessed concurrently by either another
CPU (due to things like fast gup) or by the hardware page table walker
itself, which may set access/dirty bits. In such cases, it is important
to use READ_ONCE/WRITE_ONCE when accessing page table entries so that
entries cannot be torn, merged or subject to apparent loss of coherence
due to compiler transformations.

Whilst there are some scenarios where this cannot happen (e.g. pinned
kernel mappings for the linear region), the overhead of using READ_ONCE
/WRITE_ONCE everywhere is minimal and makes the code an awful lot easier
to reason about. This patch consistently uses these macros in the arch
code, as well as explicitly namespacing pointers to page table entries
from the entries themselves by using adopting a 'p' suffix for the former
(as is sometimes used elsewhere in the kernel source).
Tested-by: NYury Norov <ynorov@caviumnetworks.com>
Tested-by: NRichard Ruigrok <rruigrok@codeaurora.org>
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

We get a warning about some slow configurations in randconfig kernels:

  mm/memory.c:83:2: error: #warning Unfortunate NUMA and NUMA Balancing config, growing page-frame for last_cpupid. [-Werror=cpp]

The warning is reasonable by itself, but gets in the way of randconfig
build testing, so I'm hiding it whenever CONFIG_COMPILE_TEST is set.

The warning was added in 2013 in commit 75980e97 ("mm: fold
page->_last_nid into page->flags where possible").

Cc: stable@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull MIPS fixes from James Hogan:
 "A few fixes for outstanding MIPS issues:

   - an __init section mismatch warning when brcmstb_pm is enabled

   - a regression handling multiple mem=X@Y arguments (4.11)

   - a USB Kconfig select warning, and related sparc cleanup (4.16)"

* tag 'mips_fixes_4.16_2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips:
  sparc,leon: Select USB_UHCI_BIG_ENDIAN_{MMIO,DESC}
  usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
  MIPS: Fix incorrect mem=X@Y handling
  MIPS: BMIPS: Fix section mismatch warning

Pull btrfs fixes from David Sterba:
 "We have a few assorted fixes, some of them show up during fstests so I
  gave them more testing"

* tag 'for-4.16-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
  Btrfs: fix null pointer dereference when replacing missing device
  btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes
  btrfs: Ignore errors from btrfs_qgroup_trace_extent_post
  Btrfs: fix unexpected -EEXIST when creating new inode
  Btrfs: fix use-after-free on root->orphan_block_rsv
  Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly
  Btrfs: fix extent state leak from tree log
  Btrfs: fix crash due to not cleaning up tree log block's dirty bits
  Btrfs: fix deadlock in run_delalloc_nocow

Merge tag 'for-4.16/dm-chained-bios-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm

Pull device mapper fix from Mike Snitzer:
 "Fix for DM core to properly propagate errors (avoids overriding
  non-zero error with 0). This is particularly important given DM core's
  increased use of chained bios"

* tag 'for-4.16/dm-chained-bios-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm: correctly handle chained bios in dec_pending()

Pull x86 platform driver fixes from Andy Shevchenko:

 - regression fix in keyboard support for Dell laptops

 - prevent out-of-boundary write in WMI bus driver

 - increase timeout to read functional key status on Lenovo laptops

* tag 'platform-drivers-x86-v4.16-4' of git://git.infradead.org/linux-platform-drivers-x86:
  platform/x86: dell-laptop: Removed duplicates in DMI whitelist
  platform/x86: dell-laptop: fix kbd_get_state's request value
  platform/x86: ideapad-laptop: Increase timeout to wait for EC answer
  platform/x86: wmi: fix off-by-one write in wmi_dev_probe()