Pull x86 fixes from Ingo Molnar:
 "Three fixes:

   - AMD microcode loading fix with randomization

   - an lguest tooling fix

   - and an APIC enumeration boundary condition fix"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/apic: Fix num_processors value in case of failure
  tools/lguest: Don't bork the terminal in case of wrong args
  x86/microcode/AMD: Fix load of builtin microcode with randomized memory

Jonathan writes:

Second set of IIO fixes for the 4.8 cycle.

We have a big rework of the kxsd9 driver queued up behind the fix below and
a fix for a recent fix that was marked for stable.
Hence this fix series is perhaps a little more urgent than average for IIO.
* core
  - a fix for a fix in the last set.  The recent fix for blocking ops when
   ! task running left a path (unlikely one) in which the function return
   value was not set - so initialise it to 0.
  - The IIO_TYPE_FRACTIONAL code previously didn't cope with negative
  fractions.  Turned out a fix for this was in Analog's tree but hadn't made
  it upstream.
* bmc150
  - reset chip at init time. At least one board out there ends up coming up
  in an unstable state due to noise during power up.  The reset does no
  harm on other boards.
* kxsd9
  - Fix a bug in the reported scaling due to failing to set the integer
  part to 0.
* hid-sensors-pressure
  - Output was in the wrong units to comply with the IIO ABI.
* tools
  - iio_generic_buffer: Fix the trigger-less mode by ensuring we don't fault
    out for having no trigger when we explicitly said we didn't want to have
    one.

Running lguest without arguments or with a wrong argument name
borks the terminal, because the cleanup handler is set up too late
in the initialization process.

Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Pull staging/IIO driver fixes from Greg KH:
 "Here are a number of small fixes for staging and IIO drivers that
  resolve reported problems.

  Full details are in the shortlog.  All of these have been in
  linux-next with no reported issues"

* tag 'staging-4.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (35 commits)
  arm: dts: rockchip: add reset node for the exist saradc SoCs
  arm64: dts: rockchip: add reset saradc node for rk3368 SoCs
  iio: adc: rockchip_saradc: reset saradc controller before programming it
  iio: accel: kxsd9: Fix raw read return
  iio: adc: ti_am335x_adc: Increase timeout value waiting for ADC sample
  iio: adc: ti_am335x_adc: Protect FIFO1 from concurrent access
  include/linux: fix excess fence.h kernel-doc notation
  staging: wilc1000: correctly check if associatedsta has not been found
  staging: wilc1000: NULL dereference on error
  staging: wilc1000: txq_event: Fix coding error
  MAINTAINERS: Add file patterns for ion device tree bindings
  MAINTAINERS: Update maintainer entry for wilc1000
  iio: chemical: atlas-ph-sensor: fix typo in val assignment
  iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"
  staging: comedi: ni_mio_common: fix AO inttrig backwards compatibility
  staging: comedi: dt2811: fix a precedence bug
  staging: comedi: adv_pci1760: Do not return EINVAL for CMDF_ROUND_DOWN.
  staging: comedi: ni_mio_common: fix wrong insn_write handler
  staging: comedi: comedi_test: fix timer race conditions
  staging: comedi: daqboard2000: bug fix board type matching code
  ...

Passing the trigger-less mode option on the command line causes
iio_generic_buffer to fail searching for an IIO trigger.
Fix this by skipping trigger initialization if trigger-less mode is
requested.

Technically it actually fixes:
7c7e9dad70 where the bug was introduced but as the window to the patch
below that changes the context was very small let's mark it with that.

Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Fixes: deb4d1fdcb5af ("iio: generic_buffer: Fix --trigger-num option")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

Pull perf fixes from Thomas Gleixner:
 "A few fixes from the perf departement

   - prevent a imbalanced preemption disable in the events teardown code
   - prevent out of bound acces in perf userspace
   - make perf tools compile with UCLIBC again
   - a fix for the userspace unwinder utility"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/core: Use this_cpu_ptr() when stopping AUX events
  perf evsel: Do not access outside hw cache name arrays
  tools lib: Reinstate strlcpy() header guard with __UCLIBC__
  perf unwind: Use addr_location::addr instead of ip for entries

Pull GPIO fixes from Linus Walleij:
 "Here are a few GPIO fixes for v4.8.

  I was expecting some fallout from the new chardev rework but nothing
  like that turned up att all.  Instead a Kconfig confusion that I think
  I have finally nailed, then some ordinary driver noise and trivia.

  This fixes a Kconfig issue with UM: when I made GPIOLIB available to
  all archs, that included UM, but the OF part of GPIOLIB requires
  HAS_IOMEM, so we add HAS_IOMEM as a dependency to OF_GPIO.

  This in turn exposed the fact that a few GPIO drivers were implicitly
  assuming OF_GPIO as their dependency but instead depended on OF alone
  (the typical problem being a pointer inside gpio_chip not existing
  unless OF_GPIO is selected) and then UM would fail to compile with
  these drivers instead.  Then I lost patience and made any GPIO driver
  depending on just OF depend on OF_GPIO instead, that is certainly what
  they meant and the only thing that makes sense anyway.  GPIO with just
  OF but !OF_GPIO does not make sense.

  Also a fix for the max730x driver data pointer, and a minor comment
  fix for the GPIO tools"

* tag 'gpio-v4.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: make any OF dependent driver depend on OF_GPIO
  gpio: Fix OF build problem on UM
  gpio: max730x: set gpiochip data pointer before using it
  tools/gpio: fix gpio-event-mon header comment

Pull perf fixes from Ingo Molnar:
 "Mostly tooling fixes, but also start/stop filter related fixes, a perf
  event read() fix, a fix uncovered by fuzzing, and an uprobes leak fix"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/core: Check return value of the perf_event_read() IPI
  perf/core: Enable mapping of the stop filters
  perf/core: Update filters only on executable mmap
  perf/core: Fix file name handling for start/stop filters
  perf/core: Fix event_function_local()
  uprobes: Fix the memcg accounting
  perf intel-pt: Fix occasional decoding errors when tracing system-wide
  tools: Sync kvm related header files for arm64 and s390
  perf probe: Release resources on error when handling exit paths
  perf probe: Check for dup and fdopen failures
  perf symbols: Fix annotation of objects with debuginfo files
  perf script: Don't disable use_callchain if input is pipe
  perf script: Show proper message when failed list scripts
  perf jitdump: Add the right header to get the major()/minor() definitions
  perf ppc64le: Fix build failure when libelf is not present
  perf tools mem: Fix -t store option for record command
  perf intel-pt: Fix ip compression

We have to check if the values are >= *_MAX, not just >, fix it.

From the bugzilla report:

''In file /tools/perf/util/evsel.c  function __perf_evsel__hw_cache_name
it appears that there is a bug that reads beyond the end of the buffer.
The statement "if (type > PERF_COUNT_HW_CACHE_MAX)" allows type to be
equal to the maximum value. Later, when statement "if
(!perf_evsel__is_cache_op_valid(type, op))" is executed, the function
can access array perf_evsel__hw_cache_stat[type] beyond the end of the
buffer.

It appears to me that the statement "if (type > PERF_COUNT_HW_CACHE_MAX)"
should be "if (type >= PERF_COUNT_HW_CACHE_MAX)"

Bug found with Coverity and manual code review. No attempts were made to
execute the code with a maximum type value.''

Committer note:

Testing it:

  $ perf record -e $(echo $(perf list cache | cut -d \[ -f1) | sed 's/ /,/g') usleep 1
  [ perf record: Woken up 16 times to write data ]
  [ perf record: Captured and wrote 0.023 MB perf.data (34 samples) ]
  $ perf evlist
  L1-dcache-load-misses
  L1-dcache-loads
  L1-dcache-stores
  L1-icache-load-misses
  LLC-load-misses
  LLC-loads
  LLC-store-misses
  LLC-stores
  branch-load-misses
  branch-loads
  dTLB-load-misses
  dTLB-loads
  dTLB-store-misses
  dTLB-stores
  iTLB-load-misses
  iTLB-loads
  node-load-misses
  node-loads
  node-store-misses
  node-stores
  $ perf list cache

  List of pre-defined events (to be used in -e):

    L1-dcache-load-misses        [Hardware cache event]
    L1-dcache-loads              [Hardware cache event]
    L1-dcache-stores             [Hardware cache event]
    L1-icache-load-misses        [Hardware cache event]
    LLC-load-misses              [Hardware cache event]
    LLC-loads                    [Hardware cache event]
    LLC-store-misses             [Hardware cache event]
    LLC-stores                   [Hardware cache event]
    branch-load-misses           [Hardware cache event]
    branch-loads                 [Hardware cache event]
    dTLB-load-misses             [Hardware cache event]
    dTLB-loads                   [Hardware cache event]
    dTLB-store-misses            [Hardware cache event]
    dTLB-stores                  [Hardware cache event]
    iTLB-load-misses             [Hardware cache event]
    iTLB-loads                   [Hardware cache event]
    node-load-misses             [Hardware cache event]
    node-loads                   [Hardware cache event]
    node-store-misses            [Hardware cache event]
    node-stores                  [Hardware cache event]
  $

Reported-by: Brian Sweeney <bsweeney@lgsinnovations.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=153351
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

perf tools build in recent kernels spews splat when cross compiling with uClibc:

|   CC       util/alias.o
| In file included from tools/perf/util/../ui/../util/cache.h:8:0,
|                 from tools/perf/util/../ui/helpline.h:7,
|                 from tools/perf/util/debug.h:8,
|                 from arch/../util/cpumap.h:9,
|                 from arch/../util/env.h:5,
|                 from arch/common.h:4,
|                 from arch/common.c:3:
| tools/include/linux/string.h:12:15: warning: redundant redeclaration of ‘strlcpy’ [-Wredundant-decls]
|  extern size_t strlcpy(char *dest, const char *src, size_t size);
               ^
This is after commit 61a6445e463a31 ("tools lib: Guard the strlcpy() header with
__GLIBC__").

The problem is uClibc also defines __GLIBC__ for exported headers for
applications. So add that specific check to not trip for uClibc.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Petri Gynther <pgynther@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: linux-snps-arc@lists.infradead.org
Link: http://lkml.kernel.org/r/1471537703-16439-1-git-send-email-vgupta@synopsys.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>