UPSTREAM: ARM: dts: rockchip: move the rk3288 thermal data into rk3288.dtsi

In order to be standard to manage for rockchip SoCs,  move the thermal
data into rk3288 dtsi, we needn't to add a new file for thermal.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Change-Id: I2b11b46d1cfb9b70882d1062dedc5b8ff1bd5adf
(cherry picked from commit f87305fa00b1d0633d2dc5fd7fb4995bed6a59e8)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ARM: dts: rockchip: fix rk3288 power-domain unit names

The power-domain sub-nodes do have reg properties, but so far are
missing the expected unit names. So add the missing ones.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring <robh@kernel.org>
Change-Id: I03d82afdc2f170c7ecce9685e15b418ca5d30d5a
(cherry picked from commit 95cface95b6a6a8de6e95de2c8a25a64fd0f3558)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ARM: dts: rockchip: fix missing usbphy unit-names

The usbphy subnodes do have a reg property but no unitname, add them.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring <robh@kernel.org>
Change-Id: I5b48e289b332397ab7c383b839b875aeefa9f114
 (cherry picked from commit a8f0fa2764626d2dd808cfbe1a160f2939a36c88)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: phy: rockchip-usb: should be a child device of the GRF

The usb-phy is fully enclosed in the general register files (GRF).
Therefore as seen from the device-tree it shouldn't be a separate
platform-device but instead a sub-device of the GRF - using the
simply-mfd mechanism.

As the usb-phy is part of the kernel for some releases now, we keep
the old (and now deprecated) binding for compatibility purposes.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Change-Id: I747a18fba361d6c6f161b6572e43955e18593a34
 (cherry picked from commit a0da445aabe49c31093ecf3930f531e3c63e0b83)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: phy: rockchip-dp: should be a child device of the GRF

The displayport-phy is fully enclosed in the general register files (GRF).
Therefore as seen from the device-tree it shouldn't be a separate platform-
device but instead a sub-device of the GRF - using the simply-mfd mechanism.

The driver entered the kernel in the current merge-window, so we can still
adapt the binding without needing a fallback, as the binding hasn't been
released with a full kernel yet.

While the edp phy is fully part of the GRF, it doesn't have any separate
register set there, so doesn't get any register-area assigned.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Change-Id: I44a857051be195386fc888b2c713bedc948d5c95
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
 (cherry picked from commit 0311c76e4722b8d6e5fa47eaee63c6552bcc74f5)

UPSTREAM: PM / AVS: rockchip-io: make io-domains a child of the GRF

IO-domain handling is part of the general register files, so should live
under the grf directly. This change allows the grf to be a simple-mfd and
the io-domains fetching the syscon regmap from that parent-node.

The old binding is of course preserved, though deprecated.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Change-Id: I562e293fc96283edc868771851f15dba0e80d3bc
(cherry picked from commit bc19b9a81da009fd1d797d756d41b518ac7e5f14)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: arm: dts: rockchip: add reset node for the exist saradc SoCs

SARADC controller needs to be reset before programming it, otherwise
it will not function properly.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Change-Id: Iaafd41b163ebd853278baea5c1c10dc82c54792b
 (cherry picked from commit 3d4267a5a3a4b7619b80ad1839d8b3bedd8b7a8d)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ARM: dts: rockchip: move rk3288 usbphy under the GRF node

The rk3288 usbphy is completely enclosed in the general register files
and the updated binding allows it to be a subnode of the GRF now.
So move the node appropriately.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Change-Id: I85ca27786da0cd388ef6b4fddb11747761a579a3
(cherry picked from commit 546a3521f251462128d877e48fb3544c74976ce4)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ARM: dts: rockchip: move rk3288 io-domain nodes to the grf

io-voltage control is actually part of the grf, so move the node under the
newly available grf simple-mfd.

To minimize duplicate code, the core node and compatible property
gets placed in the core rk3288.dtsi while the individual boards
now only need to enable it and add the necessary supply properties.
cherry picked from commit 4b91545072ad7ca1963d2a89c8b42fc2eb561484)

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Conflicts:
arch/arm/boot/dts/rk3288-miqi.dts
arch/arm/boot/dts/rk3288-rock2-som.dtsi

Change-Id: I4f5ecc16524c52e8ac6f04cf8b9cdc0e1b7d937f
 (cherry picked from commit 3445b2fae55f1a232e6e4843f4f74de074d8c07f)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ARM: dts: rockchip: move rk3288 edp phy under the GRF

The edp-phy control is a part of the General Register Files and
with a recent patch in 4.6 the phy driver can now also handle this
correctly, so move the dts node under the GRF as well.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Change-Id: I6be6270739520f758dbe388cdbd50896c1d7d6f1
(cherry picked from commit 4b91545072ad7ca1963d2a89c8b42fc2eb561484)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

UPSTREAM: ARM: dts: rockchip: make rk3288-grf a simple-mfd

Similar to the pmu, the general register files contain a lot of different
setting bits grouped into general registers, but also some somewhat special
entities like the controls for some phy-blocks or the io-voltage control.
To be able to move these blocks under the grf node where they actually
belong, make it a simple-mfd.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Change-Id: I2c7f9d6f4411ea05520515a45acbaa689814c872
(cherry picked from commit 6e38e6b26e590b21247c1dd5238be35e7b056ef9)
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>

arm64: dts: rk3399: enabled rkvdec and vpu on android next board

Change-Id: I418b1065de8e078f1cf25f24889ca78006a98a4e
Signed-off-by: huang zufang <hzf@rock-chips.com>
Signed-off-by: zhangjun <jung.zhao@rock-chips.com>
Signed-off-by: liangqing wu <wlq@rock-chips.com>

video: rockchip: rkvdec: add drm&ion allocator support

Now vpu driver support both drm and ion allocator. And have
test on rk3399-mid(drm android 7.1), rk3399-mid(ion android
6.0), rk3288(linux mini arm) platform.

Change-Id: I0096c3928849b1f11a62378675f4559b4f101445
Signed-off-by: Jung Zhao <jung.zhao@rock-chips.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Randy Li <randy.li@rock-chips.com>

ARM64: dts: rockchip: add rkvpu & vpu node in rk3399 android next dtsi

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

arm64: dts: rockchip: add allocator type inside vpu & rkvdec for rk3399-android

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

drm/rockchip: fb: allow big framebuffer

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

drm/rockchip: add dither config for connected panel

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

drm/rockchip: fix iommu_map_sg check

The return value of iommu_map_sg is size_t, it's unsigned

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

drm/rockchip: fix iommu page fault when use boot logo

Since (cacb6f5 FROMLIST: drm/rockchip: Use common IOMMU API to attach
devices), rockchip drm use common IOMMU API, the boot logo buffer
mapping need change to new api.

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

power: reset: reboot-mode: treat unrecognized reboot mode as normal mode

Some bootloader will check the reboot mode to take different action, so
we treat unrecognized reboot mode as normal mode to prevent the system
run into abnormal case.

Change-Id: I88063a5b41e4e645443229fa490b2b55db5ccf27
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>

video/rockchip: rga2 support dma fd

in drm mode ion is not support dma fd, in order
to support drm fd rga driver need fix, and user
also need set the buf type by the macro

Change-Id: I3d0eaf7fbefda5aaf715772649d972b9a9d5c06d
Signed-off-by: Zikim,Wei <wzq@rock-chips.com>

ARM: dts: rk3288: add isp node

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

clk: rockchip: rk3288: export isp and cif clk

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

usb: dwc3: gadget: change detemination method of connect status

In current code, the connect status will be set to connected state when
reset interrupt occur and change to disconnected state in disconnect
interrupt.

But the usb charger may bring about reset signal in accident if we
connect and disconnect quickly. In this case, the dwc3 controller will
change link state and set to connect status, yet not change to
disconnected state when disconnect. So the dwc3 controller suspend
fail and result in a mistake when quick reconnect.

This patch set connect status to connected state when transfer complete
to make sure that usb is connect to PC exactly.

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

usb: dwc3-rockchip: delay suspend until gadget finish transfer

DWC3 controller still need to read or write memory after dwc3
rockchip receive disconnect notify, the dwc3 controller will not
suspend immediately and the clock is still enabled even if we put
dwc_rockchip sync. So if we reconnect to PC quickly, the transer
will start before dwc3 rockchip receive connect notify and the dwc3
controller will reset during normal transer which result in the gadget
function break.

In order to suspend dwc3 controller and disable clock when transfer
finish immediately, this patch wait for usage_count of dwc3 controller
change to 1 and disconnect interrupt occur then suspend dwc3 controller
and disable clock, make the dwc3 continue transfer after dwc3 rockchip
receive connect notify, otherwise do not reset and get or put dwc3
controller if timeout.

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

phy: rockchip-inno-usb2: set floating charger type as DCP

Floating charger is a kind of special USB charger that
dp/dm not shorted, which is incompatible with BC1.2 spec.

However, we need to support this floating charger, and
consider that the max charge current of floating charger
is the same as standard USB charger (dp/dm is shorted),
so we set the charger type as DCP for floating charger.

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

drivers: video: rockchip: hdmi: modify RAYKEN5.46 pixclock

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

input: touchscreen: fix tp gslxxxx irq number bug

gslxxxx wrong irq number with the same vopb, may cause vopb abnormal.

ts->irq is gpio number, gslxxxx irq number is ts->client->irq
ts->client->irq = gpio_to_irq(ts->irq)

Change-Id: Ic1f6a46437a2a185f3218d3f0406deeddd9d670a
Signed-off-by: Bin Yang <yangbin@rock-chips.com>

arm: configs: enable dsi for rockchip linux

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

UPSTREAM: phy: rockchip-inno-usb2: fix uninitialized tmout variable

The newly added OTG support has an obvious uninitialized variable
access that gcc warns about:

drivers/phy/phy-rockchip-inno-usb2.c: In function 'rockchip_chg_detect_work':
drivers/phy/phy-rockchip-inno-usb2.c:717:7: error: 'tmout' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This replaces the use of the uninitialized variable with what
the value was in the previous USB_CHG_STATE_WAIT_FOR_DCD
state.

Change-Id: Ibeed4872e1168e135a332a0978d85a4e48083267
Fixes: 0c42fe48fd23 ("phy: rockchip-inno-usb2: support otg-port for rk3399")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: William Wu <wulf@rock-chips.com>
(cherry picked from git.kernel.org kishon/linux-phy next
 commit dd796e921ea571624fcd8685f214fdfd4406101f)

usb: rockchip-inno-usb2: pull down dp/dm for rk3399 u2phy otg-port

The linestate change interrupt may occur during suspend if port is
not connected. This patch pull down dp/dm when suspend.

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

ARM64: dts: rk3399: adjust idle-cost-data of EAS with idle state

Change-Id: I994371c6a3c2aa99ffd666047a1707754ac96290
Signed-off-by: Chen Liang <cl@rock-chips.com>

FROMLIST: usb: dwc2: assert phy reset when waking up in rk3288 platform

On the rk3288 USB host-only port (the one that's not the OTG-enabled
port) the PHY can get into a bad state when a wakeup is asserted (not
just a wakeup from full system suspend but also a wakeup from
autosuspend).

We can get the PHY out of its bad state by asserting its "port reset",
but unfortunately that seems to assert a reset onto the USB bus so it
could confuse things if we don't actually deenumerate / reenumerate the
device.

We can also get the PHY out of its bad state by fully resetting it using
the reset from the CRU (clock reset unit) in chip, which does a more full
reset.  The CRU-based reset appears to actually cause devices on the bus
to be removed and reinserted, which fixes the problem (albeit in a hacky
way).

It's unfortunate that we need to do a full re-enumeration of devices at
wakeup time, but this is better than alternative of letting the bus get
wedged.

Change-Id: I3120a38a7f646a9d244f04bd2dcfef7474a4a6d1
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(am from https://mail-archive.com/linux-kernel@vger.kernel.org/msg1254059.html)

FROMLIST: phy: rockchip-usb: use rockchip_usb_phy_reset to reset phy during wakeup

It is a hardware bug in RK3288, the only way to solve it is to
reset the phy.

Change-Id: Iad8f52b623df3c4460dc321bb55e9c3111455590
Signed-off-by: Randy Li <ayaka@soulik.info>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
 (am from https://patchwork.kernel.org/patch/9324163/)

FROMLIST: ARM: dts: rockchip: Point rk3288 dwc2 usb at the full PHY reset

The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
has a hardware errata that causes everything to get confused when we get
a remote wakeup.  We'll use the reset that's in the CRU to reset the
port when it's in a bad state.

Note that we add the reset to both dwc2 controllers even though only one
has the errata in case we find some other use for this reset that's
unrelated to the current hardware errata.  Only the host port gets the
quirk property, though.

Change-Id: I472d33fb1db8b1a6b0c4fcea9ab31fd85b61af40
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9324169/)

arm64: dts: rk3399: add a opp-suspend property for cpu opp table

The opp who contains a opp-suspend property will be configured
during suspend or reboot.

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

cpufreq: dt: change frequency to a specific value when cpufreq exits

Sometimes all cpus of big cluster are closed and its frequency
keep a high value, in order to reduce power and reset normally,
set frequency to a specific value after close all the cpus.

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

arm64: dts: rockchip: rk3399: add dp default mode for rk3399 box discrete vr

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

soc: rockchip: power-domain: export idle request

We need to put the power status of HEVC IP into IDLE unless
we can't reset that IP or the SoC would crash down.
rockchip_pmu_idle_request(dev, true)---> enter idle
rockchip_pmu_idle_request(dev, false)---> exit idle

Change-Id: I76733efd2de4f7ee183c1b6bd1545d60038ee31b
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Randy Li <randy.li@rock-chips.com>

CHROMIUM: drm/rockchip: Respect page offset in IOMMU mmap

When mapping buffers through the PRIME DMA-buf mmap path we might be
given an offset which has to be respected. The DRM GEM mmap path already
takes care of zeroing out the fake mmap offset, so we can just make the
IOMMU mmap implementation always respect the offset.

BUG=chrome-os-partner:56615
TEST=graphics_GLBench

Change-Id: Iec83e720b24ddd35a92f3df8312015bc5af798f0
Signed-off-by: rjan Eide <orjan.eide@arm.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/386477
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Randy Li <randy.li@rock-chips.com>

CHROMIUM: drm/rockchip: Respect page offset for PRIME mmap calls

When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma->vm_pgoff,
which breaks the former.

This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.

BUG=chrome-os-partner:56615
TEST=graphics_GLBench

Change-Id: Iec6e996707b0fe7e95a019423a944d98c80beaab
Signed-off-by: rjan Eide <orjan.eide@arm.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/381332
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Randy Li <randy.li@rock-chips.com>

CHROMIUM: drm/rockchip: Call drm_gem_object_release() to destroy GEM base

When converting the driver to use shmem-backed GEMs for IOMMU-enabled
systems, we forgot to add calls to drm_gem_object_release(), which gave
us a quite nice memory leak. This patch adds the missing calls.

Fixes: f11d5f0 ("FROMLIST: drm/rockchip: Do not use DMA mapping API if
attached to IOMMU domain")

BUG=chrome-os-partner:57158
TEST=while true; do backlight_dbus_tool --set --percent=0 && sleep 8 &&
 backlight_dbus_tool --set --percent=100 && sleep 3 ; done

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/385456
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_gem.c

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

CHROMIUM: drm/rockchip: Fix the call to drm_gem_put_pages()

When freeing the buffer we don't have any means of determining if the
buffer was read or written, so we must assume both and pass true for
both arguments of drm_gem_put_pages(). Let's fix the code which
currently passes false.

BUG=chrome-os-partner:56378
TEST=while true; do backlight_dbus_tool --set --percent=0 && sleep 8 &&
 backlight_dbus_tool --set --percent=100 && sleep 3 ; done

Change-Id: I7da2fd81e7e728e0ef242837b70819c4a3aee7bf
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382934
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Randy Li <randy.li@rock-chips.com>

FROMLIST: drm/rockchip: Use common IOMMU API to attach devices

Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.

Since previous patch added support for direct IOMMU address space
management, there is no need to use DMA API anymore and this patch wires
things to use the new method.

Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
(am from https://patchwork.kernel.org/patch/9196389/)

BUG=chrome-os-partner:53565
TEST=boot to ui on Gru

Reviewed-on: https://chromium-review.googlesource.com/349521
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c

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

UPSTREAM: drm/rockchip: support non-iommu buffer path

Some rockchip vop not support iommu, need use non-iommu
buffer for it. And if we get iommu issues, we can compare
the issues with non-iommu path, that would help the debug.

Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c

Change-Id: I843f087281300359b07faac1de156cd648325b45
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(cherry picked from commit 2d90d477430d3a20df74f2d11c21378e64e1d508)

UPSTREAM: drm/rockchip: don't leak iommu mapping

arm_iommu_attach_device() takes its own reference to the mapping we give
it.  Since we do not keep a reference to the mapping ourselves, we must
release it before returning.

Also fix the error path, which fails to release the mapping if it has
called arm_iommu_detach_device() since that clears archdata.mapping.

Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c

Change-Id: Ia20334afbce08ece5a3238a7b0786547ec0cafb2
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 69b007968e7519cf1e44920f4578054c9e0fbdc3)

UPSTREAM: drm/rockchip: remove redundant statement

The call to arm_iommu_detach_device() on the previous line sets
dev->archdata.mapping to NULL so this call is always a no-op.

Change-Id: I09b41c284c61885fb4b989a64839e96bcc316aa6
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit aa1ac27f48de0ed94d5a104e15b5ab62b5deb236)

CHROMIUM: rockchip: support prime import sg table

The prime fd to handle ioctl was not used with rockchip before. Support
was added in order to pass graphics_Gbm and to support potential uses
within Chrome OS (e.g. zero-copy video decode, camera).

Difference from kernel 3.14 implementation:
- prime_import_sg_table passes dma-buf as argument instead of size
- need to handle import sg_table for both DMA and IOMMU paths

TEST=test_that graphics_Gbm on kevin
BUG=chrome-os-partner:56526

Reviewed-on: https://chromium-review.googlesource.com/381991
Tested-by: Haixia Shi <hshi@chromium.org>
Commit-Queue: Haixia Shi <hshi@chromium.org>
Trybot-Ready: Haixia Shi <hshi@chromium.org>
Reviewed-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_gem.c

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

FROMLIST: drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.

This patch should not introduce any functional changes until the driver
is made to attach subdevices into an IOMMU domain with the generic IOMMU
API, which will happen in following patch. Based heavily on GEM
implementation of Tegra DRM driver.

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9196387/)

BUG=chrome-os-partner:53565
TEST=boot to ui on Gru

Reviewed-on: https://chromium-review.googlesource.com/353591
Commit-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Conflicts:
drivers/gpu/drm/rockchip/rockchip_drm_drv.h
drivers/gpu/drm/rockchip/rockchip_drm_gem.c
drivers/gpu/drm/rockchip/rockchip_drm_gem.h

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

Revert "drm/rockchip: rewrite IOMMU support code"

This reverts commit b435f1a281e8a9ff1f1013318a1147949e55130a.

Conflicts:
drivers/gpu/drm/rockchip/Kconfig
drivers/gpu/drm/rockchip/rockchip_drm_drv.h

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

Revert "drm/rockchip: gem: import dma_buf to gem"

This reverts commit a05932da07ecc0a214bd24322ffbcec79be5d5e0.

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

video: build rockchip video driver modules independently

There is not need to force the video driver dependency in parent
tree.

Also there would be too many entries in a menu, I create a submenu
for them.

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

ARM: dts: rockchip: switch to vpu-service in asus miniarm

We decide to offer the video support in old way.

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

ARM: dts: rockchip: rk3288 hevc using same clk freqs as android

If you meet a performance issue, I would suggest you to set
500MHZ for ACLK_HEVC at rk3288. It could solve the decoding quite
slow for some video resources.

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

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

* linux-linaro-lsk-v4.4-android: (61 commits)
  Linux 4.4.36
  scsi: mpt3sas: Unblock device after controller reset
  flow_dissect: call init_default_flow_dissectors() earlier
  mei: fix return value on disconnection
  mei: me: fix place for kaby point device ids.
  mei: me: disable driver on SPT SPS firmware
  drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on
  mpi: Fix NULL ptr dereference in mpi_powm() [ver #3]
  parisc: Also flush data TLB in flush_icache_page_asm
  parisc: Fix race in pci-dma.c
  parisc: Fix races in parisc_setup_cache_timing()
  NFSv4.x: hide array-bounds warning
  apparmor: fix change_hat not finding hat after policy replacement
  cfg80211: limit scan results cache size
  tile: avoid using clocksource_cyc2ns with absolute cycle count
  scsi: mpt3sas: Fix secure erase premature termination
  Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y
  USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad
  USB: serial: cp210x: add ID for the Zone DPMX
  usb: chipidea: move the lock initialization to core file
  ...

UPSTREAM: iommu/dma: Implement scatterlist segment merging

Stop wasting IOVA space by over-aligning scatterlist segments for a
theoretical worst-case segment boundary mask, and instead take the real
limits into account to merge consecutive segments wherever appropriate,
so our callers can benefit from getting back nicely simplified lists.

This also represents the last piece of functionality wanted by users of
the current arch/arm implementation, thus brings us a small step closer
to converting that over to the common code.

Change-Id: Ie583142efece02dfa6678d5e8607b5bc7266f50c
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 809eac54cdd62c67afea1e17080e681dfa33dc09)

camera: rockchip: camsys driver v0.0x21.8

Change-Id: Ib0fed5df3edfe4dae042999e71c50d67a490f88e
Signed-off-by: dalong.zhang <dalon.zhang@rock-chips.com>

ARM64: dts: rk3399: sapphire: add uboot logo support for android next

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

ARM: dts: rockchip: rk3288: add qos node

when pd power on/off, the qos regs need to save and restore.

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

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

Conflicts:
keep low scan freq in android in net/wireless/scan.c

arm64: dts: rk3399-sapphire-excavator-linux: add fiq_debugger node

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

hid: rkvr: add 0x110 key event used for touchpad

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

arm64: dts: rockchip: enable isp node for rk3399-mid-818-android-next

Change-Id: Ic6d489ab7a65cf9ec3c7d03b00541f946cb57b84
Signed-off-by: Bin Yang <yangbin@rock-chips.com>

arm64: dts: rockchip: Add RK3399 Excavator dts for drm

Change-Id: I8da4f4bc4a903e4e3702f6e5dbedb72cd5ee627f
Signed-off-by: Cody Xie <xkd@rock-chips.com>
Signed-off-by: Bin Yang <yangbin@rock-chips.com>

UPSTREAM: PCI: rockchip: Indent an if statement

The if statement wasn't intended.  Add a tab.

Change-Id: I33e4fce2cc2052dc45c3c7a2617586cdd6a6b664
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from commit 08015ee0ff8a221bdc9ee66cfcc7e3379e9bcd28)

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

 This is the 4.4.36 stable release

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

* linux-linaro-lsk-v4.4-android: (315 commits)
  Linux 4.4.35
  netfilter: nft_dynset: fix element timeout for HZ != 1000
  IB/cm: Mark stale CM id's whenever the mad agent was unregistered
  IB/uverbs: Fix leak of XRC target QPs
  IB/core: Avoid unsigned int overflow in sg_alloc_table
  IB/mlx5: Fix fatal error dispatching
  IB/mlx5: Use cache line size to select CQE stride
  IB/mlx4: Fix create CQ error flow
  IB/mlx4: Check gid_index return value
  PM / sleep: don't suspend parent when async child suspend_{noirq, late} fails
  PM / sleep: fix device reference leak in test_suspend
  uwb: fix device reference leaks
  mfd: core: Fix device reference leak in mfd_clone_cell
  iwlwifi: pcie: fix SPLC structure parsing
  rtc: omap: Fix selecting external osc
  clk: mmp: mmp2: fix return value check in mmp2_clk_init()
  clk: mmp: pxa168: fix return value check in pxa168_clk_init()
  clk: mmp: pxa910: fix return value check in pxa910_clk_init()
  drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)
  crypto: caam - do not register AES-XTS mode on LP units
  ...

Change-Id: Ic14c01a22a5e8a0356d6c0ef6bcca7bc6cad6b4b

Revert "FROMLIST: PM / sleep: don't suspend parent when async child suspend_{noirq,late} fails"

This reverts commit 11b2dcefd88e8ae01a11c6df55d91206ac226c52.
Fixed by 04c0800c73b2 ("PM / sleep: don't suspend parent when
async child suspend_{noirq, late} fails").

rockchip/vcodec: drop needless devm_clk_put

Also make sure clk is NULL if get failed.

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

ARM64: dts: rk3399-android-next: default use vopb for primary display

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

drm/rockchip: vop: skip config timing on vblank

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

drm/rockchip: vop: fix display logo flash with line flag

Use standy with dsp_hold intr would effect display timing,
Some display controller can't not allow this, such as edp,
edp panel would flash with it.

Use line flag instead it seems good.

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

CHROMIUM: drm/rockchip: Clear interrupt status bits before enabling

The enable register only masks the raw status bits to signal CPU
interrupt only for enabled interrupts. The status bits are activated
regardless of the enable register. This means that we might have an old
interrupt event queued, which we are not interested in. To avoid getting
a spurious interrupt signalled, we have to clear the old bit before we
update the enable register.

BUG=chrome-os-partner:56378
BUG=chrome-os-partner:56580
TEST=while true; do backlight_dbus_tool --set --percent=0 && sleep 8 && backlight_dbus_tool --set --percent=100 && sleep 3 ; done

Change-Id: I1b8286097f3ba102663ee3a7566fd96492e12d26
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382973
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

FROMLIST: drm/rockchip: vop: export line flag function

VOP have integrated a hardware counter which indicate the exact display
line that vop is scanning. And if we're interested in a specific line,
we can set the line number to vop line_flag register, and then vop would
generate a line_flag interrupt for it.

For example eDP PSR function is interested in the vertical blanking
period, then driver could set the line number to zero.

This patch have exported a symbol that allow other driver to listen the
line flag event with given timeout limit:
- rockchip_drm_wait_line_flag()

BUG=chrome-os-partner:54785
TEST=Success to call rockchip_drm_wait_line_flag()

Change-Id: Id7605bada87c8ead0e549d4ff113ee49d29ad126
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9231675/)
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/349084
Commit-Ready: Sean Paul <seanpaul@google.com>
Tested-by: Sean Paul <seanpaul@google.com>
Reviewed-by: Sean Paul <seanpaul@google.com>

drm/rockchip: add loader protect ops to drm connector

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

Linux 4.4.36

scsi: mpt3sas: Unblock device after controller reset

commit 7ff723ad0f87feba43dda45fdae71206063dd7d4 upstream.

While issuing any ATA passthrough command to firmware the driver will
block the device. But it will unblock the device only if the I/O
completes through the ISR path. If a controller reset occurs before
command completion the device will remain in blocked state.

Make sure we unblock the device following a controller reset if an ATA
passthrough command was queued.

[mkp: clarified patch description]

Fixes: ac6c2a93bd07 ("mpt3sas: Fix for SATA drive in blocked state, after diag reset")
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

flow_dissect: call init_default_flow_dissectors() earlier

commit c9b8af1330198ae241cd545e1f040019010d44d9 upstream.

Andre Noll reported panics after my recent fix (commit 34fad54c2537
"net: __skb_flow_dissect() must cap its return value")

After some more headaches, Alexander root caused the problem to
init_default_flow_dissectors() being called too late, in case
a network driver like IGB is not a module and receives DHCP message
very early.

Fix is to call init_default_flow_dissectors() much earlier,
as it is a core infrastructure and does not depend on another
kernel service.

Fixes: 06635a35d13d4 ("flow_dissect: use programable dissector in skb_flow_dissect and friends")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andre Noll <maan@tuebingen.mpg.de>
Diagnosed-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: fix return value on disconnection

commit 2d4d5481e2d6f93b25fcfb13a9f20bbfbf54266a upstream.

Correct errno on client disconnection is -ENODEV not -EBUSY

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: me: fix place for kaby point device ids.

This is fix of the backported patch only, it places
KBL DIDs on correct place to easy on backporting of
further DIDs.

Fixes: 5c99f32c461c ('mei: me: add kaby point device ids')
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: me: disable driver on SPT SPS firmware

commit 8c57cac1457f3125a5d13dc03635c0708c61bff0 upstream.

Sunrise Point PCH with SPS Firmware doesn't expose working
MEI interface, we need to quirk it out.
The SPS Firmware is identifiable only on the first PCI function
of the device.

Tested-by: Sujith Pandel <sujith_pandel@dell.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on

NOTE: This patch only applies to 4.5.y or older kernels. With newer
kernels, this problem cannot happen because the driver now uses
drm_crtc_vblank_on/off instead of drm_vblank_pre/post_modeset[0]. I
consider this patch safer for older kernels than backporting the API
change, because drm_crtc_vblank_on/off had various issues in older
kernels, and I'm not sure all fixes for those have been backported to
all stable branches where this patch could be applied.

    ---------------------

Fixes the vblank interrupt being disabled when it should be on, which
can cause at least the following symptoms:

* Hangs when running 'xset dpms force off' in a GNOME session with
  gnome-shell using DRI2.
* RandR 1.4 slave outputs freezing with garbage displayed using
  xf86-video-ati 7.8.0 or newer.

[0] See upstream commit:

commit 777e3cbc791f131806d9bf24b3325637c7fc228d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jan 21 11:08:57 2016 +0100

    drm/radeon: Switch to drm_vblank_on/off

Reported-and-Tested-by: Max Staudt <mstaudt@suse.de>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>

mpi: Fix NULL ptr dereference in mpi_powm() [ver #3]

commit f5527fffff3f002b0a6b376163613b82f69de073 upstream.

This fixes CVE-2016-8650.

If mpi_powm() is given a zero exponent, it wants to immediately return
either 1 or 0, depending on the modulus.  However, if the result was
initalised with zero limb space, no limbs space is allocated and a
NULL-pointer exception ensues.

Fix this by allocating a minimal amount of limb space for the result when
the 0-exponent case when the result is 1 and not touching the limb space
when the result is 0.

This affects the use of RSA keys and X.509 certificates that carry them.

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
PGD 0
Oops: 0002 [#1] SMP
Modules linked in:
CPU: 3 PID: 3014 Comm: keyctl Not tainted 4.9.0-rc6-fscache+ #278
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
task: ffff8804011944c0 task.stack: ffff880401294000
RIP: 0010:[<ffffffff8138ce5d>]  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
RSP: 0018:ffff880401297ad8  EFLAGS: 00010212
RAX: 0000000000000000 RBX: ffff88040868bec0 RCX: ffff88040868bba0
RDX: ffff88040868b260 RSI: ffff88040868bec0 RDI: ffff88040868bee0
RBP: ffff880401297ba8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000047 R11: ffffffff8183b210 R12: 0000000000000000
R13: ffff8804087c7600 R14: 000000000000001f R15: ffff880401297c50
FS:  00007f7a7918c700(0000) GS:ffff88041fb80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000401250000 CR4: 00000000001406e0
Stack:
 ffff88040868bec0 0000000000000020 ffff880401297b00 ffffffff81376cd4
 0000000000000100 ffff880401297b10 ffffffff81376d12 ffff880401297b30
 ffffffff81376f37 0000000000000100 0000000000000000 ffff880401297ba8
Call Trace:
 [<ffffffff81376cd4>] ? __sg_page_iter_next+0x43/0x66
 [<ffffffff81376d12>] ? sg_miter_get_next_page+0x1b/0x5d
 [<ffffffff81376f37>] ? sg_miter_next+0x17/0xbd
 [<ffffffff8138ba3a>] ? mpi_read_raw_from_sgl+0xf2/0x146
 [<ffffffff8132a95c>] rsa_verify+0x9d/0xee
 [<ffffffff8132acca>] ? pkcs1pad_sg_set_buf+0x2e/0xbb
 [<ffffffff8132af40>] pkcs1pad_verify+0xc0/0xe1
 [<ffffffff8133cb5e>] public_key_verify_signature+0x1b0/0x228
 [<ffffffff8133d974>] x509_check_for_self_signed+0xa1/0xc4
 [<ffffffff8133cdde>] x509_cert_parse+0x167/0x1a1
 [<ffffffff8133d609>] x509_key_preparse+0x21/0x1a1
 [<ffffffff8133c3d7>] asymmetric_key_preparse+0x34/0x61
 [<ffffffff812fc9f3>] key_create_or_update+0x145/0x399
 [<ffffffff812fe227>] SyS_add_key+0x154/0x19e
 [<ffffffff81001c2b>] do_syscall_64+0x80/0x191
 [<ffffffff816825e4>] entry_SYSCALL64_slow_path+0x25/0x25
Code: 56 41 55 41 54 53 48 81 ec a8 00 00 00 44 8b 71 04 8b 42 04 4c 8b 67 18 45 85 f6 89 45 80 0f 84 b4 06 00 00 85 c0 75 2f 41 ff ce <49> c7 04 24 01 00 00 00 b0 01 75 0b 48 8b 41 18 48 83 38 01 0f
RIP  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
 RSP <ffff880401297ad8>
CR2: 0000000000000000
---[ end trace d82015255d4a5d8d ]---

Basically, this is a backport of a libgcrypt patch:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526

Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
cc: linux-ima-devel@lists.sourceforge.net
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: Also flush data TLB in flush_icache_page_asm

commit 5035b230e7b67ac12691ed3b5495bbb617027b68 upstream.

This is the second issue I noticed in reviewing the parisc TLB code.

The fic instruction may use either the instruction or data TLB in
flushing the instruction cache.  Thus, on machines with a split TLB, we
should also flush the data TLB after setting up the temporary alias
registers.

Although this has no functional impact, I changed the pdtlb and pitlb
instructions to consistently use the index register %r0.  These
instructions do not support integer displacements.

Tested on rp3440 and c8000.

Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: Fix race in pci-dma.c

commit c0452fb9fb8f49c7d68ab9fa0ad092016be7b45f upstream.

We are still troubled by occasional random segmentation faults and
memory memory corruption on SMP machines.  The causes quite a few
package builds to fail on the Debian buildd machines for parisc.  When
gcc-6 failed to build three times in a row, I looked again at the TLB
related code.  I found a couple of issues.  This is the first.

In general, we need to ensure page table updates and corresponding TLB
purges are atomic.  The attached patch fixes an instance in pci-dma.c
where the page table update was not guarded by the TLB lock.

Tested on rp3440 and c8000.  So far, no further random segmentation
faults have been observed.

Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: Fix races in parisc_setup_cache_timing()

commit 741dc7bf1c7c7d93b853bb55efe77baa27e1b0a9 upstream.

Helge reported to me the following startup crash:

[    0.000000] Linux version 4.8.0-1-parisc64-smp (debian-kernel@lists.debian.org) (gcc version 5.4.1 20161019 (GCC) ) #1 SMP Debian 4.8.7-1 (2016-11-13)
[    0.000000] The 64-bit Kernel has started...
[    0.000000] Kernel default page size is 4 KB. Huge pages enabled with 1 MB physical and 2 MB virtual size.
[    0.000000] Determining PDC firmware type: System Map.
[    0.000000] model 9000/785/J5000
[    0.000000] Total Memory: 2048 MB
[    0.000000] Memory: 2018528K/2097152K available (9272K kernel code, 3053K rwdata, 1319K rodata, 1024K init, 840K bss, 78624K reserved, 0K cma-reserved)
[    0.000000] virtual kernel memory layout:
[    0.000000]     vmalloc : 0x0000000000008000 - 0x000000003f000000   (1007 MB)
[    0.000000]     memory  : 0x0000000040000000 - 0x00000000c0000000   (2048 MB)
[    0.000000]       .init : 0x0000000040100000 - 0x0000000040200000   (1024 kB)
[    0.000000]       .data : 0x0000000040b0e000 - 0x0000000040f533e0   (4372 kB)
[    0.000000]       .text : 0x0000000040200000 - 0x0000000040b0e000   (9272 kB)
[    0.768910] Brought up 1 CPUs
[    0.992465] NET: Registered protocol family 16
[    2.429981] Releasing cpu 1 now, hpa=fffffffffffa2000
[    2.635751] CPU(s): 2 out of 2 PA8500 (PCX-W) at 440.000000 MHz online
[    2.726692] Setting cache flush threshold to 1024 kB
[    2.729932] Not-handled unaligned insn 0x43ffff80
[    2.798114] Setting TLB flush threshold to 140 kB
[    2.928039] Unaligned handler failed, ret = -1
[    3.000419]       _______________________________
[    3.000419]      < Your System ate a SPARC! Gah! >
[    3.000419]       -------------------------------
[    3.000419]              \   ^__^
[    3.000419]                  (__)\       )\/\
[    3.000419]                   U  ||----w |
[    3.000419]                      ||     ||
[    9.340055] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-1-parisc64-smp #1 Debian 4.8.7-1
[    9.448082] task: 00000000bfd48060 task.stack: 00000000bfd50000
[    9.528040]
[   10.760029] IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004025d154 000000004025d158
[   10.868052]  IIR: 43ffff80    ISR: 0000000000340000  IOR: 000001ff54150960
[   10.960029]  CPU:        1   CR30: 00000000bfd50000 CR31: 0000000011111111
[   11.052057]  ORIG_R28: 000000004021e3b4
[   11.100045]  IAOQ[0]: irq_exit+0x94/0x120
[   11.152062]  IAOQ[1]: irq_exit+0x98/0x120
[   11.208031]  RP(r2): irq_exit+0xb8/0x120
[   11.256074] Backtrace:
[   11.288067]  [<00000000402cd944>] cpu_startup_entry+0x1e4/0x598
[   11.368058]  [<0000000040109528>] smp_callin+0x2c0/0x2f0
[   11.436308]  [<00000000402b53fc>] update_curr+0x18c/0x2d0
[   11.508055]  [<00000000402b73b8>] dequeue_entity+0x2c0/0x1030
[   11.584040]  [<00000000402b3cc0>] set_next_entity+0x80/0xd30
[   11.660069]  [<00000000402c1594>] pick_next_task_fair+0x614/0x720
[   11.740085]  [<000000004020dd34>] __schedule+0x394/0xa60
[   11.808054]  [<000000004020e488>] schedule+0x88/0x118
[   11.876039]  [<0000000040283d3c>] rescuer_thread+0x4d4/0x5b0
[   11.948090]  [<000000004028fc4c>] kthread+0x1ec/0x248
[   12.016053]  [<0000000040205020>] end_fault_vector+0x20/0xc0
[   12.092239]  [<00000000402050c0>] _switch_to_ret+0x0/0xf40
[   12.164044]
[   12.184036] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-1-parisc64-smp #1 Debian 4.8.7-1
[   12.244040] Backtrace:
[   12.244040]  [<000000004021c480>] show_stack+0x68/0x80
[   12.244040]  [<00000000406f332c>] dump_stack+0xec/0x168
[   12.244040]  [<000000004021c74c>] die_if_kernel+0x25c/0x430
[   12.244040]  [<000000004022d320>] handle_unaligned+0xb48/0xb50
[   12.244040]
[   12.632066] ---[ end trace 9ca05a7215c7bbb2 ]---
[   12.692036] Kernel panic - not syncing: Attempted to kill the idle task!

We have the insn 0x43ffff80 in IIR but from IAOQ we should have:
   4025d150:   0f f3 20 df     ldd,s r19(r31),r31
   4025d154:   0f 9f 00 9c     ldw r31(ret0),ret0
   4025d158:   bf 80 20 58     cmpb,*<> r0,ret0,4025d18c <irq_exit+0xcc>

Cpu0 has just completed running parisc_setup_cache_timing:

[    2.429981] Releasing cpu 1 now, hpa=fffffffffffa2000
[    2.635751] CPU(s): 2 out of 2 PA8500 (PCX-W) at 440.000000 MHz online
[    2.726692] Setting cache flush threshold to 1024 kB
[    2.729932] Not-handled unaligned insn 0x43ffff80
[    2.798114] Setting TLB flush threshold to 140 kB
[    2.928039] Unaligned handler failed, ret = -1

From the backtrace, cpu1 is in smp_callin:

void __init smp_callin(void)
{
       int slave_id = cpu_now_booting;

       smp_cpu_init(slave_id);
       preempt_disable();

       flush_cache_all_local(); /* start with known state */
       flush_tlb_all_local(NULL);

       local_irq_enable();  /* Interrupts have been off until now */

       cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);

So, it has just flushed its caches and the TLB. It would seem either the
flushes in parisc_setup_cache_timing or smp_callin have corrupted kernel
memory.

The attached patch reworks parisc_setup_cache_timing to remove the races
in setting the cache and TLB flush thresholds. It also corrects the
number of bytes flushed in the TLB calculation.

The patch flushes the cache and TLB on cpu0 before starting the
secondary processors so that they are started from a known state.

Tested with a few reboots on c8000.

Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

NFSv4.x: hide array-bounds warning

commit d55b352b01bc78fbc3d1bb650140668b87e58bf9 upstream.

A correct bugfix introduced a harmless warning that shows up with gcc-7:

fs/nfs/callback.c: In function 'nfs_callback_up':
fs/nfs/callback.c:214:14: error: array subscript is outside array bounds [-Werror=array-bounds]

What happens here is that the 'minorversion == 0' check tells the
compiler that we assume minorversion can be something other than 0,
but when CONFIG_NFS_V4_1 is disabled that would be invalid and
result in an out-of-bounds access.

The added check for IS_ENABLED(CONFIG_NFS_V4_1) tells gcc that this
really can't happen, which makes the code slightly smaller and also
avoids the warning.

The bugfix that introduced the warning is marked for stable backports,
we want this one backported to the same releases.

Fixes: 98b0f80c2396 ("NFSv4.x: Fix a refcount leak in nfs_callback_up_net")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

apparmor: fix change_hat not finding hat after policy replacement

commit 3d40658c977769ce2138f286cf131537bf68bdfe upstream.

After a policy replacement, the task cred may be out of date and need
to be updated. However change_hat is using the stale profiles from
the out of date cred resulting in either: a stale profile being applied
or, incorrect failure when searching for a hat profile as it has been
migrated to the new parent profile.

Fixes: 01e2b670aa898a39259bc85c78e3d74820f4d3b6 (failure to find hat)
Fixes: 898127c34ec03291c86f4ff3856d79e9e18952bc (stale policy being applied)
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000287
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cfg80211: limit scan results cache size

commit 9853a55ef1bb66d7411136046060bbfb69c714fa upstream.

It's possible to make scanning consume almost arbitrary amounts
of memory, e.g. by sending beacon frames with random BSSIDs at
high rates while somebody is scanning.

Limit the number of BSS table entries we're willing to cache to
1000, limiting maximum memory usage to maybe 4-5MB, but lower
in practice - that would be the case for having both full-sized
beacon and probe response frames for each entry; this seems not
possible in practice, so a limit of 1000 entries will likely be
closer to 0.5 MB.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tile: avoid using clocksource_cyc2ns with absolute cycle count

commit e658a6f14d7c0243205f035979d0ecf6c12a036f upstream.

For large values of "mult" and long uptimes, the intermediate
result of "cycles * mult" can overflow 64 bits.  For example,
the tile platform calls clocksource_cyc2ns with a 1.2 GHz clock;
we have mult = 853, and after 208.5 days, we overflow 64 bits.

Since clocksource_cyc2ns() is intended to be used for relative
cycle counts, not absolute cycle counts, performance is more
importance than accepting a wider range of cycle values.  So,
just use mult_frac() directly in tile's sched_clock().

Commit 4cecf6d401a0 ("sched, x86: Avoid unnecessary overflow
in sched_clock") by Salman Qazi results in essentially the same
generated code for x86 as this change does for tile.  In fact,
a follow-on change by Salman introduced mult_frac() and switched
to using it, so the C code was largely identical at that point too.

Peter Zijlstra then added mul_u64_u32_shr() and switched x86
to use it.  This is, in principle, better; by optimizing the
64x64->64 multiplies to be 32x32->64 multiplies we can potentially
save some time.  However, the compiler piplines the 64x64->64
multiplies pretty well, and the conditional branch in the generic
mul_u64_u32_shr() causes some bubbles in execution, with the
result that it's pretty much a wash.  If tilegx provided its own
implementation of mul_u64_u32_shr() without the conditional branch,
we could potentially save 3 cycles, but that seems like small gain
for a fair amount of additional build scaffolding; no other platform
currently provides a mul_u64_u32_shr() override, and tile doesn't
currently have an <asm/div64.h> header to put the override in.

Additionally, gcc currently has an optimization bug that prevents
it from recognizing the opportunity to use a 32x32->64 multiply,
and so the result would be no better than the existing mult_frac()
until such time as the compiler is fixed.

For now, just using mult_frac() seems like the right answer.

Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: mpt3sas: Fix secure erase premature termination

commit 18f6084a989ba1b38702f9af37a2e4049a924be6 upstream.

This is a work around for a bug with LSI Fusion MPT SAS2 when perfoming
secure erase. Due to the very long time the operation takes, commands
issued during the erase will time out and will trigger execution of the
abort hook. Even though the abort hook is called for the specific
command which timed out, this leads to entire device halt
(scsi_state terminated) and premature termination of the secure erase.

Set device state to busy while ATA passthrough commands are in progress.

[mkp: hand applied to 4.9/scsi-fixes, tweaked patch description]

Signed-off-by: Andrey Grodzovsky <andrey2805@gmail.com>
Acked-by: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
Cc: <linux-scsi@vger.kernel.org>
Cc: Sathya Prakash <sathya.prakash@broadcom.com>
Cc: Chaitra P B <chaitra.basappa@broadcom.com>
Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
Cc: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y

commit 2ce9d2272b98743b911196c49e7af5841381c206 upstream.

Some code (all error handling) submits CDBs that are allocated
on the stack.  This breaks with CB/CBI code that tries to create
URB directly from SCSI command buffer - which happens to be in
vmalloced memory with vmalloced kernel stacks.

Let's make copy of the command in usb_stor_CB_transport.

Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad

commit 9bfef729a3d11f04d12788d749a3ce6b47645734 upstream.

This patch adds support for the TI CC3200 LaunchPad board, which uses a
custom USB vendor ID and product ID. Channel A is used for JTAG, and
channel B is used for a UART.

Signed-off-by: Doug Brown <doug@schmorgal.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: cp210x: add ID for the Zone DPMX

commit 2ab13292d7a314fa45de0acc808e41aaad31989c upstream.

The BRIM Brothers Zone DPMX is a bicycle powermeter. This ID is for the USB
serial interface in its charging dock for the control pods, via which some
settings for the pods can be modified.

Signed-off-by: Paul Jakma <paul@jakma.org>
Cc: Barry Redmond <barry@brimbrothers.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: chipidea: move the lock initialization to core file

commit a5d906bb261cde5f881a949d3b0fbaa285dcc574 upstream.

This can fix below dump when the lock is accessed at host
mode due to it is not initialized.

[   46.119638] INFO: trying to register non-static key.
[   46.124643] the code is fine but needs lockdep annotation.
[   46.130144] turning off the locking correctness validator.
[   46.135659] CPU: 0 PID: 690 Comm: cat Not tainted 4.9.0-rc3-00079-g4b75f1d #1210
[   46.143075] Hardware name: Freescale i.MX6 SoloX (Device Tree)
[   46.148923] Backtrace:
[   46.151448] [<c010c460>] (dump_backtrace) from [<c010c658>] (show_stack+0x18/0x1c)
[   46.159038]  r7:edf52000
[   46.161412]  r6:60000193
[   46.163967]  r5:00000000
[   46.165035]  r4:c0e25c2c

[   46.169109] [<c010c640>] (show_stack) from [<c03f58a4>] (dump_stack+0xb4/0xe8)
[   46.176362] [<c03f57f0>] (dump_stack) from [<c016d690>] (register_lock_class+0x4fc/0x56c)
[   46.184554]  r10:c0e25d24
[   46.187014]  r9:edf53e70
[   46.189569]  r8:c1642444
[   46.190637]  r7:ee9da024
[   46.193191]  r6:00000000
[   46.194258]  r5:00000000
[   46.196812]  r4:00000000
[   46.199185]  r3:00000001

[   46.203259] [<c016d194>] (register_lock_class) from [<c0171294>] (__lock_acquire+0x80/0x10f0)
[   46.211797]  r10:c0e25d24
[   46.214257]  r9:edf53e70
[   46.216813]  r8:ee9da024
[   46.217880]  r7:c1642444
[   46.220435]  r6:edcd1800
[   46.221502]  r5:60000193
[   46.224057]  r4:00000000

[   46.227953] [<c0171214>] (__lock_acquire) from [<c01726c0>] (lock_acquire+0x74/0x94)
[   46.235710]  r10:00000001
[   46.238169]  r9:edf53e70
[   46.240723]  r8:edf53f80
[   46.241790]  r7:00000001
[   46.244344]  r6:00000001
[   46.245412]  r5:60000193
[   46.247966]  r4:00000000

[   46.251866] [<c017264c>] (lock_acquire) from [<c096c8fc>] (_raw_spin_lock_irqsave+0x40/0x54)
[   46.260319]  r7:ee1c6a00
[   46.262691]  r6:c062a570
[   46.265247]  r5:20000113
[   46.266314]  r4:ee9da014

[   46.270393] [<c096c8bc>] (_raw_spin_lock_irqsave) from [<c062a570>] (ci_port_test_show+0x2c/0x70)
[   46.279280]  r6:eebd2000
[   46.281652]  r5:ee9da010
[   46.284207]  r4:ee9da014

[   46.286810] [<c062a544>] (ci_port_test_show) from [<c0248d04>] (seq_read+0x1ac/0x4f8)
[   46.294655]  r9:edf53e70
[   46.297028]  r8:edf53f80
[   46.299583]  r7:ee1c6a00
[   46.300650]  r6:00000001
[   46.303205]  r5:00000000
[   46.304273]  r4:eebd2000
[   46.306850] [<c0248b58>] (seq_read) from [<c039e864>] (full_proxy_read+0x54/0x6c)
[   46.314348]  r10:00000000
[   46.316808]  r9:c0a6ad30
[   46.319363]  r8:edf53f80
[   46.320430]  r7:00020000
[   46.322986]  r6:b6de3000
[   46.324053]  r5:ee1c6a00
[   46.326607]  r4:c0248b58

[   46.330505] [<c039e810>] (full_proxy_read) from [<c021ec98>] (__vfs_read+0x34/0x118)
[   46.338262]  r9:edf52000
[   46.340635]  r8:c0107fc4
[   46.343190]  r7:00020000
[   46.344257]  r6:edf53f80
[   46.346812]  r5:c039e810
[   46.347879]  r4:ee1c6a00
[   46.350447] [<c021ec64>] (__vfs_read) from [<c021fbd0>] (vfs_read+0x8c/0x11c)
[   46.357597]  r9:edf52000
[   46.359969]  r8:c0107fc4
[   46.362524]  r7:edf53f80
[   46.363592]  r6:b6de3000
[   46.366147]  r5:ee1c6a00
[   46.367214]  r4:00020000
[   46.369782] [<c021fb44>] (vfs_read) from [<c0220a4c>] (SyS_read+0x4c/0xa8)
[   46.376672]  r8:c0107fc4
[   46.379045]  r7:00020000
[   46.381600]  r6:b6de3000
[   46.382667]  r5:ee1c6a00
[   46.385222]  r4:ee1c6a00

[   46.387817] [<c0220a00>] (SyS_read) from [<c0107e20>] (ret_fast_syscall+0x0/0x1c)
[   46.395314]  r7:00000003
[   46.397687]  r6:b6de3000
[   46.400243]  r5:00020000
[   46.401310]  r4:00020000

Fixes: 26c696c678c4 ("USB: Chipidea: rename struct ci13xxx variables from udc to ci")
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: check for pic and ioapic presence before use

commit df492896e6dfb44fd1154f5402428d8e52705081 upstream.

Split irqchip allows pic and ioapic routes to be used without them being
created, which results in NULL access.  Check for NULL and avoid it.
(The setup is too racy for a nicer solutions.)

Found by syzkaller:

  general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
  Dumping ftrace buffer:
     (ftrace buffer empty)
  Modules linked in:
  CPU: 3 PID: 11923 Comm: kworker/3:2 Not tainted 4.9.0-rc5+ #27
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Workqueue: events irqfd_inject
  task: ffff88006a06c7c0 task.stack: ffff880068638000
  RIP: 0010:[...]  [...] __lock_acquire+0xb35/0x3380 kernel/locking/lockdep.c:3221
  RSP: 0000:ffff88006863ea20  EFLAGS: 00010006
  RAX: dffffc0000000000 RBX: dffffc0000000000 RCX: 0000000000000000
  RDX: 0000000000000039 RSI: 0000000000000000 RDI: 1ffff1000d0c7d9e
  RBP: ffff88006863ef58 R08: 0000000000000001 R09: 0000000000000000
  R10: 00000000000001c8 R11: 0000000000000000 R12: ffff88006a06c7c0
  R13: 0000000000000001 R14: ffffffff8baab1a0 R15: 0000000000000001
  FS:  0000000000000000(0000) GS:ffff88006d100000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00000000004abdd0 CR3: 000000003e2f2000 CR4: 00000000000026e0
  Stack:
   ffffffff894d0098 1ffff1000d0c7d56 ffff88006863ecd0 dffffc0000000000
   ffff88006a06c7c0 0000000000000000 ffff88006863ecf8 0000000000000082
   0000000000000000 ffffffff815dd7c1 ffffffff00000000 ffffffff00000000
  Call Trace:
   [...] lock_acquire+0x2a2/0x790 kernel/locking/lockdep.c:3746
   [...] __raw_spin_lock include/linux/spinlock_api_smp.h:144
   [...] _raw_spin_lock+0x38/0x50 kernel/locking/spinlock.c:151
   [...] spin_lock include/linux/spinlock.h:302
   [...] kvm_ioapic_set_irq+0x4c/0x100 arch/x86/kvm/ioapic.c:379
   [...] kvm_set_ioapic_irq+0x8f/0xc0 arch/x86/kvm/irq_comm.c:52
   [...] kvm_set_irq+0x239/0x640 arch/x86/kvm/../../../virt/kvm/irqchip.c:101
   [...] irqfd_inject+0xb4/0x150 arch/x86/kvm/../../../virt/kvm/eventfd.c:60
   [...] process_one_work+0xb40/0x1ba0 kernel/workqueue.c:2096
   [...] worker_thread+0x214/0x18a0 kernel/workqueue.c:2230
   [...] kthread+0x328/0x3e0 kernel/kthread.c:209
   [...] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: 49df6397edfc ("KVM: x86: Split the APIC from the rest of IRQCHIP.")
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: drop error recovery in em_jmp_far and em_ret_far

commit 2117d5398c81554fbf803f5fd1dc55eb78216c0c upstream.

em_jmp_far and em_ret_far assumed that setting IP can only fail in 64
bit mode, but syzkaller proved otherwise (and SDM agrees).
Code segment was restored upon failure, but it was left uninitialized
outside of long mode, which could lead to a leak of host kernel stack.
We could have fixed that by always saving and restoring the CS, but we
take a simpler approach and just break any guest that manages to fail
as the error recovery is error-prone and modern CPUs don't need emulator
for this.

Found by syzkaller:

  WARNING: CPU: 2 PID: 3668 at arch/x86/kvm/emulate.c:2217 em_ret_far+0x428/0x480
  Kernel panic - not syncing: panic_on_warn set ...

  CPU: 2 PID: 3668 Comm: syz-executor Not tainted 4.9.0-rc4+ #49
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
   [...]
  Call Trace:
   [...] __dump_stack lib/dump_stack.c:15
   [...] dump_stack+0xb3/0x118 lib/dump_stack.c:51
   [...] panic+0x1b7/0x3a3 kernel/panic.c:179
   [...] __warn+0x1c4/0x1e0 kernel/panic.c:542
   [...] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
   [...] em_ret_far+0x428/0x480 arch/x86/kvm/emulate.c:2217
   [...] em_ret_far_imm+0x17/0x70 arch/x86/kvm/emulate.c:2227
   [...] x86_emulate_insn+0x87a/0x3730 arch/x86/kvm/emulate.c:5294
   [...] x86_emulate_instruction+0x520/0x1ba0 arch/x86/kvm/x86.c:5545
   [...] emulate_instruction arch/x86/include/asm/kvm_host.h:1116
   [...] complete_emulated_io arch/x86/kvm/x86.c:6870
   [...] complete_emulated_mmio+0x4e9/0x710 arch/x86/kvm/x86.c:6934
   [...] kvm_arch_vcpu_ioctl_run+0x3b7a/0x5a90 arch/x86/kvm/x86.c:6978
   [...] kvm_vcpu_ioctl+0x61e/0xdd0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2557
   [...] vfs_ioctl fs/ioctl.c:43
   [...] do_vfs_ioctl+0x18c/0x1040 fs/ioctl.c:679
   [...] SYSC_ioctl fs/ioctl.c:694
   [...] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:685
   [...] entry_SYSCALL_64_fastpath+0x1f/0xc2

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far jumps")
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iommu/vt-d: Fix IOMMU lookup for SR-IOV Virtual Functions

commit 1c387188c60f53b338c20eee32db055dfe022a9b upstream.

The VT-d specification (§8.3.3) says:
    ‘Virtual Functions’ of a ‘Physical Function’ are under the scope
    of the same remapping unit as the ‘Physical Function’.

The BIOS is not required to list all the possible VFs in the scope
tables, and arguably *shouldn't* make any attempt to do so, since there
could be a huge number of them.

This has been broken basically for ever — the VF is never going to match
against a specific unit's scope, so it ends up being assigned to the
INCLUDE_ALL IOMMU. Which was always actually correct by coincidence, but
now we're looking at Root-Complex integrated devices with SR-IOV support
it's going to start being wrong.

Fix it to simply use pci_physfn() before doing the lookup for PCI devices.

Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iommu/vt-d: Fix PASID table allocation

commit 910170442944e1f8674fd5ddbeeb8ccd1877ea98 upstream.

Somehow I ended up with an off-by-three error in calculating the size of
the PASID and PASID State tables, which triggers allocations failures as
those tables unfortunately have to be physically contiguous.

In fact, even the *correct* maximum size of 8MiB is problematic and is
wont to lead to allocation failures. Since I have extracted a promise
that this *will* be fixed in hardware, I'm happy to limit it on the
current hardware to a maximum of 0x20000 PASIDs, which gives us 1MiB
tables — still not ideal, but better than before.

Reported by Mika Kuoppala <mika.kuoppala@linux.intel.com> and also by
Xunlei Pang <xlpang@redhat.com> who submitted a simpler patch to fix
only the allocation (and not the free) to the "correct" limit... which
was still problematic.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/analogix: dp: remove some function which cause loader logo flash

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