gpu: mali: allow midgard for linux build as a module

In order to build a kernel for different platforms, the mali
module should be load at boot time.

Change-Id: I03144648cb3548c6916620bc73fdfa2b4dab98dd
Signed-off-by: ayaka <ayaka@soulik.info>
Signed-off-by: Randy Li <randy.li@rock-chips.com>

mali: gpu: video: make the menu of midgard for linux visible

Although it is not allow to offer two config menu source at
the same time, but at lease we could tune some options of
it now.

Change-Id: I0b447876d13a0d5a95276cfe4600b6030f6b8529
Signed-off-by: ayaka <ayaka@soulik.info>
Signed-off-by: Randy Li <randy.li@rock-chips.com>

video: rockchip: vcodec: fix reboot crash when playing

shutdown function need wait last irq finish and then continue
its work.

Change-Id: I12bed04f6eeac1f12eedf55a09699be49fb4ac35
Signed-off-by: Jung Zhao <jung.zhao@rock-chips.com>

clk: rk3288: correct cif_out to vip_out

we already have vip_src and sclk_vip_out defined, which are the clocks
we add as cif_out, so let's correct it.

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

mfd: rk808: add rk805 support

include sub modules: regulator, rtc, gpio, pwrkey

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

ARM: dts: rockchip: add clocks for iommu in RK3288

As the commit "iommu/rockchip: Add pd/clk operation in iommu"
make iommu could operation clocks and power, this commit
would assign clocks to VPU, HEVC and VOP at rk3288.

Change-Id: I6a8f57e41e7db4f57200481e5a45dd24324c72f2
Signed-off-by: Randy Li <randy.li@rock-chips.com>

arm: dts: rk3288-evb add adc keys

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

arm: rockchip_linux_defconfig: add CONFIG_KEYBOARD_ADC

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

drm/rockchip: logo: no need IOMMU_WRITE for logo

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

drm/rockchip: logo: add iommu map size for logo buffer iommu mapping

Fix bug:
  iova 0x0(logo buffer) unmap fail:
    iommu: unaligned: iova 0x0 size 0xa5638 min_pagesz 0x1000
  then cause iova 0x0 mmap fail:
    iova: 0x0000000000000000 already mapped to 0x00000000f5c00000 cannot remap to phys: 0x00000000d6c6f000 prot: 0x3

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

ASoC: codec cx2072x will only use mclk 12.288M

1. due to cx2072x only support playback samplerate 48K
2. set_clk_rate called from codec side will make the clock
   tree correct, otherwise mclk will be closed from
   i2s_runtime_suspend unexpected

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

net: stmmac: dwmac-rk: Add rk3328 gmac support

Change-Id: I6d707c67c8edf809e47e1907765440088e162855
Signed-off-by: david.wu <david.wu@rock-chips.com>

PM / AVS: rockchip-io: Add rk3328 io-domains support

Change-Id: Ib99a22042cdc23367cd48a178b61b8744a8b3a57
Signed-off-by: david.wu <david.wu@rock-chips.com>

arm64: dts: rockchip: rk3399-android-next: fix color gradation

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

HID: hid-alps: fix touchpad data report error after the android restart

Change-Id: Id4204bc9b20ca257da65bcdec02eab8a6e398d02
Signed-off-by: Zhou weixin <zwx@rock-chips.com>

ARM64: dts: rk3399-tve1205g: disable android charge

1. disable android charge
2. disable uboot charge brightness

Change-Id: Id9c4d7d2c9ef52ab319d009fe883595fc7181c0e
Signed-off-by: Shunqing Chen <csq@rock-chips.com>

drm/rockchip: gem: fixup iommu_map_sg error path

If iommu_map_sg is error, it's return value is zero, but
rockchip_gem_iommu_map feel the zero return value is success,
bug happen:

[    5.227458] [drm:rockchip_gem_iommu_map] *ERROR* failed to map buffer: 0
[   12.291590] WARNING: at drivers/gpu/drm/drm_mm.c:369
[   12.291611] Modules linked in:
[   12.291634]
[   12.291658] CPU: 4 PID: 338 Comm: cameraserver Not tainted 4.4.41 #196
[   12.291680] Hardware name: rockchip,rk3399-mid (DT)
[   12.291703] task: ffffffc0e5a23100 ti: ffffffc0e5a64000 task.ti: ffffffc0e5a64000
[   12.291739] PC is at drm_mm_remove_node+0xc/0xf8
[   12.291766] LR is at rockchip_gem_iommu_unmap+0x3c/0x54
[   12.303799] [<ffffff80084526e0>] drm_mm_remove_node+0xc/0xf8
[   12.303827] [<ffffff8008475430>] rockchip_gem_free_object+0x98/0x168
[   12.303854] [<ffffff8008449e80>] drm_gem_object_free+0x2c/0x34
[   12.303878] [<ffffff80084626c4>] drm_gem_dmabuf_release+0x90/0xa4
[   12.303904] [<ffffff80084ee73c>] dma_buf_release+0x64/0x15c
[   12.303929] [<ffffff80081aa8dc>] __fput+0xe0/0x1a4
[   12.303950] [<ffffff80081aa9f8>] ____fput+0xc/0x14
[   12.303977] [<ffffff80080b65ec>] task_work_run+0xa0/0xc0
[   12.304004] [<ffffff8008087f18>] do_notify_resume+0x40/0x54
[   12.304026] [<ffffff80080825e4>] work_pending+0x10/0x14

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

drm/sysfs: add current display mode to sysfs

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

drm/sysfs: rename connector modes' name

Most drm display mode's name is "[hdisplay]x[vdisplay]", like "1440x900",
it's not a friendly name.

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

arm64: dts: rockchip: add adc key support for rk3399 linux project.

we use linux upstream adc key driver to support adc keyboard.

Change-Id: Id93a4ab3d58ff92ce0fc11b35abd4d4b8d3737e0
Signed-off-by: wenping.zhang <wenping.zhang@rock-chips.com>

arm64: dts: rockchip: replace clkreqn with cpm GPIO for rk3399-tve1205g

We should convert to use cpm mode instead of L1 substate.
Fix it anyway.

Change-Id: I5d997d53b2151ba9b1d29bd07272894a377c2eda
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

arm64: dts: rockchip: enable PCIe for rk3399-tve1205g

Change-Id: I8492ea9deb6ba517bcd7a8b4bf97494368904f67
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

arm64: rockchip_linux_defconfig: add CONFIG_KEYBOARD_ADC for rk3399 linux project.

Change-Id: Ieb8c8bf311202119a31798a9a39883fc5e121f02
Signed-off-by: wenping.zhang <wenping.zhang@rock-chips.com>

ARM: rockchip_linux_defconfig: add some config for wifi AP function

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

arm64: rockchip_linux_defconfig: add some config for wifi AP function

Change-Id: I6884fb9335d3f035f3ea8f530dcb8422e96c73c2
Signed-off-by: zzc <zzc@rock-chips.com>

usb: dwc3: rockchip: add force dr_mode function

In current code, the mode of usb is control by extcon or
define in the dts. So in the case of none extcon, we can't
change the usb mode. This patch add a node in debug file
system for the application to change usb mode even if the
extcon is not exist. (P.S. The extcon property must not be
set and dr_mode must be otg if you want to use
rk_usb_force_mode.)

usage:
config host dr_mode:
echo host > sys/kernel/debug/usb@fe800000/rk_usb_force_mode
config peripheral dr_mode:
echo peripheral > sys/kernel/debug/usb@fe800000/rk_usb_force_mode
config otg dr_mode:
echo otg > sys/kernel/debug/usb@fe800000/rk_usb_force_mode

Change-Id: I9cb3b14b7a365fe74e4aa253f0e3f680f45e0f9f
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>

phy: rockchip-inno-usb2: add u2phy set mode function

The usb controller may need to disconnect vbus to trigger disconnect
process or connect vbus to trigger connect interrupt by software. But
current code does not realize the interface. This patch add set mode
function in usb2 phy driver, connect vbus in device mode and disconnect
in other mode.

Change-Id: I49b4180af2f47156a3f4d31f4539f3e444f89a62
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>

UPSTREAM: Input: add ADC resistor ladder driver

A common way of multiplexing buttons on a single input in cheap devices is
to use a resistor ladder on an ADC. This driver supports that configuration
by polling an ADC channel provided by IIO.

Change-Id: I110d95d7787a3ad42b5d4040d73b01efe2ca76e4
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 680772647d96ed853d20f837a2726151f24d8b20)

UPSTREAM: iio: core: Add devm_ APIs for iio_channel_{get,release}

Some of kernel driver uses the IIO framework to get the sensor
value via ADC or IIO HW driver. The client driver get iio channel
by iio_channel_get() and release it by calling iio_channel_release().

Add resource managed version (devm_*) of these APIs so that if client
calls the devm_iio_channel_get() then it need not to release it explicitly,
it can be done by managed device framework when driver get un-binded.

This reduces the code in error path and also need of .remove callback in
some cases.

Change-Id: Ia00f42dab2f66aefa0b26523db849e75927003af
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 8bf872d8d261feefcdf67027522e3f717cad2bfe)

arm64: rockchip_defconfig: Enable QUOTA related configs

af5c611fce52 ("ANDROID: android-base: Enable QUOTA related configs")

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

arm64: rockchip_defconfig: disable AIO

3ff793f3db4d ("disable aio support in recommended configuration")

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

ARM64: dts: rk3399: sapphire: type-c add vbus-5v-gpios ctrl

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

Revert "MALI: rockchip: upgrade midgard DDK to r14p0-01rel0"

This reverts commit d1637ff80953fd46692f923f3ee7b656fb917081.

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

FROMLIST: arm64: dts: rockchip: add aspm-no-l0s for rk3399

Per the discussion of bug fix[1], we now actually
leaves the default clock choice for pcie phy is
derived from 24MHz OSC to guarantee the least BER.
So let's add aspm-no-l0s here and folks could delete
this property from their dts.

Change-Id: I5ee57a2e27d3751f6541fdf059e6745c26d0a6ef
[1] https://patchwork.kernel.org/patch/9470519/
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherr picked from https://patchwork.kernel.org/patch/9477651/)

UPSTREAM: PCI: rockchip: Disable RC's ASPM L0s based on DT "aspm-no-l0s"

Rockchip's RC produces a 100MHz reference clock but there are two
methods for the PHY to generate it:

(1) Use the system PLL to generate a 100MHz clock.  The PHY will relock
    it, filter signal noise, and output the reference clock.  ASPM L0s
    works correctly, but circuit noise issues make it difficult to pass
    the TX compatibility test.

(2) Share the SoC's 24MHZ crystal oscillator with the PHY and force the
    PHY's PLL to generate 100MHz internally.  In this case, exit from
    ASPM L0s sometimes fails due to a design error in the RC receiver
    circuit.  Even if we use extended-synch, the PHY sometimes fails to
    relock the bits from FTS, which will hang the system.

We want the flexibility to use both clocking methods, so add a DT
property, "aspm-no-l0s".  If that's present, disable L0s to avoid the
issues with case (2).

Change-Id: Iefbac055dc9d916815aace25f3558e0642e3522b
[bhelgaas: changelog]
Reported-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git
commit afc9595ea4770f0157ae06fb3acedff703e169b6)

Revert "UPSTREAM: PCI: rockchip: Add quirk to disable RC's ASPM L0s"

This reverts commit 6c71bcdab9b48258ab496218581d035afb65e0dd.
As it was dropped from pci-next and we have another rework there.

Change-Id: Icaf9d7a7fbdca5ab39b550dd0a5031fd0d3770d0
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

MALI: rockchip: linux: upgrade to DDK r13p0-00rel0

Since r9p0 can't recover form  error "DATA_INVALID_FAULT",
we have to update to r13p0.

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

drm/rockchip: vop: wait for completion with timeout

Wait for completion forever is very dangerous, make system
die is very bad.

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

drm/rockchip: vop: fixup afbc flags on vop

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

drm/rockchip: mipi: move mode_set/commit to enable ops

enable/disable ops is more compatile to drm atomic framework.

fix mipi driver crash when resume:
[  195.399833] PC is at drm_mode_vrefresh+0x0/0x78
[  195.400249] LR is at dw_mipi_dsi_encoder_commit+0x2ec/0x424
[  195.400749] pc : [<ffffff800845ee7c>] lr : [<ffffff800846f190>] pstate: 20000145
[  195.529911] [<ffffff800845ee7c>] drm_mode_vrefresh+0x0/0x78
[  195.530421] [<ffffff80084441e0>] drm_atomic_helper_commit_modeset_enables+0x168/0x190
[  195.531126] [<ffffff80084733b4>] rockchip_atomic_commit_complete+0x3c/0x14c
[  195.531753] [<ffffff8008473540>] rockchip_drm_atomic_commit+0x7c/0x9c
[  195.532336] [<ffffff8008467b60>] drm_atomic_commit+0x6c/0x84
[  195.532849] [<ffffff80084447fc>] drm_atomic_helper_connector_dpms+0xf4/0x154
[  195.533481] [<ffffff800845d21c>] drm_mode_obj_set_property_ioctl+0x148/0x204
[  195.534113] [<ffffff800845d318>] drm_mode_connector_property_set_ioctl+0x40/0x60
[  195.534778] [<ffffff800844dba4>] drm_ioctl+0x270/0x3fc
[  195.535249] [<ffffff80081b9180>] do_vfs_ioctl+0x4d0/0x5bc
[  195.535739] [<ffffff80081b92cc>] SyS_ioctl+0x60/0x88
[  195.536194] [<ffffff80080826f0>] el0_svc_naked+0x24/0x28

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

drm/rockchip: vop: support overscan setting

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

mali: utgard: Fix build issue

The following statement doesn't have consistent behaviour on all machines.
Since the driver is in-tree, we can assume GPL compliance

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

ARM: rockchip: clean folder

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

ARM: dts: rockchip: sort rk3288 dts by base adress

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

ARM: dts: rockchip: add ddr related node for rk3288

Add dmc,sram,noc nodes which are used for ddr function

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

ARM: rockchip: Convert resume code to C

This CL introduces the concept of "embedded blobs" for Rockchip, which
allows you to compile some C code into a binary blob that is linked
into the kernel.  This binary blob is self contained and is intended
to run in cases where SDRAM (and thus the rest of Linux) isn't
available.  Resume is a prime candiate for this as is the planned
DDRFreq code.

We convert the existing assembly resume code into C as proof that this
works and to prepare for linking in SDRAM reinit code.

Change-Id: I0ff109766cfd4b25bf65de9258631a07d2ebe1d5
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

rockchip: pm: add deep sleep support for rk3288

This adds deep sleep support for rk3288 suspend & resume
It can suspend by "echo 1 >  /sys/module/pm/parameters/deep_sleep &&
echo mem > /sys/power/state", and resume by power

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

arm: dts: rockchip: increase vdd log for rk3288-evb-act8846

1v is too low for ddr 533, gpu 600

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

video: rockchip: edp: Solve the bug of asymmetric pd enable and disable

Change-Id: I626210fc3e63c076e402563393a388cbd25fdd74
Signed-off-by: xubilv <xbl@rock-chips.com>

UPSTREAM: phy: Add reset callback for not generic phy

I forget to add a dummy function in case the CONFIG_GENERIC_PHY
is disabled.

Change-Id: Ic324387058ef260473fd4ad20ed43eff79044dfe
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from 98430c7aad6a3fdedcc78a0d6780dabb6580dc38)

HID: hid-rkvr: update TP input events

Change-Id: I9c72693ff6db1beccc4ed79fc01b33616fd8931d
Signed-off-by: wjh <wjh@rock-chips.com>

OP-TEE: update optee_linuxdriver to match updated optee_os & optee_client

Match the optee_os version 1.5 or later.

Main update features:
1.Support 32-bit client working with 64-bit linux kernel.
2.Fix Shared Memory protection.
3.Add mutex to serialize tee-supplicant request.
4.Revert "rename tee-supplicant to tee_supplicant".

cherry-pick from 3.10
commit id:5f6467dc09e8c00f7fa6a621b3aad7046ae84d48

Change-Id: I5c77ed85aa56e36d346be7c4462c5a15120df439
Signed-off-by: sean.huang <sean.huang@rock-chips.com>

arm64: dts: rockchip: clean up emmc_phy

freq-sel, dr-sel and opdelay are obsolete now, so we
should remove them from the DT files to prevent the
spread of unused code.

Change-Id: Ibfa4fa225231a004913aa31aac475eb252e329c6
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

arm64: dts: rockchip: replace clkreqn with new cpm GPIO for rk3399-evb

We should convert to use cpm mode instead of L1 substate.
Fix it anyway.

Change-Id: I50fd43a1b15df6b8dc617783a1525ba0579b6a92
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

arm64: dts: rockchip: add pcie clkreq for cpm mode in rk3399.dtsi

Since we don't support L1 substate due to the errata of TRM,
let's instead add cpm mode if possible. Note that in cpm mode,
clkreq should be a GPIO and the EP will take over the ownship
of it and de-assert it when exiting from the low power mode.

Change-Id: I4d5542289c0118ba8702ad6b2783e6fad64828a1
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

arm64: configs: rockchip_linux: enable usb-otg related config

This adds select below config for usb-otg:
CONFIG_USB_DWC2_DUAL_ROLE
CONFIG_USB_GADGET_DEBUG_FILES
CONFIG_USB_GADGET_VBUS_DRAW=500
CONFIG_USB_CONFIGFS_UEVENT

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

arm64: dts: rockchip: enable usb2-otg as peripheral for rk3328-evb

This adds set dwc2 mode as peripheral and enable for rk3328-evb.

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

arm64: dts: rockchip: add usb2-otg nodes for rk3328

This patch adds usb2-otg nodes to support dwc2 driver for rk3328.

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

usb: dwc2: add multiple clock handling

Originally, dwc2 just handle one clock named otg, however, it may have
two or more clock need to manage for some new SoCs, so this adds
change clk to clk's array of dwc2_hsotg to handle more clocks operation.

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

arm64: rockchip_defconfig: update by savedefconfig

Change-Id: Iba75aa98d0188c9edc62c59cbf0af8f3b2c71dff
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: (199 commits)
  Linux 4.4.41
  net: mvpp2: fix dma unmapping of TX buffers for fragments
  sg_write()/bsg_write() is not fit to be called under KERNEL_DS
  kconfig/nconf: Fix hang when editing symbol with a long prompt
  target/user: Fix use-after-free of tcmu_cmds if they are expired
  powerpc: Convert cmp to cmpd in idle enter sequence
  powerpc/ps3: Fix system hang with GCC 5 builds
  nfs_write_end(): fix handling of short copies
  libceph: verify authorize reply on connect
  PCI: Check for PME in targeted sleep state
  Input: drv260x - fix input device's parent assignment
  media: solo6x10: fix lockup by avoiding delayed register write
  IB/cma: Fix a race condition in iboe_addr_get_sgid()
  IB/multicast: Check ib_find_pkey() return value
  IPoIB: Avoid reading an uninitialized member variable
  IB/mad: Fix an array index check
  fgraph: Handle a case where a tracer ignores set_graph_notrace
  platform/x86: asus-nb-wmi.c: Add X45U quirk
  ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it
  kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)
  ...

Change-Id: I8c8467700d5563d9a1121c982737ff0ab6d9cdc9

arm64: rockchip_defconfig: add alps trackpad support

Change-Id: Icbf54f457642b2541b441b9d74c18d1854e0f9d2
Signed-off-by: Zhou weixin <zwx@rock-chips.com>

HID: hid-alps: add alps hid support

Change-Id: Id3eba69f18f0f6f3548a4be0430fee3ce8cce021
Signed-off-by: Zhou weixin <zwx@rock-chips.com>

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

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

 This is the 4.4.41 stable release

video: rockchip: fb: fix switch screen lead to splash screen

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

video: rockchip: fb: fix switch screen lead to splash screen

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

power_supply: bq25700: set default input voltage ane current when shutdown

Change-Id: Ibeeab7bf882e232be7285deee995c5a0dc3f641c
Signed-off-by: Shunqing Chen <csq@rock-chips.com>

mfd: fusb302: fix connect adapter failed when reboot with adapter

The fusb PD should be reset to sync adapter PD signal after fusb
sent hard reset cmd.

Change-Id: Iad5f27cf4c017639c24000e73dc831a36dbb55ec
Signed-off-by: Zhou weixin <zwx@rock-chips.com>

arm64: dts: rockchip: add usb2 phy tuning for rk3399 discrete vr.

add usb2 phy tuning function to enhance the usb signal for discrete vr device.

Change-Id: Iab4911610ccf488be723ce462527ecaeafe7e446
Signed-off-by: wenping.zhang <wenping.zhang@rock-chips.com>

Linux 4.4.41

net: mvpp2: fix dma unmapping of TX buffers for fragments

commit 8354491c9d5b06709384cea91d13019bf5e61449 upstream.

Since commit 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX
buffers unmapping"), we are not correctly DMA unmapping TX buffers for
fragments.

Indeed, the mvpp2_txq_inc_put() function only stores in the
txq_cpu->tx_buffs[] array the physical address of the buffer to be
DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
skb_headlen(skb) to get the size to be unmapped. Both of this works fine
for TX descriptors that are associated directly to a SKB, but not the
ones that are used for fragments, with a NULL pointer as skb:

 - We have a NULL physical address when calling DMA unmap
 - skb_headlen(skb) crashes because skb is NULL

This causes random crashes when fragments are used.

To solve this problem, we need to:

 - Store the physical address of the buffer to be unmapped
   unconditionally, regardless of whether it is tied to a SKB or not.

 - Store the length of the buffer to be unmapped, which requires a new
   field.

Instead of adding a third array to store the length of the buffer to be
unmapped, and as suggested by David Miller, this commit refactors the
tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a
separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is
added. Therefore, instead of having three arrays to allocate/free, we
have a single one, which also improve data locality, reducing the
impact on the CPU cache.

Fixes: 71ce391dfb784 ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
Reported-by: Raphael G <raphael.glon@corp.ovh.com>
Cc: Raphael G <raphael.glon@corp.ovh.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sg_write()/bsg_write() is not fit to be called under KERNEL_DS

commit 128394eff343fc6d2f32172f03e24829539c5835 upstream.

Both damn things interpret userland pointers embedded into the payload;
worse, they are actually traversing those.  Leaving aside the bad
API design, this is very much _not_ safe to call with KERNEL_DS.
Bail out early if that happens.

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

kconfig/nconf: Fix hang when editing symbol with a long prompt

commit 79e51b5c2deea542b3bb8c66e0d502230b017dde upstream.

Currently it is impossible to edit the value of a config symbol with a
prompt longer than (terminal width - 2) characters.  dialog_inputbox()
calculates a negative x-offset for the input window and newwin() fails
as this is invalid.  It also doesn't check for this failure, so it
busy-loops calling wgetch(NULL) which immediately returns -1.

The additions in the offset calculations also don't match the intended
size of the window.

Limit the window size and calculate the offset similarly to
show_scroll_win().

Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

target/user: Fix use-after-free of tcmu_cmds if they are expired

commit d0905ca757bc40bd1ebc261a448a521b064777d7 upstream.

Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by
an entry in our cmd_id->cmd idr. If userspace ever resumes processing,
tcmu_handle_completions() will use the now-invalid cmd pointer.

Instead, don't free cmd. It will be freed by tcmu_handle_completion() if
userspace ever recovers, or tcmu_free_device if not.

Reported-by: Bryant G Ly <bgly@us.ibm.com>
Tested-by: Bryant G Ly <bgly@us.ibm.com>
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc: Convert cmp to cmpd in idle enter sequence

commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 upstream.

PowerPC's "cmp" instruction has four operands. Normally people write
"cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
people forget, and write "cmp" with just three operands.

With older binutils this is silently accepted as if this was "cmpw",
while often "cmpd" is wanted. With newer binutils GAS will complain
about this for 64-bit code. For 32-bit code it still silently assumes
"cmpw" is what is meant.

In this instance the code comes directly from ISA v2.07, including the
cmp, but cmpd is correct. Backport to stable so that new toolchains can
build old kernels.

Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode")
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc/ps3: Fix system hang with GCC 5 builds

commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.

GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This check is of
limited value, so just get rid of it.

Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfs_write_end(): fix handling of short copies

commit c0cf3ef5e0f47e385920450b245d22bead93e7ad upstream.

What matters when deciding if we should make a page uptodate is
not how much we _wanted_ to copy, but how much we actually have
copied.  As it is, on architectures that do not zero tail on
short copy we can leave uninitialized data in page marked uptodate.

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

libceph: verify authorize reply on connect

commit 5c056fdc5b474329037f2aa18401bd73033e0ce0 upstream.

After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b),
the client gets back a ceph_x_authorize_reply, which it is supposed to
verify to ensure the authenticity and protect against replay attacks.
The code for doing this is there (ceph_x_verify_authorizer_reply(),
ceph_auth_verify_authorizer_reply() + plumbing), but it is never
invoked by the the messenger.

AFAICT this goes back to 2009, when ceph authentication protocols
support was added to the kernel client in 4e7a5dcd1bba ("ceph:
negotiate authentication protocol; implement AUTH_NONE protocol").

The second param of ceph_connection_operations::verify_authorizer_reply
is unused all the way down.  Pass 0 to facilitate backporting, and kill
it in the next commit.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: Check for PME in targeted sleep state

commit 6496ebd7edf446fccf8266a1a70ffcb64252593e upstream.

One some systems, the firmware does not allow certain PCI devices to be put
in deep D-states.  This can cause problems for wakeup signalling, if the
device does not support PME# in the deepest allowed suspend state.  For
example, Pierre reports that on his system, ACPI does not permit his xHCI
host controller to go into D3 during runtime suspend -- but D3 is the only
state in which the controller can generate PME# signals.  As a result, the
controller goes into runtime suspend but never wakes up, so it doesn't work
properly.  USB devices plugged into the controller are never detected.

If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately report
that it cannot do wakeup from runtime suspend.  This patch modifies the
pci_dev_run_wake() routine to add this check.

Reported-by: Pierre de Villemereuil <flyos@mailoo.org>
Tested-by: Pierre de Villemereuil <flyos@mailoo.org>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: drv260x - fix input device's parent assignment

commit 5a8a6b89c15766446d845671d574a9243b6d8786 upstream.

We were assigning I2C bus controller instead of client as parent device.
Besides being logically wrong, it messed up with devm handling of input
device. As a result we were leaving input device and event node behind
after rmmod-ing the driver, which lead to a kernel oops if one were to
access the event node later.

Let's remove the assignment and rely on devm_input_allocate_device() to
set it up properly for us.

Signed-off-by: Jingkui Wang <jkwang@google.com>
Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: solo6x10: fix lockup by avoiding delayed register write

commit 5fc4b067ec082c3127e0156f800769b7e0dce078 upstream.

This fixes a lockup at device probing which happens on some solo6010
hardware samples. This is a regression introduced by commit e1ceb25a1569
("[media] SOLO6x10: remove unneeded register locking and barriers")

The observed lockup happens in solo_set_motion_threshold() called from
solo_motion_config().

This extra "flushing" is not fundamentally needed for every write, but
apparently the code in driver assumes such behaviour at last in some
places.

Actual fix was proposed by Hans Verkuil.

Fixes: e1ceb25a1569 ("[media] SOLO6x10: remove unneeded register locking and barriers")
Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

IB/cma: Fix a race condition in iboe_addr_get_sgid()

commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 upstream.

Code that dereferences the struct net_device ip_ptr member must be
protected with an in_dev_get() / in_dev_put() pair. Hence insert
calls to these functions.

Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Moni Shoua <monis@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Cc: Roland Dreier <roland@purestorage.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

IB/multicast: Check ib_find_pkey() return value

commit d3a2418ee36a59bc02e9d454723f3175dcf4bfd9 upstream.

This patch avoids that Coverity complains about not checking the
ib_find_pkey() return value.

Fixes: commit 547af76521b3 ("IB/multicast: Report errors on multicast groups if P_key changes")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

IPoIB: Avoid reading an uninitialized member variable

commit 11b642b84e8c43e8597de031678d15c08dd057bc upstream.

This patch avoids that Coverity reports the following:

    Using uninitialized value port_attr.state when calling printk

Fixes: commit 94232d9ce817 ("IPoIB: Start multicast join process only on active ports")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

IB/mad: Fix an array index check

commit 2fe2f378dd45847d2643638c07a7658822087836 upstream.

The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS
(80) elements. Hence compare the array index with that value instead
of with IB_MGMT_MAX_METHODS (128). This patch avoids that Coverity
reports the following:

Overrunning array class->method_table of 80 8-byte elements at element index 127 (byte offset 1016) using index convert_mgmt_class(mad_hdr->mgmt_class) (which evaluates to 127).

Fixes: commit b7ab0b19a85f ("IB/mad: Verify mgmt class in received MADs")
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Reviewed-by: Hal Rosenstock <hal@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fgraph: Handle a case where a tracer ignores set_graph_notrace

commit 794de08a16cf1fc1bf785dc48f66d36218cf6d88 upstream.

Both the wakeup and irqsoff tracers can use the function graph tracer when
the display-graph option is set. The problem is that they ignore the notrace
file, and record the entry of functions that would be ignored by the
function_graph tracer. This causes the trace->depth to be recorded into the
ring buffer. The set_graph_notrace uses a trick by adding a large negative
number to the trace->depth when a graph function is to be ignored.

On trace output, the graph function uses the depth to record a stack of
functions. But since the depth is negative, it accesses the array with a
negative number and causes an out of bounds access that can cause a kernel
oops or corrupt data.

Have the print functions handle cases where a tracer still records functions
even when they are in set_graph_notrace.

Also add warnings if the depth is below zero before accessing the array.

Note, the function graph logic will still prevent the return of these
functions from being recorded, which means that they will be left hanging
without a return. For example:

   # echo '*spin*' > set_graph_notrace
   # echo 1 > options/display-graph
   # echo wakeup > current_tracer
   # cat trace
   [...]
      _raw_spin_lock() {
        preempt_count_add() {
        do_raw_spin_lock() {
      update_rq_clock();

Where it should look like:

      _raw_spin_lock() {
        preempt_count_add();
        do_raw_spin_lock();
      }
      update_rq_clock();

Cc: Namhyung Kim <namhyung.kim@lge.com>
Fixes: 29ad23b00474 ("ftrace: Add set_graph_notrace filter")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

platform/x86: asus-nb-wmi.c: Add X45U quirk

commit e74e259939275a5dd4e0d02845c694f421e249ad upstream.

Without this patch, the Asus X45U wireless card can't be turned
on (hard-blocked), but after a suspend/resume it just starts working.

Following this bug report[1], there are other cases like this one, but
this Asus is the only model that I can test.

[1] https://ubuntuforums.org/showthread.php?t=2181558

Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it

commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 upstream.

With new binutils, gcc may get smart with its optimization and change a jmp
from a 5 byte jump to a 2 byte one even though it was jumping to a global
function. But that global function existed within a 2 byte radius, and gcc
was able to optimize it. Unfortunately, that jump was also being modified
when function graph tracing begins. Since ftrace expected that jump to be 5
bytes, but it was only two, it overwrote code after the jump, causing a
crash.

This was fixed for x86_64 with commit 8329e818f149, with the same subject as
this commit, but nothing was done for x86_32.

Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls")
Reported-by: Colin Ian King <colin.king@canonical.com>
Tested-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)

commit ef85b67385436ddc1998f45f1d6a210f935b3388 upstream.

When L2 exits to L0 due to "exception or NMI", software exceptions
(#BP and #OF) for which L1 has requested an intercept should be
handled by L1 rather than L0. Previously, only hardware exceptions
were forwarded to L1.

Signed-off-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT

commit f064a0de1579fabded8990bed93971e30deb9ecb upstream.

The hashed page table MMU in POWER processors can update the R
(reference) and C (change) bits in a HPTE at any time until the
HPTE has been invalidated and the TLB invalidation sequence has
completed.  In kvmppc_h_protect, which implements the H_PROTECT
hypercall, we read the HPTE, modify the second doubleword,
invalidate the HPTE in memory, do the TLB invalidation sequence,
and then write the modified value of the second doubleword back
to memory.  In doing so we could overwrite an R/C bit update done
by hardware between when we read the HPTE and when the TLB
invalidation completed.  To fix this we re-read the second
doubleword after the TLB invalidation and OR in the (possibly)
new values of R and C.  We can use an OR since hardware only ever
sets R and C, never clears them.

This race was found by code inspection.  In principle this bug could
cause occasional guest memory corruption under host memory pressure.

Fixes: a8606e20e41a ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29)
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state

commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 upstream.

When switching from/to a guest that has a transaction in progress,
we need to save/restore the checkpointed register state.  Although
XER is part of the CPU state that gets checkpointed, the code that
does this saving and restoring doesn't save/restore XER.

This fixes it by saving and restoring the XER.  To allow userspace
to read/write the checkpointed XER value, we also add a new ONE_REG
specifier.

The visible effect of this bug is that the guest may see its XER
value being corrupted when it uses transactions.

Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support")
Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

md/raid5: limit request size according to implementation limits

commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 upstream.

Current implementation employ 16bit counter of active stripes in lower
bits of bio->bi_phys_segments. If request is big enough to overflow
this counter bio will be completed and freed too early.

Fortunately this not happens in default configuration because several
other limits prevent that: stripe_cache_size * nr_disks effectively
limits count of active stripes. And small max_sectors_kb at lower
disks prevent that during normal read/write operations.

Overflow easily happens in discard if it's enabled by module parameter
"devices_handle_discard_safely" and stripe_cache_size is set big enough.

This patch limits requests size with 256Mb - 8Kb to prevent overflows.

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Shaohua Li <shli@kernel.org>
Cc: Neil Brown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sc16is7xx: Drop bogus use of IRQF_ONESHOT

commit 04da73803c05dc1150ccc31cbf93e8cd56679c09 upstream.

The use of IRQF_ONESHOT when registering an interrupt handler with
request_irq() is non-sensical.

Not only that, it also prevents the handler from being threaded when it
otherwise should be w/ IRQ_FORCED_THREADING is enabled.  This causes the
following deadlock observed by Sean Nyekjaer on -rt:

Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[..]
   rt_spin_lock_slowlock from queue_kthread_work
   queue_kthread_work from sc16is7xx_irq
   sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu
   handle_irq_event_percpu from handle_irq_event
   handle_irq_event from handle_level_irq
   handle_level_irq from generic_handle_irq
   generic_handle_irq from mxc_gpio_irq_handler
   mxc_gpio_irq_handler from mx3_gpio_irq_handler
   mx3_gpio_irq_handler from generic_handle_irq
   generic_handle_irq from __handle_domain_irq
   __handle_domain_irq from gic_handle_irq
   gic_handle_irq from __irq_svc
   __irq_svc from rt_spin_unlock
   rt_spin_unlock from kthread_worker_fn
   kthread_worker_fn from kthread
   kthread from ret_from_fork

Fixes: 9e6f4ca3e567 ("sc16is7xx: use kthread_worker for tx_work and irq")
Reported-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: Josh Cartwright <joshc@ni.com>
Cc: linux-rt-users@vger.kernel.org
Cc: Jakub Kicinski <moorray3@wp.pl>
Cc: linux-serial@vger.kernel.org
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Julia Cartwright <julia@ni.com>
Acked-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/vmlogrdr: fix IUCV buffer allocation

commit 5457e03de918f7a3e294eb9d26a608ab8a579976 upstream.

The buffer for iucv_message_receive() needs to be below 2 GB. In
__iucv_message_receive(), the buffer address is casted to an u32, which
would result in either memory corruption or an addressing exception when
using addresses >= 2 GB.

Fix this by using GFP_DMA for the buffer allocation.

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firmware: fix usermode helper fallback loading

commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream.

When you use the firmware usermode helper fallback with a timeout value set to a
value greater than INT_MAX (2147483647) a cast overflow issue causes the
timeout value to go negative and breaks all usermode helper loading. This
regression was introduced through commit 68ff2a00dbf5 ("firmware_loader:
handle timeout via wait_for_completion_interruptible_timeout()") on kernel
v4.0.

The firmware_class drivers relies on the firmware usermode helper
fallback as a mechanism to look for firmware if the direct filesystem
search failed only if:

  a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros):

  Then all of these callers will rely on the fallback mechanism in case
  the firmware is not found through an initial direct filesystem lookup:

  o request_firmware()
  o request_firmware_into_buf()
  o request_firmware_nowait()

  b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros):

  Then only callers using request_firmware_nowait() with the second
  argument set to false, this explicitly is requesting the UMH firmware
  fallback to be relied on in case the first filesystem lookup fails.

  Using Coccinelle SmPL grammar we have identified only two drivers
  explicitly requesting the UMH firmware fallback mechanism:

  - drivers/firmware/dell_rbu.c
  - drivers/leds/leds-lp55xx-common.c

Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the
biggest impact of this regression are users of the dell_rbu and
leds-lp55xx-common device driver which required the UMH to find their
respective needed firmwares.

The default timeout for the UMH is set to 60 seconds always, as of
commit 68ff2a00dbf5 ("firmware_loader: handle timeout via
wait_for_completion_interruptible_timeout()") the timeout was bumped
to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET
value was also used if the timeout was configured by a user to 0.

The following works:

echo 2147483647 > /sys/class/firmware/timeout

But both of the following set the timeout to MAX_JIFFY_OFFSET even if
we display 0 back to userspace:

echo 2147483648 > /sys/class/firmware/timeout
cat /sys/class/firmware/timeout
0

echo 0> /sys/class/firmware/timeout
cat /sys/class/firmware/timeout
0

A max value of INT_MAX (2147483647) seconds is therefore implicit due to the
another cast with simple_strtol().

This fixes the secondary cast (the first one is simple_strtol() but its an
issue only by forcing an implicit limit) by re-using the timeout variable and
only setting retval in appropriate cases.

Lastly worth noting systemd had ripped out the UMH firmware fallback
mechanism from udev since udev 2014 via commit be2ea723b1d023b3d
("udev: remove userspace firmware loading support"), so as of systemd v217.

Signed-off-by: Yves-Alexis Perez <corsac@corsac.net>
Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()"
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[mcgrof@kernel.org: gave commit log a whole lot of love]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache

commit 08fe007968b2b45e831daf74899f79a54d73f773 upstream.

An ARC700 customer reported linux boot crashes when upgrading to bigger
L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and
current code only assumed 2 colours, while theirs had 4. So default to 4
colours and complain if there are fewer. Ideally this needs to be a
Kconfig option, but heck that's too much of hassle for a single user.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: avoid a permanent stop of the scsi device's request queue

commit d2a145252c52792bc59e4767b486b26c430af4bb upstream.

A race between scanning and fc_remote_port_delete() may result in a
permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
and unblocked after.  The reason is that blocking a device sets both the
SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED.  However,
scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the
device to be ignored by scsi_target_unblock() and thus never have its
QUEUE_FLAG_STOPPED cleared leading to a device which is apparently
running but has a stopped queue.

We actually have two places where SDEV_RUNNING is set: once in
scsi_add_lun() which respects the blocked flag and once in
scsi_sysfs_add_sdev() which doesn't.  Since the second set is entirely
spurious, simply remove it to fix the problem.

Reported-by: Zengxi Chen <chenzengxi@huawei.com>
Signed-off-by: Wei Fang <fangwei1@huawei.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: zfcp: fix rport unblock race with LUN recovery

commit 6f2ce1c6af37191640ee3ff6e8fc39ea10352f4c upstream.

It is unavoidable that zfcp_scsi_queuecommand() has to finish requests
with DID_IMM_RETRY (like fc_remote_port_chkready()) during the time
window when zfcp detected an unavailable rport but
fc_remote_port_delete(), which is asynchronous via
zfcp_scsi_schedule_rport_block(), has not yet blocked the rport.

However, for the case when the rport becomes available again, we should
prevent unblocking the rport too early.  In contrast to other FCP LLDDs,
zfcp has to open each LUN with the FCP channel hardware before it can
send I/O to a LUN.  So if a port already has LUNs attached and we
unblock the rport just after port recovery, recoveries of LUNs behind
this port can still be pending which in turn force
zfcp_scsi_queuecommand() to unnecessarily finish requests with
DID_IMM_RETRY.

This also opens a time window with unblocked rport (until the followup
LUN reopen recovery has finished).  If a scsi_cmnd timeout occurs during
this time window fc_timed_out() cannot work as desired and such command
would indeed time out and trigger scsi_eh. This prevents a clean and
timely path failover.  This should not happen if the path issue can be
recovered on FC transport layer such as path issues involving RSCNs.

Fix this by only calling zfcp_scsi_schedule_rport_register(), to
asynchronously trigger fc_remote_port_add(), after all LUN recoveries as
children of the rport have finished and no new recoveries of equal or
higher order were triggered meanwhile.  Finished intentionally includes
any recovery result no matter if successful or failed (still unblock
rport so other successful LUNs work).  For simplicity, we check after
each finished LUN recovery if there is another LUN recovery pending on
the same port and then do nothing.  We handle the special case of a
successful recovery of a port without LUN children the same way without
changing this case's semantics.

For debugging we introduce 2 new trace records written if the rport
unblock attempt was aborted due to still unfinished or freshly triggered
recovery. The records are only written above the default trace level.

Benjamin noticed the important special case of new recovery that can be
triggered between having given up the erp_lock and before calling
zfcp_erp_action_cleanup() within zfcp_erp_strategy().  We must avoid the
following sequence:

ERP thread                 rport_work      other context
-------------------------  --------------  --------------------------------
port is unblocked, rport still blocked,
 due to pending/running ERP action,
 so ((port->status & ...UNBLOCK) != 0)
 and (port->rport == NULL)
unlock ERP
zfcp_erp_action_cleanup()
case ZFCP_ERP_ACTION_REOPEN_LUN:
zfcp_erp_try_rport_unblock()
((status & ...UNBLOCK) != 0) [OLD!]
                                           zfcp_erp_port_reopen()
                                           lock ERP
                                           zfcp_erp_port_block()
                                           port->status clear ...UNBLOCK
                                           unlock ERP
                                           zfcp_scsi_schedule_rport_block()
                                           port->rport_task = RPORT_DEL
                                           queue_work(rport_work)
                           zfcp_scsi_rport_work()
                           (port->rport_task != RPORT_ADD)
                           port->rport_task = RPORT_NONE
                           zfcp_scsi_rport_block()
                           if (!port->rport) return
zfcp_scsi_schedule_rport_register()
port->rport_task = RPORT_ADD
queue_work(rport_work)
                           zfcp_scsi_rport_work()
                           (port->rport_task == RPORT_ADD)
                           port->rport_task = RPORT_NONE
                           zfcp_scsi_rport_register()
                           (port->rport == NULL)
                           rport = fc_remote_port_add()
                           port->rport = rport;

Now the rport was erroneously unblocked while the zfcp_port is blocked.
This is another situation we want to avoid due to scsi_eh
potential. This state would at least remain until the new recovery from
the other context finished successfully, or potentially forever if it
failed.  In order to close this race, we take the erp_lock inside
zfcp_erp_try_rport_unblock() when checking the status of zfcp_port or
LUN.  With that, the possible corresponding rport state sequences would
be: (unblock[ERP thread],block[other context]) if the ERP thread gets
erp_lock first and still sees ((port->status & ...UNBLOCK) != 0),
(block[other context],NOP[ERP thread]) if the ERP thread gets erp_lock
after the other context has already cleard ...UNBLOCK from port->status.

Since checking fields of struct erp_action is unsafe because they could
have been overwritten (re-used for new recovery) meanwhile, we only
check status of zfcp_port and LUN since these are only changed under
erp_lock elsewhere. Regarding the check of the proper status flags (port
or port_forced are similar to the shown adapter recovery):

[zfcp_erp_adapter_shutdown()]
zfcp_erp_adapter_reopen()
 zfcp_erp_adapter_block()
  * clear UNBLOCK ---------------------------------------+
 zfcp_scsi_schedule_rports_block()                       |
 write_lock_irqsave(&adapter->erp_lock, flags);-------+  |
 zfcp_erp_action_enqueue()                            |  |
  zfcp_erp_setup_act()                                |  |
   * set ERP_INUSE -----------------------------------|--|--+
 write_unlock_irqrestore(&adapter->erp_lock, flags);--+  |  |
.context-switch.                                         |  |
zfcp_erp_thread()                                        |  |
 zfcp_erp_strategy()                                     |  |
  write_lock_irqsave(&adapter->erp_lock, flags);------+  |  |
  ...                                                 |  |  |
  zfcp_erp_strategy_check_target()                    |  |  |
   zfcp_erp_strategy_check_adapter()                  |  |  |
    zfcp_erp_adapter_unblock()                        |  |  |
     * set UNBLOCK -----------------------------------|--+  |
  zfcp_erp_action_dequeue()                           |     |
   * clear ERP_INUSE ---------------------------------|-----+
  ...                                                 |
  write_unlock_irqrestore(&adapter->erp_lock, flags);-+

Hence, we should check for both UNBLOCK and ERP_INUSE because they are
interleaved.  Also we need to explicitly check ERP_FAILED for the link
down case which currently does not clear the UNBLOCK flag in
zfcp_fsf_link_down_info_eval().

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 8830271c4819 ("[SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rport")
Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: zfcp: do not trace pure benign residual HBA responses at default level

commit 56d23ed7adf3974f10e91b643bd230e9c65b5f79 upstream.

Since quite a while, Linux issues enough SCSI commands per scsi_device
which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
and SAM_STAT_GOOD.  This floods the HBA trace area and we cannot see
other and important HBA trace records long enough.

Therefore, do not trace HBA response errors for pure benign residual
under counts at the default trace level.

This excludes benign residual under count combined with other validity
bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL.  For all those other
cases, we still do want to see both the HBA record and the corresponding
SCSI record by default.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>