MALI: rockchip: not to use sg_dma_len in midgard ddk r11p0-00rel0

When CONFIG_NEED_SG_DMA_LENGTH is enabled,
sg_dma_len is defined as follow :
"#define sg_dma_len(sg)             ((sg)->dma_length)"
But, dma_length is not used by the framework indeed.

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

MALI: rockchip: upgrade midgard DDK to r11p0-00rel0

Conflicts:

drivers/gpu/arm/midgard/mali_kbase_core_linux.c
drivers/gpu/arm/midgard/mali_kbase_jd.c

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

MALI: rockchip: upgrade midgard DDK to r9p0-05rel0

Conflicts:

drivers/gpu/arm/midgard/Kconfig

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

ARM64: rockchip_cros_defconfig: remove Rogue of G6110 GPU

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

mmc: dw_mmc: check card present before starting request

The main reason to add this check is to avoid unnecessary
mmc_request like the on-going cmd and the corresponding sbc
if the card is removed. Although we have already checked this in
dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot
for noremovable devices, but there is a timing gap before it really
calls dw_mci_get_cd as mmc_detect_change needs some delay here.

Another gain here is that we could save some checkings of card status
after sd card been removed.

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

mmc: dw_mmc: remove redundant of set_bit and clear_bit

dw_mci_get_cd have already dealt with these for
both of internal card-detect and gpio card-detect.

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

mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities

Add MMC_CAP_CMD23 for dw_mmc-rockchip, otherwise
failing to create rpmb partition. With it, we can
get rpmb successfully:

mmc1: new HS200 MMC card at address 0001
mmcblk0: mmc1:0001 DS2016 14.7 GiB
mmcblk0boot0: mmc1:0001 DS2016 partition 1 4.00 MiB
mmcblk0boot1: mmc1:0001 DS2016 partition 2 4.00 MiB
mmcblk0rpmb: mmc1:0001 DS2016 partition 3 4.00 MiB

Change-Id: I19cdb2d31ee8c864125c2bd197e38cf21b84e25f
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: dw_mmc: Consider HLE errors to be data and command errors

The dw_mmc driver enables HLE errors as part of DW_MCI_ERROR_FLAGS but
nothing in the interrupt handler actually handles them and ACKs them.
That means that if we ever get an HLE error we'll just keep getting
interrupts and we'll wedge things.

We really don't expect HLE errors but if we ever get them we shouldn't
silently ignore them.

Note that I have seen HLE errors while constantly ejecting and
inserting cards (ejecting while inserting, etc).

Change-Id: I95fcc4e2d657572b365980794bb941ea39403699
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

mmc: core: Fix HS switch failure in mmc_select_hs400

We should change HS400 mode selection timing to meet JEDEC
specification. The JEDEC 5.1 said that change the frequency to <= 52MHZ
after HS_TIMING switch. Refer to section 6.6.2.3 "HS400" timing mode
selection:

Set the "Timing Interface" parameter in the HS_TIMING[185] field of the
Extended CSD register to 0x1 to switch to High Speed mode and then set
the clock frequency to a value not greater than 52MHZ.

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

mmc: core: don't check card status when flushing cache

It's meaningless to check the card's status which execute
the on-going flush. As the status been responsed make no
any sense here.

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

mmc: core: keep consistent with upstream

Manually merge hs400es from upstream to avoid
too much rework.

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

ARM64: dts: rk3399: pd: Add gpu pd nodes

Change-Id: I7f89e721f93a750676aab966e400a4b522992cfc
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

ARM64: dts: rk3399: pd: Add vopl\vopb\mipi\hdmi pd nodes

Change-Id: Iff66cf997896d34111706f884a32e82f44e21d6f
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

ARM64: dts: rk3399: pd: enable the pd node by default

1 Remove pd_center because the ddr not allowed to power off the pd_center.
2 If the driver not used the pd. the pd will be offed after genpd init complete.
(pd disable unused)

Change-Id: I66db4df1835a48e3c0f96019bb727994e2516af9
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

ARM64: rockchip_defconfig: enable Rockchip Inno usb2phy driver

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

ARM64: dts: rockchip: rk3366: support for the usb2phy driver

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

phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

The newer SoCs (rk3366, rk3399) take a different usb-phy IP block (INNO)
than rk3288 and before, meanwhile, most of phy-related registers are also
different from the past, so a new phy driver is required necessarily.

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

Documentation: bindings: add DT documentation for Rockchip USB2PHY

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

Merge tag 'lsk-v4.4-16.05-android'

LSK 16.05 v4.4-android

ARM64: dts: rockchip: enable tsadc node for rk3366-tb

Set status of tsadc node to "okay" to make tsadc work.

Change-Id: I741adc9ce611f6f0f279fbb351dfaa5fc947db06
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>

arm64: dts: rockchip: add tsadc node and the IPA parameters for rk3366 thermal

according to our testing results, added the ipa parameters for both cpu
and gpu.

for now,the gpu thermal zone is used only to get the gpu's temperature.

Change-Id: I14274c0b2d7645d08f37d918ddb415ac49ed0d9e
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>

UPSTREAM: clk: rockchip: add a dummy clock for the watchdog pclk on rk3399

Like rk3288, the pclk supplying the watchdog is controlled via the
SGRF register area. Additionally the SGRF isn't even writable in
every boot mode.

But still the clock control is available and in the future someone
might want to use it. Therefore define a simple clock for the time
being so that the watchdog driver can read its rate.

Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit git.kernel.org mmind/linux-rockchip.git
volatile-v4.8-clk/next e3d86c1a2295184374cf25cdb525e68a93b0ff90)

Change-Id: I616846d389d324be529966c63820e8707c7d428f
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

UPSTREAM: clk: rockchip: fix cpuclk registration error handling

It maybe due to a copy-paste error the error handing should be
cclk not clk when checking if the cpuclk registration succeeded.

Reported-by: Lin Huang <lin.huang@rock-chips.com>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git.kernel.org mmind/linux-rockchip.git
v4.7-clk/fixes commit df43cf8f1c116f26fcfd89ce9b1119929c732597)

Change-Id: I7d21808194c914e9117c498309e4b69861799318
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

ARM64: config: rockchip_defconfig: make ipa work as default config

Change-Id: Ib82b0102b9b14aeb1f44e60f12451cac32b75acc
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>

arm64: dts: rockchip: add the IPA needed parameters for rk3399 thermal

according to our testing results, added the ipa parameters for both cpu
big cores and cpu little cores, and updated the  parameters for gpu.

for now,the gpu thermal zone is used only to get the gpu's temperature.

Change-Id: Ifc7708de9d880e0f9cd5da0bb71a135b0c381b45
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>

ARM64: dts: rockchip: add pstore node for rk3366-tb

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

video: rockchip: hdmi: add power domain control

grf_soc_con20 will be reset when vio pd close, so we have to
set hdmi source everytime wake up

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

video: rockchip: mipi: add dual mipi support

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

video: rockchip: fb: add parse screen physical size

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

ARM64: dts: rk3399: clk: set armclkb 816M when clk init

set armclkb 816M to slove the crash,which reset core voltage below 0.85V.
So make sure the 0.8V voltage is enough for the init clk freq.

Change-Id: I4dba25fdfd610c0751f50ce09283c32a9b3f420f
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: ASoC: rockchip: i2s: rename I2S_CKR_TRCM_TX/RXSHARE to I2S_CKR_TRCM_TX/RXONLY

this patch make it more reasonable and readable, because when we chose
I2S_CKR_TRCM_TXONLY, we only output clk_lrck_tx, and hardware need to
confirm this signal is wired to external codec lrck_tx/rx at the same time.

for convenience, we just handle lrck_txonly if we enable symmetric_rates
in driver and dai_link. otherwise, we use the separate lrck_tx/rx.

Change-Id: I383c34d2337715148566f7e2ada367f2ee279cb5
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from git.kernel.org broonie/sound.git topic/rockchip
 commit 7ec4a1c34a190297540626dfa240dc033beca196)

cpufreq: dt: fix resume warning

This is workaround, but it fix this warning when rk3399 resume:

Detected PIPT I-cache on CPU4
CPU4: found redistributor 100 region 0:0x00000000fef80000
CPU4: Booted secondary processor [410fd082]
cpu cpu4: opp_list_debug_create_link: Failed to create link
cpu cpu4: _add_opp_dev: Failed to register opp debugfs (-12)
cpu cpu5: opp_list_debug_create_link: Failed to create link
cpu cpu5: _add_opp_dev: Failed to register opp debugfs (-12)
CPU4 is up
Detected PIPT I-cache on CPU5
CPU5: found redistributor 101 region 0:0x00000000fefa0000
CPU5: Booted secondary processor [410fd082]
------------[ cut here ]------------
WARNING: at drivers/base/power/opp/core.c:1452

CPU: 2 PID: 564 Comm: system_server Not tainted 4.4.10 #194
Hardware name: Rockchip RK3399 Evaluation Board v2 (Android) (DT)
task: ffffffc0e71fec00 ti: ffffffc0dbe10000 task.ti: ffffffc0dbe10000
PC is at dev_pm_opp_set_regulator+0x64/0x100
LR is at dev_pm_opp_set_regulator+0x38/0x100
pc : [<ffffff800846e968>] lr : [<ffffff800846e93c>] pstate: 80000045
sp : ffffffc0dbe138d0
x29: ffffffc0dbe138d0 x28: ffffff8008bb708e
x27: ffffff8008f58308 x26: ffffff8008d78000
x25: 0000000000000005 x24: ffffff8008bb89e9
x23: ffffff8008bb89e9 x22: ffffffc0eff814d8
x21: ffffffc0e47d2000 x20: ffffff8008dd6000
x19: ffffff8008dd6540 x18: 0000000030d00800
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 0000000000000000
x13: ffffffffff000000 x12: 0000000000000008
x11: 0000000000000038 x10: 0101010101010101
x9 : fffffffffffffffc x8 : 7f7f7f7f7f7f7f7f
x7 : ff786b6f6f74722c x6 : 0000000000000080
x5 : ffffffc0eff814d8 x4 : ffffffc0e47d2128
x3 : ffffff8008dd6530 x2 : ffffffc0e47e6200
x1 : ffffffc0e47d2138 x0 : ffffffc0e47e3f00

SP: 0xffffffc0dbe13850:
3850  08dd6000 ffffff80 e47d2000 ffffffc0 eff814d8 ffffffc0 08bb89e9 ffffff80
3870  08bb89e9 ffffff80 00000005 00000000 08d78000 ffffff80 08f58308 ffffff80
3890  08bb708e ffffff80 dbe138d0 ffffffc0 0846e93c ffffff80 dbe138d0 ffffffc0
38b0  0846e968 ffffff80 80000045 00000000 08dd6540 ffffff80 eff814d8 ffffffc0
38d0  dbe13910 ffffffc0 086572f4 ffffff80 00000000 00000000 eff814d8 ffffffc0
38f0  da7bc400 ffffffc0 d9c3f100 ffffffc0 00000000 00000000 08d78000 ffffff80
3910  dbe13960 ffffffc0 08650678 ffffff80 da7bc400 ffffffc0 08f58438 ffffff80
3930  08f58000 ffffff80 00000001 00000000 08d4f000 ffffff80 00000005 00000000

X0: 0xffffffc0e47e3e80:
3e80  75676572 6f74616c 2d352e72 50505553 a300594c 8a2e0000 f3ff0000 fff30000
3ea0  ffff0000 4fff0000 d5770000 65320000 b4ff0000 d24c0000 ffff0000 bf170000
3ec0  bfff0000 7e770000 df2c0000 00890000 5fee0000 85af0000 ffff0000 fdde0000
3ee0  feff0000 bfbf0000 bfa70000 36920000 4e3f0000 9cee0000 ffff0000 ff2f0000
3f00  eff6e4d8 ffffffc0 e4770028 ffffffc0 e4770028 ffffffc0 00000001 00000000
3f20  000dbba0 000dbba0 e47e3f80 ffffffc0 00000000 00000000 00000000 00000000
3f40  00000000 00000000 00000000 00000000 e4770000 ffffffc0 e6fcb900 ffffffc0
3f60  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

X1: 0xffffffc0e47d20b8:
20b8  00000000 00000000 00000000 00000000 080ae3ac ffffff80 e47d2090 ffffffc0
20d8  00200005 ffffffff ffffffff 00000000 00000000 00000000 00000000 00000000
20f8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2118  00000000 00000000 00000000 00000000 d9c41900 ffffffc0 e47e6200 ffffffc0
2138  e47d2138 ffffffc0 e47d2138 ffffffc0 eff98388 ffffffc0 00009c40 00000000
2158  00000000 00000001 00000000 00000000 00000000 00000000 00000000 00000000
2178  00000000 00000000 e47e3d00 ffffffc0 e47e3f00 ffffffc0 e6fcb540 ffffffc0
2198  35757063 00000000 00000000 00000000 00000000 00000000 00000000 00000000

X2: 0xffffffc0e47e6180:
6180  e47e6280 ffffffc0 00000200 dead0000 00000001 00000000 30a32c00 00000000
61a0  000dbba0 00000000 000dbba0 00000000 000dbba0 00000000 00000000 00000000
61c0  00000000 00000000 e47d2000 ffffffc0 00000000 00000000 00000050 00000000
61e0  eff98ac0 ffffffc0 e6fd6cc0 ffffffc0 00000000 00000000 00000000 00000000
6200  e47d2128 ffffffc0 d9c41900 ffffffc0 eff814d8 ffffffc0 00000000 00000000
6220  00000000 00000000 e6fcb540 ffffffc0 00000000 00000000 00000000 00000000
6240  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
6260  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

X4: 0xffffffc0e47d20a8:
20a8  080e5090 ffffff80 00000000 00000000 00000000 00000000 00000000 00000000
20c8  080ae3ac ffffff80 e47d2090 ffffffc0 00200005 ffffffff ffffffff 00000000
20e8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2108  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2128  d9c41900 ffffffc0 e47e6200 ffffffc0 e47d2138 ffffffc0 e47d2138 ffffffc0
2148  eff98388 ffffffc0 00009c40 00000000 00000000 00000001 00000000 00000000
2168  00000000 00000000 00000000 00000000 00000000 00000000 e47e3d00 ffffffc0
2188  e47e3f00 ffffffc0 e6fcb540 ffffffc0 35757063 00000000 00000000 00000000

X5: 0xffffffc0eff81458:
1458  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1478  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1498  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
14b8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001
14d8  00000000 00000000 e6862f00 ffffffc0 e6865e00 ffffffc0 e6900020 ffffffc0
14f8  eff6e4f0 ffffffc0 e7209c10 ffffffc0 e71b6a00 ffffffc0 08dd5130 ffffff80
1518  e686a2d0 ffffffc0 00000003 00000007 00000000 00000000 00000000 00000000
1538  00000001 00000000 eff81540 ffffffc0 eff81540 ffffffc0 00000000 00000000

X13: 0xfffffffffeffff80:
ff80  ******** ******** ******** ******** ******** ******** ******** ********
ffa0  ******** ******** ******** ******** ******** ******** ******** ********
ffc0  ******** ******** ******** ******** ******** ******** ******** ********
ffe0  ******** ******** ******** ******** ******** ******** ******** ********
0000  ******** ******** ******** ******** ******** ******** ******** ********
0020  ******** ******** ******** ******** ******** ******** ******** ********
0040  ******** ******** ******** ******** ******** ******** ******** ********
0060  ******** ******** ******** ******** ******** ******** ******** ********

X21: 0xffffffc0e47d1f80:
1f80  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fa0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fc0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2000  e47d1800 ffffffc0 e479b000 ffffffc0 00000001 00000000 e47d2018 ffffffc0
2020  e47d2018 ffffffc0 00000000 00000000 00000000 00000000 00000005 00000000
2040  08d58a20 ffffff80 000f000f 00000000 00000000 00000000 e47d2050 ffffffc0
2060  00000000 00000000 e47d2060 ffffffc0 00000000 00000000 e47d2070 ffffffc0

X22: 0xffffffc0eff81458:
1458  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1478  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1498  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
14b8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001
14d8  00000000 00000000 e6862f00 ffffffc0 e6865e00 ffffffc0 e6900020 ffffffc0
14f8  eff6e4f0 ffffffc0 e7209c10 ffffffc0 e71b6a00 ffffffc0 08dd5130 ffffff80
1518  e686a2d0 ffffffc0 00000003 00000007 00000000 00000000 00000000 00000000
1538  00000001 00000000 eff81540 ffffffc0 eff81540 ffffffc0 00000000 00000000

X29: 0xffffffc0dbe13850:
3850  08dd6000 ffffff80 e47d2000 ffffffc0 eff814d8 ffffffc0 08bb89e9 ffffff80
3870  08bb89e9 ffffff80 00000005 00000000 08d78000 ffffff80 08f58308 ffffff80
3890  08bb708e ffffff80 dbe138d0 ffffffc0 0846e93c ffffff80 dbe138d0 ffffffc0
38b0  0846e968 ffffff80 80000045 00000000 08dd6540 ffffff80 eff814d8 ffffffc0
38d0  dbe13910 ffffffc0 086572f4 ffffff80 00000000 00000000 eff814d8 ffffffc0
38f0  da7bc400 ffffffc0 d9c3f100 ffffffc0 00000000 00000000 08d78000 ffffff80
3910  dbe13960 ffffffc0 08650678 ffffff80 da7bc400 ffffffc0 08f58438 ffffff80
3930  08f58000 ffffff80 00000001 00000000 08d4f000 ffffff80 00000005 00000000

---[ end trace e939d14abbcc0fd3 ]---
Call trace:
Exception stack(0xffffffc0dbe13710 to 0xffffffc0dbe13830)
3700:                                   ffffff8008dd6540 ffffff8008dd6000
3720: ffffffc0dbe138d0 ffffff800846e968 ffffffc0dbe13770 ffffff80086b096c
3740: 0000000000000004 ffffffbffe800924 ffffffc0dbe13780 ffffff80086b0930
3760: ffffff8008f58d50 ffffffc0eff96758 ffffffc0dbe13780 ffffff80086b0940
3780: ffffffc0dbe13790 ffffff80086b13b4 ffffffc0dbe137d0 ffffff80086b1620
37a0: 0000000000000000 ffffffbffe800870 ffffffc0e47e3f00 ffffffc0e47d2138
37c0: ffffffc0e47e6200 ffffff8008dd6530 ffffffc0e47d2128 ffffffc0eff814d8
37e0: 0000000000000080 ff786b6f6f74722c 7f7f7f7f7f7f7f7f fffffffffffffffc
3800: 0101010101010101 0000000000000038 0000000000000008 ffffffffff000000
3820: 0000000000000000 0000000000000000
[<ffffff800846e968>] dev_pm_opp_set_regulator+0x64/0x100
[<ffffff80086572f4>] cpufreq_init+0xb8/0x290
[<ffffff8008650678>] cpufreq_online+0x268/0x680
[<ffffff8008650ae0>] cpufreq_cpu_callback+0x50/0x5c
[<ffffff80080b5168>] notifier_call_chain+0x48/0x80
[<ffffff80080b5498>] __raw_notifier_call_chain+0xc/0x14
[<ffffff800809a480>] __cpu_notify+0x30/0x50
[<ffffff800809a4b4>] cpu_notify+0x14/0x1c
[<ffffff800809ab9c>] _cpu_up+0x10c/0x1e0
[<ffffff800809b2c4>] enable_nonboot_cpus+0x114/0x230
[<ffffff80080d7e10>] suspend_enter+0x464/0x61c
[<ffffff80080d8088>] suspend_devices_and_enter+0xc0/0x2b8
[<ffffff80080d8814>] pm_suspend+0x594/0x600
[<ffffff80080d6c10>] state_store+0x50/0x88
[<ffffff8008305434>] kobj_attr_store+0x18/0x28
[<ffffff80081e98bc>] sysfs_kf_write+0x44/0x4c
[<ffffff80081e8c78>] kernfs_fop_write+0x10c/0x168
[<ffffff800818b3e4>] __vfs_write+0x28/0xd0
[<ffffff800818b640>] vfs_write+0xac/0x174
[<ffffff800818b7d4>] SyS_write+0x48/0x84
[<ffffff8008084530>] el0_svc_naked+0x24/0x28
cpu cpu5: Failed to set regulator for cpu5: -16
CPU5 is up

It seems recent LSK and upstream is buggy about OPP and cpufreq,
we will waiting for new patch to fix this bug.

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

ARM64: config: rockchip_defconfig remove Rogue of G6110 GPU.

Change-Id: Ib10daa86eb9e3aa2e33c2b5b4b9fdb3f66709b6a
Signed-off-by: ZhuangXiaoLiang <zhuangxl@rock-chips.com>

ARM64: dts: rk3399-evb: enable saradc node

Set status of saradc node to "okay", to support saradc.

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

ARM64: dts: rockchip: remove clk_ignore_unused bootarg for rk3366-tb

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

ARM64: dts: rk3399-android: mipi dsi host1 add grf

Change-Id: Ifa69588690c33da4d58c393f33f344101a4ea11d
Signed-off-by: Xubilv <xbl@rock-chips.com>

usb: gadget: accessory: add compat_ioctl

Add compat_ioctl for accessory to work on 64-bit platforms.

Change-Id: I805395c35017111bf0c462847f11765c7088d266
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>

usb: gadget: mtp: add new ioctl for compat

Define a new ioctl for MTP_SEND_EVENT, as its
ioctl numbers depends on the size of struct
mtp_event, which varies in ARCH32 and ARCH64.

Change-Id: I060604057ac6c55991118b3f61b187468b4ee0fd
Signed-off-by: Rohith Seelaboyina <rseelaboyina@nvidia.com>
Reviewed-on: http://git-master/r/377800
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Venkat Moganty <vmoganty@nvidia.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>

usb: gadget: mtp: add compat_ioctl

Add compat_ioctl for mtp to work on 64-bit platforms.

Change-Id: Icef0f42a554d770a83152c4185aca9e39e041165
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>

ARM64: dts: rk3399: add node support for reboot-mode

Rockchip RK3399 SoCs support reboot with modes, such as recovery mode,
loader mode and normal mode.

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

rk: remove cpuquiet

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

rk: force enable asm goto on android gcc

It seems than android gcc can't pass gcc-goto.sh check, but asm goto work.
So let's active it.

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

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

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

 This is the 4.4.11 stable release

ARM64: dts: rk3399-evb: add more for pcie for evb board

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

ARM64: dts: rk3399: add pcie support

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

pci: Add PCIe driver for Rockchip Soc

RK3399 has a PCIe controller which can be used as Root Complex.
This driver supports a PCIe controller as Root Complex mode.

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

Documentation: add binding description of Rockchip PCIe controller

This patch add some required and optional properties for Rockchip
PCIe controller. Also we add a example for how to use it.

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

video: rockchip: mipi: free cmds buf in rockchip_lcd_mipi_remove

Change-Id: If805e7b6797841a92252a879526200da166141fd
Signed-off-by: Xubilv <xbl@rock-chips.com>

ARM64: dts: rk3399: add rktimer device node

Select rktimer0 as broadcast timer.

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

clocksource: rockchip: add support for rk3399 SoC

The CONTROL register offset is different from old SoCs.
For Linux driver, there are not functional changes at all.
Let's call it v2.

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

dt-bindings: document rk3399 rk-timer bindings

Add compatible string for rk3399 because which timer is a little
different from older SoCs. So rename the file name from
rockchip,rk3288-timer.txt to rockchip,rk-timer.txt.
Clarify rockchip,rk3288-timer supported SoCs.

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

clocksource: rockchip: add dynamic irq flag to the timer

The rockchip timer is broadcast timer. Add CLOCK_EVT_FEAT_DYNIRQ
flag and set cpumask to all cpu to save power by avoid unnecessary
wakeups and IPIs.

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

clocksource: rockchip: remove unnecessary clear irq before request_irq

rk_timer_interrupt_clear and rk_timer_disable is unnecessary before
request_irq. Timer should keep disabled before booting Linux.

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

dtsi: screen-timing: lcd-LP097Qx2: for rk3399 mid prototype

Change-Id: Ia01ee063d5d3f5d7e26e6d0a2683e616eebd19f2
Signed-off-by: Xubilv <xbl@rock-chips.com>

dtsi: screen-timing: lcd-ls055r1sx04-mipi: for rk3399 vr prototype

Change-Id: Iee299bfe2786ece1b7cc1d53a81e4a4c29a4bf0e
Signed-off-by: Xubilv <xbl@rock-chips.com>

Linux 4.4.11

nf_conntrack: avoid kernel pointer value leak in slab name

commit 31b0b385f69d8d5491a4bca288e25e63f1d945d0 upstream.

The slab name ends up being visible in the directory structure under
/sys, and even if you don't have access rights to the file you can see
the filenames.

Just use a 64-bit counter instead of the pointer to the 'net' structure
to generate a unique name.

This code will go away in 4.7 when the conntrack code moves to a single
kmemcache, but this is the backportable simple solution to avoiding
leaking kernel pointers to user space.

Fixes: 5b3501faa874 ("netfilter: nf_conntrack: per netns nf_conntrack_cachep")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon: fix DP link training issue with second 4K monitor

commit 1a738347df2ee4977459a8776fe2c62196bdcb1b upstream.

There is an issue observed when we hotplug a second DP
4K monitor to the system. Sometimes, the link training
fails for the second monitor after HPD interrupt
generation.

The issue happens when some queued or deferred transactions
are already present on the AUX channel when we initiate
a new transcation to (say) get DPCD or during link training.

We set AUX_IGNORE_HPD_DISCON bit in the AUX_CONTROL
register so that we can ignore any such deferred
transactions when a new AUX transaction is initiated.

Signed-off-by: Arindam Nath <arindam.nath@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/i915/bdw: Add missing delay during L3 SQC credit programming

commit d6a862fe8c48229ba342648bcd535b2404724603 upstream.

BSpec requires us to wait ~100 clocks before re-enabling clock gating,
so make sure we do this.

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1462280061-1457-2-git-send-email-imre.deak@intel.com
(cherry picked from commit 48e5d68d28f00c0cadac5a830980ff3222781abb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915: Bail out of pipe config compute loop on LPT

commit 2700818ac9f935d8590715eecd7e8cadbca552b6 upstream.

LPT is pch, so might run into the fdi bandwidth constraint (especially
since it has only 2 lanes). But right now we just force pipe_bpp back
to 24, resulting in a nice loop (which we bail out with a loud
WARN_ON). Fix this.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=93477
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch
(cherry picked from commit f58a1acc7e4a1f37d26124ce4c875c647fbcc61f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon: fix PLL sharing on DCE6.1 (v2)

commit e3c00d87845ab375f90fa6e10a5e72a3a5778cd3 upstream.

On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not
be taken into consideration when looking for an already enabled PLL
to be shared with other outputs.

This fixes the broken VGA port (TRAVIS DP->VGA bridge) on my Richland
based laptop, where the internal display is connected to UNIPHYA through
a TRAVIS DP->LVDS bridge.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78987

v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop
    extra parameter.

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

Revert "[media] videobuf2-v4l2: Verify planes array in buffer dequeueing"

commit 93f0750dcdaed083d6209b01e952e98ca730db66 upstream.

This patch causes a Kernel panic when called on a DVB driver.

This was also reported by David R <david@unsolicited.net>:

May  7 14:47:35 server kernel: [  501.247123] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
May  7 14:47:35 server kernel: [  501.247239] IP: [<ffffffffa0222c71>] __verify_planes_array.isra.3+0x1/0x80 [videobuf2_v4l2]
May  7 14:47:35 server kernel: [  501.247354] PGD cae6f067 PUD ca99c067 PMD 0
May  7 14:47:35 server kernel: [  501.247426] Oops: 0000 [#1] SMP
May  7 14:47:35 server kernel: [  501.247482] Modules linked in: xfs tun xt_connmark xt_TCPMSS xt_tcpmss xt_owner xt_REDIRECT nf_nat_redirect xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ts_kmp ts_bm xt_string ipt_REJECT nf_reject_ipv4 xt_recent xt_conntrack xt_multiport xt_pkttype xt_tcpudp xt_mark nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables ip6table_filter ip6_tables x_tables pppoe pppox dm_crypt ts2020 regmap_i2c ds3000 cx88_dvb dvb_pll cx88_vp3054_i2c mt352 videobuf2_dvb cx8800 cx8802 cx88xx pl2303 tveeprom videobuf2_dma_sg ppdev videobuf2_memops videobuf2_v4l2 videobuf2_core dvb_usb_digitv snd_hda_codec_via snd_hda_codec_hdmi snd_hda_codec_generic radeon dvb_usb snd_hda_intel amd64_edac_mod serio_raw snd_hda_codec edac_core fbcon k10temp bitblit softcursor snd_hda_core font snd_pcm_oss i2c_piix4 snd_mixer_oss tileblit drm_kms_helper syscopyarea snd_pcm snd_seq_dummy sysfillrect snd_seq_oss sysimgblt fb_sys_fops ttm snd_seq_midi r8169 snd_rawmidi drm snd_seq_midi_event e1000e snd_seq snd_seq_device snd_timer snd ptp pps_core i2c_algo_bit soundcore parport_pc ohci_pci shpchp tpm_tis tpm nfsd auth_rpcgss oid_registry hwmon_vid exportfs nfs_acl mii nfs bonding lockd grace lp sunrpc parport
May  7 14:47:35 server kernel: [  501.249564] CPU: 1 PID: 6889 Comm: vb2-cx88[0] Not tainted 4.5.3 #3
May  7 14:47:35 server kernel: [  501.249644] Hardware name: System manufacturer System Product Name/M4A785TD-V EVO, BIOS 0211    07/08/2009
May  7 14:47:35 server kernel: [  501.249767] task: ffff8800aebf3600 ti: ffff8801e07a0000 task.ti: ffff8801e07a0000
May  7 14:47:35 server kernel: [  501.249861] RIP: 0010:[<ffffffffa0222c71>]  [<ffffffffa0222c71>] __verify_planes_array.isra.3+0x1/0x80 [videobuf2_v4l2]
May  7 14:47:35 server kernel: [  501.250002] RSP: 0018:ffff8801e07a3de8  EFLAGS: 00010086
May  7 14:47:35 server kernel: [  501.250071] RAX: 0000000000000283 RBX: ffff880210dc5000 RCX: 0000000000000283
May  7 14:47:35 server kernel: [  501.250161] RDX: ffffffffa0222cf0 RSI: 0000000000000000 RDI: ffff880210dc5014
May  7 14:47:35 server kernel: [  501.250251] RBP: ffff8801e07a3df8 R08: ffff8801e07a0000 R09: 0000000000000000
May  7 14:47:35 server kernel: [  501.250348] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8800cda2a9d8
May  7 14:47:35 server kernel: [  501.250438] R13: ffff880210dc51b8 R14: 0000000000000000 R15: ffff8800cda2a828
May  7 14:47:35 server kernel: [  501.250528] FS:  00007f5b77fff700(0000) GS:ffff88021fc40000(0000) knlGS:00000000adaffb40
May  7 14:47:35 server kernel: [  501.250631] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
May  7 14:47:35 server kernel: [  501.250704] CR2: 0000000000000004 CR3: 00000000ca19d000 CR4: 00000000000006e0
May  7 14:47:35 server kernel: [  501.250794] Stack:
May  7 14:47:35 server kernel: [  501.250822]  ffff8801e07a3df8 ffffffffa0222cfd ffff8801e07a3e70 ffffffffa0236beb
May  7 14:47:35 server kernel: [  501.250937]  0000000000000283 ffff8801e07a3e94 0000000000000000 0000000000000000
May  7 14:47:35 server kernel: [  501.251051]  ffff8800aebf3600 ffffffff8108d8e0 ffff8801e07a3e38 ffff8801e07a3e38
May  7 14:47:35 server kernel: [  501.251165] Call Trace:
May  7 14:47:35 server kernel: [  501.251200]  [<ffffffffa0222cfd>] ? __verify_planes_array_core+0xd/0x10 [videobuf2_v4l2]
May  7 14:47:35 server kernel: [  501.251306]  [<ffffffffa0236beb>] vb2_core_dqbuf+0x2eb/0x4c0 [videobuf2_core]
May  7 14:47:35 server kernel: [  501.251398]  [<ffffffff8108d8e0>] ? prepare_to_wait_event+0x100/0x100
May  7 14:47:35 server kernel: [  501.251482]  [<ffffffffa023855b>] vb2_thread+0x1cb/0x220 [videobuf2_core]
May  7 14:47:35 server kernel: [  501.251569]  [<ffffffffa0238390>] ? vb2_core_qbuf+0x230/0x230 [videobuf2_core]
May  7 14:47:35 server kernel: [  501.251662]  [<ffffffffa0238390>] ? vb2_core_qbuf+0x230/0x230 [videobuf2_core]
May  7 14:47:35 server kernel: [  501.255982]  [<ffffffff8106f984>] kthread+0xc4/0xe0
May  7 14:47:35 server kernel: [  501.260292]  [<ffffffff8106f8c0>] ? kthread_park+0x50/0x50
May  7 14:47:35 server kernel: [  501.264615]  [<ffffffff81697a5f>] ret_from_fork+0x3f/0x70
May  7 14:47:35 server kernel: [  501.268962]  [<ffffffff8106f8c0>] ? kthread_park+0x50/0x50
May  7 14:47:35 server kernel: [  501.273216] Code: 0d 01 74 16 48 8b 46 28 48 8b 56 30 48 89 87 d0 01 00 00 48 89 97 d8 01 00 00 5d c3 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 <8b> 46 04 48 89 e5 8d 50 f7 31 c0 83 fa 01 76 02 5d c3 48 83 7e
May  7 14:47:35 server kernel: [  501.282146] RIP  [<ffffffffa0222c71>] __verify_planes_array.isra.3+0x1/0x80 [videobuf2_v4l2]
May  7 14:47:35 server kernel: [  501.286391]  RSP <ffff8801e07a3de8>
May  7 14:47:35 server kernel: [  501.290619] CR2: 0000000000000004
May  7 14:47:35 server kernel: [  501.294786] ---[ end trace b2b354153ccad110 ]---

This reverts commit 2c1f6951a8a82e6de0d82b1158b5e493fc6c54ab.

Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Fixes: 2c1f6951a8a8 ("[media] videobuf2-v4l2: Verify planes array in buffer dequeueing")
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: max8997-haptic - fix NULL pointer dereference

commit 6ae645d5fa385f3787bf1723639cd907fe5865e7 upstream.

NULL pointer derefence happens when booting with DTB because the
platform data for haptic device is not set in supplied data from parent
MFD device.

The MFD device creates only platform data (from Device Tree) for itself,
not for haptic child.

Unable to handle kernel NULL pointer dereference at virtual address 0000009c
pgd = c0004000
[0000009c] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
(max8997_haptic_probe) from [<c03f9cec>] (platform_drv_probe+0x4c/0xb0)
(platform_drv_probe) from [<c03f8440>] (driver_probe_device+0x214/0x2c0)
(driver_probe_device) from [<c03f8598>] (__driver_attach+0xac/0xb0)
(__driver_attach) from [<c03f67ac>] (bus_for_each_dev+0x68/0x9c)
(bus_for_each_dev) from [<c03f7a38>] (bus_add_driver+0x1a0/0x218)
(bus_add_driver) from [<c03f8db0>] (driver_register+0x78/0xf8)
(driver_register) from [<c0101774>] (do_one_initcall+0x90/0x1d8)
(do_one_initcall) from [<c0a00dbc>] (kernel_init_freeable+0x15c/0x1fc)
(kernel_init_freeable) from [<c06bb5b4>] (kernel_init+0x8/0x114)
(kernel_init) from [<c0107938>] (ret_from_fork+0x14/0x3c)

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes: 104594b01ce7 ("Input: add driver support for MAX8997-haptic")
[k.kozlowski: Write commit message, add CC-stable]
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

get_rock_ridge_filename(): handle malformed NM entries

commit 99d825822eade8d827a1817357cbf3f889a552d6 upstream.

Payloads of NM entries are not supposed to contain NUL.  When we run
into such, only the part prior to the first NUL goes into the
concatenation (i.e. the directory entry name being encoded by a bunch
of NM entries).  We do stop when the amount collected so far + the
claimed amount in the current NM entry exceed 254.  So far, so good,
but what we return as the total length is the sum of *claimed*
sizes, not the actual amount collected.  And that can grow pretty
large - not unlimited, since you'd need to put CE entries in
between to be able to get more than the maximum that could be
contained in one isofs directory entry / continuation chunk and
we are stop once we'd encountered 32 CEs, but you can get about 8Kb
easily.  And that's what will be passed to readdir callback as the
name length.  8Kb __copy_to_user() from a buffer allocated by
__get_free_page()

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

tools lib traceevent: Do not reassign parg after collapse_tree()

commit 106b816cb46ebd87408b4ed99a2e16203114daa6 upstream.

At the end of process_filter(), collapse_tree() was changed to update
the parg parameter, but the reassignment after the call wasn't removed.

What happens is that the "current_op" gets modified and freed and parg
is assigned to the new allocated argument. But after the call to
collapse_tree(), parg is assigned again to the just freed "current_op",
and this causes the tool to crash.

The current_op variable must also be assigned to NULL in case of error,
otherwise it will cause it to be free()ed twice.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Fixes: 42d6194d133c ("tools lib traceevent: Refactor process_filter()")
Link: http://lkml.kernel.org/r/20160511150936.678c18a1@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

qla1280: Don't allocate 512kb of host tags

commit 2bcbc81421c511ef117cadcf0bee9c4340e68db0 upstream.

The qla1280 driver sets the scsi_host_template's can_queue field to 0xfffff
which results in an allocation failure when allocating the block layer tags
for the driver's queues. This was introduced with the change for host wide
tags in commit 64d513ac31b - "scsi: use host wide tags by default".

Reduce can_queue to MAX_OUTSTANDING_COMMANDS (512) to solve the allocation
error.

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Fixes: 64d513ac31b - "scsi: use host wide tags by default"
Cc: Laura Abbott <labbott@redhat.com>
Cc: Michael Reed <mdr@sgi.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <jejb@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

atomic_open(): fix the handling of create_error

commit 10c64cea04d3c75c306b3f990586ffb343b63287 upstream.

* if we have a hashed negative dentry and either CREAT|EXCL on
r/o filesystem, or CREAT|TRUNC on r/o filesystem, or CREAT|EXCL
with failing may_o_create(), we should fail with EROFS or the
error may_o_create() has returned, but not ENOENT.  Which is what
the current code ends up returning.

* if we have CREAT|TRUNC hitting a regular file on a read-only
filesystem, we can't fail with EROFS here.  At the very least,
not until we'd done follow_managed() - we might have a writable
file (or a device, for that matter) bound on top of that one.
Moreover, the code downstream will see that O_TRUNC and attempt
to grab the write access (*after* following possible mount), so
if we really should fail with EROFS, it will happen.  No need
to do that inside atomic_open().

The real logics is much simpler than what the current code is
trying to do - if we decided to go for simple lookup, ended
up with a negative dentry *and* had create_error set, fail with
create_error.  No matter whether we'd got that negative dentry
from lookup_real() or had found it in dcache.

Acked-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: axp20x: Fix axp22x ldo_io voltage ranges

commit a2262e5a12e05389ab4c7fc5cf60016b041dd8dc upstream.

The minium voltage of 1800mV is a copy and paste error from the axp20x
regulator info. The correct minimum voltage for the ldo_io regulators
on the axp22x is 700mV.

Fixes: 1b82b4e4f954 ("regulator: axp20x: Add support for AXP22X regulators")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: s2mps11: Fix invalid selector mask and voltages for buck9

commit 3b672623079bb3e5685b8549e514f2dfaa564406 upstream.

The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff
instead of 0x1f) thus reading entire register as buck9's voltage. This
effectively caused regulator core to interpret values as higher voltages
than they were and then to set real voltage much lower than intended.

The buck9 provides power to other regulators, including LDO13
and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower
voltage caused SD card detection errors on Odroid XU3/XU4:
mmc1: card never left busy state
mmc1: error -110 whilst initialising SD card

During driver probe the regulator core was checking whether initial
voltage matches the constraints. With incorrect vsel_mask of 0xff and
default value of 0x50, the core interpreted this as 5 V which is outside
of constraints (3-3.775 V). Then the regulator core was adjusting the
voltage to match the constraints. With incorrect vsel_mask this new
voltage mapped to a vere low voltage in the driver.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

workqueue: fix rebind bound workers warning

commit f7c17d26f43d5cc1b7a6b896cd2fa24a079739b9 upstream.

------------[ cut here ]------------
WARNING: CPU: 0 PID: 16 at kernel/workqueue.c:4559 rebind_workers+0x1c0/0x1d0
Modules linked in:
CPU: 0 PID: 16 Comm: cpuhp/0 Not tainted 4.6.0-rc4+ #31
Hardware name: IBM IBM System x3550 M4 Server -[7914IUW]-/00Y8603, BIOS -[D7E128FUS-1.40]- 07/23/2013
 0000000000000000 ffff881037babb58 ffffffff8139d885 0000000000000010
 0000000000000000 0000000000000000 0000000000000000 ffff881037babba8
 ffffffff8108505d ffff881037ba0000 000011cf3e7d6e60 0000000000000046
Call Trace:
 dump_stack+0x89/0xd4
 __warn+0xfd/0x120
 warn_slowpath_null+0x1d/0x20
 rebind_workers+0x1c0/0x1d0
 workqueue_cpu_up_callback+0xf5/0x1d0
 notifier_call_chain+0x64/0x90
 ? trace_hardirqs_on_caller+0xf2/0x220
 ? notify_prepare+0x80/0x80
 __raw_notifier_call_chain+0xe/0x10
 __cpu_notify+0x35/0x50
 notify_down_prepare+0x5e/0x80
 ? notify_prepare+0x80/0x80
 cpuhp_invoke_callback+0x73/0x330
 ? __schedule+0x33e/0x8a0
 cpuhp_down_callbacks+0x51/0xc0
 cpuhp_thread_fun+0xc1/0xf0
 smpboot_thread_fn+0x159/0x2a0
 ? smpboot_create_threads+0x80/0x80
 kthread+0xef/0x110
 ? wait_for_completion+0xf0/0x120
 ? schedule_tail+0x35/0xf0
 ret_from_fork+0x22/0x50
 ? __init_kthread_worker+0x70/0x70
---[ end trace eb12ae47d2382d8f ]---
notify_down_prepare: attempt to take down CPU 0 failed

This bug can be reproduced by below config w/ nohz_full= all cpus:

CONFIG_BOOTPARAM_HOTPLUG_CPU0=y
CONFIG_DEBUG_HOTPLUG_CPU0=y
CONFIG_NO_HZ_FULL=y

As Thomas pointed out:

| If a down prepare callback fails, then DOWN_FAILED is invoked for all
| callbacks which have successfully executed DOWN_PREPARE.
|
| But, workqueue has actually two notifiers. One which handles
| UP/DOWN_FAILED/ONLINE and one which handles DOWN_PREPARE.
|
| Now look at the priorities of those callbacks:
|
| CPU_PRI_WORKQUEUE_UP        = 5
| CPU_PRI_WORKQUEUE_DOWN      = -5
|
| So the call order on DOWN_PREPARE is:
|
| CB 1
| CB ...
| CB workqueue_up() -> Ignores DOWN_PREPARE
| CB ...
| CB X ---> Fails
|
| So we call up to CB X with DOWN_FAILED
|
| CB 1
| CB ...
| CB workqueue_up() -> Handles DOWN_FAILED
| CB ...
| CB X-1
|
| So the problem is that the workqueue stuff handles DOWN_FAILED in the up
| callback, while it should do it in the down callback. Which is not a good idea
| either because it wants to be called early on rollback...
|
| Brilliant stuff, isn't it? The hotplug rework will solve this problem because
| the callbacks become symetric, but for the existing mess, we need some
| workaround in the workqueue code.

The boot CPU handles housekeeping duty(unbound timers, workqueues,
timekeeping, ...) on behalf of full dynticks CPUs. It must remain
online when nohz full is enabled. There is a priority set to every
notifier_blocks:

workqueue_cpu_up > tick_nohz_cpu_down > workqueue_cpu_down

So tick_nohz_cpu_down callback failed when down prepare cpu 0, and
notifier_blocks behind tick_nohz_cpu_down will not be called any
more, which leads to workers are actually not unbound. Then hotplug
state machine will fallback to undo and online cpu 0 again. Workers
will be rebound unconditionally even if they are not unbound and
trigger the warning in this progress.

This patch fix it by catching !DISASSOCIATED to avoid rebind bound
workers.

Cc: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Suggested-by: Lai Jiangshan <jiangshanlai@gmail.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: at91: sam9x5: Fix the memory range assigned to the PMC

commit aab0a4c83ceb344d2327194bf354820e50607af6 upstream.

The memory range assigned to the PMC (Power Management Controller) was
not including the PMC_PCR register which are used to control peripheral
clocks.

This was working fine thanks to the page granularity of ioremap(), but
started to fail when we switched to syscon/regmap, because regmap is
making sure that all accesses are falling into the reserved range.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Richard Genoud <richard.genoud@gmail.com>
Tested-by: Richard Genoud <richard.genoud@gmail.com>
Fixes: 863a81c3be1d ("clk: at91: make use of syscon to share PMC registers in several drivers")
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vfs: rename: check backing inode being equal

commit 9409e22acdfc9153f88d9b1ed2bd2a5b34d2d3ca upstream.

If a file is renamed to a hardlink of itself POSIX specifies that rename(2)
should do nothing and return success.

This condition is checked in vfs_rename().  However it won't detect hard
links on overlayfs where these are given separate inodes on the overlayfs
layer.

Overlayfs itself detects this condition and returns success without doing
anything, but then vfs_rename() will proceed as if this was a successful
rename (detach_mounts(), d_move()).

The correct thing to do is to detect this condition before even calling
into overlayfs.  This patch does this by calling vfs_select_inode() to get
the underlying inodes.

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vfs: add vfs_select_inode() helper

commit 54d5ca871e72f2bb172ec9323497f01cd5091ec7 upstream.

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

perf/core: Disable the event on a truncated AUX record

commit 9f448cd3cbcec8995935e60b27802ae56aac8cc0 upstream.

When the PMU driver reports a truncated AUX record, it effectively means
that there is no more usable room in the event's AUX buffer (even though
there may still be some room, so that perf_aux_output_begin() doesn't take
action). At this point the consumer still has to be woken up and the event
has to be disabled, otherwise the event will just keep spinning between
perf_aux_output_begin() and perf_aux_output_end() until its context gets
unscheduled.

Again, for cpu-wide events this means never, so once in this condition,
they will be forever losing data.

Fix this by disabling the event and waking up the consumer in case of a
truncated AUX record.

Reported-by: Markus Metzger <markus.t.metzger@intel.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/1462886313-13660-3-git-send-email-alexander.shishkin@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case

commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 upstream.

Specifically for the case of reads that use the Extended Register
Read Long command, a multi-byte read operation is broken up into
8-byte chunks.  However the call to spmi_ext_register_readl() is
incorrectly passing 'val_size', which if greater than 8 will
always fail.  The argument should instead be 'len'.

Fixes: c9afbb05a9ff ("regmap: spmi: support base and extended register spaces")
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pinctrl: at91-pio4: fix pull-up/down logic

commit 5305a7b7e860bb40ab226bc7d58019416073948a upstream.

The default configuration of a pin is often with a value in the
pull-up/down field at chip reset. So, even if the internal logic of the
controller prevents writing a configuration with pull-up and pull-down at
the same time, we must ensure explicitly this condition before writing the
register.

This was leading to a pull-down condition not taken into account for
instance.

Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Fixes: 776180848b57 ("pinctrl: introduce driver for Atmel PIO4 controller")
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: spi-ti-qspi: Handle truncated frames properly

commit 1ff7760ff66b98ef244bf0e5e2bd5310651205ad upstream.

We clamp frame_len_words to a maximum of 4096, but do not actually
limit the number of words written or read through the DATA registers
or the length added to spi_message::actual_length.  This results in
silent data corruption for commands longer than this maximum.

Recalculate the length of each transfer, taking frame_len_words into
account.  Use this length in qspi_{read,write}_msg(), and to increment
spi_message::actual_length.

Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: spi-ti-qspi: Fix FLEN and WLEN settings if bits_per_word is overridden

commit ea1b60fb085839a9544cb3a0069992991beabb7f upstream.

Each transfer can specify 8, 16 or 32 bits per word independently of
the default for the device being addressed.  However, currently we
calculate the number of words in the frame assuming that the word size
is the device default.

If multiple transfers in the same message have differing
bits_per_word, we bitwise-or the different values in the WLEN register
field.

Fix both of these.  Also rename 'frame_length' to 'frame_len_words' to
make clear that it's not a byte count like spi_message::frame_length.

Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spi: pxa2xx: Do not detect number of enabled chip selects on Intel SPT

commit 66ec246eb9982e7eb8e15e1fc55f543230310dd0 upstream.

Certain Intel Sunrisepoint PCH variants report zero chip selects in SPI
capabilities register even they have one per port. Detection in
pxa2xx_spi_probe() sets master->num_chipselect to 0 leading to -EINVAL
from spi_register_master() where chip select count is validated.

Fix this by not using SPI capabilities register on Sunrisepoint. They don't
have more than one chip select so use the default value 1 instead of
detection.

Fixes: 8b136baa5892 ("spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals")
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - Fix broken reconfig

commit addacd801e1638f41d659cb53b9b73fc14322cb1 upstream.

The HD-audio reconfig function got broken in the recent kernels,
typically resulting in a failure like:
  snd_hda_intel 0000:00:1b.0: control 3:0:0:Playback Channel Map:0 is already present

This is because of the code restructuring to move the PCM and control
instantiation into the codec drive probe, by the commit [bcd96557bd0a:
ALSA: hda - Build PCMs and controls at codec driver probe].  Although
the commit above removed the calls of snd_hda_codec_build_pcms() and
*_build_controls() at the controller driver probe, the similar calls
in the reconfig were still left forgotten.  This caused the
conflicting and duplicated PCMs and controls.

The fix is trivial: just remove these superfluous calls from
reconfig_codec().

Fixes: bcd96557bd0a ('ALSA: hda - Build PCMs and controls at codec driver probe')
Reported-by: Jochen Henneberg <jh@henneberg-systemdesign.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - Fix white noise on Asus UX501VW headset

commit 2da2dc9ead232f25601404335cca13c0f722d41b upstream.

For reducing the noise from the headset output on ASUS UX501VW,
call the existing fixup, alc_fixup_headset_mode_alc668(), additionally.

Thread: https://bbs.archlinux.org/viewtopic.php?id=209554

Signed-off-by: Kaho Ng <ngkaho1234@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda - Fix subwoofer pin on ASUS N751 and N551

commit 3231e2053eaeee70bdfb216a78a30f11e88e2243 upstream.

Subwoofer does not work out of the box on ASUS N751/N551 laptops. This
patch fixes it. Patch tested on N751 laptop. N551 part is not tested,
but according to [1] and [2] this laptop requires similar changes, so I
included them in the patch.

1. https://github.com/honsiorovskyi/asus-n551-hda-fix
2. https://bugs.launchpad.net/ubuntu/+source/alsa-tools/+bug/1405691

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117781
Signed-off-by: Yura Pakhuchiy <pakhuchiy@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Yet another Phoneix Audio device quirk

commit 84add303ef950b8d85f54bc2248c2bc73467c329 upstream.

Phoenix Audio has yet another device with another id (even a different
vendor id, 0556:0014) that requires the same quirk for the sample
rate.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Quirk for yet another Phoenix Audio devices (v2)

commit 2d2c038a9999f423e820d89db2b5d7774b67ba49 upstream.

Phoenix Audio MT202pcs (1de7:0114) and MT202exe (1de7:0013) need the
same workaround as TMX320 for avoiding the firmware bug.  It fixes the
frequent error about the sample rate inquiries and the slow device
probe as consequence.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117321
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: testmgr - Use kmalloc memory for RSA input

commit df27b26f04ed388ff4cc2b5d8cfdb5d97678816f upstream.

As akcipher uses an SG interface, you must not use vmalloc memory
as input for it.  This patch fixes testmgr to copy the vmalloc
test vectors to kmalloc memory before running the test.

This patch also removes a superfluous sg_virt call in do_test_rsa.

Reported-by: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: hash - Fix page length clamping in hash walk

commit 13f4bb78cf6a312bbdec367ba3da044b09bf0e29 upstream.

The crypto hash walk code is broken when supplied with an offset
greater than or equal to PAGE_SIZE.  This patch fixes it by adjusting
walk->pg and walk->offset when this happens.

Reported-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: qat - fix invalid pf2vf_resp_wq logic

commit 9e209fcfb804da262e38e5cd2e680c47a41f0f95 upstream.

The pf2vf_resp_wq is a global so it has to be created at init
and destroyed at exit, instead of per device.

Tested-by: Suresh Marikkannu <sureshx.marikkannu@intel.com>
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

s390/mm: fix asce_bits handling with dynamic pagetable levels

commit 723cacbd9dc79582e562c123a0bacf8bfc69e72a upstream.

There is a race with multi-threaded applications between context switch and
pagetable upgrade. In switch_mm() a new user_asce is built from mm->pgd and
mm->context.asce_bits, w/o holding any locks. A concurrent mmap with a
pagetable upgrade on another thread in crst_table_upgrade() could already
have set new asce_bits, but not yet the new mm->pgd. This would result in a
corrupt user_asce in switch_mm(), and eventually in a kernel panic from a
translation exception.

Fix this by storing the complete asce instead of just the asce_bits, which
can then be read atomically from switch_mm(), so that it either sees the
old value or the new value, but no mixture. Both cases are OK. Having the
old value would result in a page fault on access to the higher level memory,
but the fault handler would see the new mm->pgd, if it was a valid access
after the mmap on the other thread has completed. So as worst-case scenario
we would have a page fault loop for the racing thread until the next time
slice.

Also remove dead code and simplify the upgrade/downgrade path, there are no
upgrades from 2 levels, and only downgrades from 3 levels for compat tasks.
There are also no concurrent upgrades, because the mmap_sem is held with
down_write() in do_mmap, so the flush and table checks during upgrade can
be removed.

Reported-by: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
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>

zsmalloc: fix zs_can_compact() integer overflow

commit 44f43e99fe70833058482d183e99fdfd11220996 upstream.

zs_can_compact() has two race conditions in its core calculation:

unsigned long obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) -
zs_stat_get(class, OBJ_USED);

1) classes are not locked, so the numbers of allocated and used
   objects can change by the concurrent ops happening on other CPUs
2) shrinker invokes it from preemptible context

Depending on the circumstances, thus, OBJ_ALLOCATED can become
less than OBJ_USED, which can result in either very high or
negative `total_scan' value calculated later in do_shrink_slab().

do_shrink_slab() has some logic to prevent those cases:

 vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
 vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
 vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-64
 vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
 vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62
 vmscan: shrink_slab: zs_shrinker_scan+0x0/0x28 [zsmalloc] negative objects to delete nr=-62

However, due to the way `total_scan' is calculated, not every
shrinker->count_objects() overflow can be spotted and handled.
To demonstrate the latter, I added some debugging code to do_shrink_slab()
(x86_64) and the results were:

 vmscan: OVERFLOW: shrinker->count_objects() == -1 [18446744073709551615]
 vmscan: but total_scan > 0: 92679974445502
 vmscan: resulting total_scan: 92679974445502
[..]
 vmscan: OVERFLOW: shrinker->count_objects() == -1 [18446744073709551615]
 vmscan: but total_scan > 0: 22634041808232578
 vmscan: resulting total_scan: 22634041808232578

Even though shrinker->count_objects() has returned an overflowed value,
the resulting `total_scan' is positive, and, what is more worrisome, it
is insanely huge. This value is getting used later on in
shrinker->scan_objects() loop:

        while (total_scan >= batch_size ||
               total_scan >= freeable) {
                unsigned long ret;
                unsigned long nr_to_scan = min(batch_size, total_scan);

                shrinkctl->nr_to_scan = nr_to_scan;
                ret = shrinker->scan_objects(shrinker, shrinkctl);
                if (ret == SHRINK_STOP)
                        break;
                freed += ret;

                count_vm_events(SLABS_SCANNED, nr_to_scan);
                total_scan -= nr_to_scan;

                cond_resched();
        }

`total_scan >= batch_size' is true for a very-very long time and
'total_scan >= freeable' is also true for quite some time, because
`freeable < 0' and `total_scan' is large enough, for example,
22634041808232578. The only break condition, in the given scheme of
things, is shrinker->scan_objects() == SHRINK_STOP test, which is a
bit too weak to rely on, especially in heavy zsmalloc-usage scenarios.

To fix the issue, take a pool stat snapshot and use it instead of
racy zs_stat_get() calls.

Link: http://lkml.kernel.org/r/20160509140052.3389-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ocfs2: fix posix_acl_create deadlock

commit c25a1e0671fbca7b2c0d0757d533bd2650d6dc0c upstream.

Commit 702e5bc68ad2 ("ocfs2: use generic posix ACL infrastructure")
refactored code to use posix_acl_create.  The problem with this function
is that it is not mindful of the cluster wide inode lock making it
unsuitable for use with ocfs2 inode creation with ACLs.  For example,
when used in ocfs2_mknod, this function can cause deadlock as follows.
The parent dir inode lock is taken when calling posix_acl_create ->
get_acl -> ocfs2_iop_get_acl which takes the inode lock again.  This can
cause deadlock if there is a blocked remote lock request waiting for the
lock to be downconverted.  And same deadlock happened in ocfs2_reflink.
This fix is to revert back using ocfs2_init_acl.

Fixes: 702e5bc68ad2 ("ocfs2: use generic posix ACL infrastructure")
Signed-off-by: Tariq Saeed <tariq.x.saeed@oracle.com>
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Mark Fasheh <mfasheh@suse.de>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Joseph Qi <joseph.qi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ocfs2: revert using ocfs2_acl_chmod to avoid inode cluster lock hang

commit 5ee0fbd50fdf1c1329de8bee35ea9d7c6a81a2e0 upstream.

Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
introduced this issue.  ocfs2_setattr called by chmod command holds
cluster wide inode lock when calling posix_acl_chmod.  This latter
function in turn calls ocfs2_iop_get_acl and ocfs2_iop_set_acl.  These
two are also called directly from vfs layer for getfacl/setfacl commands
and therefore acquire the cluster wide inode lock.  If a remote
conversion request comes after the first inode lock in ocfs2_setattr,
OCFS2_LOCK_BLOCKED will be set.  And this will cause the second call to
inode lock from the ocfs2_iop_get_acl() to block indefinetly.

The deleted version of ocfs2_acl_chmod() calls __posix_acl_chmod() which
does not call back into the filesystem.  Therefore, we restore
ocfs2_acl_chmod(), modify it slightly for locking as needed, and use that
instead.

Fixes: 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
Signed-off-by: Tariq Saeed <tariq.x.saeed@oracle.com>
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Mark Fasheh <mfasheh@suse.de>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Joseph Qi <joseph.qi@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/route: enforce hoplimit max value

[ Upstream commit 626abd59e51d4d8c6367e03aae252a8aa759ac78 ]

Currently, when creating or updating a route, no check is performed
in both ipv4 and ipv6 code to the hoplimit value.

The caller can i.e. set hoplimit to 256, and when such route will
 be used, packets will be sent with hoplimit/ttl equal to 0.

This commit adds checks for the RTAX_HOPLIMIT value, in both ipv4
ipv6 route code, substituting any value greater than 255 with 255.

This is consistent with what is currently done for ADVMSS and MTU
in the ipv4 code.

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: refresh skb timestamp at retransmit time

[ Upstream commit 10a81980fc47e64ffac26a073139813d3f697b64 ]

In the very unlikely case __tcp_retransmit_skb() can not use the cloning
done in tcp_transmit_skb(), we need to refresh skb_mstamp before doing
the copy and transmit, otherwise TCP TS val will be an exact copy of
original transmit.

Fixes: 7faee5c0d514 ("tcp: remove TCP_SKB_CB(skb)->when")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: thunderx: avoid exposing kernel stack

[ Upstream commit 161de2caf68c549c266e571ffba8e2163886fb10 ]

Reserved fields should be set to zero to avoid exposing
bits from the kernel stack.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: fix a kernel infoleak in x25 module

[ Upstream commit 79e48650320e6fba48369fccf13fd045315b19b8 ]

Stack object "dte_facilities" is allocated in x25_rx_call_request(),
which is supposed to be initialized in x25_negotiate_facilities.
However, 5 fields (8 bytes in total) are not initialized. This
object is then copied to userland via copy_to_user, thus infoleak
occurs.

Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

uapi glibc compat: fix compile errors when glibc net/if.h included before linux/if.h MIME-Version: 1.0

[ Upstream commit 4a91cb61bb995e5571098188092e296192309c77 ]

glibc's net/if.h contains copies of definitions from linux/if.h and these
conflict and cause build failures if both files are included by application
source code. Changes in uapi headers, which fixed header file dependencies to
include linux/if.h when it was needed, e.g. commit 1ffad83d, made the
net/if.h and linux/if.h incompatibilities visible as build failures for
userspace applications like iproute2 and xtables-addons.

This patch fixes compile errors when glibc net/if.h is included before
linux/if.h:

./linux/if.h:99:21: error: redeclaration of enumerator ‘IFF_NOARP’
./linux/if.h:98:23: error: redeclaration of enumerator ‘IFF_RUNNING’
./linux/if.h:97:26: error: redeclaration of enumerator ‘IFF_NOTRAILERS’
./linux/if.h:96:27: error: redeclaration of enumerator ‘IFF_POINTOPOINT’
./linux/if.h:95:24: error: redeclaration of enumerator ‘IFF_LOOPBACK’
./linux/if.h:94:21: error: redeclaration of enumerator ‘IFF_DEBUG’
./linux/if.h:93:25: error: redeclaration of enumerator ‘IFF_BROADCAST’
./linux/if.h:92:19: error: redeclaration of enumerator ‘IFF_UP’
./linux/if.h:252:8: error: redefinition of ‘struct ifconf’
./linux/if.h:203:8: error: redefinition of ‘struct ifreq’
./linux/if.h:169:8: error: redefinition of ‘struct ifmap’
./linux/if.h:107:23: error: redeclaration of enumerator ‘IFF_DYNAMIC’
./linux/if.h:106:25: error: redeclaration of enumerator ‘IFF_AUTOMEDIA’
./linux/if.h:105:23: error: redeclaration of enumerator ‘IFF_PORTSEL’
./linux/if.h:104:25: error: redeclaration of enumerator ‘IFF_MULTICAST’
./linux/if.h:103:21: error: redeclaration of enumerator ‘IFF_SLAVE’
./linux/if.h:102:22: error: redeclaration of enumerator ‘IFF_MASTER’
./linux/if.h:101:24: error: redeclaration of enumerator ‘IFF_ALLMULTI’
./linux/if.h:100:23: error: redeclaration of enumerator ‘IFF_PROMISC’

The cases where linux/if.h is included before net/if.h need a similar fix in
the glibc side, or the order of include files can be changed userspace
code as a workaround.

This change was tested in x86 userspace on Debian unstable with
scripts/headers_compile_test.sh:

$ make headers_install && \
  cd usr/include && ../../scripts/headers_compile_test.sh -l -k
...
cc -Wall -c -nostdinc -I /usr/lib/gcc/i586-linux-gnu/5/include -I /usr/lib/gcc/i586-linux-gnu/5/include-fixed -I . -I /home/mcfrisk/src/linux-2.6/usr/headers_compile_test_include.2uX2zH -I /home/mcfrisk/src/linux-2.6/usr/headers_compile_test_include.2uX2zH/i586-linux-gnu -o /dev/null ./linux/if.h_libc_before_kernel.h
PASSED libc before kernel test: ./linux/if.h

Reported-by: Jan Engelhardt <jengelh@inai.de>
Reported-by: Josh Boyer <jwboyer@fedoraproject.org>
Reported-by: Stephen Hemminger <shemming@brocade.com>
Reported-by: Waldemar Brodkorb <mail@waldemar-brodkorb.de>
Cc: Gabriel Laskar <gabriel@lse.epita.fr>
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bridge: fix igmp / mld query parsing

[ Upstream commit 856ce5d083e14571d051301fe3c65b32b8cbe321 ]

With the newly introduced helper functions the skb pulling is hidden
in the checksumming function - and undone before returning to the
caller.

The IGMP and MLD query parsing functions in the bridge still
assumed that the skb is pointing to the beginning of the IGMP/MLD
message while it is now kept at the beginning of the IPv4/6 header.

If there is a querier somewhere else, then this either causes
the multicast snooping to stay disabled even though it could be
enabled. Or, if we have the querier enabled too, then this can
create unnecessary IGMP / MLD query messages on the link.

Fixing this by taking the offset between IP and IGMP/MLD header into
account, too.

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: bridge: fix old ioctl unlocked net device walk

[ Upstream commit 31ca0458a61a502adb7ed192bf9716c6d05791a5 ]

get_bridge_ifindices() is used from the old "deviceless" bridge ioctl
calls which aren't called with rtnl held. The comment above says that it is
called with rtnl but that is not really the case.
Here's a sample output from a test ASSERT_RTNL() which I put in
get_bridge_ifindices and executed "brctl show":
[  957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30)
[  957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G        W  O
4.6.0-rc4+ #157
[  957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[  957.423009]  0000000000000000 ffff880058adfdf0 ffffffff8138dec5
0000000000000400
[  957.423009]  ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32
0000000000000001
[  957.423009]  00007ffec1a444b0 0000000000000400 ffff880053c19130
0000000000008940
[  957.423009] Call Trace:
[  957.423009]  [<ffffffff8138dec5>] dump_stack+0x85/0xc0
[  957.423009]  [<ffffffffa05ead32>]
br_ioctl_deviceless_stub+0x212/0x2e0 [bridge]
[  957.423009]  [<ffffffff81515beb>] sock_ioctl+0x22b/0x290
[  957.423009]  [<ffffffff8126ba75>] do_vfs_ioctl+0x95/0x700
[  957.423009]  [<ffffffff8126c159>] SyS_ioctl+0x79/0x90
[  957.423009]  [<ffffffff8163a4c0>] entry_SYSCALL_64_fastpath+0x23/0xc1

Since it only reads bridge ifindices, we can use rcu to safely walk the net
device list. Also remove the wrong rtnl comment above.

Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

VSOCK: do not disconnect socket when peer has shutdown SEND only

[ Upstream commit dedc58e067d8c379a15a8a183c5db318201295bb ]

The peer may be expecting a reply having sent a request and then done a
shutdown(SHUT_WR), so tearing down the whole socket at this point seems
wrong and breaks for me with a client which does a SHUT_WR.

Looking at other socket family's stream_recvmsg callbacks doing a shutdown
here does not seem to be the norm and removing it does not seem to have
had any adverse effects that I can see.

I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact
on the vmci transport.

Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
Cc: Andy King <acking@vmware.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Cc: Jorgen Hansen <jhansen@vmware.com>
Cc: Adit Ranadive <aditr@vmware.com>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>