linux-toradex.git/drivers/firmware, branch v4.10 Linux kernel for Apalis and Colibri modules efi/fdt: Avoid FDT manipulation after ExitBootServices() 2017-02-01T20:17:49+00:00 Ard Biesheuvel ard.biesheuvel@linaro.org 2017-02-01T17:45:02+00:00 c8f325a59cfc718d13a50fbc746ed9b415c25e92 Some AArch64 UEFI implementations disable the MMU in ExitBootServices(), after which unaligned accesses to RAM are no longer supported. Commit: abfb7b686a3e ("efi/libstub/arm*: Pass latest memory map to the kernel") fixed an issue in the memory map handling of the stub FDT code, but inadvertently created an issue with such firmware, by moving some of the FDT manipulation to after the invocation of ExitBootServices(). Given that the stub's libfdt implementation uses the ordinary, accelerated string functions, which rely on hardware handling of unaligned accesses, manipulating the FDT with the MMU off may result in alignment faults. So fix the situation by moving the update_fdt_memmap() call into the callback function invoked by efi_exit_boot_services() right before it calls the ExitBootServices() UEFI service (which is arguably a better place for it anyway) Note that disabling the MMU in ExitBootServices() is not compliant with the UEFI spec, and carries great risk due to the fact that switching from cached to uncached memory accesses halfway through compiler generated code (i.e., involving a stack) can never be done in a way that is architecturally safe. Fixes: abfb7b686a3e ("efi/libstub/arm*: Pass latest memory map to the kernel") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Riku Voipio <riku.voipio@linaro.org> Cc: <stable@vger.kernel.org> Cc: mark.rutland@arm.com Cc: linux-efi@vger.kernel.org Cc: matt@codeblueprint.co.uk Cc: leif.lindholm@linaro.org Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1485971102-23330-2-git-send-email-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org> 
Some AArch64 UEFI implementations disable the MMU in ExitBootServices(),
after which unaligned accesses to RAM are no longer supported.

Commit:

  abfb7b686a3e ("efi/libstub/arm*: Pass latest memory map to the kernel")

fixed an issue in the memory map handling of the stub FDT code, but
inadvertently created an issue with such firmware, by moving some
of the FDT manipulation to after the invocation of ExitBootServices().

Given that the stub's libfdt implementation uses the ordinary, accelerated
string functions, which rely on hardware handling of unaligned accesses,
manipulating the FDT with the MMU off may result in alignment faults.

So fix the situation by moving the update_fdt_memmap() call into the
callback function invoked by efi_exit_boot_services() right before it
calls the ExitBootServices() UEFI service (which is arguably a better
place for it anyway)

Note that disabling the MMU in ExitBootServices() is not compliant with
the UEFI spec, and carries great risk due to the fact that switching from
cached to uncached memory accesses halfway through compiler generated code
(i.e., involving a stack) can never be done in a way that is architecturally
safe.

Fixes: abfb7b686a3e ("efi/libstub/arm*: Pass latest memory map to the kernel")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Riku Voipio <riku.voipio@linaro.org>
Cc: <stable@vger.kernel.org>
Cc: mark.rutland@arm.com
Cc: linux-efi@vger.kernel.org
Cc: matt@codeblueprint.co.uk
Cc: leif.lindholm@linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1485971102-23330-2-git-send-email-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 2017-01-15T18:54:39+00:00 Linus Torvalds torvalds@linux-foundation.org 2017-01-15T18:54:39+00:00 255e6140fa76ec9d0e24f201427e7e9a9573f681 Pull EFI fixes from Ingo Molnar: "A number of regression fixes: - Fix a boot hang on machines that have somewhat unusual memory map entries of phys_addr=0x0 num_pages=0, which broke due to a recent commit. This commit got cherry-picked from the v4.11 queue because the bug is affecting real machines. - Fix a boot hang also reported by KASAN, caused by incorrect init ordering introduced by a recent optimization. - Fix a recent robustification fix to allocate_new_fdt_and_exit_boot() that introduced an invalid assumption. Neither bugs were seen in the wild AFAIK" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/x86: Prune invalid memory map entries and fix boot regression x86/efi: Don't allocate memmap through memblock after mm_init() efi/libstub/arm*: Pass latest memory map to the kernel 
Pull EFI fixes from Ingo Molnar:
 "A number of regression fixes:

   - Fix a boot hang on machines that have somewhat unusual memory map
     entries of phys_addr=0x0 num_pages=0, which broke due to a recent
     commit. This commit got cherry-picked from the v4.11 queue because
     the bug is affecting real machines.

   - Fix a boot hang also reported by KASAN, caused by incorrect init
     ordering introduced by a recent optimization.

   - Fix a recent robustification fix to allocate_new_fdt_and_exit_boot()
     that introduced an invalid assumption. Neither bugs were seen in
     the wild AFAIK"

* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi/x86: Prune invalid memory map entries and fix boot regression
  x86/efi: Don't allocate memmap through memblock after mm_init()
  efi/libstub/arm*: Pass latest memory map to the kernel
x86/efi: Don't allocate memmap through memblock after mm_init() 2017-01-07T07:58:07+00:00 Nicolai Stange nicstange@gmail.com 2017-01-05T12:51:29+00:00 20b1e22d01a4b0b11d3a1066e9feb04be38607ec With the following commit: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data") ... efi_bgrt_init() calls into the memblock allocator through efi_mem_reserve() => efi_arch_mem_reserve() *after* mm_init() has been called. Indeed, KASAN reports a bad read access later on in efi_free_boot_services(): BUG: KASAN: use-after-free in efi_free_boot_services+0xae/0x24c at addr ffff88022de12740 Read of size 4 by task swapper/0/0 page:ffffea0008b78480 count:0 mapcount:-127 mapping: (null) index:0x1 flags: 0x5fff8000000000() [...] Call Trace: dump_stack+0x68/0x9f kasan_report_error+0x4c8/0x500 kasan_report+0x58/0x60 __asan_load4+0x61/0x80 efi_free_boot_services+0xae/0x24c start_kernel+0x527/0x562 x86_64_start_reservations+0x24/0x26 x86_64_start_kernel+0x157/0x17a start_cpu+0x5/0x14 The instruction at the given address is the first read from the memmap's memory, i.e. the read of md->type in efi_free_boot_services(). Note that the writes earlier in efi_arch_mem_reserve() don't splat because they're done through early_memremap()ed addresses. So, after memblock is gone, allocations should be done through the "normal" page allocator. Introduce a helper, efi_memmap_alloc() for this. Use it from efi_arch_mem_reserve(), efi_free_boot_services() and, for the sake of consistency, from efi_fake_memmap() as well. Note that for the latter, the memmap allocations cease to be page aligned. This isn't needed though. Tested-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Nicolai Stange <nicstange@gmail.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> # v4.9 Cc: Dave Young <dyoung@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Mika Penttilä <mika.penttila@nextfour.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Fixes: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data") Link: http://lkml.kernel.org/r/20170105125130.2815-1-nicstange@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> 
With the following commit:

  4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data")

...  efi_bgrt_init() calls into the memblock allocator through
efi_mem_reserve() => efi_arch_mem_reserve() *after* mm_init() has been called.

Indeed, KASAN reports a bad read access later on in efi_free_boot_services():

  BUG: KASAN: use-after-free in efi_free_boot_services+0xae/0x24c
            at addr ffff88022de12740
  Read of size 4 by task swapper/0/0
  page:ffffea0008b78480 count:0 mapcount:-127
  mapping:          (null) index:0x1 flags: 0x5fff8000000000()
  [...]
  Call Trace:
   dump_stack+0x68/0x9f
   kasan_report_error+0x4c8/0x500
   kasan_report+0x58/0x60
   __asan_load4+0x61/0x80
   efi_free_boot_services+0xae/0x24c
   start_kernel+0x527/0x562
   x86_64_start_reservations+0x24/0x26
   x86_64_start_kernel+0x157/0x17a
   start_cpu+0x5/0x14

The instruction at the given address is the first read from the memmap's
memory, i.e. the read of md->type in efi_free_boot_services().

Note that the writes earlier in efi_arch_mem_reserve() don't splat because
they're done through early_memremap()ed addresses.

So, after memblock is gone, allocations should be done through the "normal"
page allocator. Introduce a helper, efi_memmap_alloc() for this. Use
it from efi_arch_mem_reserve(), efi_free_boot_services() and, for the sake
of consistency, from efi_fake_memmap() as well.

Note that for the latter, the memmap allocations cease to be page aligned.
This isn't needed though.

Tested-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: <stable@vger.kernel.org> # v4.9
Cc: Dave Young <dyoung@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Mika Penttilä <mika.penttila@nextfour.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Fixes: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data")
Link: http://lkml.kernel.org/r/20170105125130.2815-1-nicstange@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Merge tag 'psci-fixes-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux into fixes 2017-01-04T15:38:39+00:00 Arnd Bergmann arnd@arndb.de 2017-01-04T15:38:39+00:00 5c6ec6a02c1378ba0e3ac530f8c80523ea74e5de Pull "PSCI fixes for v4.10" from Lorenzo Pieralisi: Two minor fixes following the merge of the PSCI checker: - Annotate the PSCI checker timer on the stack used to wake-up from suspend to prevent warnings when the DEBUG_OBJECTS config option is enabled - Extend the PSCI entry in the maintainers list to also include the PSCI checker code * tag 'psci-fixes-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux: MAINTAINERS: extend PSCI entry to cover the newly add PSCI checker code drivers: psci: annotate timer on stack to silence odebug messages 
Pull "PSCI fixes for v4.10" from Lorenzo Pieralisi:

Two minor fixes following the merge of the PSCI checker:

- Annotate the PSCI checker timer on the stack used to wake-up from
  suspend to prevent warnings when the DEBUG_OBJECTS config option
  is enabled
- Extend the PSCI entry in the maintainers list to also include the
  PSCI checker code

* tag 'psci-fixes-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux:
  MAINTAINERS: extend PSCI entry to cover the newly add PSCI checker code
  drivers: psci: annotate timer on stack to silence odebug messages
drivers: psci: annotate timer on stack to silence odebug messages 2017-01-03T17:52:48+00:00 Sudeep Holla sudeep.holla@arm.com 2017-01-03T12:32:47+00:00 4309cfe334af9c3565d39e1ce3f9c62183cc67e4 When DEBUG_OBJECTS config is enabled, we get the below odebug warnings: ODEBUG: object is on stack, but not annotated WARNING: CPU: 3 PID: 1304 at kernel/lib/debugobjects.c:300 __debug_object_init+0x1f0/0x458 CPU: 3 PID: 1304 Comm: psci_suspend_te Tainted: G W 4.9.0-06564-gf80f3f199260 #284 task: ffffe9e1b55a1600 task.stack: ffffe9e1b51c0000 PC is at __debug_object_init+0x1f0/0x458 LR is at __debug_object_init+0x1ec/0x458 Call trace: __debug_object_init+0x1f0/0x458 debug_object_activate+0x150/0x260 mod_timer+0xb4/0x4c0 suspend_test_thread+0x1cc/0x3c0 kthread+0x110/0x140 ret_from_fork+0x10/0x40 This patch annotates the timer on the stack using setup_timer_on_stack function to remove the above warnings. Cc: Kevin Brodsky <kevin.brodsky@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> 
When DEBUG_OBJECTS config is enabled, we get the below odebug warnings:

ODEBUG: object is on stack, but not annotated

WARNING: CPU: 3 PID: 1304 at kernel/lib/debugobjects.c:300 __debug_object_init+0x1f0/0x458
CPU: 3 PID: 1304 Comm: psci_suspend_te Tainted: G W 4.9.0-06564-gf80f3f199260 #284
task: ffffe9e1b55a1600 task.stack: ffffe9e1b51c0000
PC is at __debug_object_init+0x1f0/0x458
LR is at __debug_object_init+0x1ec/0x458
Call trace:
 __debug_object_init+0x1f0/0x458
 debug_object_activate+0x150/0x260
 mod_timer+0xb4/0x4c0
 suspend_test_thread+0x1cc/0x3c0
 kthread+0x110/0x140
 ret_from_fork+0x10/0x40

This patch annotates the timer on the stack using setup_timer_on_stack
function to remove the above warnings.

Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
firmware: arm_scpi: fix reading sensor values on pre-1.0 SCPI firmwares 2016-12-30T14:53:36+00:00 Martin Blumenstingl martin.blumenstingl@googlemail.com 2016-12-11T21:14:32+00:00 a766347b15c01507db9bf01f9b7021be5a776691 The pre-1.0 SCPI firmwares are using single __le32 as sensor value, while the SCPI v1.0 protocol uses two __le32 as sensor values(64bit) split into 32bit upper and 32bit lower value. Using an "struct sensor_value" to read the sensor value on a pre-1.0 SCPI firmware gives garbage in the "hi_val" field. This patch fixes the issue by reading only the lower 32-bit value for all pre-1.0 SCPI versions. Suggested-by: Sudeep Holla <Sudeep.Holla@arm.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> [sudeep.holla@arm.com: updated the commit log to reflect the implementation] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> 
The pre-1.0 SCPI firmwares are using single __le32 as sensor value,
while the SCPI v1.0 protocol uses two __le32 as sensor values(64bit)
split into 32bit upper and 32bit lower value.

Using an "struct sensor_value" to read the sensor value on a pre-1.0
SCPI firmware gives garbage in the "hi_val" field.

This patch fixes the issue by reading only the lower 32-bit value for
all pre-1.0 SCPI versions.

Suggested-by: Sudeep Holla <Sudeep.Holla@arm.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[sudeep.holla@arm.com: updated the commit log to reflect the implementation]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
efi/libstub/arm*: Pass latest memory map to the kernel 2016-12-28T08:23:32+00:00 Ard Biesheuvel ard.biesheuvel@linaro.org 2016-12-24T13:59:23+00:00 abfb7b686a3e5be27bf81db62f9c5c895b76f5d1 As reported by James Morse, the current libstub code involving the annotated memory map only works somewhat correctly by accident, due to the fact that a pool allocation happens to be reused immediately, retaining its former contents on most implementations of the UEFI boot services. Instead of juggling memory maps, which makes the code more complex than it needs to be, simply put placeholder values into the FDT for the memory map parameters, and only write the actual values after ExitBootServices() has been called. Reported-by: James Morse <james.morse@arm.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org Fixes: ed9cc156c42f ("efi/libstub: Use efi_exit_boot_services() in FDT") Link: http://lkml.kernel.org/r/1482587963-20183-2-git-send-email-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org> 
As reported by James Morse, the current libstub code involving the
annotated memory map only works somewhat correctly by accident, due
to the fact that a pool allocation happens to be reused immediately,
retaining its former contents on most implementations of the
UEFI boot services.

Instead of juggling memory maps, which makes the code more complex than
it needs to be, simply put placeholder values into the FDT for the memory
map parameters, and only write the actual values after ExitBootServices()
has been called.

Reported-by: James Morse <james.morse@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: <stable@vger.kernel.org>
Cc: Jeffrey Hugo <jhugo@codeaurora.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-efi@vger.kernel.org
Fixes: ed9cc156c42f ("efi/libstub: Use efi_exit_boot_services() in FDT")
Link: http://lkml.kernel.org/r/1482587963-20183-2-git-send-email-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
firmware: dmi_scan: Always show system identification string 2016-12-19T09:01:47+00:00 Kefeng Wang wangkefeng.wang@huawei.com 2016-12-19T09:01:47+00:00 d4af49f810db8b855b043615c3b4312e5ba8aedb Let's keep consistent when print dmi_ids_string between SMBIOS 2.x and SMBIOS 3.x, and always show the system identification string, like Vendor, Product/Board name and BIOS infos. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Jean Delvare <jdelvare@suse.de> 
Let's keep consistent when print dmi_ids_string between SMBIOS 2.x
and SMBIOS 3.x, and always show the system identification string,
like Vendor, Product/Board name and BIOS infos.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc 2016-12-16T00:03:25+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-12-16T00:03:25+00:00 991688bfc63550b8c7ab9fb1de2feb44e3071d29 Pull ARM SoC driver updates from Arnd Bergmann: "Driver updates for ARM SoCs, including a couple of newly added drivers: - A new driver for the power management controller on TI Keystone - Support for the prerelease "SCPI" firmware protocol that ended up being shipped by Amlogic in their GXBB SoC. - A soc_device can now be matched using a glob from inside the kernel, when another driver wants to know the specific chip it is running on and cannot find out from DT, firmware or hardware. - Renesas SoCs now support identification through the soc_device interface, both in user space and kernel. - Renesas r8a7743 and r8a7745 gain support for their system controller - A new checking module for the ARM "PSCI" (not to be confused with "SCPI" mentioned above) firmware interface. - A new driver for the Tegra GMI memory interface - Support for the Tegra firmware interfaces with their power management controllers As usual, the updates for the reset controller framework are merged here, as they tend to touch multiple SoCs as well, including a new driver for the Oxford (now Broadcom) OX820 chip and the Tegra bpmp interface. The existing drivers for Atmel, Qualcomm, NVIDIA, TI Davinci, and Rockchips SoCs see some further updates" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (76 commits) misc: sram: remove useless #ifdef drivers: psci: Allow PSCI node to be disabled drivers: psci: PSCI checker module soc: renesas: Identify SoC and register with the SoC bus firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails firmware: qcom: scm: Remove core, iface and bus clocks dependency dt-bindings: firmware: scm: Add MSM8996 DT bindings memory: da8xx-ddrctl: drop the call to of_flat_dt_get_machine_name() bus: da8xx-mstpri: drop the call to of_flat_dt_get_machine_name() ARM: shmobile: Document DT bindings for Product Register soc: renesas: rcar-sysc: add R8A7745 support reset: Add Tegra BPMP reset driver dt-bindings: firmware: Allow child nodes inside the Tegra BPMP dt-bindings: Add power domains to Tegra BPMP firmware firmware: tegra: Add BPMP support firmware: tegra: Add IVC library dt-bindings: firmware: Add bindings for Tegra BPMP mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells() mailbox: Add Tegra HSP driver firmware: arm_scpi: add support for pre-v1.0 SCPI compatible ... 
Pull ARM SoC driver updates from Arnd Bergmann:
 "Driver updates for ARM SoCs, including a couple of newly added
  drivers:

   - A new driver for the power management controller on TI Keystone

   - Support for the prerelease "SCPI" firmware protocol that ended up
     being shipped by Amlogic in their GXBB SoC.

   - A soc_device can now be matched using a glob from inside the
     kernel, when another driver wants to know the specific chip it is
     running on and cannot find out from DT, firmware or hardware.

   - Renesas SoCs now support identification through the soc_device
     interface, both in user space and kernel.

   - Renesas r8a7743 and r8a7745 gain support for their system
     controller

   - A new checking module for the ARM "PSCI" (not to be confused with
     "SCPI" mentioned above) firmware interface.

   - A new driver for the Tegra GMI memory interface

   - Support for the Tegra firmware interfaces with their power
     management controllers

  As usual, the updates for the reset controller framework are merged
  here, as they tend to touch multiple SoCs as well, including a new
  driver for the Oxford (now Broadcom) OX820 chip and the Tegra bpmp
  interface.

  The existing drivers for Atmel, Qualcomm, NVIDIA, TI Davinci, and
  Rockchips SoCs see some further updates"

* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (76 commits)
  misc: sram: remove useless #ifdef
  drivers: psci: Allow PSCI node to be disabled
  drivers: psci: PSCI checker module
  soc: renesas: Identify SoC and register with the SoC bus
  firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails
  firmware: qcom: scm: Remove core, iface and bus clocks dependency
  dt-bindings: firmware: scm: Add MSM8996 DT bindings
  memory: da8xx-ddrctl: drop the call to of_flat_dt_get_machine_name()
  bus: da8xx-mstpri: drop the call to of_flat_dt_get_machine_name()
  ARM: shmobile: Document DT bindings for Product Register
  soc: renesas: rcar-sysc: add R8A7745 support
  reset: Add Tegra BPMP reset driver
  dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
  dt-bindings: Add power domains to Tegra BPMP firmware
  firmware: tegra: Add BPMP support
  firmware: tegra: Add IVC library
  dt-bindings: firmware: Add bindings for Tegra BPMP
  mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
  mailbox: Add Tegra HSP driver
  firmware: arm_scpi: add support for pre-v1.0 SCPI compatible
  ...
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial 2016-12-14T19:12:25+00:00 Linus Torvalds torvalds@linux-foundation.org 2016-12-14T19:12:25+00:00 a9042defa29a01cc538b742eab047848e9b5ae14 Pull trivial updates from Jiri Kosina. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: NTB: correct ntb_spad_count comment typo misc: ibmasm: fix typo in error message Remove references to dead make variable LINUX_INCLUDE Remove last traces of ikconfig.h treewide: Fix printk() message errors Documentation/device-mapper: s/getsize/getsz/ 
Pull trivial updates from Jiri Kosina.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial:
  NTB: correct ntb_spad_count comment typo
  misc: ibmasm: fix typo in error message
  Remove references to dead make variable LINUX_INCLUDE
  Remove last traces of ikconfig.h
  treewide: Fix printk() message errors
  Documentation/device-mapper: s/getsize/getsz/