Revert "arm64: dts: rk3399-sapphire: add vbus-5v gpio control in fusb302 node."

This reverts commit cb3e42dc8cf5e1e0431535a2fbe2a39dfac91d39.

This will make usb port in my board can't work, no 5v voltage.
Is it no issues in android?

Change-Id: I95fbd957d0ddb5fddf215d3b00ef74aae8af08d3
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

drm: support ignore drm ioctl permission

Change-Id: I269766a9f3f844933bd294ce681466f5a97b1d43
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

UPSTREAM: arm64: dts: rockchip: add the tcpc for rk3399 power domain

The tcpc is the Type C Port Controller and Type C Port Delivery (tcpd)
is part of it, we haven't used them now, add it to save power consumption.

Change-Id: Ia1046fd3bb7382498811159d8280ee46b3753ebd
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 4a3a3d32c77f942a10c0319f589186a768821397)

UPSTREAM: soc: rockchip: power-domain: avoid infinite loop

In some cases, we have met the infinite loop in
rockchip_pmu_set_idle_request() or rockchip_do_pmu_set_power_domain().

As the crosbug.com/p/57351 reported, the boot hangs right after this
[1.629163] bootconsole [uart8250] disabled
[1.639286] [drm:drm_core_init] Initialized drm 1.1.0 20060810
[1.645926] [drm:drm_get_platform_dev] Initialized vgem 1.0.0 20120112..
[1.654558] iommu: Adding device ff8f0000.vop to group 0
[1.660569] iommu: Adding device ff900000.vop to group 1
<hang>

This patch adds the error message and timeout to avoid infinite loop if
it fails to get the ack.

Change-Id: Ia1e2edbdb48de3ec776f1304a941136d3e7a1854
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git.kernel.org mmind/linux-rockchip.git
 v4.10-armsoc/drivers commit e4c8cd82d5e1146590611c393001d846535bac5b)

ARM64: dts: rk3399: support cluster idle feature

Add cluster sleep in cpu idle_states for RK3399 SoCs.

Change-Id: I85ea62f9af0d0c61e866a1937f79921d854fd1dc
Signed-off-by: tony.xie <tony.xie@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>

MALI: midgard: ARM: patch for fence timeout in monkey test

comes from mali support case [TAC674871].

Change-Id: I5e7c54190e24eea0306a9d64545482c6209a2c0d
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

rk: gcc-wrapper.py ignore memcontrol.c:5346

Change-Id: I19b5f58f395cce934fe2efbb01267576b7772c02
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

arm64: rockchip_defconfig: enable cpu avs

Change-Id: I626d1d238ea8efa38763fb6360936ce13c0c17fe
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs

This patch supports adjusting opp's voltage according to leakage

Change-Id: Ifbb6b6fec03abe0c7708a148affe4d7646ce38fa
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

arm64: dts: rockchip: add cpu-avs node for rk3399

Change-Id: Ibfcda65b6b97af453942888cf07e8f08b06768c2
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

dt-bindings: add binding document for Rockchip cpu avs

This patch documents the Rockchip cpu avs device tree binding.

Change-Id: I4a86cd384f304a5d77ff2763b2347804699b9b93
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

PM / OPP: Support adjusting OPP voltages at runtime

On some SoCs the Adaptive Voltage Scaling (AVS) technique is
employed to optimize the operating voltage of a device. At a
given frequency, the hardware monitors dynamic factors and either
makes a suggestion for how much to adjust a voltage for the
current frequency, or it automatically adjusts the voltage
without software intervention. Add an API to the OPP library for
the former case, so that AVS type devices can update the voltages
for an OPP when the hardware determines the voltage should
change. The assumption is that drivers like CPUfreq or devfreq
will register for the OPP notifiers and adjust the voltage
according to suggestions that AVS makes.

Change-Id: Ia6dddc0976f116555965f784794b8eca37582737
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

arm64: dts: rockchip: rk3399: add discrete vr support for box hardware

Change-Id: I64078f3ab5730a451df05e64bee779fe99051af0
Signed-off-by: Luo wei <lw@rock-chips.com>

arm64: dts: rk3399-vr: enable rk_headset on rk3399 vr

Change-Id: I4e078c586e6654c3a4711d0b0108d28360db9453
Signed-off-by: Wu Liangqing <wlq@rock-chips.com>

arm64: rockchip_defconfig: enable DEFAULT_USE_ENERGY_AWARE

Same as before merge last lsk.

Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

Merge branch 'linux-linaro-lsk-v4.4-android' of git://git.linaro.org/kernel/linux-linaro-stable.git

* linux-linaro-lsk-v4.4-android: (1362 commits)
  Linux 4.4.30
  Revert "fix minor infoleak in get_user_ex()"
  Revert "x86/mm: Expand the exception table logic to allow new handling options"
  Linux 4.4.29
  ARM: pxa: pxa_cplds: fix interrupt handling
  powerpc/nvram: Fix an incorrect partition merge
  mpt3sas: Don't spam logs if logging level is 0
  perf symbols: Fixup symbol sizes before picking best ones
  perf symbols: Check symbol_conf.allow_aliases for kallsyms loading too
  perf hists browser: Fix event group display
  clk: divider: Fix clk_divider_round_rate() to use clk_readl()
  clk: qoriq: fix a register offset error
  s390/con3270: fix insufficient space padding
  s390/con3270: fix use of uninitialised data
  s390/cio: fix accidental interrupt enabling during resume
  x86/mm: Expand the exception table logic to allow new handling options
  dmaengine: ipu: remove bogus NO_IRQ reference
  power: bq24257: Fix use of uninitialized pointer bq->charger
  staging: r8188eu: Fix scheduling while atomic splat
  ASoC: dapm: Fix kcontrol creation for output driver widget
  ...

Revert "ARM64: cpufreq_sched: implement event CPUFREQ_GOV_LIMIT for governor"

This reverts commit d94634b0ab1bd61cc4088de63608287938a8fec2.

Fixed by commit 24884e54340e35d43bd09af0b12caef57a63458f
("sched/cpufreq_sched: Consolidated update")

Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

Revert "ARM64: sched: cpufreq_sched: fix bug: init data before use it in thread"

This reverts commit 0ac5bfd6d9652d477387764a11e3b48f1afe6891.

Fixed by commit ac6f9bad52a79154bebd1626344dfc206d1cbefe
("FIXUP: sched: scheduler-driven cpu frequency selection")

Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

Revert "ARM64: sched: fix bug: avoid infinite loop"

This reverts commit d4773e1407b6d59a202bd4ce8acc83deaceafa29.

Fixed by commit abdb60d816bfd20b8d4f61c3e7c95a61ad12212a
("FIXUP: sched/fair: Fix hang during suspend in sched_group_energy")

Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

Revert "ROCKCHIP: sched: enable the feature ENERGY_AWARE"

This reverts commit a9ad2b25a053c995e9a5fd256cc655f32897ed68.

Fixed by commit fc1d6c8c6a6e7353147bcb02d0236db5714804d2
("sched: Add Kconfig option DEFAULT_USE_ENERGY_AWARE to set ENERGY_AWARE feature flag")

Signed-off-by: Huang, Tao <huangtao@rock-chips.com>

Revert "UPSTREAM: usb: dwc3: core: Move the mode setting to the right place"

This reverts commit 104756064072e39790eb16c5c987744e81d52a62.

This commit 1047560 will reinit dwc3 controller mode
when resuming dwc3 core. Generally, this patch can be
used for "dr_mode = host", "dr_mode = peripheral" and
"dr_mode = otg".

However, rockchip dwc3 core don't support otg function,
but only support DRD mode. So on rockchip platform, we
set dr_mode to otg for DRD mode, then switch host and
peripheral dynamically by extcon notifier. Also, we will
enable dwc3 to be a wakeup source and enable usb3 power
domain in suspend mode if usb device is pluged in. So
dwc3 controller will not lost the mode when resuming dwc3
core.

Change-Id: I0ee4f5b02d4504e853d8ef81df3df9a8a4ac284f
Signed-off-by: William Wu <wulf@rock-chips.com>

nvmem: rockchip-efuse: Change initcall to subsys

We will add a avs driver to adjust opp's voltage according to leakage.
As it need register a notifier before cpufreq starts, and make cpufreq
defer probe is probably not really easy, so avs should probe earlier
than cpufreq, efuse should probe earlier than avs.

Change-Id: I817aa44c3b34d2fdf44148e6b9649ceed76d8f1f
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>

UPSTREAM: phy: Add reset callback

The only use for this is for solving a hardware design problem in
usb of Rockchip RK3288.

Change-Id: I40b17f5c33125c77759808720763d2694dfc25f2
Signed-off-by: Randy Li <ayaka@soulik.info>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit cac18ecb6f44b11bc303d7afbae3887b27938fa4)

firmware: rockchip: sip: add rockchip SIP runtime service

Change-Id: I996a90b3f6cb471f255566dfab0059a55da8866d
Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>

video: rockchip: 3399 vop: fix pwm config done lead to iommu pagefault

Change-Id: Ia8e8a3ccaf9a713d96e93a435503d8b55b794f3b
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

arm64: dts: rockchip: enable rk_headset on rk3399 mid

Change-Id: I8ef75283727152e7c5fa7380813296bc7220ed91
Signed-off-by: zhangjun <zhangjun@rock-chips.com>

Merge branch 'linux-linaro-lsk-v4.4' into linux-linaro-lsk-v4.4-android

 Merge tag 'v4.4.30' into linux-linaro-lsk-v4.4

 This is the 4.4.30 stable release

CHROMIUM: xhci: stop roothub port polling timer in shutdown

The xhci hcd use the port polling timer (rh_timer) to poll the
roothub for port events. But we can't allow the USB core to poll
the port events during shutdown because the xhci controller may
be disable and can't be accessed in shutdown. If we access xhci
port registers with port polling timer after xhci shutdown, it
may cause kernel crash or unexpected behavior. So we need to stop
the port polling timer while shutdown xhci.

I can easily reproduce the issue on rk3399 platform, plug in a
Type-C hub and an USB ethernet dongle, then do reboot test,
result in a crash with the following backtrace.

Unhandled fault: synchronous external abort (0x96000010) at 0xffffff80002f0430
Internal error: : 96000010 [#1] PREEMPT SMP
task: ffffffc001092cb0 ti: ffffffc00107c000 task.ti: ffffffc00107c000
PC is at xhci_hub_status_data+0xec/0x1e4
LR is at xhci_hub_status_data+0xb0/0x1e4
[<ffffffc00067a210>] xhci_hub_status_data+0xec/0x1e4
[<ffffffc00063ebf8>] usb_hcd_poll_rh_status+0x54/0x148
[<ffffffc00063ed0c>] rh_timer_func+0x20/0x2c
[<ffffffc0002845cc>] call_timer_fn+0xa4/0x1c8
[<ffffffc000284964>] run_timer_softirq+0x248/0x2cc
[<ffffffc000200928>] __do_softirq+0x178/0x338
[<ffffffc000224b08>] irq_exit+0x78/0xc0
[<ffffffc00027089c>] __handle_domain_irq+0x9c/0xbc
[<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188

BUG=chrome-os-partner:59111
TEST=Plug in a Type-C hub, then do reboot test, check if
kernel crash during shutdown.

Change-Id: I3ca3d12d101241cd78138ea5d995708a2893d1a0
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/401121
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

CHROMIUM: xhci: do shutdown only hcd is registered

On some sepcial platforms (e.g. rk3399 platform), they will call
usb_remove_hcd() to remove xhci hcd if no device connected, and
also call xhci_stop() to halt and reset xhci. So we don't need to
do the same thing in shutdown if hcd has been unregistered.

In addition to remove hcd, rk3399 platform will disable xhci power
domain in runtime suspend, if we try to access xhci registers in
shutdown, it might cause kernel crash or unexpected behavior.

BUG=chrome-os-partner:59111
TEST=reboot the system

Change-Id: I7ecfce068211ff1c4a884fc4a8a54ca5b84c1c09
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/401120
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

CHROMIUM: usb: xhci-plat: use usb_hcd_platform_shutdown() callback

The xhci driver provides xhci_shutdown() to be called with the main
usb_hcd (the USB3 roothub) while do reboot. But actually, xhci-plat
never call xhci_shutdwon() during reboot because it doesn't use the
usb_hcd_platform_shutdown() helper.

So we use use usb_hcd_platform_shutdown() for xhci-plat, and the
normal shutdown call trace is:
kernel_restart -> kernel_restart_prepare -> device_shutdown ->
platform_drv_shutdown -> usb_hcd_platform_shutdown -> xhci_shutdown

BUG=chrome-os-partner:59111
TEST=reboot the system

Change-Id: I9be424257ea6ba1e51521cbdd01f4698ae1752ad
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/401119
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>

Linux 4.4.30

Revert "fix minor infoleak in get_user_ex()"

This reverts commit 9d25c78ec01c402dc56272693c44ef9d72ecdd2e which is
1c109fabbd51863475cd12ac206bdd249aee35af upstream

Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "x86/mm: Expand the exception table logic to allow new handling options"

This reverts commit fcf5e5198b447969ed2a56ec335dae3c695a6b46 which is
548acf19234dbda5a52d5a8e7e205af46e9da840 upstream.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 4.4.29

ARM: pxa: pxa_cplds: fix interrupt handling

commit 9ba63e3cc849cdaf3b675c47cc51fe35419e5117 upstream.

Since its initial commit, the driver is buggy for multiple interrupts
handling. The translation from the former lubbock.c file was not
complete, and might stall all interrupt handling when multiple
interrupts occur.

This is especially true when inside the interrupt handler and if a new
interrupt comes and is not handled, leaving the output line still held,
and not creating a transition as the GPIO block behind would expect to
trigger another cplds_irq_handler() call.

For the record, the hardware is working as follows.

The interrupt mechanism relies on :
 - one status register
 - one mask register

Let's suppose the input irq lines are called :
 - i_sa1111
 - i_lan91x
 - i_mmc_cd
Let's suppose the status register for each irq line is called :
 - status_sa1111
 - status_lan91x
 - status_mmc_cd
Let's suppose the interrupt mask for each irq line is called :
 - irqen_sa1111
 - irqen_lan91x
 - irqen_mmc_cd
Let's suppose the output irq line, connected to GPIO0 is called :
 - o_gpio0

The behavior is as follows :
 - o_gpio0 = not((status_sa1111 & irqen_sa1111) |
 (status_lan91x & irqen_lan91x) |
 (status_mmc_cd & irqen_mmc_cd))
   => this is a N-to-1 NOR gate and multiple AND gates
 - irqen_* is exactly as programmed by a write to the FPGA
 - status_* behavior is governed by a bi-stable D flip-flop
   => on next FPGA clock :
     - if i_xxx is high, status_xxx becomes 1
     - if i_xxx is low, status_xxx remains as it is
     - if software sets status_xxx to 0, the D flip-flop is reset
       => status_xxx becomes 0
       => on next FPGA clock cycle, if i_xxx is high, status_xxx becomes
  1 again

Fixes: fc9e38c0f4d3 ("ARM: pxa: lubbock: use new pxa_cplds driver")
Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc/nvram: Fix an incorrect partition merge

commit 11b7e154b132232535befe51c55db048069c8461 upstream.

When we merge two contiguous partitions whose signatures are marked
NVRAM_SIG_FREE, We need update prev's length and checksum, then write it
to nvram, not cur's. So lets fix this mistake now.

Also use memset instead of strncpy to set the partition's name. It's
more readable if we want to fill up with duplicate chars .

Fixes: fa2b4e54d41f ("powerpc/nvram: Improve partition removal")
Signed-off-by: Pan Xinhui <xinhui.pan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mpt3sas: Don't spam logs if logging level is 0

commit 0d667f72b2a20bbac72bec0ab11467fc70bb0f1f upstream.

In _scsih_io_done() we test if the ioc->logging_level does _not_ have
the MPT_DEBUG_REPLY bit set and if it hasn't we print the debug
messages. This unfortunately is the wrong way around.

Note, the actual bug is older than af0094115 but this commit removed the
CONFIG_SCSI_MPT3SAS_LOGGING Kconfig option which hid the bug.

Fixes: af0094115 'mpt2sas, mpt3sas: Remove SCSI_MPTXSAS_LOGGING entry from Kconfig'
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Acked-by: Chaitra P B <chaitra.basappa@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf symbols: Fixup symbol sizes before picking best ones

commit 432746f8e0b6a82ba832b771afe31abd51af6752 upstream.

When we call symbol__fixup_duplicate() we use algorithms to pick the
"best" symbols for cases where there are various functions/aliases to an
address, and those check zero size symbols, which, before calling
symbol__fixup_end() are _all_ symbols in a just parsed kallsyms file.

So first fixup the end, then fixup the duplicates.

Found while trying to figure out why 'perf test vmlinux' failed, see the
output of 'perf test -v vmlinux' to see cases where the symbols picked
as best for vmlinux don't match the ones picked for kallsyms.

Cc: Anton Blanchard <anton@samba.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 694bf407b061 ("perf symbols: Add some heuristics for choosing the best duplicate symbol")
Link: http://lkml.kernel.org/n/tip-rxqvdgr0mqjdxee0kf8i2ufn@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf symbols: Check symbol_conf.allow_aliases for kallsyms loading too

commit c97b40e4d15f13a36cd037d598e45cbe9e1e5757 upstream.

We can allow aliases to be kept, but we were checking this just when
loading vmlinux files, be consistent, do it for any symbol table loading
code that calls symbol__fixup_duplicate() by making this function check
.allow_aliases instead.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 680d926a8cb0 ("perf symbols: Allow symbol alias when loading map for symbol name")
Link: http://lkml.kernel.org/n/tip-z0avp0s6cfjckc4xj3pdfjdz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf hists browser: Fix event group display

commit d9ea48bc4e7cc297ca1073fa3f90ed80d964b7b4 upstream.

Milian reported that the event group on TUI shows duplicated overhead.
This was due to a bug on calculating hpp->buf position.  The
hpp_advance() was called from __hpp__slsmg_color_printf() on TUI but
it's already called from the hpp__call_print_fn macro in __hpp__fmt().
The end result is that the print function returns number of bytes it
printed but the buffer advanced twice of the length.

This is generally not a problem since it doesn't need to access the
buffer again.  But with event group, overhead needs to be printed
multiple times and hist_entry__snprintf_alignment() tries to fill the
space with buffer after it printed.  So it (brokenly) showed the last
overhead again.

The bug was there from the beginning, but I think it's only revealed
when the alignment function was added.

Reported-by: Milian Wolff <milian.wolff@kdab.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Fixes: 89fee7094323 ("perf hists: Do column alignment on the format iterator")
Link: http://lkml.kernel.org/r/20160912061958.16656-2-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: divider: Fix clk_divider_round_rate() to use clk_readl()

commit 2cf9a57811bddb6fa6b0f8d7376da164d5534813 upstream.

clk-divider uses clk_readl()/clk_writel() everywhere, except in
clk_divider_round_rate(), where plain readl() is used. Change this to
clk_readl(), as it makes a difference on powerpc.

Fixes: e6d5e7d90be92cee ("clk-divider: Fix READ_ONLY when divider > 1")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

clk: qoriq: fix a register offset error

commit 8964193f6bfda5c4cf14eedb7e94892c1f1c34f0 upstream.

The offset of Core Cluster clock control/status register
on cluster group V3 version is different from others, and
should be plus 0x70000.

Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
Reviewed-by: Scott Wood <oss@buserror.net>
Fixes: 9e19ca2f627e ("clk: qoriq: Add ls2080a support.")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/con3270: fix insufficient space padding

commit 6cd997db911f28f2510b771691270c52b63ed2e6 upstream.

con3270 contains an optimisation that reduces the amount of data to be
transmitted to the 3270 terminal by putting a Repeat to Address (RA)
order into the data stream. The RA order itself takes up space, so
con3270 only uses it if there's enough space left in the line
buffer. Otherwise it just pads out the line manually.

For lines that were _just_ short enough that the RA order still fit in
the line buffer, the line was instead padded with an insufficient
amount of spaces. This was caused by examining the size of the
allocated line buffer rather than the length of the string to be
displayed.

For con3270_cline_end(), we just compare against the line length. For
con3270_update_string() however that isn't available anymore, so we
check whether the Repeat to Address order is present.

Fixes: f51320a5 ("[PATCH] s390: new 3270 driver.") (tglx/history.git)
Tested-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Tested-by: Yang Chen <bjcyang@linux.vnet.ibm.com>
Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/con3270: fix use of uninitialised data

commit c14f2aac7aa147861793eed9f41f91dd530f0be1 upstream.

con3270 contains an optimisation that reduces the amount of data to be
transmitted to the 3270 terminal by putting a Repeat to Address (RA)
order into the data stream. The RA order itself takes up space, so
con3270 only uses it if there's enough space left in the line
buffer. Otherwise it just pads out the line manually.

For lines too long to include the RA order, one byte was left
uninitialised. This was caused by an off-by-one bug in the loop that
pads out the line. Since the buffer is allocated from a common pool,
the single byte left uninitialised contained some previous buffer
content. Usually this was just a space or some character (which can
result in clutter but is otherwise harmless). Sometimes, however, it
was a Repeat to Address order, messing up the entire screen layout and
causing the display to send the entire buffer content on every
keystroke.

Fixes: f51320a5 ("[PATCH] s390: new 3270 driver.") (tglx/history.git)
Reported-by: Liu Jing <liujbjl@linux.vnet.ibm.com>
Tested-by: Jing Liu <liujbjl@linux.vnet.ibm.com>
Tested-by: Yang Chen <bjcyang@linux.vnet.ibm.com>
Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/cio: fix accidental interrupt enabling during resume

commit d53c51f26145657aa7c55fa396f93677e613548d upstream.

Since commit 9f3d6d7 chsc_get_channel_measurement_chars is called with
interrupts disabled during resume from hibernate. Since this function
used spin_unlock_irq, interrupts have been enabled accidentally. Fix
this by using the irqsave variant.

Since we can't guarantee the IRQ-enablement state for all (future/
external) callers, change the locking in related functions to prevent
similar bugs in the future.

Fixes: 9f3d6d7 ("s390/cio: update measurement characteristics")
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/mm: Expand the exception table logic to allow new handling options

commit 548acf19234dbda5a52d5a8e7e205af46e9da840 upstream.

Huge amounts of help from  Andy Lutomirski and Borislav Petkov to
produce this. Andy provided the inspiration to add classes to the
exception table with a clever bit-squeezing trick, Boris pointed
out how much cleaner it would all be if we just had a new field.

Linus Torvalds blessed the expansion with:

  ' I'd rather not be clever in order to save just a tiny amount of space
    in the exception table, which isn't really criticial for anybody. '

The third field is another relative function pointer, this one to a
handler that executes the actions.

We start out with three handlers:

 1: Legacy - just jumps the to fixup IP
 2: Fault - provide the trap number in %ax to the fixup code
 3: Cleaned up legacy for the uaccess error hack

Signed-off-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/f6af78fcbd348cf4939875cfda9c19689b5e50b8.1455732970.git.tony.luck@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: ipu: remove bogus NO_IRQ reference

commit 86c7e6836479c4045a9a81ed5ea76c51d719f9c1 upstream.

A workaround for a warning introduced a use of the NO_IRQ
macro that should have been gone for a long time.

It is clear from the code that the value cannot actually
be used, but apparently there was a configuration at
some point that caused a warning, so instead of just
reverting that patch, this rearranges the code in a way that
the warning cannot reappear.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 6ef41cf6f721 ("dmaengine :ipu: change ipu_irq_handler() to remove compile warning")
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

power: bq24257: Fix use of uninitialized pointer bq->charger

commit 0610735928ee47870e083d5901caa371089216f1 upstream.

bq->charger is initialized in bq24257_power_supply_init.
Therefore, bq24257_power_supply_init should be called before the
registration of the IRQ handler bq24257_irq_handler_thread that calls
power_supply_changed(bq->charger).

Signed-off-by: Georges Savoundararadj <savoundg@gmail.com>
Cc: Aurelien Chanot <chanot.a@gmail.com>
Cc: Andreas Dannenberg <dannenberg@ti.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Fixes: 2219a935963e ("power_supply: Add TI BQ24257 charger driver")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: r8188eu: Fix scheduling while atomic splat

commit 1335a9516d3d52f157ad87456efdd8dc9ae1747b upstream.

Commit fadbe0cd5292851608e2e01b91d9295fa287b9fe ("staging: rtl8188eu:
Remove rtw_zmalloc(), wrapper for kzalloc()") changed all allocation
calls to be GFP_KERNEL even though the original wrapper was testing
to determine if the caller was in atomic mode. Most of the mistakes
were corrected with commit 33dc85c3c667209c930b2dac5ccbc2a365e06b7a
("staging: r8188eu: Fix scheduling while atomic error introduced in
commit fadbe0cd"); however, two kzalloc calls were missed as the
call only happens when the driver is shutting down.

Fixes: fadbe0cd5292851608e2e01b91d9295fa287b9fe ("staging: rtl8188eu: Remove rtw_zmalloc(), wrapper for kzalloc()")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: navin patidar <navin.patidar@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: dapm: Fix kcontrol creation for output driver widget

commit a3930ed060df4ccf2a06cf0b68738dec3e6ff89a upstream.

Commit d88429a695a4 ("ASoC: dapm: Add output driver widget") added
the snd_soc_dapm_out_drv ID for the output driver widget, which is
the same as the PGA widget, with a later power sequence number.

Commit 19a2557b76d6 ("ASoC: dapm: Add kcontrol support for PGAs")
then added kcontrol support for PGA widgets, but failed to account
for output driver widgets. Attempts to use kcontrols with output
driver widgets result in silent failures, with the developer having
little idea about what went on.

Add snd_soc_dapm_out_drv to the switch/case block under snd_soc_dapm_pga
in dapm_create_or_share_kcontrol, since they are essentially the same.

Fixes: 19a2557b76d6 (ASoC: dapm: Add kcontrol support for PGAs)
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: dapm: Fix value setting for _ENUM_DOUBLE MUX's second channel

commit 071133a209354f39d4e5785d5a6a390e03241841 upstream.

The value for the second channel in _ENUM_DOUBLE (double channel) MUXs
is not correctly updated, due to using the wrong bit shift.

Use the correct bit shift, so both channels toggle together.

Fixes: 3727b4968453 (ASoC: dapm: Consolidate MUXs and value MUXs)
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: dapm: Fix possible uninitialized variable in snd_soc_dapm_get_volsw()

commit 01ad5e7de67b408d9b48b437b06a9938ddf460b5 upstream.

If soc_dapm_read() fails, val will be uninitialized, and bogus values
will be written later:

ret = soc_dapm_read(dapm, reg, &val);
val = (val >> shift) & mask;

However, the compiler does not give a warning. Return on error before
val is really used to avoid this.

This is similar to the commit 6912831623c5 ("ASoC: dapm: Fix
uninitialized variable in snd_soc_dapm_get_enum_double()")

Fixes: ce0fc93ae56e (ASoC: Add DAPM support at the component level)
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: topology: Fix error return code in soc_tplg_dapm_widget_create()

commit 8ae3ea48df0d746b663057cf0b972a18d0777b7b upstream.

Fix to return error code -ENOMEM instead of 0 when failed to create
widget, as done elsewhere in this function.

Fixes: 8a9782346dcc ("ASoC: topology: Add topology core")
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hwrng: omap - Only fail if pm_runtime_get_sync returns < 0

commit ad8529fde9e3601180a839867a8ab041109aebb5 upstream.

Currently omap-rng checks the return value of pm_runtime_get_sync and
reports failure if anything is returned, however it should be checking
if ret < 0 as pm_runtime_get_sync return 0 on success but also can return
1 if the device was already active which is not a failure case. Only
values < 0 are actual failures.

Fixes: 61dc0a446e5d ("hwrng: omap - Fix assumption that runtime_get_sync will always succeed")
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: arm/ghash-ce - add missing async import/export

commit ed4767d612fd2c39e2c4c69eba484c1219dcddb6 upstream.

Since commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero"),
all ahash drivers are required to implement import()/export(), and must have
a non-zero statesize. Fix this for the ARM Crypto Extensions GHASH
implementation.

Fixes: 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: gcm - Fix IV buffer size in crypto_gcm_setkey

commit 50d2e6dc1f83db0563c7d6603967bf9585ce934b upstream.

The cipher block size for GCM is 16 bytes, and thus the CTR transform
used in crypto_gcm_setkey() will also expect a 16-byte IV. However,
the code currently reserves only 8 bytes for the IV, causing
an out-of-bounds access in the CTR transform. This patch fixes
the issue by setting the size of the IV buffer to 16 bytes.

Fixes: 84c911523020 ("[CRYPTO] gcm: Add support for async ciphers")
Signed-off-by: Ondrej Mosnacek <omosnacek@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mwifiex: correct aid value during tdls setup

commit b64db1b252e9974a43a51ba083fa7d03e4716167 upstream.

AID gets updated during TDLS setup, but modified value isn't reflected
in "priv->assoc_rsp_buf". This causes TDLS setup failure. The problem is
fixed here.

Fixes: 4aff53ef18e4a4 ("mwifiex: parsing aid while receiving..")
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: spi-fsl-dspi: Drop extra spi_master_put in device remove function

commit 6999aeabbb703a81a204cb6f9f8f151759a99ac4 upstream.

The call sequence spi_alloc_master/spi_register_master/spi_unregister_master
is complete; it reduces the device reference count to zero, which and results
in device memory being freed. The subsequent call to spi_master_put is
unnecessary and results in an access to free memory. Drop it.

Fixes: 9298bc727385 ("spi: spi-fsl-dspi: Remove spi-bitbang")
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: clk-imx35: fix name for ckil clk

commit fcff03813a7c612873303037cef5ba0329850c35 upstream.

This fixes
[    0.000000] i.MX clk 82: register failed with -17
because the name is duplicated.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 3713e3f5e927 ("clk: imx35: define two clocks for rtc")
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

uio: fix dmem_region_start computation

commit 4d31a2588ae37a5d0f61f4d956454e9504846aeb upstream.

The variable i contains a total number of resources (including
IORESOURCE_IRQ). However, we want the dmem_region_start to point
after the last resource of type IORESOURCE_MEM. The original behaviour
leads (very likely) to skipping several UIO mapping regions and makes
them useless. Fix this by computing dmem_region_start from the uiomem
which points to the last used UIO mapping.

Fixes: 0a0c3b5a24bd ("Add new uio device for dynamic memory allocation")
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

genirq/generic_chip: Add irq_unmap callback

commit ee26c013cdee0b947e29d6cadfb9ff3341c69ff9 upstream.

Without this patch irq_domain_disassociate() cannot properly release the
interrupt. In fact, irq_map_generic_chip() checks a bit on 'gc->installed'
but said bit is never cleared, only set.

Commit 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
added irq_map_generic_chip() function and also stated "This lacks a removal
function for now".

This commit provides an implementation of an unmap function that can be
called by irq_domain_disassociate().

[ tglx: Made the function static and removed the export as we have neither
   a prototype nor a modular user. ]

Fixes: 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
Signed-off-by: Sebastian Frias <sf84@laposte.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mason <slash.tmp@free.fr>
Cc: Jason Cooper <jason@lakedaemon.net>
Link: http://lkml.kernel.org/r/579F5C5A.2070507@laposte.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf stat: Fix interval output values

commit 51fd2df1e882a3c2a3f4b6c9ff243a93c9046dba upstream.

We broke interval data displays with commit:

  3f416f22d1e2 ("perf stat: Do not clean event's private stats")

This commit removed stats cleaning, which is important for '-r' option
to carry counters data over the whole run. But it's necessary to clean
it for interval mode, otherwise the displayed value is avg of all
previous values.

Before:
  $ perf stat -e cycles -a -I 1000 record
  #           time             counts unit events
       1.000240796         75,216,287      cycles
       2.000512791        107,823,524      cycles

  $ perf stat report
  #           time             counts unit events
       1.000240796         75,216,287      cycles
       2.000512791         91,519,906      cycles

Now:
  $ perf stat report
  #           time             counts unit events
       1.000240796         75,216,287      cycles
       2.000512791        107,823,524      cycles

Notice the second value being bigger (91,.. < 107,..).

This could be easily verified by using perf script which displays raw
stat data:

  $ perf script
  CPU  THREAD       VAL         ENA         RUN        TIME EVENT
    0      -1  23855779  1000209530  1000209530  1000240796 cycles
    1      -1  33340397  1000224964  1000224964  1000240796 cycles
    2      -1  15835415  1000226695  1000226695  1000240796 cycles
    3      -1   2184696  1000228245  1000228245  1000240796 cycles
    0      -1  97014312  2000514533  2000514533  2000512791 cycles
    1      -1  46121497  2000543795  2000543795  2000512791 cycles
    2      -1  32269530  2000543566  2000543566  2000512791 cycles
    3      -1   7634472  2000544108  2000544108  2000512791 cycles

The sum of the first 4 values is the first interval aggregated value:

  23855779 + 33340397 + 15835415 + 2184696 = 75,216,287

The sum of the second 4 values minus first value is the second interval
aggregated value:

  97014312 + 46121497 + 32269530 + 7634472 - 75216287 = 107,823,524

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1454485436-20639-1-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc/eeh: Null check uses of eeh_pe_bus_get

commit 04fec21c06e35b169a83e75a84a015ab4606bf5e upstream.

eeh_pe_bus_get() can return NULL if a PCI bus isn't found for a given PE.
Some callers don't check this, and can cause a null pointer dereference
under certain circumstances.

Fix this by checking NULL everywhere eeh_pe_bus_get() is called.

Fixes: 8a6b1bc70dbb ("powerpc/eeh: EEH core to handle special event")
Cc: stable@vger.kernel.org # v3.11+
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tunnels: Remove encapsulation offloads on decap.

commit a09a4c8dd1ec7f830e1fb9e59eb72bddc965d168 upstream.

If a packet is either locally encapsulated or processed through GRO
it is marked with the offloads that it requires. However, when it is
decapsulated these tunnel offload indications are not removed. This
means that if we receive an encapsulated TCP packet, aggregate it with
GRO, decapsulate, and retransmit the resulting frame on a NIC that does
not support encapsulation, we won't be able to take advantage of hardware
offloads even though it is just a simple TCP packet at this point.

This fixes the problem by stripping off encapsulation offload indications
when packets are decapsulated.

The performance impacts of this bug are significant. In a test where a
Geneve encapsulated TCP stream is sent to a hypervisor, GRO'ed, decapsulated,
and bridged to a VM performance is improved by 60% (5Gbps->8Gbps) as a
result of avoiding unnecessary segmentation at the VM tap interface.

Reported-by: Ramu Ramamurthy <sramamur@linux.vnet.ibm.com>
Fixes: 68c33163 ("v4 GRE: Add TCP segmentation offload for GRE")
Signed-off-by: Jesse Gross <jesse@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
(backported from commit a09a4c8dd1ec7f830e1fb9e59eb72bddc965d168)
[adapt iptunnel_pull_header arguments, avoid 7f290c9]
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juerg Haefliger <juerg.haefliger@hpe.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tunnels: Don't apply GRO to multiple layers of encapsulation.

commit fac8e0f579695a3ecbc4d3cac369139d7f819971 upstream.

When drivers express support for TSO of encapsulated packets, they
only mean that they can do it for one layer of encapsulation.
Supporting additional levels would mean updating, at a minimum,
more IP length fields and they are unaware of this.

No encapsulation device expresses support for handling offloaded
encapsulated packets, so we won't generate these types of frames
in the transmit path. However, GRO doesn't have a check for
multiple levels of encapsulation and will attempt to build them.

UDP tunnel GRO actually does prevent this situation but it only
handles multiple UDP tunnels stacked on top of each other. This
generalizes that solution to prevent any kind of tunnel stacking
that would cause problems.

Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack")
Signed-off-by: Jesse Gross <jesse@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Juerg Haefliger <juerg.haefliger@hpe.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipip: Properly mark ipip GRO packets as encapsulated.

commit b8cba75bdf6a48ea4811bbefb11a94a5c7281b68 upstream.

ipip encapsulated packets can be merged together by GRO but the result
does not have the proper GSO type set or even marked as being
encapsulated at all. Later retransmission of these packets will likely
fail if the device does not support ipip offloads. This is similar to
the issue resolved in IPv6 sit in feec0cb3
("ipv6: gro: support sit protocol").

Reported-by: Patrick Boutilier <boutilpj@ednet.ns.ca>
Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload")
Tested-by: Patrick Boutilier <boutilpj@ednet.ns.ca>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jesse Gross <jesse@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Juerg Haefliger <juerg.haefliger@hpe.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

posix_acl: Clear SGID bit when setting file permissions

commit 073931017b49d9458aa351605b43a7e34598caef upstream.

When file permissions are modified via chmod(2) and the user is not in
the owning group or capable of CAP_FSETID, the setgid bit is cleared in
inode_change_ok().  Setting a POSIX ACL via setxattr(2) sets the file
permissions as well as the new ACL, but doesn't clear the setgid bit in
a similar way; this allows to bypass the check in chmod(2).  Fix that.

References: CVE-2016-7097
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()

commit ded89912156b1a47d940a0c954c43afbabd0c42c upstream.

User-space can choose to omit NL80211_ATTR_SSID and only provide raw
IE TLV data. When doing so it can provide SSID IE with length exceeding
the allowed size. The driver further processes this IE copying it
into a local variable without checking the length. Hence stack can be
corrupted and used as exploit.

Reported-by: Daxing Guo <freener.gdx@gmail.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Juerg Haefliger <juerg.haefliger@hpe.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm/hugetlb: fix memory offline with hugepage size > memory block size

commit 2247bb335ab9c40058484cac36ea74ee652f3b7b upstream.

Patch series "mm/hugetlb: memory offline issues with hugepages", v4.

This addresses several issues with hugepages and memory offline.  While
the first patch fixes a panic, and is therefore rather important, the
last patch is just a performance optimization.

The second patch fixes a theoretical issue with reserved hugepages,
while still leaving some ugly usability issue, see description.

This patch (of 3):

dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
list corruption and addressing exception when trying to set a memory
block offline that is part (but not the first part) of a "gigantic"
hugetlb page with a size > memory block size.

When no other smaller hugetlb page sizes are present, the VM_BUG_ON()
will trigger directly.  In the other case we will run into an addressing
exception later, because dissolve_free_huge_page() will not work on the
head page of the compound hugetlb page which will result in a NULL
hstate from page_hstate().

To fix this, first remove the VM_BUG_ON() because it is wrong, and then
use the compound head page in dissolve_free_huge_page().  This means
that an unused pre-allocated gigantic page that has any part of itself
inside the memory block that is going offline will be dissolved
completely.  Losing an unused gigantic hugepage is preferable to failing
the memory offline, for example in the situation where a (possibly
faulty) memory DIMM needs to go offline.

Changes for v4.4 stable:
  - make it apply w/o commit c1470b33 "mm/hugetlb: fix incorrect
    hugepages count during mem hotplug"

Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Link: http://lkml.kernel.org/r/20160926172811.94033-2-gerald.schaefer@de.ibm.com
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Unalias obj->phys_handle and obj->userptr

commit ca5732c53bf66ad755284786897e0dd10330de87 upstream.

We use obj->phys_handle to choose the pread/pwrite path, but as
obj->phys_handle is a union with obj->userptr, we then mistakenly use
the phys_handle path for userptr objects within pread/pwrite.

Testcase: igt/gem_userptr_blits/forbidden-operations
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-2-chris@chris-wilson.co.uk
(cherry picked from commit 5f12b80a0b42da253691ca03828033014bb786eb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Account for TSEG size when determining 865G stolen base

commit d721b02fd00bf133580f431b82ef37f3b746dfb2 upstream.

Looks like the TSEG lives just above TOUD, stolen comes after TSEG.

The spec seems somewhat self-contradictory in places, in the ESMRAMC
register desctription it says:
 TSEG Size:
  10=(TOUD + 512 KB) to TOUD
  11 =(TOUD + 1 MB) to TOUD

so that agrees with TSEG being at TOUD. But the example given
elsehwere in the spec says:

 TOUD equals 62.5 MB = 03E7FFFFh
 TSEG selected as 512 KB in size,
 Graphics local memory selected as 1 MB in size
 General System RAM available in system = 62.5 MB
 General system RAM range00000000h to 03E7FFFFh
 TSEG address range03F80000h to 03FFFFFFh
 TSEG pre-allocated from03F80000h to 03FFFFFFh
 Graphics local memory pre-allocated from03E80000h to 03F7FFFFh

so here we have TSEG above stolen.

Real world evidence agrees with the TOUD->TSEG->stolen order however, so
let's fix up the code to account for the TSEG size.

Cc: Taketo Kabe <fdporg@vega.pgw.jp>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Fixes: 0ad98c74e093 ("drm/i915: Determine the stolen memory base address on gen2")
Fixes: a4dff76924fe ("x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms")
Reported-by: Taketo Kabe <fdporg@vega.pgw.jp>
Tested-by: Taketo Kabe <fdporg@vega.pgw.jp>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96473
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470653919-27251-1-git-send-email-ville.syrjala@linux.intel.com
Link: http://download.intel.com/design/chipsets/datashts/25251405.pdf
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "drm/i915: Check live status before reading edid"

commit 23f889bdf6ee5cfff012d8b09f6bec920c691696 upstream.

This reverts commit 237ed86c693d8a8e4db476976aeb30df4deac74b.

Our current implementation of live status check (repeat 9 times
with 10ms delays between each attempt as a workaround for
buggy displays) imposes a rather serious penalty, time wise,
on intel_hdmi_detect().  Since we we already skip live status
checks on platforms before gen 7, and since we seem to have
coped quite well before the live status check was introduced
for newer platforms too, the previous behaviour is probably
preferable, at least unless someone can point to a use-case
that the live status check improves (apart from "Bspec says so".)

Signed-off-by: David Weinehall <david.weinehall@linux.intel.com>
Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid")
Fixes: f8d03ea0053b ("drm/i915: increase the tries for HDMI hotplug live status checking")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97139
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94014
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160817124748.31208-1-david.weinehall@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915/gen9: fix the WaWmMemoryReadLatency implementation

commit 4e4d3814a9bb4d71cd3ff0701d8d7041edefd8f0 upstream.

Bspec says:
  "The mailbox response data may not account for memory read latency.
   If the mailbox response data for level 0 is 0us, add 2 microseconds
   to the result for each valid level."

This means we should only do the +2 in case wm[0] == 0, not always.

So split the sanitizing implementation from the WA implementation and
fix the WA implementation.

v2: Add Fixes tag (Maarten).

Fixes: 367294be7c25 ("drm/i915/gen9: Add 2us read latency to WM level")
Cc: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-5-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 0727e40a48a1d08cf54ce2c01e120864b92e59bf)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xenbus: don't look up transaction IDs for ordinary writes

commit 9a035a40f7f3f6708b79224b86c5777a3334f7ea upstream.

This should really only be done for XS_TRANSACTION_END messages, or
else at least some of the xenstore-* tools don't work anymore.

Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced condition")
Reported-by: Richard Schütz <rschuetz@uni-koblenz.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Richard Schütz <rschuetz@uni-koblenz.de>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: "M. Vefa Bicakci" <m.v.b@runbox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/vmwgfx: Limit the user-space command buffer size

commit 51ab70bed997f64f091a639dbe22b629725a7faf upstream.

With older hardware versions, the user could specify arbitrarily large
command buffer sizes, causing a vmalloc / vmap space exhaustion.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon: change vblank_time's calculation method to reduce computational error.

commit 02cfb5fccb0f9f968f0e208d89d9769aa16267bc upstream.

Ported from Rex's amdgpu change.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon/si/dpm: fix phase shedding setup

commit 427920292b00474d978d632bc03a8e4e50029af3 upstream.

Used the wrong index to setup the phase shedding mask.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon: narrow asic_init for virtualization

commit 884031f0aacf57dad1575f96714efc80de9b19cc upstream.

Only needed on CIK+ due to the way pci reset is handled
by the GPU.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: change vblank_time's calculation method to reduce computational error.

commit dc8184aa8621ee8048652496884d9f40d4bb407f upstream.

Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/dce11: add missing drm_mode_config_cleanup call

commit 140c94da3c3338c0ff4cc127cf9bec87905ca83c upstream.

All other amdgpu/dce_v* files have this call, it's only mysteriously
missing from dce_v11_0.c since the file was added and causes leaks.

Fixes: aaa36a976bbb ("drm/amdgpu: Add initial VI support")
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/dce11: disable hpd on local panels

commit 3a9d993ee9809c217f4322623a9b78c8d17fdd1f upstream.

Otherwise we can get a hotplug interrupt storm when
we turn the panel off if hpd interrupts were enabled
by the bios.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97471

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/dce8: disable hpd on local panels

commit 324082586cc5918e3230f0b2f326656c653201eb upstream.

Otherwise we can get a hotplug interrupt storm when
we turn the panel off if hpd interrupts were enabled
by the bios.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97471

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/dce10: disable hpd on local panels

commit e96ec90f496603c48e0945f8bdeb4cdf3088cbba upstream.

Otherwise we can get a hotplug interrupt storm when
we turn the panel off if hpd interrupts were enabled
by the bios.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97471

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix IB alignment for UVD

commit c4795ca642b8bd76b5b6ffba41ba909543273d43 upstream.

According to the hw team, it should be 16, not 8.

Cc: Peter Fang <peter.fang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/prime: Pass the right module owner through to dma_buf_export()

commit 56a76c0123d6cb034975901c80fce2627338ef9e upstream.

dma_buf_export() adds a reference to the owning module to the dmabuf (to
prevent the driver from being unloaded whilst a third party still refers
to the dmabuf). However, drm_gem_prime_export() was passing its own
THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right
owner from the device->fops instead.

v2: Use C99 initializers to zero out unset elements of
dma_buf_export_info
v3: Extract the right module from dev->fops.

Testcase: igt/vgem_basic/unload
Reported-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Christian König <christian.koenig@amd.com>
Tested-by: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161005122145.1507-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc_otg_310: fix smatch warnings relate to locking imbalance.

This patch corrects the below locking imbalance warnings:

drivers/usb/dwc_otg_310/dwc_otg_driver.c:406 dwc_otg_force_device()
warn: inconsistent returns 'irqsave:flags'.
  Locked on:   line 390
  Unlocked on: line 406

Change-Id: Id79ebe0d41fbbab38c59384e23d7e2133c436c96
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>

rockchip/iep: bugfix, inconsistent mutex operation

Fix a inconsistent mutex operation in iep driver.

Change-Id: Iddb25d89013438da9a4985f9d9f663061c750eeb
Signed-off-by: alpha lin <alpha.lin@rock-chips.com>

Merge branch 'linux-linaro-lsk-v4.4' into linux-linaro-lsk-v4.4-android

 Merge tag 'v4.4.28' into linux-linaro-lsk-v4.4

 This is the 4.4.28 stable release

arm64: dts: rk3399-box: adjust hdmi phy_table for physical signal test

Change-Id: I4184d26dd26ccfa786d1147ec73caae006e32343
Signed-off-by: xuhuicong <xhc@rock-chips.com>

video: rockchip: hdmi: modify wrong phy freq of 4k@60hz(yuv420)10bit

the original phy pll of this Resolution is configure incorrect.
result in the phy clk freq Double. now fix it.

Change-Id: I2bcb669a2d61d53fee1ed521e672ea4306b401d5
Signed-off-by: xuhuicong <xhc@rock-chips.com>

Linux 4.4.28

target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code

commit 926317de33998c112c5510301868ea9aa34097e2 upstream.

This patch addresses a bug where a local EXTENDED_COPY WRITE or READ
backend I/O request would always return SAM_STAT_CHECK_CONDITION,
even if underlying xcopy_pt_cmd->se_cmd generated a different
SCSI status code.

ESX host environments expect to hit SAM_STAT_RESERVATION_CONFLICT
for certain scenarios, and SAM_STAT_CHECK_CONDITION results in
non-retriable status for these cases.

Tested on v4.1.y with ESX v5.5u2+ with local IBLOCK backend copy.

Reported-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
Tested-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
Cc: Nixon Vincent <nixon.vincent@calsoftinc.com>
Tested-by: Dinesh Israni <ddi@datera.io>
Signed-off-by: Dinesh Israni <ddi@datera.io>
Cc: Dinesh Israni <ddi@datera.io>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLE

commit 449a137846c84829a328757cd21fd9ca65c08519 upstream.

This patch addresses a bug where EXTENDED_COPY across multiple LUNs
results in a CHECK_CONDITION when the source + destination are not
located on the same physical node.

ESX Host environments expect sense COPY_ABORTED w/ COPY TARGET DEVICE
NOT REACHABLE to be returned when this occurs, in order to signal
fallback to local copy method.

As described in section 6.3.3 of spc4r22:

  "If it is not possible to complete processing of a segment because the
   copy manager is unable to establish communications with a copy target
   device, because the copy target device does not respond to INQUIRY,
   or because the data returned in response to INQUIRY indicates
   an unsupported logical unit, then the EXTENDED COPY command shall be
   terminated with CHECK CONDITION status, with the sense key set to
   COPY ABORTED, and the additional sense code set to COPY TARGET DEVICE
   NOT REACHABLE."

Tested on v4.1.y with ESX v5.5u2+ with BlockCopy across multiple nodes.

Reported-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
Tested-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
Cc: Nixon Vincent <nixon.vincent@calsoftinc.com>
Tested-by: Dinesh Israni <ddi@datera.io>
Signed-off-by: Dinesh Israni <ddi@datera.io>
Cc: Dinesh Israni <ddi@datera.io>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

target: Re-add missing SCF_ACK_KREF assignment in v4.1.y

commit 527268df31e57cf2b6d417198717c6d6afdb1e3e upstream.

This patch fixes a regression in >= v4.1.y code where the original
SCF_ACK_KREF assignment in target_get_sess_cmd() was dropped upstream
in commit 054922bb, but the series for addressing TMR ABORT_TASK +
LUN_RESET with fabric session reinstatement in commit febe562c20 still
depends on this code in transport_cmd_finish_abort().

The regression manifests itself as a se_cmd->cmd_kref +1 leak, where
ABORT_TASK + LUN_RESET can hang indefinately for a specific I_T session
for drivers using SCF_ACK_KREF, resulting in hung kthreads.

This patch has been verified with v4.1.y code.

Reported-by: Vaibhav Tandon <vst@datera.io>
Tested-by: Vaibhav Tandon <vst@datera.io>
Cc: Vaibhav Tandon <vst@datera.io>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ubifs: Fix xattr_names length in exit paths

commit 843741c5778398ea67055067f4cc65ae6c80ca0e upstream.

When the operation fails we also have to undo the changes
we made to ->xattr_names. Otherwise listxattr() will report
wrong lengths.

Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

jbd2: fix incorrect unlock on j_list_lock

commit 559cce698eaf4ccecb2213b2519ea3a0413e5155 upstream.

When 'jh->b_transaction == transaction' (asserted by below)

  J_ASSERT_JH(jh, (jh->b_transaction == transaction || ...

'journal->j_list_lock' will be incorrectly unlocked, since
the the lock is aquired only at the end of if / else-if
statements (missing the else case).

Signed-off-by: Taesoo Kim <tsgatesv@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Fixes: 6e4862a5bb9d12be87e4ea5d9a60836ebed71d28
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: do not advertise encryption support when disabled

commit c4704a4fbe834eee4109ca064131d440941f6235 upstream.

The sysfs file /sys/fs/ext4/features/encryption was present on kernels
compiled with CONFIG_EXT4_FS_ENCRYPTION=n.  This was misleading because
such kernels do not actually support ext4 encryption.  Therefore, only
provide this file on kernels compiled with CONFIG_EXT4_FS_ENCRYPTION=y.

Note: since the ext4 feature files are all hardcoded to have a contents
of "supported", it really is the presence or absence of the file that is
significant, not the contents (and this change reflects that).

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led

commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 upstream.

Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device,
must be done when it's runtime resumed. Currently this isn't case when
changing the led, so let's fix this by adding a pm_runtime_get_sync() and
a pm_runtime_put() around those operations.

Reported-by: Ritesh Raj Sarraf <rrs@researchut.com>
Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>