UPSTREAM: regulator: rk808: Migrate to regulator core's simplified DT parsing code

A common simplified DT parsing code for regulators was introduced in
commit a0c7b164ad11 ("regulator: of: Provide simplified DT parsing
method")

While at it also added RK8XX_DESC and RK8XX_DESC_SWITCH macros for the
regulator_desc struct initialization. This just makes the driver more compact.

Change-Id: I5c1211decf37d27a68167be9b6354834532cc87b
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 9e9daa0a67d59df432664cdca1cf4659057fd00c)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: regulator: rk808: Add rk808_reg_ops_ranges for LDO3

LDO_REG3 descriptor is using linear_ranges.
Add and use proper ops for LDO_REG3.

Change-Id: Iad515fd23e7b3bca6248739a54335a71eed01238
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 129d7cf98f5c739014ae5aa0311e48f6a64b0758)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: regulator: rk808: remove unused rk808_reg_ops_ranges

After removing all uses of the range operations in a recent patch,
we get a warning about the symbol not being referenced anywhere:

drivers/regulator/rk808-regulator.c:306:29: 'rk808_reg_ops_ranges' defined but not used

This removes the now-unused structure along with the
rk808_set_suspend_voltage_range function that is only referenced from
rk808_reg_ops_ranges.

Fixes: afcd666d9db0 ("regulator: rk808: remove linear range definitions with a single range")
Change-Id: I565c91186ab5d7457a62b3bc4b4896a08f39dd2e
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 4a5ed8c1adc39f86a2887183c71b007bc962fdce)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

UPSTREAM: regulator: rk808: remove linear range definitions with a single range

The driver was using only linear ranges. Now we remove linear range
definitions with a single range. So we have to add an ops struct for
ranges and adjust all other ops functions accordingly.

Change-Id: I6b2dd5e035832f9460ec8a24b5214204f7a930b7
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit afcd666d9db0ebfbf2751cce1e07b548547ca82e)
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>

arm64: dts: rockchip: add dts file for rk3399-evb-rev3-android

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

arm64: dts: rockchip: cleanup rk3399-android.dtsi

default enable rkvdec and vpu.
rga is default on, remove duplicate configuration.

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

drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz

add 594Mhz configuration parameters in rockchip_phy_config

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

drm/edid: Add 3840x2160@60hz modes

Add 3840x2160@60hz modes in edid_4k_modes[] array.

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

FROMLIST: drm: edid: HDMI 2.0 HF-VSDB block parsing

Adds parsing for HDMI 2.0 'HDMI Forum Vendor
Specific Data Block'. This block is present in
some HDMI 2.0 EDID's and gives information about
scrambling support, SCDC, 3D Views, and others.

Parsed parameters are stored in drm_connector
structure.
(am from: https://patchwork.kernel.org/patch/9273645)

Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Change-Id: I5a1485b79a407fd27ac4754827de318175bb8f6a
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

FROMLIST: drm: Add SCDC helpers

SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.

(am from: https://patchwork.kernel.org/patch/7258251/)

Change-Id: I378bc2b465a720ccfede35a93bce0d9371e78f78
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>

dt-bindings: rockchip: add missing vop document

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

ARM64: dts: rk3328: add vop display node

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

drm/rockchip: support rk3328 vop

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

drm/rockchip: vop: get rid of max_output_fb

max_output_fb is similar to max_display_output

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

drm/rockchip: vop: improve and add more info to vop sysfs

cat /sys/kernel/debug/dri/0/summary:

VOP [ff900000.vop]: ACTIVE
    Connector: DSI
        bus_format[0] output_mode[0]
    Display mode: 1200x1920p60
        clk[159390] real_clk[159390] type[8] flag[a]
        H: 1200 1280 1281 1341
        V: 1920 1955 1956 1981
    win0-0: DISABLED
    win1-0: DISABLED
    win2-0: ACTIVE
        format: XB24 little-endian (0x34324258)
        zpos: 0
        src: pos[0x0] rect[1200x1920]
        dst: pos[0x0] rect[1200x1920]
        buf[0]: addr: 0x0000000002d3a000 pitch: 4800 offset: 0
    win2-0: DISABLED
    win2-1: DISABLED
    win2-2: DISABLED
    win3-0: DISABLED
    win3-0: DISABLED
    win3-1: DISABLED
    win3-2: DISABLED
VOP [ff8f0000.vop]: DISABLED

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

drm: support drm_get_connector_name

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

arm64: dts: rockchip: add cpu's power coefficient for rk3328

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

arm64: dts: rockchip: add tsadc and thermal basic config for rk3328

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

thermal: rockchip: add rk3328 support

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

arm64: dts: rockchip: complete cpufreq config data for rk3328

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

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

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

 This is the 4.4.52 stable release

Linux 4.4.52

kvm: vmx: ensure VMCS is current while enabling PML

commit 4e59516a12a6ef6dcb660cb3a3f70c64bd60cfec upstream.

Between loading the new VMCS and enabling PML, the CPU was unpinned.
If the vCPU thread were migrated to another CPU in the interim (e.g.,
due to preemption or sleeping alloc_page), then the VMWRITEs to enable
PML would target the wrong VMCS -- or no VMCS at all:

  [ 2087.266950] vmwrite error: reg 200e value 3fe1d52000 (err -506126336)
  [ 2087.267062] vmwrite error: reg 812 value 1ff (err 511)
  [ 2087.267125] vmwrite error: reg 401e value 12229c00 (err 304258048)

This patch ensures that the VMCS remains current while enabling PML by
doing the VMWRITEs while the CPU is pinned. Allocation of the PML buffer
is hoisted out of the critical section.

Signed-off-by: Peter Feiner <pfeiner@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Herongguang (Stephen)" <herongguang.he@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "usb: chipidea: imx: enable CI_HDRC_SET_NON_ZERO_TTHA"

commit 1bc7da87c7410c6990c3251589e3854e64c55af2 upstream.

This reverts commit e765bfb73ff7.

In the most of cases, we only use one transaction per frame and the
frame rate may be high, If the platforms want to support multiple
transactions but less frame rate cases like [1] and [2], it can set
"non-zero-ttctrl-ttha" at dts.

[1] http://www.spinics.net/lists/linux-usb/msg123125.html
[2] http://www.spinics.net/lists/linux-usb/msg118679.html

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Cc: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down

commit 575ddce0507789bf9830d089557d2199d2f91865 upstream.

In the function rtl_usb_start we pre-allocate a certain number of urbs
for RX path but they will not be freed when calling rtl_usb_stop. This
results in leaking urbs when doing ifconfig up and down. Eventually,
the system has no available urbs.

Signed-off-by: Michael Schenk <michael.schenk@albis-elcon.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

block: fix double-free in the failure path of cgwb_bdi_init()

commit 5f478e4ea5c5560b4e40eb136991a09f9389f331 upstream.

When !CONFIG_CGROUP_WRITEBACK, bdi has single bdi_writeback_congested
at bdi->wb_congested.  cgwb_bdi_init() allocates it with kzalloc() and
doesn't do further initialization.  This usually works fine as the
reference count gets bumped to 1 by wb_init() and the put from
wb_exit() releases it.

However, when wb_init() fails, it puts the wb base ref automatically
freeing the wb and the explicit kfree() in cgwb_bdi_init() error path
ends up trying to free the same pointer the second time causing a
double-free.

Fix it by explicitly initilizing the refcnt to 1 and putting the base
ref from cgwb_bdi_destroy().

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: a13f35e87140 ("writeback: don't embed root bdi_writeback_congested in bdi_writeback")
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

goldfish: Sanitize the broken interrupt handler

commit 6cf18e6927c0b224f972e3042fb85770d63cb9f8 upstream.

This interrupt handler is broken in several ways:

  - It loops forever when the op code is not decodeable

  - It never returns IRQ_HANDLED because the only way to exit the loop
    returns IRQ_NONE unconditionally.

The whole concept of this is broken. Creating devices in an interrupt
handler is beyond any point of sanity.

Make it at least behave halfways sane so accidental users do not have to
deal with a hard to debug lockup.

Fixes: e809c22b8fb028 ("goldfish: add the goldfish virtual bus")
Reported-by: Gabriel C <nix.or.die@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/platform/goldfish: Prevent unconditional loading

commit 47512cfd0d7a8bd6ab71d01cd89fca19eb2093eb upstream.

The goldfish platform code registers the platform device unconditionally
which causes havoc in several ways if the goldfish_pdev_bus driver is
enabled:

 - Access to the hardcoded physical memory region, which is either not
   available or contains stuff which is completely unrelated.

 - Prevents that the interrupt of the serial port can be requested

 - In case of a spurious interrupt it goes into a infinite loop in the
   interrupt handler of the pdev_bus driver (which needs to be fixed
   seperately).

Add a 'goldfish' command line option to make the registration opt-in when
the platform is compiled in.

I'm seriously grumpy about this engineering trainwreck, which has seven
SOBs from Intel developers for 50 lines of code. And none of them figured
out that this is broken. Impressive fail!

Fixes: ddd70cf93d78 ("goldfish: platform device for x86")
Reported-by: Gabriel C <nix.or.die@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: ark3116: fix register-accessor error handling

commit 9fef37d7cf170522fb354d6d0ea6de09b9b16678 upstream.

The current implementation failed to detect short transfers, something
which could lead to bits of the uninitialised heap transfer buffer
leaking to user space.

Fixes: 149fc791a452 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.")
Fixes: f4c1e8d597d1 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: opticon: fix CTS retrieval at open

commit 2eee05020a0e7ee7c04422cbacdb07859e45dce6 upstream.

The opticon driver used a control request at open to trigger a CTS
status notification to be sent over the bulk-in pipe. When the driver
was converted to using the generic read implementation, an inverted test
prevented this request from being sent, something which could lead to
TIOCMGET reporting an incorrect CTS state.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 7a6ee2b02751 ("USB: opticon: switch to generic read implementation")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: spcp8x5: fix modem-status handling

commit 5ed8d41023751bdd3546f2fe4118304357efe8d2 upstream.

Make sure to detect short control transfers and return zero on success
when retrieving the modem status.

This fixes the TIOCMGET implementation which since e1ed212d8593 ("USB:
spcp8x5: add proper modem-status support") has returned TIOCM_LE on
successful retrieval, and avoids leaking bits from the stack on short
transfers.

This also fixes the carrier-detect implementation which since the above
mentioned commit unconditionally has returned true.

Fixes: e1ed212d8593 ("USB: spcp8x5: add proper modem-status support")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: ftdi_sio: fix line-status over-reporting

commit a6bb1e17a39818b01b55d8e6238b4b5f06d55038 upstream.

FTDI devices use a receive latency timer to periodically empty the
receive buffer and report modem and line status (also when the buffer is
empty).

When a break or error condition is detected the corresponding status
flags will be set on a packet with nonzero data payload and the flags
are not updated until the break is over or further characters are
received.

In order to avoid over-reporting break and error conditions, these flags
must therefore only be processed for packets with payload.

This specifically fixes the case where after an overrun, the error
condition is continuously reported and NULL-characters inserted until
further data is received.

Reported-by: Michael Walle <michael@walle.cc>
Fixes: 72fda3ca6fc1 ("USB: serial: ftd_sio: implement sysrq handling on
break")
Fixes: 166ceb690750 ("USB: ftdi_sio: clean up line-status handling")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: ftdi_sio: fix extreme low-latency setting

commit c6dce2626606ef16434802989466636bc28c1419 upstream.

Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") the FTDI driver has been using a receive latency-timer value of
1 ms instead of the device default of 16 ms.

The latency timer is used to periodically empty a non-full receive
buffer, but a status header is always sent when the timer expires
including when the buffer is empty. This means that a two-byte bulk
message is received every millisecond also for an otherwise idle port as
long as it is open.

Let's restore the pre-2009 behaviour which reduces the rate of the
status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to
62.5 Hz) by not setting ASYNC_LOW_LATENCY by default.

Anyone willing to pay the price for the minimum-latency behaviour should
set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool
such as setserial (e.g. setserial /dev/ttyUSB0 low_latency).

Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove
tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but
to set a minimal latency timer.

Reported-by: Antoine Aubert <a.aubert@overkiz.com>
Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: ftdi_sio: fix modem-status error handling

commit 427c3a95e3e29e65f59d99aaf320d7506f3eed57 upstream.

Make sure to detect short responses when fetching the modem status in
order to avoid parsing uninitialised buffer data and having bits of it
leak to user space.

Note that we still allow for short 1-byte responses.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: cp210x: add new IDs for GE Bx50v3 boards

commit 9a593656def0dc2f6c227851e8e602077267a5f1 upstream.

Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design
change.

Signed-off-by: Ken Lin <yungching0725@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: mos7840: fix another NULL-deref at open

commit 5182c2cf2a9bfb7f066ef0bdd2bb6330b94dd74e upstream.

Fix another NULL-pointer dereference at open should a malicious device
lack an interrupt-in endpoint.

Note that the driver has a broken check for an interrupt-in endpoint
which means that an interrupt URB has never even been submitted.

Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: serial: msm: Fix module autoload

commit abe81f3b8ed2996e1712d26d38ff6b73f582c616 upstream.

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/tty/serial/msm_serial.ko | grep alias
$

After this patch:

$ modinfo drivers/tty/serial/msm_serial.ko | grep alias
alias:          of:N*T*Cqcom,msm-uartdmC*
alias:          of:N*T*Cqcom,msm-uartdm
alias:          of:N*T*Cqcom,msm-uartC*
alias:          of:N*T*Cqcom,msm-uart

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: socket: fix recvmmsg not returning error from sock_error

[ Upstream commit e623a9e9dec29ae811d11f83d0074ba254aba374 ]

Commit 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path"),
changed the exit path of recvmmsg to always return the datagrams
variable and modified the error paths to set the variable to the error
code returned by recvmsg if necessary.

However in the case sock_error returned an error, the error code was
then ignored, and recvmmsg returned 0.

Change the error path of recvmmsg to correctly return the error code
of sock_error.

The bug was triggered by using recvmmsg on a CAN interface which was
not up. Linux 4.6 and later return 0 in this case while earlier
releases returned -ENETDOWN.

Fixes: 34b88a68f26a ("net: Fix use after free in the recvmmsg exit path")
Signed-off-by: Maxime Jayat <maxime.jayat@mobile-devices.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ip: fix IP_CHECKSUM handling

[ Upstream commit ca4ef4574f1ee5252e2cd365f8f5d5bafd048f32 ]

The skbs processed by ip_cmsg_recv() are not guaranteed to
be linear e.g. when sending UDP packets over loopback with
MSGMORE.
Using csum_partial() on [potentially] the whole skb len
is dangerous; instead be on the safe side and use skb_checksum().

Thanks to syzkaller team to detect the issue and provide the
reproducer.

v1 -> v2:
 - move the variable declaration in a tighter scope

Fixes: ad6f939ab193 ("ip: Add offset parameter to ip_cmsg_recv")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

irda: Fix lockdep annotations in hashbin_delete().

[ Upstream commit 4c03b862b12f980456f9de92db6d508a4999b788 ]

A nested lock depth was added to the hasbin_delete() code but it
doesn't actually work some well and results in tons of lockdep splats.

Fix the code instead to properly drop the lock around the operation
and just keep peeking the head of the hashbin queue.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dccp: fix freeing skb too early for IPV6_RECVPKTINFO

[ Upstream commit 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 ]

In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet
is forcibly freed via __kfree_skb in dccp_rcv_state_process if
dccp_v6_conn_request successfully returns.

However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb
is saved to ireq->pktopts and the ref count for skb is incremented in
dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed
in dccp_rcv_state_process.

Fix by calling consume_skb instead of doing goto discard and therefore
calling __kfree_skb.

Similar fixes for TCP:

fb7e2399ec17f1004c0e0ccfd17439f8759ede01 [TCP]: skb is unexpectedly freed.
0aea76d35c9651d55bbaf746e7914e5f9ae5a25d tcp: SYN packets are now
simply consumed

Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

packet: Do not call fanout_release from atomic contexts

[ Upstream commit 2bd624b4611ffee36422782d16e1c944d1351e98 ]

Commit 6664498280cf ("packet: call fanout_release, while UNREGISTERING a
netdev"), unfortunately, introduced the following issues.

1. calling mutex_lock(&fanout_mutex) (fanout_release()) from inside
rcu_read-side critical section. rcu_read_lock disables preemption, most often,
which prohibits calling sleeping functions.

[  ] include/linux/rcupdate.h:560 Illegal context switch in RCU read-side critical section!
[  ]
[  ] rcu_scheduler_active = 1, debug_locks = 0
[  ] 4 locks held by ovs-vswitchd/1969:
[  ]  #0:  (cb_lock){++++++}, at: [<ffffffff8158a6c9>] genl_rcv+0x19/0x40
[  ]  #1:  (ovs_mutex){+.+.+.}, at: [<ffffffffa04878ca>] ovs_vport_cmd_del+0x4a/0x100 [openvswitch]
[  ]  #2:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81564157>] rtnl_lock+0x17/0x20
[  ]  #3:  (rcu_read_lock){......}, at: [<ffffffff81614165>] packet_notifier+0x5/0x3f0
[  ]
[  ] Call Trace:
[  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
[  ]  [<ffffffff810c9077>] lockdep_rcu_suspicious+0x107/0x110
[  ]  [<ffffffff810a2da7>] ___might_sleep+0x57/0x210
[  ]  [<ffffffff810a2fd0>] __might_sleep+0x70/0x90
[  ]  [<ffffffff8162e80c>] mutex_lock_nested+0x3c/0x3a0
[  ]  [<ffffffff810de93f>] ? vprintk_default+0x1f/0x30
[  ]  [<ffffffff81186e88>] ? printk+0x4d/0x4f
[  ]  [<ffffffff816106dd>] fanout_release+0x1d/0xe0
[  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0

2. calling mutex_lock(&fanout_mutex) inside spin_lock(&po->bind_lock).
"sleeping function called from invalid context"

[  ] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
[  ] in_atomic(): 1, irqs_disabled(): 0, pid: 1969, name: ovs-vswitchd
[  ] INFO: lockdep is turned off.
[  ] Call Trace:
[  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
[  ]  [<ffffffff810a2f52>] ___might_sleep+0x202/0x210
[  ]  [<ffffffff810a2fd0>] __might_sleep+0x70/0x90
[  ]  [<ffffffff8162e80c>] mutex_lock_nested+0x3c/0x3a0
[  ]  [<ffffffff816106dd>] fanout_release+0x1d/0xe0
[  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0

3. calling dev_remove_pack(&fanout->prot_hook), from inside
spin_lock(&po->bind_lock) or rcu_read-side critical-section. dev_remove_pack()
-> synchronize_net(), which might sleep.

[  ] BUG: scheduling while atomic: ovs-vswitchd/1969/0x00000002
[  ] INFO: lockdep is turned off.
[  ] Call Trace:
[  ]  [<ffffffff813770c1>] dump_stack+0x85/0xc4
[  ]  [<ffffffff81186274>] __schedule_bug+0x64/0x73
[  ]  [<ffffffff8162b8cb>] __schedule+0x6b/0xd10
[  ]  [<ffffffff8162c5db>] schedule+0x6b/0x80
[  ]  [<ffffffff81630b1d>] schedule_timeout+0x38d/0x410
[  ]  [<ffffffff810ea3fd>] synchronize_sched_expedited+0x53d/0x810
[  ]  [<ffffffff810ea6de>] synchronize_rcu_expedited+0xe/0x10
[  ]  [<ffffffff8154eab5>] synchronize_net+0x35/0x50
[  ]  [<ffffffff8154eae3>] dev_remove_pack+0x13/0x20
[  ]  [<ffffffff8161077e>] fanout_release+0xbe/0xe0
[  ]  [<ffffffff81614459>] packet_notifier+0x2f9/0x3f0

4. fanout_release() races with calls from different CPU.

To fix the above problems, remove the call to fanout_release() under
rcu_read_lock(). Instead, call __dev_remove_pack(&fanout->prot_hook) and
netdev_run_todo will be happy that &dev->ptype_specific list is empty. In order
to achieve this, I moved dev_{add,remove}_pack() out of fanout_{add,release} to
__fanout_{link,unlink}. So, call to {,__}unregister_prot_hook() will make sure
fanout->prot_hook is removed as well.

Fixes: 6664498280cf ("packet: call fanout_release, while UNREGISTERING a netdev")
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Anoob Soman <anoob.soman@citrix.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

packet: fix races in fanout_add()

[ Upstream commit d199fab63c11998a602205f7ee7ff7c05c97164b ]

Multiple threads can call fanout_add() at the same time.

We need to grab fanout_mutex earlier to avoid races that could
lead to one thread freeing po->rollover that was set by another thread.

Do the same in fanout_release(), for peace of mind, and to help us
finding lockdep issues earlier.

Fixes: dc99f600698d ("packet: Add fanout support.")
Fixes: 0648ab70afe6 ("packet: rollover prepare: per-socket state")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/llc: avoid BUG_ON() in skb_orphan()

[ Upstream commit 8b74d439e1697110c5e5c600643e823eb1dd0762 ]

It seems nobody used LLC since linux-3.12.

Fortunately fuzzers like syzkaller still know how to run this code,
otherwise it would be no fun.

Setting skb->sk without skb->destructor leads to all kinds of
bugs, we now prefer to be very strict about it.

Ideally here we would use skb_set_owner() but this helper does not exist yet,
only CAN seems to have a private helper for that.

Fixes: 376c7311bdb6 ("net: add a temporary sanity check in skb_orphan()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

blk-mq: really fix plug list flushing for nomerge queues

commit 87c279e613f848c691111b29d49de8df3f4f56da upstream.

Commit 0809e3ac6231 ("block: fix plug list flushing for nomerge queues")
updated blk_mq_make_request() to set request_count even when
blk_queue_nomerges() returns true. However, blk_mq_make_request() only
does limited plugging and doesn't use request_count;
blk_sq_make_request() is the one that should have been fixed. Do that
and get rid of the unnecessary work in the mq version.

Fixes: 0809e3ac6231 ("block: fix plug list flushing for nomerge queues")
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rtc: interface: ignore expired timers when enqueuing new timers

commit 2b2f5ff00f63847d95adad6289bd8b05f5983dd5 upstream.

This patch fixes a RTC wakealarm issue, namely, the event fires during
hibernate and is not cleared from the list, causing hwclock to block.

The current enqueuing does not trigger an alarm if any expired timers
already exist on the timerqueue. This can occur when a RTC wake alarm
is used to wake a machine out of hibernate and the resumed state has
old expired timers that have not been removed from the timer queue.
This fix skips over any expired timers and triggers an alarm if there
are no pending timers on the timerqueue. Note that the skipped expired
timer will get reaped later on, so there is no need to clean it up
immediately.

The issue can be reproduced by putting a machine into hibernate and
waking it with the RTC wakealarm.  Running the example RTC test program
from tools/testing/selftests/timers/rtctest.c after the hibernate will
block indefinitely.  With the fix, it no longer blocks after the
hibernate resume.

BugLink: http://bugs.launchpad.net/bugs/1333569
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

rtlwifi: rtl_usb: Fix missing entry in USB driver's private data

commit 60f59ce0278557f7896d5158ae6d12a4855a72cc upstream.

These drivers need to be able to reference "struct ieee80211_hw" from
the driver's private data, and vice versa. The USB driver failed to
store the address of ieee80211_hw in the private data. Although this
bug has been present for a long time, it was not exposed until
commit ba9f93f82aba ("rtlwifi: Fix enter/exit power_save").

Fixes: ba9f93f82aba ("rtlwifi: Fix enter/exit power_save")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/rockchip: dw_hdmi: use crtc_clock as vpll clock rate

adjusted_mode.crtc_clock is the real pixel clock rate.

Change-Id: Iac242b89e3144bc53c40170c2cec0c0913ef6ee0
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

drm: bridge/dw_hdmi: support DRM_MODE_FLAG_DBLCLK

Change-Id: I66d9456d6bde38fcf17d5cd5f6394517e4308a68
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>

drm/rockchip: vop: support DRM_MODE_FLAG_DBLCLK

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

mfd: rk805: fix submodules node available match error

include: rtc, gpio, pwrkey

Change-Id: I3c91e2ade911017125c80008c122f4bf484767f3
Signed-off-by: chenjh <chenjh@rock-chips.com>

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

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

 This is the 4.4.51 stable release

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

Change-Id: Ie3c9cadb3cfbd9d4080ff54c0b65933f347e093a
Signed-off-by: Zhangbin Tong <zebulun.tong@rock-chips.com>

arm64: dts: rockchip: clk: rk3399: support dual pll for drm linux

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

drm: print framebuffer size when plane check fail

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

Linux 4.4.51

mmc: core: fix multi-bit bus width without high-speed mode

commit 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 upstream.

Commit 577fb13199b1 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().

However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.

This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.

Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.

Tested with a Zynq-7000 PicoZed 7020 board.

Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
[anssi.hannula@bitwise.fi: backported for the different err variable
 check on v4.4 and tested]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bcache: Make gc wakeup sane, remove set_task_state()

commit be628be09563f8f6e81929efbd7cf3f45c344416 upstream.

Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ntb_transport: Pick an unused queue

commit 8fcd0950c021d7be8493280541332b924b9de962 upstream.

Fix typo causing ntb_transport_create_queue to select the first
queue every time, instead of using the next free queue.

Signed-off-by: Thomas VanSelus <tvanselus@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Fixes: fce8a7bb5 ("PCI-Express Non-Transparent Bridge Support")
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

NTB: ntb_transport: fix debugfs_remove_recursive

commit dd62245e73de9138333cb0e7a42c8bc1215c3ce6 upstream.

The call to debugfs_remove_recursive(qp->debugfs_dir) of the sub-level
directory must not be later than
debugfs_remove_recursive(nt_debugfs_dir) of the top-level directory.
Otherwise, the sub-level directory will not exist, and it would be
invalid (panic) to attempt to remove it.  This removes the top-level
directory last, after sub-level directories have been cleaned up.

Signed-off-by: Allen Hubbe <Allen.Hubbe@dell.com>
Fixes: e26a5843f ("NTB: Split ntb_hw_intel and ntb_transport drivers")
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

printk: use rcuidle console tracepoint

commit fc98c3c8c9dcafd67adcce69e6ce3191d5306c9c upstream.

Use rcuidle console tracepoint because, apparently, it may be issued
from an idle CPU:

  hw-breakpoint: Failed to enable monitor mode on CPU 0.
  hw-breakpoint: CPU 0 failed to disable vector catch

  ===============================
  [ ERR: suspicious RCU usage.  ]
  4.10.0-rc8-next-20170215+ #119 Not tainted
  -------------------------------
  ./include/trace/events/printk.h:32 suspicious rcu_dereference_check() usage!

  other info that might help us debug this:

  RCU used illegally from idle CPU!
  rcu_scheduler_active = 2, debug_locks = 0
  RCU used illegally from extended quiescent state!
  2 locks held by swapper/0/0:
   #0:  (cpu_pm_notifier_lock){......}, at: [<c0237e2c>] cpu_pm_exit+0x10/0x54
   #1:  (console_lock){+.+.+.}, at: [<c01ab350>] vprintk_emit+0x264/0x474

  stack backtrace:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc8-next-20170215+ #119
  Hardware name: Generic OMAP4 (Flattened Device Tree)
    console_unlock
    vprintk_emit
    vprintk_default
    printk
    reset_ctrl_regs
    dbg_cpu_pm_notify
    notifier_call_chain
    cpu_pm_exit
    omap_enter_idle_coupled
    cpuidle_enter_state
    cpuidle_enter_state_coupled
    do_idle
    cpu_startup_entry
    start_kernel

This RCU warning, however, is suppressed by lockdep_off() in printk().
lockdep_off() increments the ->lockdep_recursion counter and thus
disables RCU_LOCKDEP_WARN() and debug_lockdep_rcu_enabled(), which want
lockdep to be enabled "current->lockdep_recursion == 0".

Link: http://lkml.kernel.org/r/20170217015932.11898-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <rmk@armlinux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user()

commit 9e3440481845b2ec22508f60837ee2cab2b6054f upstream.

The 64-bit get_user() wasn't clearing the high word due to a typo in the
error handler. The exception handler entry was already correct, though.
Noticed during recent usercopy test additions in lib/test_user_copy.c.

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

futex: Move futex_init() to core_initcall

commit 25f71d1c3e98ef0e52371746220d66458eac75bc upstream.

The UEVENT user mode helper is enabled before the initcalls are executed
and is available when the root filesystem has been mounted.

The user mode helper is triggered by device init calls and the executable
might use the futex syscall.

futex_init() is marked __initcall which maps to device_initcall, but there
is no guarantee that futex_init() is invoked _before_ the first device init
call which triggers the UEVENT user mode helper.

If the user mode helper uses the futex syscall before futex_init() then the
syscall crashes with a NULL pointer dereference because the futex subsystem
has not been initialized yet.

Move futex_init() to core_initcall so futexes are initialized before the
root filesystem is mounted and the usermode helper becomes available.

[ tglx: Rewrote changelog ]

Signed-off-by: Yang Yang <yang.yang29@zte.com.cn>
Cc: jiang.biao2@zte.com.cn
Cc: jiang.zhengxiong@zte.com.cn
Cc: zhong.weidong@zte.com.cn
Cc: deng.huali@zte.com.cn
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1483085875-6130-1-git-send-email-yang.yang29@zte.com.cn
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/dp/mst: fix kernel oops when turning off secondary monitor

commit bb08c04dc867b5f392caec635c097d5d5fcd8c9f upstream.

100% reproducible issue found on SKL SkullCanyon NUC with two external
DP daisy-chained monitors in DP/MST mode. When turning off or changing
the input of the second monitor the machine stops with a kernel
oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly.

This issue is traced to an inconsistent control flow in
drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the
same time as 'req_payload.num_slots' is set to zero, but the pointer is
dereferenced even when req_payload.num_slot is zero.

The problematic dereference was introduced in commit dfda0df34
("drm/mst: rework payload table allocation to conform better") and may
impact all versions since v3.18

The fix suggested by Chris Wilson removes the kernel oops and was found to
work well after 10mn of monkey-testing with the second monitor power and
input buttons

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990
Fixes: dfda0df34264 ("drm/mst: rework payload table allocation to conform better.")
Cc: Dave Airlie <airlied@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487076561-2169-1-git-send-email-jani.nikula@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursor

commit d74c67dd7800fc7aae381f272875c337f268806c upstream.

The crtc_h/vdisplay fields may not match the CRTC viewport dimensions
with special modes such as interlaced ones.

Fixes the HW cursor disappearing in the bottom half of the screen with
interlaced modes.

Fixes: 6b16cf7785a4 ("drm/radeon: Hide the HW cursor while it's out of bounds")
Reported-by: Ashutosh Kumar <ashutosh.kumar@amd.com>
Tested-by: Sonny Jiang <sonny.jiang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: elan_i2c - add ELAN0605 to the ACPI table

commit 722c5ac708b4f5c1fcfad5fed4c95234c8b06590 upstream.

ELAN0605 has been confirmed to be a variant of ELAN0600, which is
blacklisted in the hid-core to be managed by elan_i2c. This device can be
found in Lenovo ideapad 310s (80U4000).

Signed-off-by: Hiroka IHARA <ihara_h@live.jp>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix missing sanity check in /dev/sg

commit 137d01df511b3afe1f05499aea05f3bafc0fb221 upstream.

What happens is that a write to /dev/sg is given a request with non-zero
->iovec_count combined with zero ->dxfer_len.  Or with ->dxferp pointing
to an array full of empty iovecs.

Having write permission to /dev/sg shouldn't be equivalent to the
ability to trigger BUG_ON() while holding spinlocks...

Found by Dmitry Vyukov and syzkaller.

[ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the
  underlying issue.  - Linus ]

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: don't BUG_ON() empty DMA transfers

commit fd3fc0b4d7305fa7246622dcc0dec69c42443f45 upstream.

Don't crash the machine just because of an empty transfer. Use WARN_ON()
combined with returning an error.

Found by Dmitry Vyukov and syzkaller.

[ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root
  cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON()
  might still be a cause of excessive log spamming.

  NOTE! If this warning ever triggers, we may end up leaking resources,
  since this doesn't bother to try to clean the command up. So this
  WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is
  much worse.

  People really need to stop using BUG_ON() for "this shouldn't ever
  happen". It makes pretty much any bug worse.     - Linus ]

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: James Bottomley <jejb@linux.vnet.ibm.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fuse: fix use after free issue in fuse_dev_do_read()

commit 6ba4d2722d06960102c981322035239cd66f7316 upstream.

There is a potential race between fuse_dev_do_write()
and request_wait_answer() contexts as shown below:

TASK 1:
__fuse_request_send():
  |--spin_lock(&fiq->waitq.lock);
  |--queue_request();
  |--spin_unlock(&fiq->waitq.lock);
  |--request_wait_answer():
       |--if (test_bit(FR_SENT, &req->flags))
       <gets pre-empted after it is validated true>
                                   TASK 2:
                                   fuse_dev_do_write():
                                     |--clears bit FR_SENT,
                                     |--request_end():
                                        |--sets bit FR_FINISHED
                                        |--spin_lock(&fiq->waitq.lock);
                                        |--list_del_init(&req->intr_entry);
                                        |--spin_unlock(&fiq->waitq.lock);
                                        |--fuse_put_request();
       |--queue_interrupt();
       <request gets queued to interrupts list>
            |--wake_up_locked(&fiq->waitq);
       |--wait_event_freezable();
       <as FR_FINISHED is set, it returns and then
       the caller frees this request>

Now, the next fuse_dev_do_read(), see interrupts list is not empty
and then calls fuse_read_interrupt() which tries to access the request
which is already free'd and gets the below crash:

[11432.401266] Unable to handle kernel paging request at virtual address
6b6b6b6b6b6b6b6b
...
[11432.418518] Kernel BUG at ffffff80083720e0
[11432.456168] PC is at __list_del_entry+0x6c/0xc4
[11432.463573] LR is at fuse_dev_do_read+0x1ac/0x474
...
[11432.679999] [<ffffff80083720e0>] __list_del_entry+0x6c/0xc4
[11432.687794] [<ffffff80082c65e0>] fuse_dev_do_read+0x1ac/0x474
[11432.693180] [<ffffff80082c6b14>] fuse_dev_read+0x6c/0x78
[11432.699082] [<ffffff80081d5638>] __vfs_read+0xc0/0xe8
[11432.704459] [<ffffff80081d5efc>] vfs_read+0x90/0x108
[11432.709406] [<ffffff80081d67f0>] SyS_read+0x58/0x94

As FR_FINISHED bit is set before deleting the intr_entry with input
queue lock in request completion path, do the testing of this flag and
queueing atomically with the same lock in queue_interrupt().

Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

siano: make it work again with CONFIG_VMAP_STACK

commit f9c85ee67164b37f9296eab3b754e543e4e96a1c upstream.

Reported as a Kaffeine bug:
https://bugs.kde.org/show_bug.cgi?id=375811

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

On Kernel 4.9, the default is to not accept DMA on stack anymore
on x86 architecture. On other architectures, this has been a
requirement since Kernel 2.2. So, after this patch, this driver
should likely work fine on all archs.

Tested with USB ID 2040:5510: Hauppauge Windham

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vfs: fix uninitialized flags in splice_to_pipe()

commit 5a81e6a171cdbd1fa8bc1fdd80c23d3d71816fac upstream.

Flags (PIPE_BUF_FLAG_PACKET, PIPE_BUF_FLAG_GIFT) could remain on the
unused part of the pipe ring buffer.  Previously splice_to_pipe() left
the flags value alone, which could result in incorrect behavior.

Uninitialized flags appears to have been there from the introduction of
the splice syscall.

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

arm64: configs: enable network filesystem for rockchip linux

NFS is a important feature and should be enabled.

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

ARM: configs: enable network filesystem for rockchip linux

NFS is a important feature and should be enabled.

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

arm64: rockchip_linux_defconfig: enable USB_CONFIGFS_ACM

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

arm64: rockchip_defconfig: enable USB_CONFIGFS_MASS_STORAGE

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

arm64: rockchip_defconfig: enable USB_CONFIGFS_ACM

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

ARM: rockchip_linux_defconfig: enable MASS_STORAGE config

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

arm64/uao: fix compiler warning

Adding a 'return 0' to fix a compiler warning

arch/arm64/mm/fault.c: In function 'cpu_enable_uao':
arch/arm64/mm/fault.c:689:1: warning: control reaches end of non-void
function [-Wreturn-type]

That was introduced by a conflict fix.

Signed-off-by: Alex Shi <alex.shi@linaro.org>

drm/rockchip: cdn-dp: modify switchdev name to "cdn-dp"

If DP and HDMI are enabled at the same board, they will be
register switchdev with the same name in the same directory.
This would cause register switchdev fail.

Resulting in the following error:
[    0.882415] [<ffffff8008212044>] sysfs_warn_dup+0x60/0x7c
[    0.882424] [<ffffff800821212c>] sysfs_create_dir_ns+0x74/0x94
[    0.882436] [<ffffff8008359fc0>] kobject_add_internal+0xc8/0x290
[    0.882446] [<ffffff800835a428>] kobject_add+0xe0/0x10c
[    0.882454] [<ffffff80084c2874>] device_add+0xec/0x508
[    0.882462] [<ffffff80084c2e3c>] device_create_groups_vargs+0xb4/0xf8
[    0.882471] [<ffffff80084c2eac>] device_create_vargs+0x2c/0x34
[    0.882479] [<ffffff80084c2f14>] device_create+0x60/0x80
[    0.882491] [<ffffff80087248bc>] switch_dev_register+0x8c/0x120
[    0.882502] [<ffffff80084709ec>] cdn_dp_bind+0x4c4/0x644
[    0.882511] [<ffffff80084c091c>] component_bind_all+0x94/0x1c0
[    0.882523] [<ffffff8008478550>] rockchip_drm_bind+0x1c4/0xb54
[    0.882533] [<ffffff80084c0554>] try_to_bring_up_master.part.3+0xac/0x114
[    0.882542] [<ffffff80084c0780>] component_add+0x88/0xf8
[    0.882550] [<ffffff8008470504>] cdn_dp_probe+0x140/0x164
[    0.882559] [<ffffff80084c71f8>] platform_drv_probe+0x58/0xa4
[    0.882568] [<ffffff80084c5498>] driver_probe_device+0x118/0x2ac
[    0.882576] [<ffffff80084c5778>] __device_attach_driver+0x88/0x98
[    0.882584] [<ffffff80084c38a0>] bus_for_each_drv+0x7c/0xac
[    0.882592] [<ffffff80084c52cc>] __device_attach+0xa4/0x124
[    0.882600] [<ffffff80084c58e4>] device_initial_probe+0x10/0x18
[    0.882609] [<ffffff80084c4924>] bus_probe_device+0x2c/0x8c
[    0.882617] [<ffffff80084c4da0>] deferred_probe_work_func+0x74/0xa0
[    0.882628] [<ffffff80080b2b38>] process_one_work+0x218/0x3e0
[    0.882636] [<ffffff80080b3538>] worker_thread+0x2e8/0x404
[    0.882644] [<ffffff80080b7e70>] kthread+0xe8/0xf0
[    0.882653] [<ffffff8008082690>] ret_from_fork+0x10/0x40
[    0.882675] kobject_add_internal failed for hdmi with -EEXIST, don't try to
register things with the same name in the same directory.

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

ASoC: rockchip: i2s: add a delay before i2s clear

in order to keep i2s lrck signal integrity, when i2s stop,
need at least one lrck cycle to ensure signal integrity.

the max delay time is when lrck is 8khz, the delay time is
125us(1/8khz), using udelay(150) with a 25us margin.

Change-Id: Ia0b0c8b0153e25ed3686eee2e13f370d0c3da380
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>

arm64: rockchip_linux_defconfig: enable MASS_STORAGE config

Change-Id: Ibe549b102632e6c19c508f46df1b4d4a2b518d51
Signed-off-by: Binyuan Lan <lby@rock-chips.com>

drm/rockchip: support cpu cache for drm memory

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

ARM64: dts: rk3399-tve1205g: set fixed clock timing of panel

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

drm/rockchip: fixup input source check

check destination with max_input is wrong.

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

rockchip: clk: rk3399: default enable dual pll for vop

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

clk: rockchip: add pll_wait_lock for pll_enable

if pll is power down,when power up pll need wait pll lock.

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

phy: rockchip-inno-usb3: support u3 to work on u2 only mode

Current code set usb2.0 only mode by type in command and may be
failed if change to usb3.0 for that we need reset the controller
when change mode. This patch add a node in debug file system for
config usb2.0 only or usb2.0/usb3.0 mode. So SLT testing or anyone
else can use this node to change config mode.

1. Config to usb2.0/usb3.0 mode:
   echo u3 > /sys/kernel/debug/<phy name>/u3phy_mode

2. Config to usb2.0 only mode:
   echo u2 > /sys/kernel/debug/<phy name>/u3phy_mode

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

arm64: dts: rockchip: add grf handle for rk3328 u3phy

The USB 3.0 PHY need to config grf when change between
USB 2.0 only and USB 2.0/3.0 mode, so we add grf property
for u3phy node.

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

usb: dwc3: rockchip-inno: support to set testmodes via debugfs

This patch create host_testmode file in debugfs for
USB HOST. It's useful for us to use a scope to verify
signal integrity for USB2/USB3 HOST.

For example, set testmodes for rk3328 board USB:
1. set test packet for the USB2 port of USB3 interface:
   echo test_packet > /sys/kernel/debug/usb.23/host_testmode

2. set compliance mode for the USB3 port of USB3 interface:
   echo test_u3 > /sys/kernel/debug/usb.23/host_testmode

3. check the testmode status:
   cat /sys/kernel/debug/usb.23/host_testmode
   The log maybe like this:
   U2: test_packet     /* means that U2 in test mode */
   U3: compliance mode /* means that U3 in test mode */

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

phy: rockchip-inno-usb3: add phy_cp_test function for u3phy

The Inno USB3 PHY disable the ability to toggle the CP test
pattern by default. But when do do USB3 compliance test, it
need to change the CP test pattern according to the requirement
of oscilloscope.

This patch add phy_cp_test function to enable the USB3 PHY
to detect the negative pulse which from the Aux Out of the
oscilloscope in SSRX+, and then the USB3 PHY can toggle the
CP test pattern while do USB3 compliance test.

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

phy: add cp_test callback

There are several SoCs (e.g. rk3228h and rk3328) that integrated
with Inno USB3 PHY, they can't toggle CP test pattern when do
USB3 compliance test by default.

This patch add a cp_test callback for USB3 controller to enable
the special USB3 PHY to toggle the CP test pattern.

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

usb: host: xhci-plat: get the usb3 phy for shared_hcd

This patch tries to get the USB3 PHY using, and associates
the XHCI shared_hcd device with it.

With this patch, the USB HUB core driver can do USB PHY
operations base on USB PHY framework, e.g. call usb_phy_
notify_connect() or usb_phy_notify_disconnect() to notify
USB PHY driver to do soft connect or soft disconnect.

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

arm64: dts: rockchip: add u3 autosuspend quirk for rk3328

This patch adds a quirk to disable rk3328 xHCI controller
USB3 port autosuspend function, and USB2 port autosuspend
function is still enabled.

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

usb: dwc3: add dis_u3_autosuspend_quirk

Some xHCI controllers (e.g. Rockchip rk3328 SoC) integrated
in DWC3 IP, don't support USB 3.0 autosuspend well, so we
need to disable USB 3.0 HUB autosuspend function with a quirk.

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

usb: host: xhci: set xhci autosuspend quirk based on platform data

Some USB controllers (such as rk3328 SoC DWC3 controller with INNO
USB 3.0 PHY) don't support autosuspend well, when receive remote
wakeup signal from autosuspend, the Port Link State training failed,
the correct PLC is Resume->Recovery->U0, but when the issue happens,
the wrong PLC is Resume->Recovery->Inactive, cause resuming SS port
fail. This issue always occurs when connect with external USB 3.0 HUB.

This patch add a quirk to disable autosuspend function, and add new
'usb3_disable_autosuspend' member in xHCI platform data to support
set the quirk based on platform data.

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

usb: core: hub: add quirk for hub with broken autosuspend function

Some USB host controller seems to have problems with
autosuspend. For example, Rockchip rk3328 SoC USB 3.0
wouldn't handle remote wakeup correctly with external
hub after entered autosuspend, caused to resume SS
port fail.

This patch introduces a new quirk flag for hub that
should remain disabled for autosuspend.

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

net: wireless: rockchip_wlan: add rtl8188fu support

update rtl8188eu wifi driver to version v4.3.23.6_20964.20170110

Change-Id: I8665563259e49bcdb0498b93fac6138c42ffd051
Signed-off-by: huweiguo <hwg@rock-chips.com>

arm64: dts: rockchip: enable otg-port node of usb2-phy for rk3328-evb

This patch enable otg-port node of usb2-phy for dwc2 otg controller
on rk3328-evb board.

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