CHROMIUM: v4l2-ctrls: fix s_ext_ctrls error when passing non-zero ctrl_class

due to a merge mistake in I3b80a31681765836a134812ebc56686324ca5194.

Change-Id: Iad2914518997b664704f2c2933c8327fc4252bbb
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>

clk: rockchip: rk3399: add cru regs dump for panic

Add cru and pmucru regs dump when system panic.
It's just for debug.

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

phy: rockchip-inno-usb2: support otg-port for rk3399

This patch add otg-port support. For now, however,
it only support BC1.2 charger detect, power management,
and hold a wakelock when work as SDP(e.g. connect to PC),
and it need to implement otg device/host switch in future.

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

FROMLIST: dt-bindings: add simple-panel-dsi and simple-panel

Allow user add display timing on device tree with simple-panel-dsi
or simple-panel.

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Change-Id: I95cdd8634ccd7dc2861a1ed93bcc625f0552c3a3
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9238725)

FROMLIST: drm/panel: add of display timing support

We want add display support on loader, share the same timing
with kernel side, but the timing is hide into kernel code,
can't be share, avoid config twice display timing, add device-tree
display timing support would be good idea.

With this patch, loader and kernel can share same timing from
device node.

Cc: Thierry Reding <thierry.reding@gmail.com>
Change-Id: I6c1ee6ad0194e242035e2f11589d86fdb363b80a
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9238727)

ARM: dts: rockchip: merge the hdmi-audio card with rt5640-codec card

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

ARM: configs: rockchip: enable RT5640 support for linux defconfig

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

ARM: dts: rk3288: Enable high speed on sd card on rk3288-evb

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

ARM: dts: rk3288: add missing regulator-ramp-delay for act8846

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

ARM: configs: enable dw-hdmi audio with i2s interface

Default enable CONFIG_DRM_DW_HDMI_I2S_AUDIO.

Change-Id: I317f90e622ab65aaf66c9199e070a14fd1877f13
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

ARM: dts: rk3288: add asoc simple card for DW-HDMI audio for EVB board

HDMI use the I2S0 as the audio input source, and DW-HDMI audio function
is based on generic hdmi-codec driver.

Change-Id: I6c85ffe7c214b17a3b5b319e4cd20e95a1b46398
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

FROMLIST: drm: bridge: add DesignWare HDMI I2S audio support

Current dw-hdmi is supporting sound via AHB bus, but it has
I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
This HDMI I2S is supported by using ALSA SoC common HDMI encoder
driver.

Change-Id: I32e95f66838883ac44a45f95c55583184a0a1b46
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am form https://patchwork.kernel.org/patch/9196453/)

drm/rockchip: inno_hdmi: add the missing parameter in struct hdmi_codec_ops

Commit b360d3748e ("ASoC: hdmi-codec: callback function will be called
with private data") have introduced an external parameter in struct
hdmi_codec_ops, so need to fix the old interfaces.

Change-Id: Iaebd49ba7eb7fc0d857ff8aa8f9af39ea4678143
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

FROMLIST: ASoC: hdmi-codec: callback function will be called with private data

Current hdmi-codec driver is assuming that it will be registered
from HDMI driver. Because of this assumption, each callback function
has struct device pointer which is parent device (= HDMI).
Then, it can use dev_get_drvdata() to get private data.

OTOH, on some SoC/HDMI case, SoC has VIDEO/SOUND and HDMI IPs.
This case, it needs SoC VIDEO, SoC SOUND and HDMI video, HDMI codec
driver. In DesignWare HDMI IP case, SoC VIDEO (= DRM/KMS) driver tries
to bind DesignWare HDMI video driver, and HDMI codec driver
(= hdmi-codec). This case, above "parent device" of HDMI codec driver
is DRM/KMS driver and its "device" already has private data.

And, from DT and ASoC CPU/Codec/Card binding point of view, HDMI codec
(= hdmi-codec) needs to have "parent device" (= DRM/KMS), otherwise,
it never detect sound card.

Because of these reasons, some driver can't use dev_get_drvdata() to
get private data on hdmi-codec driver. This patch add new void pointer
on hdmi_codec_pdata for private data, and callback function will be
called with it.

Change-Id: Ic7f4bb6cc06b5f7ce9a5a60f54566a780ddf1f65
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am form https://patchwork.kernel.org/patch/9196459/)

ARM64: dts: rk3399: move hdmi-sound nodes to rk3399-evb.dtsi

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

arm64: dts: rockchip: support use drm on android

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

MALI: rockchip: upgrade midgard DDK to r12p0-04rel0

Signed-off-by: chenzhen <chenzhen@rock-chips.com>
Conflicts:

drivers/gpu/arm/midgard/mali_kbase_core_linux.c

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

arm64: dts: rockchip: add touch panel gslx680 for 3399 vr board

Change-Id: I8d106b2146c01371bae8952e3926e44d86df464a
Signed-off-by: jerry.zhang <jerry.zhang@rock-chips.com>

arm64: rockchip_defconfig: add CONFIG_TOUCHSCREEN_GSLX680_VR=y

Change-Id: I9f34d60eec83ab6a8480caa5142805e5ae1f92f0
Signed-off-by: jerry.zhang <jerry.zhang@rock-chips.com>

Input: add gslx680 touch panel for 3399 VR

Change-Id: I89c3dd181324f6b39e50c40fd404743eab43fe52
Signed-off-by: jerry.zhang <jerry.zhang@rock-chips.com>

arm64: dts: rockchip: add saradc and key for 3399 VR board

Change-Id: I8f331ffc30fe900afbe669c504b96350dd4de79e
Signed-off-by: jerry.zhang <jerry.zhang@rock-chips.com>

thermal: rockchip: rk3399: enhance the tsadc's bandgap feature

Due to the voltage ripple, the sensing data of the tsadc is not accurate.
And in this patch, the bandgap feature is enhanced to remove the voltage
ripple, and then the tsadc can sense the temperature more precisely.

Obsolete codes are removed as well.

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

CHROMIUM: drm: rockchip/dw_hdmi: introduce werid audio tmds_n table

There are some rates that would be ranged for better clock jitter at
Chrome OS tree, like 25.175Mhz would range to 25.170732Mhz.

But due to the clock is aglined to KHz in struct drm_display_mode,
this would bring some inaccurate error if we still run the compute_n
math, so let's just code an const table for it until we can actually
get the right clock rate.

Change-Id: Ief14b7c9bffa95ff3b173925f3e1bd795625320d
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/316280
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>

CHROMIUM: drm: bridge/dw_hdmi: improved the hdmi audio N/CTS cacluate math

The original math would bring some inaccurate to N/CTS that would
caused those magic number won't fit the HDMI 1.4 Spec request:
128 * SampleRate = Tmds * N / CTS;

So this time we try to improved to math of N that would find the
minimal inaccurate with the HDMI 1.4 Spec.

Change-Id: Ied3cde3c352d955ae6f15d5e7fb172e92316c2a5
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/315424
Reviewed-by: Douglas Anderson <dianders@chromium.org>

CHROMIUM: drm: rockchip/dw_hdmi-rockchip: Fixup the clock to be what we expect

We allow some amount of slop in dw_hdmi_rockchip_mode_valid().  That's
a good thing since allowing a little bit of slop lets us support a
bunch of extra resolutions.

Originally, we also made a change to the VOP code to add the concept
of slop in there.  That was reasonable, but there was a problem: it
would tend to request clock rates that weren't _exactly_ clock rates
that we thought about.  It's possible that the common clock framework
would map these to PLL rates that we haven't thought about and we
haven't tested for jitter.

Instead of changing VOP, we should probably adjust the clock ourselves
in the mode_fixup function.  That way we'll request the exact clock we
tested and we'll know how the common clock framework will map it.

Change-Id: I56c2b046f76d554aab5eaed7a6b171ea074d6a62
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/284376
Reviewed-by: Alexandru Stan <amstan@chromium.org>

CHROMIUM: drm: rockchip/dw_hdmi-rockchip: Protect against > 2GHz pixel clocks

Add a check just to make sure that someone doesn't try to give us a
pixel clock that is > 2GHz.  If they did that, some of our math might
overflow, so it's good to make sure we don't do it.

Change-Id: I451602f0d771bb16b399b43e376e1054b7ee060f
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/284642
Reviewed-by: Alexandru Stan <amstan@chromium.org>

CHROMIUM: drm: rockchip/dw_hdmi-rockchip: refactor the mode table

This cleanup will allow the following patch to implement slop easier.

25175000-40000000 and a few other ranges use the same settings.
And the rest of the driver already snaps to the next highest
frequency when it gets the settings. So this patch removes
a lot of the duplicates. It should be a noop change.

And frequencies within 0.1% should be close enough, let's redo
rockchip hdmi to allow slop.

Change-Id: Ic4865b2825de9b6c3b3e8d029066a8964e8ede6b
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

media: rockchip-vpu: fix compiled warning about uninitialized 'ret'

rockchip_vpu_hw.c:251:5: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]

Change-Id: Ia5564c2da345c5922341b818961b18d2b1419013
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

ARM64: dts: rk3399: modify i2s node in rk3399-evb.dtsi

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

phy: rockchip-emmc: enable internal pull-down for strobe line

We enable it by default as we could see the usage of PCB layout
will not stuff this registor. For currently boards which soldered
it already, there should be no harmful.

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

UPSTREAM: ASoC: rt5616: add missing mute control for HPVOL

Add missing kcontrol for HPVOL mute control.

Signed-off-by: John Lin <john.lin@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 25923642

(cherry picked from git.kernel.org broonie/sound.git for-next
 commit d7fcd13663fe43ad938fec1acd46ff196dddf914)
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: I75951c4b67474951e6c033e0dece5134c51dc233
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ASoC: rt5616: Add support sample rate to 192KHz

Reference the TRM, the ALC5616 support one 24bit/8KHz ~ 192KHz
I2S/PCM Interface for stereo DAC and stereo ADC.

Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 27307957
Patchset: fetch the upstream ASoC for rk3036 kylin board.

(cherry picked from git.kernel.org broonie/sound.git for-next
 commit 4e26ad80cbd3a6b0d606201892e81a9a9c6864ce)
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: I1751e2c663689d4a45cd94d609c0b61d1ac9237b
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ASoC: rt5616: add the mclk for the codec driver

This patch adds the code to enable the clock to the CODEC driver
if it needs the clock enabled.

In some case, We need to claim the clock which is driving the codec
so that when we enable clock gating, we continue to clock the codec
when needed.

if mclk provided, to enable and disable the clock source.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 27307957
Patchset: fetch the upstream ASoC for rk3036 kylin board.

(cherry picked from git.kernel.org broonie/sound.git for-next
 commit 76d3204eaa9364a662f0fe0f075dfe61e6bd14fe)
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: Iaa1b07a1ff729f3b84c1e32cd0fdd0f36d9a8889
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ASoC: rt5616: trivial: fix the typo

This patch try to fix the trivial typo.

Run "scripts/checkpatch.pl -f --subjective xxx"
The enable more subjective tests.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 27307957
Patchset: fetch the upstream ASoC for rk3036 kylin board.
(Note: match the Kconfig for rt5616)

(cherry picked friom git.kernel.org broonie/sound.git for-next
 commit 99081589c5ad590e9828ae9febc384612f241164)
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: Ied09a6f69a7364daa68309fa9a0a4cd2e4a368e6
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ASoC: rt5616: rename some alsa control names

Rename some alsa control name as what they should be.

Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 25923642
Patchset: rt5616 audio

(cherry picked from broonie/sound.git#for-next e2133b64820df302a8e3d00c7531018470cd63a9)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I1d81031ddbe7ce5c38602c38ab643f893f436ef0
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ASoC: rt5616: add an of_match table

Add a device tree match table. This serves to make the driver's support
of device tree more explicit.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 25923642
Patchset: rt5616 audio

(cherry picked from broonie/sound.git#for-next e17ff2de826f8c2153cf23c8bbd9097219a84fa9)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I7ee1967a3cdf9583942c0d75b5e4d0125d31cd0c
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ASoC: rt5616: Return error if device ID mismatch

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 25923642
Patchset: rt5616 audio

(cherry picked from broonie/sound.git#for-next 36ddd489b0669f8913c8eda192507f8267749917)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I55e15dfb42bf5022a976451311214980c4897aa5
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ASoC: rt5616: add rt5616 codec driver

This is the initial codec driver for rt5616.

Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 25923642
Patchset: rt5616 audio

(cherry picked from broonie/sound.git#for-next b1d15059957d33d111e0ed38724a6b2c5caac790)
Signed-off-by: Kees Cook <keescook@chromium.org>
Change-Id: I17f99e549cb59a3788b257f63e51a84b3e9d4162
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

sound: rockchip: remove rk's 5616 code

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

ARM: configs: rokchip: enable RT5616 support for linux defconfig

Quick way to test rt5616 on RK3036 Kylin board, you need bellow
commands:
  tinymix "HP Playback Switch" 1
  tinymix "HPVOL Playback Switch" 1
  tinymix "HP Playback Volume" 10
  tinymix "HPO MIX HPVOL Switch" 1
  tinymix "OUT MIXR DAC R1 Switch" 1
  tinymix "OUT MIXL DAC L1 Switch" 1
  tinymix "Stereo DAC MIXR DAC R1 Switch" 1
  tinymix "Stereo DAC MIXL DAC L1 Switch" 1

Test command:
root@linaro-alip:~#  aplay -D plughw:CARD=rockchiprt5616c,DEV=0 /opt/Third_Eye.wav

Change-Id: Ic4d44ed1a373869d5e0e670701b06f58f0e6399c
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

ARM: dts: rockchip: merge the hdmi-audio card with rt5616-codec card

Change-Id: I2888cbb7df9d4cd9d270f7fd81f34b27b40997cc
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

drm/rockchip: select hdmi codec when enable inno_hdmi

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

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

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

 This is the 4.4.15 stable release

arm64: dts: rockchip: add usb typec phy node for rk3399

Change-Id: I0313f7812bad02136abbd8868a201cf4409620d6
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>

drm/rockchip: dw-mipi: add dw-mipi power domain support

Reference the power domain incase dw-mipi power down when
in use.

Change-Id: I54a0f418f20299a744f87c1337f06ff3341dfac5
Signed-off-by: Chris Zhong <zyw@rock-chips.com>

arm64: dts: rockchip: add HDMI device node for RK3399

Change-Id: Ibfdf59eed0f055900d9409f6ceab20d0ec8f480c
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

arm64: dts: rockchip: rk3399-evb: merge common part

dtbs is same as before.

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

video: rockchip: 3399 vop: add support DP output and YUV422 output mode

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

video: rockchip: fb: add DP and yuv422 define

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

video: rockchip: vop: 3399: fix polarity config error

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

video: rockchip: fb: no need close all win when hdmi switch screen at first time

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

ARM64: dts: rk3399-box-808-android: add disp policy for box product

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

drm/rockchip: gem: import dma_buf to gem

We want to display a buffer allocated by other driver, need import
the buffer to gem.

Change-Id: Ifd5fef3fbf2b4daea6d624ed2a250c2fe626309d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

power_supply: Add new type for USB chargers

This adds a power supply type for special USB charger,
this kind of USB charger is similar to Dedicated Charging
Port, but not a standard DCP because of D+/D- not short.

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

arm64: dts: rockchip: add u2phy0 and u2phy0_otg node for rk3399

RK3399 SoC usb2 PHY comprises with one host-port and
one otg-port, we support otg-port for the time being.

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

FROMLIST: drm/rockchip: dw_hdmi: introduce the pclk for grf

For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.

Change-Id: I8f43e5c46c8559d6b6fe96a12cd026319b1d84e5
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223317/)

FROMLIST: drm/rockchip: dw_hdmi: introduce the VPLL clock setting

For RK3399 HDMI, there is an external clock need for HDMI PHY,
and it should keep the same clock rate with VOP DCLK.

VPLL have supported the clock for HDMI PHY, but there is no
clock divider bewteen VPLL and HDMI PHY. So we need to set the
VPLL rate manually in HDMI driver.

Change-Id: I73abc382ff43bfa93d150c3449693f207029549f
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223327/)

FROMLIST: drm/rockchip: dw_hdmi: add RK3399 HDMI support

RK3399 and RK3288 shared the same HDMI IP controller, only some light
difference with GRF configure.

Change-Id: Ic404ff3df6004a87b709f00552d91eb546c78450
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223315/)

FROMLIST: drm/rockchip: dw_hdmi: Use auto-generated tables

The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor.  Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (not that we use those anyway).  It was also always a lot of
extra work every time we wanted to add a new clock rate since we had
to cross-reference several tables.

In <http://crosreview.com/285855> I've gone through the work to figure
out how to generate this table automatically.  Let's now use the
automatically generated table and then we'll never need to look at it
again.

We only support 8-bit mode right now and only support a small number
of clock rates and and I've verified that the only 8-bit rate that was
affected was 148.5.  That mode appears to have been wrong in the old
table.

Change-Id: I42b260300880f2bab6732c5ee3b11bc78e87500c
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
(am from https://patchwork.kernel.org/patch/9223325)

FROMLIST: drm/rockchip: dw_hdmi: adjust cklvl & txlvl for RF/EMI

Dut to the high HDMI signal voltage driver, Mickey have meet
a serious RF/EMI problem, so we decided to reduce HDMI signal
voltage to a proper value.

The default params for phy is cklvl = 20 & txlvl = 13 (RF/EMI failed)
  ck: lvl = 13, term=100, vlo = 2.71, vhi=3.14, vswing = 0.43
  tx: lvl = 20, term=100, vlo = 2.81, vhi=3.16, vswing = 0.35

1. We decided to reduce voltage value to lower, but VSwing still
keep high, RF/EMI have been improved but still failed.
   ck: lvl =  6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50
   tx: lvl =  6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50

2. We try to keep voltage value and vswing both lower, then RF/EMI
test all passed  ;)
   ck: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
   tx: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
When we back to run HDMI different test and single-end test, we see
different test passed, but signle-end test failed. The oscilloscope
show that simgle-end clock's VL value is 1.78v (which remind LowLimit
should not lower then 2.6v).

3. That's to say there are some different between PHY document and
measure value. And according to experiment 2 results, we need to
higher clock voltage and lower data voltage, then we can keep RF/EMI
satisfied and single-end & differen test passed.
  ck: lvl =  9, term=100, vlo = 2.65, vhi=3.12, vswing = 0.47
  tx: lvl = 16, term=100, vlo = 2.75, vhi=3.15, vswing = 0.39

Change-Id: I766df9ad519ddddb9be76f95fbbdb36c5a2d6e51
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
(am from https://patchwork.kernel.org/patch/9223303/)

FROMLIST: drm/rockchip: dw_hdmi: Set cur_ctr to 0 always

Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL.  In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin.  We believe that
lowering the bandwidth like this is safe given sufficient testing.

Change-Id: Ife266747f0e6ed46f914f4868362fefc481440f9
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223301/)

ARM: dts: rockchip: add sdmmc for rk3288 fennec

Add sdmmc dts nodes support for RK3288-Fennec boards

Change-Id: I6e62da8ef84a7c5a492f54448fc7261ff87432bf
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

ARM: config: add the rockchip_linux_defconfig for rockchip

Add the config for rockchip SoCs with ubuntu os, the most of SoCs will be supported
for this config. (e.g: rk3036. rk3288....)

Change-Id: Ia781de208ccaad7a95b6a325fce97db5e588fafa
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

video: rockchip: hdmi: set default color depth to 8bit

Change-Id: I2e4f8d9f980c4169e254ad56793503f76f091e7f
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 34468c2b30ae361ded2a8867e478c972bb5de5a6)

video: rockchip: hdmi: fix current color mode and depth info

If current color mode and depth is auto, information in sysfs
node is equal to zero, is not responsed to actual mode and
depth, now fix it.

Change-Id: Ifd2888b2af5522a026be92071d98d6bc081d02db
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit c2cac5c2cff8464ab4ba2c2638a84d997aa0365e)

arm64: dts: rockchip: enable isp0 and isp1 for rk3399 mid board

Change-Id: Ib4404a2af7309200d48e7beeede4f237ee03d455
Signed-off-by: Yankun Zheng <zyk@rock-chips.com>

arm64: dts: rockchip: add sensors config for rk3399 mid board

Change-Id: Ib97f1802ea14fb0d5fcb043325733f4d58e1188a
Signed-off-by: Zorro Liu <lyx@rock-chips.com>

ARM64: dts: rockchip: add sensor mpu6500 node for rk3399 mid board

Change-Id: If78d74fccf3195e3e81b91dc6d5981929ca16319
Signed-off-by: Zorro Liu <lyx@rock-chips.com>

ARM64: rockchip_defconfig: enable isp driver

Change-Id: I5025d6301a3f1ec7f6b3e243777216493e77ec9c
Signed-off-by: Yankun Zheng <zyk@rock-chips.com>

ARM64: rockchip_defconfig: enable sensors devices

Change-Id: I75f4893ffa0842915138b3de7d29afc6ef35e2fc
Signed-off-by: Zorro Liu <lyx@rock-chips.com>

driver, sensors: fix compile err

Change-Id: Ice9e31086b29a20e37bf5ba3bf08d1e77a9a36a3
Signed-off-by: Zorro Liu <lyx@rock-chips.com>

driver, sensors, ak8963: modify for new 64bit akm hal

Change-Id: Idd84d215eaeeec24b687c632189ef1fbbafbbf22
Signed-off-by: Zorro Liu <lyx@rock-chips.com>

drivers, input: add sensors to compile

Change-Id: I7227ab9d989df3adef73883f7be2860d1742c225
Signed-off-by: Zorro Liu <lyx@rock-chips.com>

Linux 4.4.15

usb: dwc3: exynos: Fix deferred probing storm.

commit 4879efb34f7d49235fac334d76d9c6a77a021413 upstream.

dwc3-exynos has two problems during init if the regulators are slow
to come up (for instance if the I2C bus driver is not on the initramfs)
and return probe deferral. First, every time this happens, the driver
leaks the USB phys created; they need to be deallocated on error.

Second, since the phy devices are created before the regulators fail,
this means that there's a new device to re-trigger deferred probing,
which causes it to essentially go into a busy loop of re-probing the
device until the regulators come up.

Move the phy creation to after the regulators have succeeded, and also
fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs
which doesn't contain the I2C driver), this reduces the number of probe
attempts (for each of the two controllers) from more than 2000 to eight.

Signed-off-by: Steinar H. Gunderson <sesse@google.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Vivek Gautam <gautam.vivek@samsung.com>
Fixes: d720f057fda4 ("usb: dwc3: exynos: add nop transceiver support")
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: host: ehci-tegra: Grab the correct UTMI pads reset

commit f8a15a9650694feaa0dabf197b0c94d37cd3fb42 upstream.

There are three EHCI controllers on Tegra SoCs, each with its own reset
line. However, the first controller contains a set of UTMI configuration
registers that are shared with its siblings. These registers will only
be reset as part of the first controller's reset. For proper operation
it must be ensured that the UTMI configuration registers are reset
before any of the EHCI controllers are enabled, irrespective of the
probe order.

Commit a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to
broken USB") introduced code that ensures the first controller is always
reset before setting up any of the controllers, and is never again reset
afterwards.

This code, however, grabs the wrong reset. Each EHCI controller has two
reset controls attached: 1) the USB controller reset and 2) the UTMI
pads reset (really the first controller's reset). In order to reset the
UTMI pads registers the code must grab the second reset, but instead it
grabbing the first.

Fixes: a47cc24cd1e5 ("USB: EHCI: tegra: Fix probe order issue leading to broken USB")
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: fix spinlock dead lock in gadgetfs

commit d246dcb2331c5783743720e6510892eb1d2801d9 upstream.

[   40.467381] =============================================
[   40.473013] [ INFO: possible recursive locking detected ]
[   40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted
[   40.483466] ---------------------------------------------
[   40.489098] usb/733 is trying to acquire lock:
[   40.493734]  (&(&dev->lock)->rlock){-.....}, at: [<bf129288>] ep0_complete+0x18/0xdc [gadgetfs]
[   40.502882]
[   40.502882] but task is already holding lock:
[   40.508967]  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
[   40.517811]
[   40.517811] other info that might help us debug this:
[   40.524623]  Possible unsafe locking scenario:
[   40.524623]
[   40.530798]        CPU0
[   40.533346]        ----
[   40.535894]   lock(&(&dev->lock)->rlock);
[   40.540088]   lock(&(&dev->lock)->rlock);
[   40.544284]
[   40.544284]  *** DEADLOCK ***
[   40.544284]
[   40.550461]  May be due to missing lock nesting notation
[   40.550461]
[   40.557544] 2 locks held by usb/733:
[   40.561271]  #0:  (&f->f_pos_lock){+.+.+.}, at: [<c02a6114>] __fdget_pos+0x40/0x48
[   40.569219]  #1:  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
[   40.578523]
[   40.578523] stack backtrace:
[   40.583075] CPU: 0 PID: 733 Comm: usb Not tainted 4.6.0-08691-g7f3db9a #37
[   40.590246] Hardware name: Generic AM33XX (Flattened Device Tree)
[   40.596625] [<c010ffbc>] (unwind_backtrace) from [<c010c1bc>] (show_stack+0x10/0x14)
[   40.604718] [<c010c1bc>] (show_stack) from [<c04207fc>] (dump_stack+0xb0/0xe4)
[   40.612267] [<c04207fc>] (dump_stack) from [<c01886ec>] (__lock_acquire+0xf68/0x1994)
[   40.620440] [<c01886ec>] (__lock_acquire) from [<c0189528>] (lock_acquire+0xd8/0x238)
[   40.628621] [<c0189528>] (lock_acquire) from [<c06ad6b4>] (_raw_spin_lock_irqsave+0x38/0x4c)
[   40.637440] [<c06ad6b4>] (_raw_spin_lock_irqsave) from [<bf129288>] (ep0_complete+0x18/0xdc [gadgetfs])
[   40.647339] [<bf129288>] (ep0_complete [gadgetfs]) from [<bf10a728>] (musb_g_giveback+0x118/0x1b0 [musb_hdrc])
[   40.657842] [<bf10a728>] (musb_g_giveback [musb_hdrc]) from [<bf108768>] (musb_g_ep0_queue+0x16c/0x188 [musb_hdrc])
[   40.668772] [<bf108768>] (musb_g_ep0_queue [musb_hdrc]) from [<bf12a944>] (ep0_read+0x544/0x5e0 [gadgetfs])
[   40.678963] [<bf12a944>] (ep0_read [gadgetfs]) from [<c0284470>] (__vfs_read+0x20/0x110)
[   40.687414] [<c0284470>] (__vfs_read) from [<c0285324>] (vfs_read+0x88/0x114)
[   40.694864] [<c0285324>] (vfs_read) from [<c0286150>] (SyS_read+0x44/0x9c)
[   40.702051] [<c0286150>] (SyS_read) from [<c0107820>] (ret_fast_syscall+0x0/0x1c)

This is caused by the spinlock bug in ep0_read().
Fix the two other deadlock sources in gadgetfs_setup() too.

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: mos7720: delete parport

commit dcb21ad4385731b7fc3ef39d255685f2f63c8c5d upstream.

parport subsystem has introduced parport_del_port() to delete a port
when it is going away. Without parport_del_port() the registered port
will not be unregistered.
To reproduce and verify the error:
Command to be used is : ls /sys/bus/parport/devices
1) without the device attached there is no output as there is no
registered parport.
2) Attach the device, and the command will show "parport0".
3) Remove the device and the command still shows "parport0".
4) Attach the device again and we get "parport1".

With the patch applied:
1) without the device attached there is no output as there is no
registered parport.
2) Attach the device, and the command will show "parport0".
3) Remove the device and there is no output as "parport0" is now
removed.
4) Attach device again to get "parport0" again.

Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Fix handling timeouted commands on hosts in weird states.

commit 3425aa03f484d45dc21e0e791c2f6c74ea656421 upstream.

If commands timeout we mark them for abortion, then stop the command
ring, and turn the commands to no-ops and finally restart the command
ring.

If the host is working properly the no-op commands will finish and
pending completions are called.
If we notice the host is failing, driver clears the command ring and
completes, deletes and frees all pending commands.

There are two separate cases reported where host is believed to work
properly but is not. In the first case we successfully stop the ring
but no abort or stop command ring event is ever sent and host locks up.

The second case is if a host is removed, command times out and driver
believes the ring is stopped, and assumes it will be restarted, but
actually ends up timing out on the same command forever.
If one of the pending commands has the xhci->mutex held it will block
xhci_stop() in the remove codepath which otherwise would cleanup pending
commands.

Add a check that clears all pending commands in case host is removed,
or we are stuck timing out on the same command. Also restart the
command timeout timer when stopping the command ring to ensure we
recive an ring stop/abort event.

Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: xhci: Add broken streams quirk for Frescologic device id 1009

commit d95815ba6a0f287213118c136e64d8c56daeaeab upstream.

I got one of these cards for testing uas with, it seems that with streams
it dma-s all over the place, corrupting memory. On my first tests it
managed to dma over the BIOS of the motherboard somehow and completely
bricked it.

Tests on another motherboard show that it does work with streams disabled.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: xhci-plat: properly handle probe deferral for devm_clk_get()

commit de95c40d5beaa47f6dc8fe9ac4159b4672b51523 upstream.

On some platforms, the clocks might be registered by a platform
driver. When this is the case, the clock platform driver may very well
be probed after xhci-plat, in which case the first probe() invocation
of xhci-plat will receive -EPROBE_DEFER as the return value of
devm_clk_get().

The current code handles that as a normal error, and simply assumes
that this means that the system doesn't have a clock for the XHCI
controller, and continues probing without calling
clk_prepare_enable(). Unfortunately, this doesn't work on systems
where the XHCI controller does have a clock, but that clock is
provided by another platform driver. In order to fix this situation,
we handle the -EPROBE_DEFER error condition specially, and abort the
XHCI controller probe(). It will be retried later automatically, the
clock will be available, devm_clk_get() will succeed, and the probe()
will continue with the clock prepared and enabled as expected.

In practice, such issue is seen on the ARM64 Marvell 7K/8K platform,
where the clocks are registered by a platform driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Cleanup only when releasing primary hcd

commit 27a41a83ec54d0edfcaf079310244e7f013a7701 upstream.

Under stress occasions some TI devices might not return early when
reading the status register during the quirk invocation of xhci_irq made
by usb_hcd_pci_remove.  This means that instead of returning, we end up
handling this interruption in the middle of a shutdown.  Since
xhci->event_ring has already been freed in xhci_mem_cleanup, we end up
accessing freed memory, causing the Oops below.

commit 8c24d6d7b09d ("usb: xhci: stop everything on the first call to
xhci_stop") is the one that changed the instant in which we clean up the
event queue when stopping a device.  Before, we didn't call
xhci_mem_cleanup at the first time xhci_stop is executed (for the shared
HCD), instead, we only did it after the invocation for the primary HCD,
much later at the removal path.  The code flow for this oops looks like
this:

xhci_pci_remove()
usb_remove_hcd(xhci->shared)
        xhci_stop(xhci->shared)
  xhci_halt()
xhci_mem_cleanup(xhci);  // Free the event_queue
usb_hcd_pci_remove(primary)
xhci_irq()  // Access the event_queue if STS_EINT is set. Crash.
xhci_stop()
xhci_halt()
// return early

The fix modifies xhci_stop to only cleanup the xhci data when releasing
the primary HCD.  This way, we still have the event_queue configured
when invoking xhci_irq.  We still halt the device on the first call to
xhci_stop, though.

I could reproduce this issue several times on the mainline kernel by
doing a bind-unbind stress test with a specific storage gadget attached.
I also ran the same test over-night with my patch applied and didn't
observe the issue anymore.

[  113.334124] Unable to handle kernel paging request for data at address 0x00000028
[  113.335514] Faulting instruction address: 0xd00000000d4f767c
[  113.336839] Oops: Kernel access of bad area, sig: 11 [#1]
[  113.338214] SMP NR_CPUS=1024 NUMA PowerNV

[c000000efe47ba90] c000000000720850 usb_hcd_irq+0x50/0x80
[c000000efe47bac0] c00000000073d328 usb_hcd_pci_remove+0x68/0x1f0
[c000000efe47bb00] d00000000daf0128 xhci_pci_remove+0x78/0xb0
[xhci_pci]
[c000000efe47bb30] c00000000055cf70 pci_device_remove+0x70/0x110
[c000000efe47bb70] c00000000061c6bc __device_release_driver+0xbc/0x190
[c000000efe47bba0] c00000000061c7d0 device_release_driver+0x40/0x70
[c000000efe47bbd0] c000000000619510 unbind_store+0x120/0x150
[c000000efe47bc20] c0000000006183c4 drv_attr_store+0x64/0xa0
[c000000efe47bc60] c00000000039f1d0 sysfs_kf_write+0x80/0xb0
[c000000efe47bca0] c00000000039e14c kernfs_fop_write+0x18c/0x1f0
[c000000efe47bcf0] c0000000002e962c __vfs_write+0x6c/0x190
[c000000efe47bd90] c0000000002eab40 vfs_write+0xc0/0x200
[c000000efe47bde0] c0000000002ec85c SyS_write+0x6c/0x110
[c000000efe47be30] c000000000009260 system_call+0x38/0x108

Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: joel@jms.id.au
Reviewed-by: Roger Quadros <rogerq@ti.com>
Tested-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: host: correct cppi dma channel for isoch transfer

commit 04471eb8c3158c0ad9df4b24da845a63b2e8f23a upstream.

Incorrect cppi dma channel is referenced in musb_rx_dma_iso_cppi41(),
which causes kernel NULL pointer reference oops later when calling
cppi41_dma_channel_program().

Fixes: 069a3fd (usb: musb: Remove ifdefs for musb_host_rx in musb_host.c
part1)

Reported-by: Matwey V. Kornilov <matwey@sai.msu.ru>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: Ensure rx reinit occurs for shared_fifo endpoints

commit f3eec0cf784e0d6c47822ca6b66df3d5812af7e6 upstream.

shared_fifo endpoints would only get a previous tx state cleared
out, the rx state was only cleared for non shared_fifo endpoints
Change this so that the rx state is cleared for all endpoints.
This addresses an issue that resulted in rx packets being dropped
silently.

Signed-off-by: Andrew Goodbody <andrew.goodbody@cambrionix.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: Stop bulk endpoint while queue is rotated

commit 7b2c17f829545df27a910e8d82e133c21c9a8c9c upstream.

Ensure that the endpoint is stopped by clearing REQPKT before
clearing DATAERR_NAKTIMEOUT before rotating the queue on the
dedicated bulk endpoint.
This addresses an issue where a race could result in the endpoint
receiving data before it was reprogrammed resulting in a warning
about such data from musb_rx_reinit before it was thrown away.
The data thrown away was a valid packet that had been correctly
ACKed which meant the host and device got out of sync.

Signed-off-by: Andrew Goodbody <andrew.goodbody@cambrionix.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: only restore devctl when session was set in backup

commit 84ac5d1140f716a616522f952734e850448d2556 upstream.

If the session bit was not set in the backup of devctl register,
restoring devctl would clear the session bit. Therefor, only restore
devctl register when the session bit was set in the backup.

This solves the device enumeration failure in otg mode exposed by commit
56f487c (PM / Runtime: Update last_busy in rpm_resume).

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: quirks: Add no-lpm quirk for Acer C120 LED Projector

commit 32cb0b37098f4beeff5ad9e325f11b42a6ede56c upstream.

The Acer C120 LED Projector is a USB-3 connected pico projector which
takes both its power and video data from USB-3.

In combination with some hubs this device does not play well with
lpm, so disable lpm for it.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: quirks: Fix sorting

commit 81099f97bd31e25ff2719a435b1860fc3876122f upstream.

Properly sort all the entries by vendor id.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: uas: Fix slave queue_depth not being set

commit 593224ea77b1ca842f45cf76f4deeef44dfbacd1 upstream.

Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level")
removed the scsi_change_queue_depth() call from uas_slave_configure()
assuming that the slave would inherit the host's queue_depth, which
that commit sets to the same value.

This is incorrect, without the scsi_change_queue_depth() call the slave's
queue_depth defaults to 1, introducing a performance regression.

This commit restores the call, fixing the performance regression.

Fixes: 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level")
Reported-by: Tom Yan <tom.ty89@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: user - re-add size check for CRYPTO_MSG_GETALG

commit 055ddaace03580455a7b7dbea8e93d62acee61fc upstream.

Commit 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG")
accidentally removed the minimum size check for CRYPTO_MSG_GETALG
netlink messages. This allows userland to send a truncated
CRYPTO_MSG_GETALG message as short as a netlink header only making
crypto_report() operate on uninitialized memory by accessing data
beyond the end of the netlink message.

Fix this be re-adding the minimum required size of CRYPTO_MSG_GETALG
messages to the crypto_msg_min[] array.

Fixes: 9aa867e46565 ("crypto: user - Add CRYPTO_MSG_DELRNG")
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: 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: ux500 - memmove the right size

commit 19ced623db2fe91604d69f7d86b03144c5107739 upstream.

The hash buffer is really HASH_BLOCK_SIZE bytes, someone
must have thought that memmove takes n*u32 words by mistake.
Tests work as good/bad as before after this patch.

Cc: Joakim Bech <joakim.bech@linaro.org>
Reported-by: David Binderman <linuxdev.baldrick@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: vmx - Increase priority of aes-cbc cipher

commit 12d3f49e1ffbbf8cbbb60acae5a21103c5c841ac upstream.

All of the VMX AES ciphers (AES, AES-CBC and AES-CTR) are set at
priority 1000. Unfortunately this means we never use AES-CBC and
AES-CTR, because the base AES-CBC cipher that is implemented on
top of AES inherits its priority.

To fix this, AES-CBC and AES-CTR have to be a higher priority. Set
them to 2000.

Testing on a POWER8 with:

cryptsetup benchmark --cipher aes --key-size 256

Shows decryption speed increase from 402.4 MB/s to 3069.2 MB/s,
over 7x faster. Thanks to Mike Strosaker for helping me debug
this issue.

Fixes: 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module")
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

AX.25: Close socket connection on session completion

[ Upstream commit 4a7d99ea1b27734558feb6833f180cd38a159940 ]

A socket connection made in ax.25 is not closed when session is
completed.  The heartbeat timer is stopped prematurely and this is
where the socket gets closed. Allow heatbeat timer to run to close
socket. Symptom occurs in kernels >= 4.2.0

Originally sent 6/15/2016. Resend with distribution list matching
scripts/maintainer.pl output.

Signed-off-by: Basil Gunn <basil@pacabunga.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf: try harder on clones when writing into skb

[ Upstream commit 3697649ff29e0f647565eed04b27a7779c646a22 ]

When we're dealing with clones and the area is not writeable, try
harder and get a copy via pskb_expand_head(). Replace also other
occurences in tc actions with the new skb_try_make_writable().

Reported-by: Ashhad Sheikh <ashhadsheikh394@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: alx: Work around the DMA RX overflow issue

[ Upstream commit 881d0327db37ad917a367c77aff1afa1ee41e0a9 ]

Note: This is a verified backported patch for stable 4.4 kernel, and it
could also be applied to 4.3/4.2/4.1/3.18/3.16

There is a problem with alx devices, that the network link will be
lost in 1-5 minutes after the device is up.

>From debugging without datasheet, we found the error always
happen when the DMA RX address is set to 0x....fc0, which is very
likely to be a HW/silicon problem.

This patch will apply rx skb with 64 bytes longer space, and if the
allocated skb has a 0x...fc0 address, it will use skb_resever(skb, 64)
to advance the address, so that the RX overflow can be avoided.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70761
Signed-off-by: Feng Tang <feng.tang@intel.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Tested-by: Ole Lukoie <olelukoie@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: macb: fix default configuration for GMAC on AT91

[ Upstream commit 6bdaa5e9ed39b3b3328f35d218e8ad5a99cfc4d2 ]

On AT91 SoCs, the User Register (USRIO) exposes a switch to configure the
"Reduced" or "Traditional" version of the Media Independent Interface
(RMII vs. MII or RGMII vs. GMII).
As on the older EMAC version, on GMAC, this switch is set by default to the
non-reduced type of interface, so use the existing capability and extend it to
GMII as well. We then keep the current logic in the macb_init() function.

The capabilities of sama5d2, sama5d4 and sama5d3 GEM interface are updated in
the macb_config structure to be able to properly enable them with a traditional
interface (GMII or MII).

Reported-by: Romain HENRIET <romain.henriet@l-acoustics.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[cyrille.pitchen@atmel.com: backported to 4.4.y]
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

neigh: Explicitly declare RCU-bh read side critical section in neigh_xmit()

[ Upstream commit b560f03ddfb072bca65e9440ff0dc4f9b1d1f056 ]

neigh_xmit() expects to be called inside an RCU-bh read side critical
section, and while one of its two current callers gets this right, the
other one doesn't.

More specifically, neigh_xmit() has two callers, mpls_forward() and
mpls_output(), and while both callers call neigh_xmit() under
rcu_read_lock(), this provides sufficient protection for neigh_xmit()
only in the case of mpls_forward(), as that is always called from
softirq context and therefore doesn't need explicit BH protection,
while mpls_output() can be called from process context with softirqs
enabled.

When mpls_output() is called from process context, with softirqs
enabled, we can be preempted by a softirq at any time, and RCU-bh
considers the completion of a softirq as signaling the end of any
pending read-side critical sections, so if we do get a softirq
while we are in the part of neigh_xmit() that expects to be run inside
an RCU-bh read side critical section, we can end up with an unexpected
RCU grace period running right in the middle of that critical section,
making things go boom.

This patch fixes this impedance mismatch in the callee, by making
neigh_xmit() always take rcu_read_{,un}lock_bh() around the code that
expects to be treated as an RCU-bh read side critical section, as this
seems a safer option than fixing it in the callers.

Fixes: 4fd3d7d9e868f ("neigh: Add helper function neigh_xmit")
Signed-off-by: David Barroso <dbarroso@fastly.com>
Signed-off-by: Lennert Buytenhek <lbuytenhek@fastly.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: Robert Shearman <rshearma@brocade.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bpf, perf: delay release of BPF prog after grace period

[ Upstream commit ceb56070359b7329b5678b5d95a376fcb24767be ]

Commit dead9f29ddcc ("perf: Fix race in BPF program unregister") moved
destruction of BPF program from free_event_rcu() callback to __free_event(),
which is problematic if used with tail calls: if prog A is attached as
trace event directly, but at the same time present in a tail call map used
by another trace event program elsewhere, then we need to delay destruction
via RCU grace period since it can still be in use by the program doing the
tail call (the prog first needs to be dropped from the tail call map, then
trace event with prog A attached destroyed, so we get immediate destruction).

Fixes: dead9f29ddcc ("perf: Fix race in BPF program unregister")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Cc: Jann Horn <jann@thejh.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sock_diag: do not broadcast raw socket destruction

[ Upstream commit 9a0fee2b552b1235fb1706ae1fc664ae74573be8 ]

Diag intends to broadcast tcp_sk and udp_sk socket destruction.
Testing sk->sk_protocol for IPPROTO_TCP/IPPROTO_UDP alone is not
sufficient for this. Raw sockets can have the same type.

Add a test for sk->sk_type.

Fixes: eb4cb008529c ("sock_diag: define destruction multicast groups")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>