arm64: dts: rockchip: add otg-port node of usb2-phy for rk3328 dwc2

This patch adds otg-port node of usb2-phy for dwc2 otg controller
on rk3328 SoC.

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

phy: rockchip-inno-usb2: add otg-port support for rk3328

This patch adds otg-port configuration for rk3328 SoC.

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

ARM64: dts: rk3399-tve1205g: turn off codec power when suspend

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

ASoC: Update driver for codec cx2072x

1. codec into bias off mode when secondary standby
2. restore hw registers during a suspend/resume cycle.
(Note: codec power must be closed after suspend)

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

arm64: dts: rk3399: remove next

Very small clean up.

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

arm64: dts: rk3399: rename android-next to android

The md5sum is identical after rename, so this commit is safe.

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

arm64: dts: rk3399: rename android to android-6.0

Except dts of VR.
The md5sum is identical after rename, so this commit is safe.

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

Documentation: bindings: add otg-vbus-gpios property for Rockchip USB2PHY

Add otg-vbus-gpios optional property to assigned a gpio to
control vbus of otg port.

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

phy: rockchip-inno-usb2: support to control vbus by gpio

The current code of u2phy set vbus level by set cable state of power
controller, so we can't control vbus level if the platform use gpio
to control vbus. This patch add gpio in u2phy driver and set vbus
level if the mode of usb is detect by u2phy.

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

arm64: dts: rockchip: Add bt sco audio support for rk3399-tve1205g

disable spdif support which is useless meanwhile

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

arm64: rockchip_defconfig: enable bt sco codec driver

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

MALI: midgard: RK: adapt cores_pm in DDK r14 for solution_1_for_glitch

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

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

Along with a slight modification in mali_kbase_core_linux.c,
for building in rk Linux 4.4:
-#if KERNEL_VERSION(4, 6, 0) > LINUX_VERSION_CODE
+#if KERNEL_VERSION(4, 4, 0) > LINUX_VERSION_CODE

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

Revert "Revert "MALI: midgard: RK: not to power off all the pm cores""

This reverts commit d94880b547779baaaa9e9b733c38881cad8aa685.

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

Revert "MALI: midgard: RK: slowdown clk_gpu before poweroff cores"

This reverts commit 89501d8dd3c214e4a162e94804f0d56c61c23237.

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

Revert "MALI: midgard: avoid GPU voltage domain keeping the initial voltage"

This reverts commit 57984d531806892a8e14bb7c1b42b1c4c406ddf9.

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

Revert "MALI: midgard: support sharing regulator with other devices"

This reverts commit 85b4e1dffa2e7a0bbd092d294043f19f82417d74.

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

Linux 4.4.50

l2tp: do not use udp_ioctl()

[ Upstream commit 72fb96e7bdbbdd4421b0726992496531060f3636 ]

udp_ioctl(), as its name suggests, is used by UDP protocols,
but is also used by L2TP :(

L2TP should use its own handler, because it really does not
look the same.

SIOCINQ for instance should not assume UDP checksum or headers.

Thanks to Andrey and syzkaller team for providing the report
and a nice reproducer.

While crashes only happen on recent kernels (after commit
7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue")), this
probably needs to be backported to older kernels.

Fixes: 7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue")
Fixes: 85584672012e ("udp: Fix udp_poll() and ioctl()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ping: fix a null pointer dereference

[ Upstream commit 73d2c6678e6c3af7e7a42b1e78cd0211782ade32 ]

Andrey reported a kernel crash:

  general protection fault: 0000 [#1] SMP KASAN
  Dumping ftrace buffer:
     (ftrace buffer empty)
  Modules linked in:
  CPU: 2 PID: 3880 Comm: syz-executor1 Not tainted 4.10.0-rc6+ #124
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  task: ffff880060048040 task.stack: ffff880069be8000
  RIP: 0010:ping_v4_push_pending_frames net/ipv4/ping.c:647 [inline]
  RIP: 0010:ping_v4_sendmsg+0x1acd/0x23f0 net/ipv4/ping.c:837
  RSP: 0018:ffff880069bef8b8 EFLAGS: 00010206
  RAX: dffffc0000000000 RBX: ffff880069befb90 RCX: 0000000000000000
  RDX: 0000000000000018 RSI: ffff880069befa30 RDI: 00000000000000c2
  RBP: ffff880069befbb8 R08: 0000000000000008 R09: 0000000000000000
  R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069befab0
  R13: ffff88006c624a80 R14: ffff880069befa70 R15: 0000000000000000
  FS:  00007f6f7c716700(0000) GS:ffff88006de00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00000000004a6f28 CR3: 000000003a134000 CR4: 00000000000006e0
  Call Trace:
   inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
   sock_sendmsg_nosec net/socket.c:635 [inline]
   sock_sendmsg+0xca/0x110 net/socket.c:645
   SYSC_sendto+0x660/0x810 net/socket.c:1687
   SyS_sendto+0x40/0x50 net/socket.c:1655
   entry_SYSCALL_64_fastpath+0x1f/0xc2

This is because we miss a check for NULL pointer for skb_peek() when
the queue is empty. Other places already have the same check.

Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

packet: round up linear to header len

[ Upstream commit 57031eb794906eea4e1c7b31dc1e2429c0af0c66 ]

Link layer protocols may unconditionally pull headers, as Ethernet
does in eth_type_trans. Ensure that the entire link layer header
always lies in the skb linear segment. tpacket_snd has such a check.
Extend this to packet_snd.

Variable length link layer headers complicate the computation
somewhat. Here skb->len may be smaller than dev->hard_header_len.

Round up the linear length to be at least as long as the smallest of
the two.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Willem de Bruijn <willemb@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>

net: introduce device min_header_len

[ Upstream commit 217e6fa24ce28ec87fca8da93c9016cb78028612 ]

The stack must not pass packets to device drivers that are shorter
than the minimum link layer header length.

Previously, packet sockets would drop packets smaller than or equal
to dev->hard_header_len, but this has false positives. Zero length
payload is used over Ethernet. Other link layer protocols support
variable length headers. Support for validation of these protocols
removed the min length check for all protocols.

Introduce an explicit dev->min_header_len parameter and drop all
packets below this value. Initially, set it to non-zero only for
Ethernet and loopback. Other protocols can follow in a patch to
net-next.

Fixes: 9ed988cd5915 ("packet: validate variable length ll headers")
Reported-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sit: fix a double free on error path

[ Upstream commit d7426c69a1942b2b9b709bf66b944ff09f561484 ]

Dmitry reported a double free in sit_init_net():

  kernel BUG at mm/percpu.c:689!
  invalid opcode: 0000 [#1] SMP KASAN
  Dumping ftrace buffer:
     (ftrace buffer empty)
  Modules linked in:
  CPU: 0 PID: 15692 Comm: syz-executor1 Not tainted 4.10.0-rc6-next-20170206 #1
  Hardware name: Google Google Compute Engine/Google Compute Engine,
  BIOS Google 01/01/2011
  task: ffff8801c9cc27c0 task.stack: ffff88017d1d8000
  RIP: 0010:pcpu_free_area+0x68b/0x810 mm/percpu.c:689
  RSP: 0018:ffff88017d1df488 EFLAGS: 00010046
  RAX: 0000000000010000 RBX: 00000000000007c0 RCX: ffffc90002829000
  RDX: 0000000000010000 RSI: ffffffff81940efb RDI: ffff8801db841d94
  RBP: ffff88017d1df590 R08: dffffc0000000000 R09: 1ffffffff0bb3bdd
  R10: dffffc0000000000 R11: 00000000000135dd R12: ffff8801db841d80
  R13: 0000000000038e40 R14: 00000000000007c0 R15: 00000000000007c0
  FS:  00007f6ea608f700(0000) GS:ffff8801dbe00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 000000002000aff8 CR3: 00000001c8d44000 CR4: 00000000001426f0
  DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
  Call Trace:
   free_percpu+0x212/0x520 mm/percpu.c:1264
   ipip6_dev_free+0x43/0x60 net/ipv6/sit.c:1335
   sit_init_net+0x3cb/0xa10 net/ipv6/sit.c:1831
   ops_init+0x10a/0x530 net/core/net_namespace.c:115
   setup_net+0x2ed/0x690 net/core/net_namespace.c:291
   copy_net_ns+0x26c/0x530 net/core/net_namespace.c:396
   create_new_namespaces+0x409/0x860 kernel/nsproxy.c:106
   unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
   SYSC_unshare kernel/fork.c:2281 [inline]
   SyS_unshare+0x64e/0xfc0 kernel/fork.c:2231
   entry_SYSCALL_64_fastpath+0x1f/0xc2

This is because when tunnel->dst_cache init fails, we free dev->tstats
once in ipip6_tunnel_init() and twice in sit_init_net(). This looks
redundant but its ndo_uinit() does not seem enough to clean up everything
here. So avoid this by setting dev->tstats to NULL after the first free,
at least for -net.

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

sctp: avoid BUG_ON on sctp_wait_for_sndbuf

[ Upstream commit 2dcab598484185dea7ec22219c76dcdd59e3cb90 ]

Alexander Popov reported that an application may trigger a BUG_ON in
sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is
waiting on it to queue more data and meanwhile another thread peels off
the association being used by the first thread.

This patch replaces the BUG_ON call with a proper error handling. It
will return -EPIPE to the original sendmsg call, similarly to what would
have been done if the association wasn't found in the first place.

Acked-by: Alexander Popov <alex.popov@linux.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mlx4: Invoke softirqs after napi_reschedule

[ Upstream commit bd4ce941c8d5b862b2f83364be5dbe8fc8ab48f8 ]

mlx4 may schedule napi from a workqueue. Afterwards, softirqs are not run
in a deterministic time frame and the following message may be logged:
NOHZ: local_softirq_pending 08

The problem is the same as what was described in commit ec13ee80145c
("virtio_net: invoke softirqs after __napi_schedule") and this patch
applies the same fix to mlx4.

Fixes: 07841f9d94c1 ("net/mlx4_en: Schedule napi when RX buffers allocation fails")
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

macvtap: read vnet_hdr_size once

[ Upstream commit 837585a5375c38d40361cfe64e6fd11e1addb936 ]

When IFF_VNET_HDR is enabled, a virtio_net header must precede data.
Data length is verified to be greater than or equal to expected header
length tun->vnet_hdr_sz before copying.

Macvtap functions read the value once, but unless READ_ONCE is used,
the compiler may ignore this and read multiple times. Enforce a single
read and locally cached value to avoid updates between test and use.

Signed-off-by: Willem de Bruijn <willemb@google.com>
Suggested-by: Eric Dumazet <edumazet@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>

tun: read vnet_hdr_sz once

[ Upstream commit e1edab87faf6ca30cd137e0795bc73aa9a9a22ec ]

When IFF_VNET_HDR is enabled, a virtio_net header must precede data.
Data length is verified to be greater than or equal to expected header
length tun->vnet_hdr_sz before copying.

Read this value once and cache locally, as it can be updated between
the test and use (TOCTOU).

Signed-off-by: Willem de Bruijn <willemb@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
CC: Eric Dumazet <edumazet@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>

tcp: avoid infinite loop in tcp_splice_read()

[ Upstream commit ccf7abb93af09ad0868ae9033d1ca8108bdaec82 ]

Splicing from TCP socket is vulnerable when a packet with URG flag is
received and stored into receive queue.

__tcp_splice_read() returns 0, and sk_wait_data() immediately
returns since there is the problematic skb in queue.

This is a nice way to burn cpu (aka infinite loop) and trigger
soft lockups.

Again, this gem was found by syzkaller tool.

Fixes: 9c55e01c0cc8 ("[TCP]: Splice receive support.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv6: tcp: add a missing tcp_v6_restore_cb()

[ Upstream commit ebf6c9cb23d7e56eec8575a88071dec97ad5c6e2 ]

Dmitry reported use-after-free in ip6_datagram_recv_specific_ctl()

A similar bug was fixed in commit 8ce48623f0cf ("ipv6: tcp: restore
IP6CB for pktoptions skbs"), but I missed another spot.

tcp_v6_syn_recv_sock() can indeed set np->pktoptions from ireq->pktopts

Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ip6_gre: fix ip6gre_err() invalid reads

[ Upstream commit 7892032cfe67f4bde6fc2ee967e45a8fbaf33756 ]

Andrey Konovalov reported out of bound accesses in ip6gre_err()

If GRE flags contains GRE_KEY, the following expression
*(((__be32 *)p) + (grehlen / 4) - 1)

accesses data ~40 bytes after the expected point, since
grehlen includes the size of IPv6 headers.

Let's use a "struct gre_base_hdr *greh" pointer to make this
code more readable.

p[1] becomes greh->protocol.
grhlen is the GRE header length.

Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
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>

netlabel: out of bound access in cipso_v4_validate()

[ Upstream commit d71b7896886345c53ef1d84bda2bc758554f5d61 ]

syzkaller found another out of bound access in ip_options_compile(),
or more exactly in cipso_v4_validate()

Fixes: 20e2a8648596 ("cipso: handle CIPSO options correctly when NetLabel is disabled")
Fixes: 446fda4f2682 ("[NetLabel]: CIPSOv4 engine")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Acked-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv4: keep skb->dst around in presence of IP options

[ Upstream commit 34b2cef20f19c87999fff3da4071e66937db9644 ]

Andrey Konovalov got crashes in __ip_options_echo() when a NULL skb->dst
is accessed.

ipv4_pktinfo_prepare() should not drop the dst if (evil) IP options
are present.

We could refine the test to the presence of ts_needtime or srr,
but IP options are not often used, so let's be conservative.

Thanks to syzkaller team for finding this bug.

Fixes: d826eb14ecef ("ipv4: PKTINFO doesnt need dst reference")
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>

net: use a work queue to defer net_disable_timestamp() work

[ Upstream commit 5fa8bbda38c668e56b0c6cdecced2eac2fe36dec ]

Dmitry reported a warning [1] showing that we were calling
net_disable_timestamp() -> static_key_slow_dec() from a non
process context.

Grabbing a mutex while holding a spinlock or rcu_read_lock()
is not allowed.

As Cong suggested, we now use a work queue.

It is possible netstamp_clear() exits while netstamp_needed_deferred
is not zero, but it is probably not worth trying to do better than that.

netstamp_needed_deferred atomic tracks the exact number of deferred
decrements.

[1]
[ INFO: suspicious RCU usage. ]
4.10.0-rc5+ #192 Not tainted
-------------------------------
./include/linux/rcupdate.h:561 Illegal context switch in RCU read-side
critical section!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 0
2 locks held by syz-executor14/23111:
 #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>] lock_sock
include/net/sock.h:1454 [inline]
 #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>]
rawv6_sendmsg+0x1e65/0x3ec0 net/ipv6/raw.c:919
 #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>] nf_hook
include/linux/netfilter.h:201 [inline]
 #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>]
__ip6_local_out+0x258/0x840 net/ipv6/output_core.c:160

stack backtrace:
CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4452
 rcu_preempt_sleep_check include/linux/rcupdate.h:560 [inline]
 ___might_sleep+0x560/0x650 kernel/sched/core.c:7748
 __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
 mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
 atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
 __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
 static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
 net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
 sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
 __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
 sk_destruct+0x47/0x80 net/core/sock.c:1460
 __sk_free+0x57/0x230 net/core/sock.c:1468
 sock_wfree+0xae/0x120 net/core/sock.c:1645
 skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
 skb_release_all+0x15/0x60 net/core/skbuff.c:668
 __kfree_skb+0x15/0x20 net/core/skbuff.c:684
 kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
 inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
 inet_frag_put include/net/inet_frag.h:133 [inline]
 nf_ct_frag6_gather+0x1106/0x3840
net/ipv6/netfilter/nf_conntrack_reasm.c:617
 ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
 nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
 nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
 nf_hook include/linux/netfilter.h:212 [inline]
 __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
 ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
 ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
 ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
 rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
 rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
 sock_sendmsg_nosec net/socket.c:635 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:645
 sock_write_iter+0x326/0x600 net/socket.c:848
 do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
 do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
 vfs_writev+0x87/0xc0 fs/read_write.c:911
 do_writev+0x110/0x2c0 fs/read_write.c:944
 SYSC_writev fs/read_write.c:1017 [inline]
 SyS_writev+0x27/0x30 fs/read_write.c:1014
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445559
RSP: 002b:00007f6f46fceb58 EFLAGS: 00000292 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000445559
RDX: 0000000000000001 RSI: 0000000020f1eff0 RDI: 0000000000000005
RBP: 00000000006e19c0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000700000
R13: 0000000020f59000 R14: 0000000000000015 R15: 0000000000020400
BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:752
in_atomic(): 1, irqs_disabled(): 0, pid: 23111, name: syz-executor14
INFO: lockdep is turned off.
CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 ___might_sleep+0x47e/0x650 kernel/sched/core.c:7780
 __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
 mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
 atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
 __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
 static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
 net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
 sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
 __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
 sk_destruct+0x47/0x80 net/core/sock.c:1460
 __sk_free+0x57/0x230 net/core/sock.c:1468
 sock_wfree+0xae/0x120 net/core/sock.c:1645
 skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
 skb_release_all+0x15/0x60 net/core/skbuff.c:668
 __kfree_skb+0x15/0x20 net/core/skbuff.c:684
 kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
 inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
 inet_frag_put include/net/inet_frag.h:133 [inline]
 nf_ct_frag6_gather+0x1106/0x3840
net/ipv6/netfilter/nf_conntrack_reasm.c:617
 ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
 nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
 nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
 nf_hook include/linux/netfilter.h:212 [inline]
 __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
 ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
 ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
 ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
 rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
 rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
 sock_sendmsg_nosec net/socket.c:635 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:645
 sock_write_iter+0x326/0x600 net/socket.c:848
 do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
 do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
 vfs_writev+0x87/0xc0 fs/read_write.c:911
 do_writev+0x110/0x2c0 fs/read_write.c:944
 SYSC_writev fs/read_write.c:1017 [inline]
 SyS_writev+0x27/0x30 fs/read_write.c:1014
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445559

Fixes: b90e5794c5bd ("net: dont call jump_label_dec from irq context")
Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: fix 0 divide in __tcp_select_window()

[ Upstream commit 06425c308b92eaf60767bc71d359f4cbc7a561f8 ]

syszkaller fuzzer was able to trigger a divide by zero, when
TCP window scaling is not enabled.

SO_RCVBUF can be used not only to increase sk_rcvbuf, also
to decrease it below current receive buffers utilization.

If mss is negative or 0, just return a zero TCP window.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv6: pointer math error in ip6_tnl_parse_tlv_enc_lim()

[ Upstream commit 63117f09c768be05a0bf465911297dc76394f686 ]

Casting is a high precedence operation but "off" and "i" are in terms of
bytes so we need to have some parenthesis here.

Fixes: fbfa743a9d2a ("ipv6: fix ip6_tnl_parse_tlv_enc_lim()")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.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>

ipv6: fix ip6_tnl_parse_tlv_enc_lim()

[ Upstream commit fbfa743a9d2a0ffa24251764f10afc13eb21e739 ]

This function suffers from multiple issues.

First one is that pskb_may_pull() may reallocate skb->head,
so the 'raw' pointer needs either to be reloaded or not used at all.

Second issue is that NEXTHDR_DEST handling does not validate
that the options are present in skb->data, so we might read
garbage or access non existent memory.

With help from Willem de Bruijn.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov <dvyukov@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>

can: Fix kernel panic at security_sock_rcv_skb

[ Upstream commit f1712c73714088a7252d276a57126d56c7d37e64 ]

Zhang Yanmin reported crashes [1] and provided a patch adding a
synchronize_rcu() call in can_rx_unregister()

The main problem seems that the sockets themselves are not RCU
protected.

If CAN uses RCU for delivery, then sockets should be freed only after
one RCU grace period.

Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
ease stable backports with the following fix instead.

[1]
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81495e25>] selinux_socket_sock_rcv_skb+0x65/0x2a0

Call Trace:
 <IRQ>
 [<ffffffff81485d8c>] security_sock_rcv_skb+0x4c/0x60
 [<ffffffff81d55771>] sk_filter+0x41/0x210
 [<ffffffff81d12913>] sock_queue_rcv_skb+0x53/0x3a0
 [<ffffffff81f0a2b3>] raw_rcv+0x2a3/0x3c0
 [<ffffffff81f06eab>] can_rcv_filter+0x12b/0x370
 [<ffffffff81f07af9>] can_receive+0xd9/0x120
 [<ffffffff81f07beb>] can_rcv+0xab/0x100
 [<ffffffff81d362ac>] __netif_receive_skb_core+0xd8c/0x11f0
 [<ffffffff81d36734>] __netif_receive_skb+0x24/0xb0
 [<ffffffff81d37f67>] process_backlog+0x127/0x280
 [<ffffffff81d36f7b>] net_rx_action+0x33b/0x4f0
 [<ffffffff810c88d4>] __do_softirq+0x184/0x440
 [<ffffffff81f9e86c>] do_softirq_own_stack+0x1c/0x30
 <EOI>
 [<ffffffff810c76fb>] do_softirq.part.18+0x3b/0x40
 [<ffffffff810c8bed>] do_softirq+0x1d/0x20
 [<ffffffff81d30085>] netif_rx_ni+0xe5/0x110
 [<ffffffff8199cc87>] slcan_receive_buf+0x507/0x520
 [<ffffffff8167ef7c>] flush_to_ldisc+0x21c/0x230
 [<ffffffff810e3baf>] process_one_work+0x24f/0x670
 [<ffffffff810e44ed>] worker_thread+0x9d/0x6f0
 [<ffffffff810e4450>] ? rescuer_thread+0x480/0x480
 [<ffffffff810ebafc>] kthread+0x12c/0x150
 [<ffffffff81f9ccef>] ret_from_fork+0x3f/0x70

Reported-by: Zhang Yanmin <yanmin.zhang@intel.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: rockchip: add gmac support for rk3328-evb

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

arm64: dts: rockchip: add io-domain support for rk3328-evb

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

arm64: dts: rockchip: modify auto dp rayken hwrotation for rk3399-box-rev2-disvr dts

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

clk: rockchip: rk3328: add SCLK_HDMI_SFC id

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

arm64: dts: rockchip: add pwm support for rk3328

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

pwm: rockchip: need the Distinguish between rk3328 and rk3288 for clk used

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

Bluetooth: update rtk_btusb driver to v 4.1.2

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

mfd: rk808: add sysfs debug node "/sys/rk8xx/rk8xx_dbg"

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

arm64: dts: rockchip: add gmac support for rk3328

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

arm64: dts: rockchip: change the compatible for rk3328 i2c

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

i2c: rk3x: Don't need to add rk3328 i2c compitiable

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

arm64: dts: rockchip: enable usb3 controller for rk3328-evb

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

usb: dwc3: add a new glue layer for rockchip SoCs with INNO PHY

This patch add a rockchip specific glue layer to support
USB 3.0 HOST only mode for rockchip USB 3.0 core wrapper
consisting of USB 3.0 controller IP from Synopsys and USB
3.0 PHY IP from Innosilicon.

With this patch, we can support for XHCI integrated in
DWC3 IP on rockchip platforms. Because some INNO USB 3.0
PHY can't detect disconnection by PHY IP, and cause USB3
device unrecognized when replugged again. So we depend on
the HUB core driver to detect the disconnection, and send
notifier to DWC3 driver from USB PHY driver, then we can
do phy reset and remove/add hcd to reinit HCD.

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

arm64: dts: rockchip: add usb3 controller node for rk3328

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

usb: dwc3: rockchip-inno: add devicetree bindings documentation

This patch adds the devicetree documentation required for Rockchip
USB 3.0 core wrapper consisting of USB 3.0 controller IP from Synopsys
and USB 3.0 PHY IP from Innosilicon.

It supports DRD mode, and could operate in device mode (SS, HS, FS)
and host mode (SS, HS, FS, LS).

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

phy: rockchip-inno-usb3: workaround for USB3 PHY disconnection det issue

The rk322xh USB3 PHY has a problem to detect disconnection,
it loses the ability to detect an absence of a far-end
receiver termination specified in USB3 spec Table 6-21,
and this causes the linkstate to change between SS.Inactive
and Polling state, but not return to correct state Rx.detect.

To workaround this bug, we depends on the hub_event to
detect the port linkstate change and do soft disconnect.
And then do USB3 PHY reset and reinit HCD to recovery
the whole USB3.

The workaround process is:
Plug out USB3 device -> hub_event detect PLC and find
USB 3.0 port in the Inactive -> call usb_remove_device()
to do soft disconnect -> call usb_phy_notify_connect()
-> send notifier to DWC3 controller driver to do USB3
PHY reset and reinit HCD.

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

phy: rockchip-inno-usb3: select USB_PHY

Some rockchip SoCs (e.g. rk322xh/rk3328) integrated with
INNO USB 3.0 PHY have a problem to detect disconnection
correctly. So we need to depend on the usb phy framework
to handle the disconnection.

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

arm64: dts: rockchip: enable usb3 phy for rk3328-evb

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

arm64: rockchip_linux_defconfig: enable INNO USB 3.0 PHY

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

phy: rockchip-inno-usb3: add a new driver for Rockchip USB 3.0 PHY

This patch implements a USB 3.0 PHY driver for Rockchip
platform (e.g. rk3328) with Innosilicon IP block.

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

arm64: dts: rockchip: add usb3 phy nodes for rk3328

This patch adds USB 3.0 PHY grf node and apb node
for rk3328 USB 3.0 module.

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

Documentation: bindings: add dt doc for Rockchip USB 3.0 PHY

This patch adds a binding that describes the Rockchip USB 3.0
PHY designed by Innosilicon.

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

usb: dwc3: rockchip: delete unused binding documentation

We have cherry-pick new binding documentation for dwc3
from upstream, so delete the legacy one.

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

block/partitions/rk: extend the property setting for NVMe

In order not to cause ABI regression, let's invent a new
androidboot.mode for NVMe instead. Just elaborate a bit more
that we now doesn't support mtd devices, otherwise we should
rework it to make it more scalable.

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

clk: rockchip: rk3328: fix up the describe error for aclk_usb3otg

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

arm64: dts: rockchip: Fix indentation of rk3399-android-next

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

ASoC: bt-sco: Compatible stereo format

Compatible the platform which unsupported mono channel

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

video: rockchip: hdmi: add dts property rockchip,defaultdepth

To modify hdmi default output color depth, use following dts:

&hdmi {
rockchip,defaultdepth = <10>;
}

rockchip,defaultdepth could be following value:
<0>  auto select color depth, prefer 8bit
<8>  8bit
<10> 10bit

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

video: rockchip: hdmi: support set hdr metedata

Use following command to set hdr metadata:

cd /sys/class/display/HDMI
echo "hdrmdata=1 2 3 4 5 6 7 8 9 10 11 12" > color

Use following command to get current hdr metadata

cat /sys/class/display/HDMI/color

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

video: rockchip: hdmi: support modify color mode and depth simultaneously

Use following command:

echo mode=<value> > /sys/class/display/HDMI/mode

<value> is decimal digits, lower 8bit is color mode, upper 8bit is depth.
For example:
value = 131 = 0x83 means YCbCr444 8bit output
value = 164 = 0xa4 means YCbCr422 10bit output
value = 0 means restore auto mode(8bit, priority YCbCr444)

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

video: rockchip: hdmi: fix compile warning

fix warning: switch condition has boolean value [-Wswitch-bool]

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

video: rockchip: hdmi: v2: fix some format check error

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

video: rockchip: hdmi: fix can not disable hdr error

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

video: rockchip: hdmi: fix CTS HF1-53 HDR test

1. HDR MetaData HB2 is 26.
2. Under HF1-53, HDR MetaData should be sent and
PB1 value should be exist in EDID.

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

video: rockchip: hdmi: improve hdr function when out of sink tmds clk

If output tmdsclk is out of sink max tmds clk, we need to set output
mode to 8bit or YCbCr422.

For example, sink max tmds clk is 600M, but 3840x2160p-60 10bit tmdsclk
is 594*1.25 > 600, we set output mode to YCbCr422 10bit which tmds clk
is 594, so we can get max picture quality.

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

video: rockchip: hdmi: enable hdr when resolution is not 4K

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

video: rockchip: hdmi: support hdr function

HDR is introduced by HDMI2.0a, which need parsing HDR Static
Metedata data Block defined in EDID, and send Dynamic Range
and Mastering InfoFrame to inform TV to switch to HDR mode.

If TV support HDR, it's EOTF is shown in sysfs node
/sys/class/display/HDMI/color with key word "Supported EOTF:".

For example, "Support EOTF: 0x7" means support following EOTF:
BIT0: Traditional gamma - SDR
BIT1: Traditional gamma - HDR
BIT2: ST_2084

To switch eotf mode, you can use following command:
echo hdr=value > /sys/class/display/HDMI/color
value could be:
0 - Disable sending Dynamic Range and Mastering InfoFrame
1 - Traditional gamma - SDR
2 - Traditional gamma - HDR
4 - ST_2084
0、1 both means SDR mode， 4 is HDR10/Dolby HDR mode.

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

video: rockchip: hdmi: change the way to enable debug log

user can change hdmi_dbg_level value to printf log which you want.
1 : cec
2 : hdmi
3 : hdcp
such as, echo 2 > /sys/module/rockchip_hdmi_sysfs/parameters/hdmi_dbg_level

Change-Id: Iaa5a66c2926789694e0d544196bedc81fb3a755a
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>
(cherry picked from commit 919cb0208a877a1b80bf4171d479f36c9a2dbca2)

video: rockchip: hdmi: contrast uboot and kernel resolution

When box is starting, if kernel resolution is different from uboot,
need to clear hdmi->uboot

Change-Id: Iec56862fe20dcaccc12fefae21de55b56ab2fe54
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>
(cherry picked from commit 899bf65ac08492fc5aec36a1b23509baa008d409)

video: rockchip: hdmi: yuv420 resolution retain 4K 50/60HZ

Change-Id: I75ae87bbd274af10b7da9b6699d5892e6f864dba
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>
(cherry picked from commit 6acb6585c03dd4bf7eaf2a548cb3f836070ba56c)

video: rockchip: hdmi: delete cec grf register operation

CEC GRF register can be replaced by hdmi cec register
CEC_CTRL BIT 5.

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

Revert "mfd: fusb302: avoid sending notifier to USB/DP during PM suspend"

This reverts commit 082f43af91698a82583053679ec0d0be89b36b2d.

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

PM / Domains: Keep the pd status during system PM phases

If a PM domain is powered off before system suspend,
we hope do nothing in system runtime suspend noirq phase
and system runtime resume noirq phase.

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

UPSTREAM: PM / Domains: Allow runtime PM during system PM phases

In cases when a PM domain isn't powered off when genpd's ->prepare()
callback is invoked, genpd runtime resumes and disables runtime PM for the
device. This behaviour was needed when genpd managed intermediate states
during the power off sequence, as to maintain proper low power states of
devices during system PM suspend/resume.

Commit ba2bbfbf6307 (PM / Domains: Remove intermediate states from the
power off sequence), enables genpd to improve its behaviour in that
respect.

The PM core disables runtime PM at __device_suspend_late() before it calls
a system PM "late" callback for a device. When resuming a device, after a
corresponding "early" callback has been invoked, the PM core re-enables
runtime PM.

By changing genpd to allow runtime PM according to the same system PM
phases as the PM core, devices can be runtime resumed by their
corresponding subsystem/driver when really needed.

In this way, genpd no longer need to runtime resume the device from its
->prepare() callback. In most cases that avoids unnecessary and energy-
wasting operations of runtime resuming devices that have nothing to do,
only to runtime suspend them shortly after.

Although, because of changing this behaviour in genpd and due to that
genpd powers on the PM domain unconditionally in the system PM resume
"noirq" phase, it could potentially cause a PM domain to stay powered
on even if it's unused after the system has resumed. To avoid this,
schedule a power off work when genpd's system PM ->complete() callback
has been invoked for the last device in the PM domain.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 4d23a5e84806b202d9231929c9507ef7cf7a0185)

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

UPSTREAM: PM / Domains: Remove redundant pm_request_idle() call in genpd

The PM core increases the runtime PM usage count at the system PM prepare
phase. Later when the system resumes, it does a pm_runtime_put() in the
complete phase, which in addition to decrementing the usage count, does
the equivalent of a pm_request_idle().

Therefore the call to pm_request_idle() from within genpd's ->complete()
callback is redundant, so remove it.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 9b002b8f0e386966dfc2dddf47eebed3b71ef876)

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

UPSTREAM: PM / Domains: Remove redundant wrapper functions for system PM

Due to the previous changes in genpd, which removed the suspend_power_off
flag, several of the system PM callbacks no longer do any additional
checks but only invoke corresponding pm_generic_* helper functions.

To clean up the code, drop these wrapper functions as they have
become redundant. Instead, assign the system PM callbacks directly
to the pm_generic_*() helper functions.

While changing this, it has bocame clear that some of the current
system PM callbacks in genpd invoke wrong driver callbacks. For
example, the genpd's ->restore() callback invokes pm_generic_resume(),
while that should be pm_generic_restore(). Fix that as well.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 800188538965d90759cea13bcb4f87a214cf5c53)

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

UPSTREAM: PM / Domains: Allow genpd to power on during system PM phases

If a PM domain is powered off when the first device starts its system PM
prepare phase, genpd prevents any further attempts to power on the PM
domain during the following system PM phases. Not until the system PM
complete phase is finalized for all devices in the PM domain, genpd again
allows it to be powered on.

This behaviour needs to be changed, as a subsystem/driver for a device in
the same PM domain may still need to be able to serve requests in some of
the system PM phases. Accordingly, it may need to runtime resume its
device and thus also request the corresponding PM domain to be powered on.

To deal with these scenarios, let's make the device operational in the
system PM prepare phase by runtime resuming it, no matter if the PM domain
is powered on or off. Changing this also enables us to remove genpd's
suspend_power_off flag, as it's being used to track this condition.
Additionally, we must allow the PM domain to be powered on via runtime PM
during the system PM phases.

This change also requires a fix in the AMD ACP (Audio CoProcessor) drm
driver. It registers a genpd to model the ACP as a PM domain, but
unfortunately it's also abuses genpd's "internal" suspend_power_off flag
to deal with a corner case at system PM resume.

More precisely, the so called SMU block powers on the ACP at system PM
resume, unconditionally if it's being used or not. This may lead to that
genpd's internal status of the power state, may not correctly reflect the
power state of the HW after a system PM resume.

Because of changing the behaviour of genpd, by runtime resuming devices in
the prepare phase, the AMD ACP drm driver no longer have to deal with this
corner case. So let's just drop the related code in this driver.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Maruthi Bayyavarapu <maruthi.bayyavarapu@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 39dd0f234fc37da071dadbd9b49fe800d62139b4)

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

UPSTREAM: PM / Domains: Drop unnecessary wakeup code from pm_genpd_prepare()

As the PM core already have wakeup management during the system PM phase,
it seems reasonable that genpd and its users should be able to rely on
that. Therefore let's remove this from pm_genpd_prepare().

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 164a2159a2d6789bc7e3c4b126dde7f3ce865992)

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

UPSTREAM: PM / Domains: Remove redundant pm_runtime_get|put*() in pm_genpd_prepare()

The PM core increases and decreases the runtime PM usage count in the
system PM prepare phase. This makes some of the pm_runtime_get|put*()
calls in pm_genpd_prepare() redundant, so let's remove them.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 624c8df7d2823ec0df9609025480309322886ed3)

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

arm64: dts: rockchip: fix dp register fail for rk3399-mid

1. MID board is only one dp port, we need to assign a phy.
2. MID board not use HDMI, we need to disabled it.

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

arm64: dts: rk3399-box-next: using drm hdmi audio framework

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

ARM64: rockchip_defconfig: enable CONFIG_DRM_DW_HDMI_I2S_AUDIO

enable CONFIG_DRM_DW_HDMI_I2S_AUDIO for drm hdmi audio.

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

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

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

 This is the 4.4.49 stable release

Linux 4.4.49

drm/i915: fix use-after-free in page_flip_completed()

commit 5351fbb1bf1413f6024892093528280769ca852f upstream.

page_flip_completed() dereferences 'work' variable after executing
queue_work(). This is not safe as the 'work' item might be already freed
by queued work:

    BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr ffff8803dc010f90
    Call Trace:
     __asan_report_load8_noabort+0x59/0x80
     page_flip_completed+0x3ff/0x490
     intel_finish_page_flip_mmio+0xe3/0x130
     intel_pipe_handle_vblank+0x2d/0x40
     gen8_irq_handler+0x4a7/0xed0
     __handle_irq_event_percpu+0xf6/0x860
     handle_irq_event_percpu+0x6b/0x160
     handle_irq_event+0xc7/0x1b0
     handle_edge_irq+0x1f4/0xa50
     handle_irq+0x41/0x70
     do_IRQ+0x9a/0x200
     common_interrupt+0x89/0x89

    Freed:
     kfree+0x113/0x4d0
     intel_unpin_work_fn+0x29a/0x3b0
     process_one_work+0x79e/0x1b70
     worker_thread+0x611/0x1460
     kthread+0x241/0x3a0
     ret_from_fork+0x27/0x40

Move queue_work() after trace_i915_flip_complete() to fix this.

Fixes: e5510fac98a7 ("drm/i915: add tracepoints for flip requests & completions")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126143211.24013-1-aryabinin@virtuozzo.com
(cherry picked from commit 05c41f926fcc7ef838c80a6a99d84f67b4e0b824)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: seq: Don't handle loop timeout at snd_seq_pool_done()

commit 37a7ea4a9b81f6a864c10a7cb0b96458df5310a3 upstream.

snd_seq_pool_done() syncs with closing of all opened threads, but it
aborts the wait loop with a timeout, and proceeds to the release
resource even if not all threads have been closed.  The timeout was 5
seconds, and if you run a crazy stuff, it can exceed easily, and may
result in the access of the invalid memory address -- this is what
syzkaller detected in a bug report.

As a fix, let the code graduate from naiveness, simply remove the loop
timeout.

BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: seq: Fix race at creating a queue

commit 4842e98f26dd80be3623c4714a244ba52ea096a8 upstream.

When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
new queue element to the public list before referencing it.  Thus the
queue might be deleted before the call of snd_seq_queue_use(), and it
results in the use-after-free error, as spotted by syzkaller.

The fix is to reference the queue object at the right time.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

commit 74470954857c264168d2b5a113904cf0cfd27d18 upstream.

rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may dereference
queue->rx.sring which is set to NULL in xennet_disconnect_backend().

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: mpt3sas: disable ASPM for MPI2 controllers

commit ffdadd68af5a397b8a52289ab39d62e1acb39e63 upstream.

MPI2 controllers sometimes got lost (i.e. disappear from
/sys/bus/pci/devices) if ASMP is enabled.

Signed-off-by: Slava Kardakov <ojab@ojab.ru>
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60644
Acked-by: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: aacraid: Fix INTx/MSI-x issue with older controllers

commit 8af8e1c22f9994bb1849c01d66c24fe23f9bc9a0 upstream.

commit 78cbccd3bd68 ("aacraid: Fix for KDUMP driver hang")

caused a problem on older controllers which do not support MSI-x (namely
ASR3405,ASR3805). This patch conditionalizes the previous patch to
controllers which support MSI-x

Fixes: 78cbccd3bd68 ("aacraid: Fix for KDUMP driver hang")
Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
Signed-off-by: Dave Carroll <david.carroll@microsemi.com>
Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: zfcp: fix use-after-free by not tracing WKA port open/close on failed send

commit 2dfa6688aafdc3f74efeb1cf05fb871465d67f79 upstream.

Dan Carpenter kindly reported:
<quote>
The patch d27a7cb91960: "zfcp: trace on request for open and close of
WKA port" from Aug 10, 2016, leads to the following static checker
warning:

drivers/s390/scsi/zfcp_fsf.c:1615 zfcp_fsf_open_wka_port()
warn: 'req' was already freed.

drivers/s390/scsi/zfcp_fsf.c
  1609          zfcp_fsf_start_timer(req, ZFCP_FSF_REQUEST_TIMEOUT);
  1610          retval = zfcp_fsf_req_send(req);
  1611          if (retval)
  1612                  zfcp_fsf_req_free(req);
                                          ^^^
Freed.

  1613  out:
  1614          spin_unlock_irq(&qdio->req_q_lock);
  1615          if (req && !IS_ERR(req))
  1616                  zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id);
                                                                  ^^^^^^^^^^^
Use after free.

  1617          return retval;
  1618  }

Same thing for zfcp_fsf_close_wka_port() as well.
</quote>

Rather than relying on req being NULL (or ERR_PTR) for all cases where
we don't want to trace or should not trace,
simply check retval which is unconditionally initialized with -EIO != 0
and it can only become 0 on successful retval = zfcp_fsf_req_send(req).
With that we can also remove the then again unnecessary unconditional
initialization of req which was introduced with that earlier commit.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Suggested-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: d27a7cb91960 ("zfcp: trace on request for open and close of WKA port")
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netvsc: Set maximum GSO size in the right place

Commit a50af86dd49e "netvsc: reduce maximum GSO size" was wrongly
backported to 4.4-stable.  The maximum size needs to be set before the
net device is registered, in netvsc_probe().

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>