5.4.73-rc1 review

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/ibm/ibmveth.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/net/ethernet/ibm/ibmveth.c +5 -5

@@ -1353,16 +1353,16 @@ static int ibmveth_poll(struct napi_stru
 			skb_put(skb, length);
 			skb->protocol = eth_type_trans(skb, netdev);
 
-			if (csum_good) {
-				skb->ip_summed = CHECKSUM_UNNECESSARY;
-				ibmveth_rx_csum_helper(skb, adapter);
-			}
-
 			if (length > netdev->mtu + ETH_HLEN) {
 				ibmveth_rx_mss_helper(skb, mss, lrg_pkt);
 				adapter->rx_large_packets++;
 			}
 
+			if (csum_good) {
+				skb->ip_summed = CHECKSUM_UNNECESSARY;
+				ibmveth_rx_csum_helper(skb, adapter);
+			}
+
 			napi_gro_receive(napi, skb);	/* send it up */
 
 			netdev->stats.rx_packets++;

Greg Kroah-Hartman

author maintainer

2020-10-27 14:30 UTC #2 lore raw

PATCH 2/408 ibmveth: Identify ingress large send packets.

From: David Wilder <[email protected]>

[ Upstream commit 413f142cc05cb03f2d1ea83388e40c1ddc0d74e9 ]

Ingress large send packets are identified by either:
The IBMVETH_RXQ_LRG_PKT flag in the receive buffer
or with a -1 placed in the ip header checksum.
The method used depends on firmware version. Frame geometry and sufficient header validation is performed by the hypervisor eliminating the need for further header checks here.

Fixes 7b5967389f5a ("ibmveth: set correct gso_size and gso_type")

Signed-off-by David Wilder <[email protected]>

Reviewed-by Thomas Falcon <[email protected]>

Reviewed-by Cristobal Forno <[email protected]>

Reviewed-by Pradeep Satyanarayana <[email protected]>

Acked-by Willem de Bruijn <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/ibm/ibmveth.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

drivers/net/ethernet/ibm/ibmveth.c +12 -1

@@ -1317,6 +1317,7 @@ static int ibmveth_poll(struct napi_stru
 			int offset = ibmveth_rxq_frame_offset(adapter);
 			int csum_good = ibmveth_rxq_csum_good(adapter);
 			int lrg_pkt = ibmveth_rxq_large_packet(adapter);
+			__sum16 iph_check = 0;
 
 			skb = ibmveth_rxq_get_buffer(adapter);

@@ -1353,7 +1354,17 @@ static int ibmveth_poll(struct napi_stru
 			skb_put(skb, length);
 			skb->protocol = eth_type_trans(skb, netdev);
 
-			if (length > netdev->mtu + ETH_HLEN) {
+			/* PHYP without PLSO support places a -1 in the ip
+			 * checksum for large send frames.
+			 */
+			if (skb->protocol == cpu_to_be16(ETH_P_IP)) {
+				struct iphdr *iph = (struct iphdr *)skb->data;
+
+				iph_check = iph->check;
+			}
+
+			if ((length > netdev->mtu + ETH_HLEN) ||
+			    lrg_pkt || iph_check == 0xffff) {
 				ibmveth_rx_mss_helper(skb, mss, lrg_pkt);
 				adapter->rx_large_packets++;
 			}

Greg Kroah-Hartman

author maintainer

2020-10-27 14:28 UTC #3 lore raw

PATCH 3/408 ipv4: Restore flowi4_oif update before call to xfrm_lookup_route

From: David Ahern <[email protected]>

[ Upstream commit 874fb9e2ca949b443cc419a4f2227cafd4381d39 ]

Tobias reported regressions in IPsec tests following the patch referenced by the Fixes tag below. The root cause is dropping the reset of the flowi4_oif after the fib_lookup. Apparently it is needed for xfrm cases, so restore the oif update to ip_route_output_flow right before the call to xfrm_lookup_route.

Fixes 2fbc6e89b2f1 ("ipv4: Update exception handling for multipath routes via same device")

Reported-by Tobias Brunner <[email protected]>

Signed-off-by David Ahern <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ipv4/route.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

net/ipv4/route.c +3 -1

@@ -2728,10 +2728,12 @@ struct rtable *ip_route_output_flow(stru
 	if (IS_ERR(rt))
 		return rt;
 
-	if (flp4->flowi4_proto)
+	if (flp4->flowi4_proto) {
+		flp4->flowi4_oif = rt->dst.dev->ifindex;
 		rt = (struct rtable *)xfrm_lookup_route(net, &rt->dst,
 							flowi4_to_flowi(flp4),
 							sk, 0);
+	}
 
 	return rt;
 }

Greg Kroah-Hartman

author maintainer

2020-10-27 14:29 UTC #4 lore raw

PATCH 4/408 mlx4: handle non-napi callers to napi_poll

From: Jonathan Lemon <[email protected]>

[ Upstream commit b2b8a92733b288128feb57ffa694758cf475106c ]

netcons calls napi_poll with a budget of 0 to transmit packets. Handle this by:
- skipping RX processing
- do not try to recycle TX packets to the RX cache

Signed-off-by Jonathan Lemon <[email protected]>

Reviewed-by Tariq Toukan <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx4/en_rx.c |    3 +++
 drivers/net/ethernet/mellanox/mlx4/en_tx.c |    2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

drivers/net/ethernet/mellanox/mlx4/en_rx.c +3 -0

@@ -942,6 +942,9 @@ int mlx4_en_poll_rx_cq(struct napi_struc
 	bool clean_complete = true;
 	int done;
 
+	if (!budget)
+		return 0;
+
 	if (priv->tx_ring_num[TX_XDP]) {
 		xdp_tx_cq = priv->tx_cq[TX_XDP][cq->ring];
 		if (xdp_tx_cq->xdp_busy) {

drivers/net/ethernet/mellanox/mlx4/en_tx.c +1 -1

@@ -350,7 +350,7 @@ u32 mlx4_en_recycle_tx_desc(struct mlx4_
 		.dma = tx_info->map0_dma,
 	};
 
-	if (!mlx4_en_rx_recycle(ring->recycle_ring, &frame)) {
+	if (!napi_mode || !mlx4_en_rx_recycle(ring->recycle_ring, &frame)) {
 		dma_unmap_page(priv->ddev, tx_info->map0_dma,
 			       PAGE_SIZE, priv->dma_dir);
 		put_page(tx_info->page);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:28 UTC #5 lore raw

PATCH 5/408 net: fec: Fix phy_device lookup for phy_reset_after_clk_enable()

From: Marek Vasut <[email protected]>

[ Upstream commit 64a632da538a6827fad0ea461925cedb9899ebe2 ]

The phy_reset_after_clk_enable() is always called with ndev->phydev, however that pointer may be NULL even though the PHY device instance already exists and is sufficient to perform the PHY reset.

This condition happens in fec_open(), where the clock must be enabled first, then the PHY must be reset, and then the PHY IDs can be read out of the PHY.

If the PHY still is not bound to the MAC, but there is OF PHY node and a matching PHY device instance already, use the OF PHY node to obtain the PHY device instance, and then use that PHY device instance when triggering the PHY reset.

Fixes 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support")

Signed-off-by Marek Vasut <[email protected]>

Cc Christoph Niedermaier <[email protected]>

Cc David S. Miller <[email protected]>

Cc NXP Linux Team <[email protected]>

Cc Richard Leitner <[email protected]>

Cc Shawn Guo <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/freescale/fec_main.c |   25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

drivers/net/ethernet/freescale/fec_main.c +23 -2

@@ -1945,6 +1945,27 @@ out:
 	return ret;
 }
 
+static void fec_enet_phy_reset_after_clk_enable(struct net_device *ndev)
+{
+	struct fec_enet_private *fep = netdev_priv(ndev);
+	struct phy_device *phy_dev = ndev->phydev;
+
+	if (phy_dev) {
+		phy_reset_after_clk_enable(phy_dev);
+	} else if (fep->phy_node) {
+		/*
+		 * If the PHY still is not bound to the MAC, but there is
+		 * OF PHY node and a matching PHY device instance already,
+		 * use the OF PHY node to obtain the PHY device instance,
+		 * and then use that PHY device instance when triggering
+		 * the PHY reset.
+		 */
+		phy_dev = of_phy_find_device(fep->phy_node);
+		phy_reset_after_clk_enable(phy_dev);
+		put_device(&phy_dev->mdio.dev);
+	}
+}
+
 static int fec_enet_clk_enable(struct net_device *ndev, bool enable)
 {
 	struct fec_enet_private *fep = netdev_priv(ndev);

@@ -1971,7 +1992,7 @@ static int fec_enet_clk_enable(struct ne
 		if (ret)
 			goto failed_clk_ref;
 
-		phy_reset_after_clk_enable(ndev->phydev);
+		fec_enet_phy_reset_after_clk_enable(ndev);
 	} else {
 		clk_disable_unprepare(fep->clk_enet_out);
 		if (fep->clk_ptp) {

@@ -2991,7 +3012,7 @@ fec_enet_open(struct net_device *ndev)
 	 * phy_reset_after_clk_enable() before because the PHY wasn't probed.
 	 */
 	if (reset_again)
-		phy_reset_after_clk_enable(ndev->phydev);
+		fec_enet_phy_reset_after_clk_enable(ndev);
 
 	if (fep->quirks & FEC_QUIRK_ERR006687)
 		imx6q_cpuidle_fec_irqs_used();

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #6 lore raw

PATCH 6/408 net: fec: Fix PHY init after phy_reset_after_clk_enable()

From: Marek Vasut <[email protected]>

[ Upstream commit 0da1ccbbefb662915228bc17e1c7d4ad28b3ddab ]

The phy_reset_after_clk_enable() does a PHY reset, which means the PHY loses its register settings. The fec_enet_mii_probe() starts the PHY and does the necessary calls to configure the PHY via PHY framework, and loads the correct register settings into the PHY. Therefore, fec_enet_mii_probe() should be called only after the PHY has been reset, not before as it is now.

Fixes 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support")

Reviewed-by Andrew Lunn <[email protected]>

Tested-by Richard Leitner <[email protected]>

Signed-off-by Marek Vasut <[email protected]>

Cc Christoph Niedermaier <[email protected]>

Cc David S. Miller <[email protected]>

Cc NXP Linux Team <[email protected]>

Cc Shawn Guo <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/freescale/fec_main.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/net/ethernet/freescale/fec_main.c +5 -5

@@ -3003,17 +3003,17 @@ fec_enet_open(struct net_device *ndev)
 	/* Init MAC prior to mii bus probe */
 	fec_restart(ndev);
 
-	/* Probe and connect to PHY when open the interface */
-	ret = fec_enet_mii_probe(ndev);
-	if (ret)
-		goto err_enet_mii_probe;
-
 	/* Call phy_reset_after_clk_enable() again if it failed during
 	 * phy_reset_after_clk_enable() before because the PHY wasn't probed.
 	 */
 	if (reset_again)
 		fec_enet_phy_reset_after_clk_enable(ndev);
 
+	/* Probe and connect to PHY when open the interface */
+	ret = fec_enet_mii_probe(ndev);
+	if (ret)
+		goto err_enet_mii_probe;
+
 	if (fep->quirks & FEC_QUIRK_ERR006687)
 		imx6q_cpuidle_fec_irqs_used();

Greg Kroah-Hartman

author maintainer

2020-10-27 14:29 UTC #7 lore raw

PATCH 7/408 net: fix pos incrementment in ipv6_route_seq_next

From: Yonghong Song <[email protected]>

[ Upstream commit 6617dfd440149e42ce4d2be615eb31a4755f4d30 ]

Commit 4fc427e05158 ("ipv6_route_seq_next should increase position index") tried to fix the issue where seq_file pos is not increased
if a NULL element is returned with seq_ops->next(). See bug
https://bugzilla.kernel.org/show_bug.cgi?id=206283
The commit effectively does:
- increase pos for all seq_ops->start()
- increase pos for all seq_ops->next()

For ipv6_route, increasing pos for all seq_ops->next() is correct. But increasing pos for seq_ops->start() is not correct since pos is used to determine how many items to skip during seq_ops->start():
iter->skip = *pos;
seq_ops->start() just fetches the *current* pos item.
The item can be skipped only after seq_ops->show() which essentially is the beginning of seq_ops->next().

For example, I have 7 ipv6 route entries,
root@arch-fb-vm1:~/net-next dd if=/proc/net/ipv6_route bs=4096
00000000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000400 00000001 00000000 00000001 eth0
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000001 00000000 00000001 eth0
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00000000 00200200 lo
00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000003 00000000 80200001 lo
fe800000000000002050e3fffebd3be8 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00000000 80200001 eth0
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000004 00000000 00000001 eth0
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00000000 00200200 lo
0+1 records in
0+1 records out
1050 bytes (1.0 kB, 1.0 KiB) copied, 0.00707908 s, 148 kB/s root@arch-fb-vm1:~/net-next

In the above, I specify buffer size 4096, so all records can be returned to user space with a single trip to the kernel.

If I use buffer size 128, since each record size is 149, internally kernel seq_read() will read 149 into its internal buffer and return the data to user space in two read() syscalls. Then user read() syscall will trigger next seq_ops->start(). Since the current implementation increased pos even for seq_ops->start(), it will skip record #2, #4 and #6, assuming the first record is #1.

root@arch-fb-vm1:~/net-next dd if=/proc/net/ipv6_route bs=128
00000000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000400 00000001 00000000 00000001 eth0
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00000000 00200200 lo
fe800000000000002050e3fffebd3be8 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00000000 80200001 eth0
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00000000 00200200 lo
4+1 records in
4+1 records out
600 bytes copied, 0.00127758 s, 470 kB/s

To fix the problem, create a fake pos pointer so seq_ops->start() won't actually increase seq_file pos. With this fix, the above dd command with bs=128 will show correct result.

Fixes 4fc427e05158 ("ipv6_route_seq_next should increase position index")

Cc Alexei Starovoitov <[email protected]>

Reviewed-by Vasily Averin <[email protected]>

Signed-off-by Yonghong Song <[email protected]>

Acked-by Martin KaFai Lau <[email protected]>

Acked-by Andrii Nakryiko <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ipv6/ip6_fib.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

net/ipv6/ip6_fib.c +3 -1

@@ -2519,8 +2519,10 @@ static void *ipv6_route_seq_start(struct
 	iter->skip = *pos;
 
 	if (iter->tbl) {
+		loff_t p = 0;
+
 		ipv6_route_seq_setup_walk(iter, net);
-		return ipv6_route_seq_next(seq, NULL, pos);
+		return ipv6_route_seq_next(seq, NULL, &p);
 	} else {
 		return NULL;
 	}

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #8 lore raw

PATCH 8/408 net/smc: fix valid DMBE buffer sizes

From: Karsten Graul <[email protected]>

[ Upstream commit ef12ad45880b696eb993d86c481ca891836ab593 ]

The SMCD_DMBE_SIZES should include all valid DMBE buffer sizes, so the correct value is 6 which means 1MB. With 7 the registration of an ISM buffer would always fail because of the invalid size requested. Fix that and set the value to 6.

Fixes c6ba7c9ba43d ("net/smc: add base infrastructure for SMC-D and ISM")

Signed-off-by Karsten Graul <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/smc/smc_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/smc/smc_core.c +1 -1

@@ -795,7 +795,7 @@ static struct smc_buf_desc *smcr_new_buf
 	return buf_desc;
 }
 
-#define SMCD_DMBE_SIZES		7 /* 0 -> 16KB, 1 -> 32KB, .. 6 -> 1MB */
+#define SMCD_DMBE_SIZES		6 /* 0 -> 16KB, 1 -> 32KB, .. 6 -> 1MB */
 
 static struct smc_buf_desc *smcd_new_buf_create(struct smc_link_group *lgr,
 						bool is_dmb, int bufsize)

Greg Kroah-Hartman

author maintainer

2020-10-27 14:29 UTC #9 lore raw

PATCH 9/408 net/tls: sendfile fails with ktls offload

From: Rohit Maheshwari <[email protected]>

[ Upstream commit ea1dd3e9d080c961b9a451130b61c72dc9a5397b ]

At first when sendpage gets called, if there is more data, 'more' in tls_push_data() gets set which later sets pending_open_record_frags, but when there is no more data in file left, and last time tls_push_data() gets called, pending_open_record_frags doesn't get reset. And later when 2 bytes of encrypted alert comes as sendmsg, it first checks for pending_open_record_frags, and since this is set, it creates a record with 0 data bytes to encrypt, meaning record length is prepend_size + tag_size only, which causes problem.
We should set/reset pending_open_record_frags based on more bit.

Fixes e8f69799810c ("net/tls: Add generic NIC offload infrastructure")

Signed-off-by Rohit Maheshwari <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/tls/tls_device.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

net/tls/tls_device.c +6 -5

@@ -405,14 +405,14 @@ static int tls_push_data(struct sock *sk
 	struct tls_context *tls_ctx = tls_get_ctx(sk);
 	struct tls_prot_info *prot = &tls_ctx->prot_info;
 	struct tls_offload_context_tx *ctx = tls_offload_ctx_tx(tls_ctx);
-	int more = flags & (MSG_SENDPAGE_NOTLAST | MSG_MORE);
 	struct tls_record_info *record = ctx->open_record;
 	int tls_push_record_flags;
 	struct page_frag *pfrag;
 	size_t orig_size = size;
 	u32 max_open_record_len;
-	int copy, rc = 0;
+	bool more = false;
 	bool done = false;
+	int copy, rc = 0;
 	long timeo;
 
 	if (flags &

@@ -480,9 +480,8 @@ handle_error:
 		if (!size) {
 last_record:
 			tls_push_record_flags = flags;
-			if (more) {
-				tls_ctx->pending_open_record_frags =
-						!!record->num_frags;
+			if (flags & (MSG_SENDPAGE_NOTLAST | MSG_MORE)) {
+				more = true;
 				break;
 			}

@@ -514,6 +513,8 @@ last_record:
 		}
 	} while (!done);
 
+	tls_ctx->pending_open_record_frags = more;
+
 	if (orig_size - size > 0)
 		rc = orig_size - size;

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #10 lore raw

PATCH 10/408 net: usb: qmi_wwan: add Cellient MPL200 card

From: Wilken Gottwalt <[email protected]>

[ Upstream commit 28802e7c0c9954218d1830f7507edc9d49b03a00 ]

Add usb ids of the Cellient MPL200 card.

Signed-off-by Wilken Gottwalt <[email protected]>

Acked-by Bjørn Mork <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/usb/qmi_wwan.c |    1 +
 1 file changed, 1 insertion(+)

drivers/net/usb/qmi_wwan.c +1 -0

@@ -1375,6 +1375,7 @@ static const struct usb_device_id produc
 	{QMI_QUIRK_SET_DTR(0x2cb7, 0x0104, 4)},	/* Fibocom NL678 series */
 	{QMI_FIXED_INTF(0x0489, 0xe0b4, 0)},	/* Foxconn T77W968 LTE */
 	{QMI_FIXED_INTF(0x0489, 0xe0b5, 0)},	/* Foxconn T77W968 LTE with eSIM support*/
+	{QMI_FIXED_INTF(0x2692, 0x9025, 4)},    /* Cellient MPL200 (rebranded Qualcomm 05c6:9025) */
 
 	/* 4. Gobi 1000 devices */
 	{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},	/* Acer Gobi Modem Device */

Greg Kroah-Hartman

author maintainer

2020-10-27 14:28 UTC #11 lore raw

PATCH 11/408 tipc: fix the skb_unshare() in tipc_buf_append()

From: Cong Wang <[email protected]>

[ Upstream commit ed42989eab57d619667d7e87dfbd8fe207db54fe ]

skb_unshare() drops a reference count on the old skb unconditionally, so in the failure case, we end up freeing the skb twice here. And because the skb is allocated in fclone and cloned by caller tipc_msg_reassemble(), the consequence is actually freeing the original skb too, thus triggered the UAF by syzbot.

Fix this by replacing this skb_unshare() with skb_cloned()+skb_copy().

Fixes ff48b6222e65 ("tipc: use skb_unshare() instead in tipc_buf_append()")

Reported-and-tested-by [email protected]

Cc Jon Maloy <[email protected]>

Cc Ying Xue <[email protected]>

Signed-off-by Cong Wang <[email protected]>

Reviewed-by Xin Long <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/tipc/msg.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

net/tipc/msg.c +2 -1

@@ -140,7 +140,8 @@ int tipc_buf_append(struct sk_buff **hea
 	if (fragid == FIRST_FRAGMENT) {
 		if (unlikely(head))
 			goto err;
-		frag = skb_unshare(frag, GFP_ATOMIC);
+		if (skb_cloned(frag))
+			frag = skb_copy(frag, GFP_ATOMIC);
 		if (unlikely(!frag))
 			goto err;
 		head = *headbuf = frag;

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #12 lore raw

PATCH 12/408 socket: fix option SO_TIMESTAMPING_NEW

From: Christian Eggers <[email protected]>

[ Upstream commit 59e611a566e7cd48cf54b6777a11fe3f9c2f9db5 ]

The comparison of optname with SO_TIMESTAMPING_NEW is wrong way around, so SOCK_TSTAMP_NEW will first be set and than reset again. Additionally move it out of the test for SOF_TIMESTAMPING_RX_SOFTWARE as this seems unrelated.

This problem happens on 32 bit platforms were the libc has already switched to struct timespec64 (from SO_TIMExxx_OLD to SO_TIMExxx_NEW socket options). ptp4l complains with "missing timestamp on transmitted peer delay request" because the wrong format is received (and discarded).

Fixes 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW")

Signed-off-by Christian Eggers <[email protected]>

Reviewed-by Willem de Bruijn <[email protected]>

Reviewed-by Deepa Dinamani <[email protected]>

Acked-by Willem de Bruijn <[email protected]>

Acked-by Deepa Dinamani <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/core/sock.c |   10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

net/core/sock.c +3 -7

@@ -928,8 +928,6 @@ set_rcvbuf:
 		break;
 
 	case SO_TIMESTAMPING_NEW:
-		sock_set_flag(sk, SOCK_TSTAMP_NEW);
-		/* fall through */
 	case SO_TIMESTAMPING_OLD:
 		if (val & ~SOF_TIMESTAMPING_MASK) {
 			ret = -EINVAL;

@@ -958,16 +956,14 @@ set_rcvbuf:
 		}
 
 		sk->sk_tsflags = val;
+		sock_valbool_flag(sk, SOCK_TSTAMP_NEW, optname == SO_TIMESTAMPING_NEW);
+
 		if (val & SOF_TIMESTAMPING_RX_SOFTWARE)
 			sock_enable_timestamp(sk,
 					      SOCK_TIMESTAMPING_RX_SOFTWARE);
-		else {
-			if (optname == SO_TIMESTAMPING_NEW)
-				sock_reset_flag(sk, SOCK_TSTAMP_NEW);
-
+		else
 			sock_disable_timestamp(sk,
 					       (1UL << SOCK_TIMESTAMPING_RX_SOFTWARE));
-		}
 		break;
 
 	case SO_RCVLOWAT:

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #13 lore raw

PATCH 13/408 can: m_can_platform: dont call m_can_class_suspend in runtime suspend

From: Lucas Stach <[email protected]>

[ Upstream commit 81f1f5ae8b3cbd54fdd994c9e9aacdb7b414a802 ]

    0704c5743694 can: m_can_platform: remove unnecessary m_can_class_resume() call

removed the m_can_class_resume() call in the runtime resume path to get rid of a infinite recursion, so the runtime resume now only handles the device clocks.

Unfortunately it did not remove the complementary m_can_class_suspend() call in the runtime suspend function, so those paths are now unbalanced, which causes the pinctrl state to get stuck on the "sleep" state, which breaks all CAN functionality on SoCs where this state is defined. Remove the m_can_class_suspend() call to fix this.

Fixes 0704c5743694 can: m_can_platform: remove unnecessary m_can_class_resume() call

Signed-off-by Lucas Stach <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Acked-by Dan Murphy <[email protected]>

Signed-off-by Marc Kleine-Budde <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/can/m_can/m_can_platform.c |    2 --
 1 file changed, 2 deletions(-)

drivers/net/can/m_can/m_can_platform.c +0 -2

@@ -144,8 +144,6 @@ static int __maybe_unused m_can_runtime_
 	struct net_device *ndev = dev_get_drvdata(dev);
 	struct m_can_classdev *mcan_class = netdev_priv(ndev);
 
-	m_can_class_suspend(dev);
-
 	clk_disable_unprepare(mcan_class->cclk);
 	clk_disable_unprepare(mcan_class->hclk);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:32 UTC #14 lore raw

PATCH 14/408 can: j1935: j1939_tp_tx_dat_new(): fix missing initialization of skbcnt

From: Cong Wang <[email protected]>

[ Upstream commit e009f95b1543e26606dca2f7e6e9f0f9174538e5 ]

This fixes an uninit-value warning:

BUG: KMSAN: uninit-value in can_receive+0x26b/0x630 net/can/af_can.c:650

Reported-and-tested-by [email protected]

Fixes 9d71dd0c7009 ("can: add support of SAE J1939 protocol")

Cc Robin van der Gracht <[email protected]>

Cc Oleksij Rempel <[email protected]>

Cc Pengutronix Kernel Team <[email protected]>

Cc Oliver Hartkopp <[email protected]>

Cc Marc Kleine-Budde <[email protected]>

Signed-off-by Cong Wang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Marc Kleine-Budde <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/can/j1939/transport.c |    1 +
 1 file changed, 1 insertion(+)

net/can/j1939/transport.c +1 -0

@@ -580,6 +580,7 @@ sk_buff *j1939_tp_tx_dat_new(struct j193
 	skb->dev = priv->ndev;
 	can_skb_reserve(skb);
 	can_skb_prv(skb)->ifindex = priv->ndev->ifindex;
+	can_skb_prv(skb)->skbcnt = 0;
 	/* reserve CAN header */
 	skb_reserve(skb, offsetof(struct can_frame, data));

Greg Kroah-Hartman

author maintainer

2020-10-27 14:32 UTC #15 lore raw

PATCH 15/408 net: j1939: j1939_session_fresh_new(): fix missing initialization of skbcnt

From: Marc Kleine-Budde <[email protected]>

[ Upstream commit 13ba4c434422837d7c8c163f9c8d854e67bf3c99 ]

This patch add the initialization of skbcnt, similar to:

    e009f95b1543 can: j1935: j1939_tp_tx_dat_new(): fix missing initialization of skbcnt

Let's play save and initialize this skbcnt as well.

Fixes 9d71dd0c7009 ("can: add support of SAE J1939 protocol")

Signed-off-by Marc Kleine-Budde <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/can/j1939/transport.c |    1 +
 1 file changed, 1 insertion(+)

net/can/j1939/transport.c +1 -0

@@ -1488,6 +1488,7 @@ j1939_session *j1939_session_fresh_new(s
 	skb->dev = priv->ndev;
 	can_skb_reserve(skb);
 	can_skb_prv(skb)->ifindex = priv->ndev->ifindex;
+	can_skb_prv(skb)->skbcnt = 0;
 	skcb = j1939_skb_to_cb(skb);
 	memcpy(skcb, rel_skcb, sizeof(*skcb));

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #16 lore raw

PATCH 16/408 net/ipv4: always honour route mtu during forwarding

From: "Maciej Żenczykowski" <[email protected]>

[ Upstream commit 02a1b175b0e92d9e0fa5df3957ade8d733ceb6a0 ]

Documentation/networking/ip-sysctl.txt:46 says:
ip_forward_use_pmtu - BOOLEAN
By default we don't trust protocol path MTUs while forwarding because they could be easily forged and can lead to unwanted fragmentation by the router.
You only need to enable this if you have user-space software which tries to discover path mtus by itself and depends on the kernel honoring this information. This is normally not the case.
Default: 0 (disabled)
Possible values:
0 - disabled
1 - enabled

Which makes it pretty clear that setting it to 1 is a potential security/safety/DoS issue, and yet it is entirely reasonable to want forwarded traffic to honour explicitly administrator configured route mtus (instead of defaulting to device mtu).

Indeed, I can't think of a single reason why you wouldn't want to. Since you configured a route mtu you probably know better...

It is pretty common to have a higher device mtu to allow receiving large (jumbo) frames, while having some routes via that interface (potentially including the default route to the internet) specify a lower mtu.

Note that ipv6 forwarding uses device mtu unless the route is locked (in which case it will use the route mtu).

This approach is not usable for IPv4 where an 'mtu lock' on a route also has the side effect of disabling TCP path mtu discovery via disabling the IPv4 DF (don't frag) bit on all outgoing frames.

I'm not aware of a way to lock a route from an IPv6 RA, so that also potentially seems wrong.

Signed-off-by Maciej Żenczykowski <[email protected]>

Cc Eric Dumazet <[email protected]>

Cc Willem de Bruijn <[email protected]>

Cc Lorenzo Colitti <[email protected]>

Cc Sunmeet Gill (Sunny) <[email protected]>

Cc Vinay Paradkar <[email protected]>

Cc Tyler Wear <[email protected]>

Cc David Ahern <[email protected]>

Reviewed-by Eric Dumazet <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/net/ip.h |    6 ++++++
 1 file changed, 6 insertions(+)

include/net/ip.h +6 -0

@@ -439,12 +439,18 @@ static inline unsigned int ip_dst_mtu_ma
 						    bool forwarding)
 {
 	struct net *net = dev_net(dst->dev);
+	unsigned int mtu;
 
 	if (net->ipv4.sysctl_ip_fwd_use_pmtu ||
 	    ip_mtu_locked(dst) ||
 	    !forwarding)
 		return dst_mtu(dst);
 
+	/* 'forwarding = true' case should always honour route mtu */
+	mtu = dst_metric_raw(dst, RTAX_MTU);
+	if (mtu)
+		return mtu;
+
 	return min(READ_ONCE(dst->dev->mtu), IP_MAX_MTU);
 }

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #17 lore raw

PATCH 17/408 net_sched: remove a redundant goto chain check

From: Cong Wang <[email protected]>

[ Upstream commit 1aad8049909a6d3379175ef2824a68ac35c0b564 ]

All TC actions call tcf_action_check_ctrlact() to validate goto chain, so this check in tcf_action_init_1() is actually redundant. Remove it to save troubles of leaking memory.

Fixes e49d8c22f126 ("net_sched: defer tcf_idr_insert() in tcf_action_init_1()")

Reported-by Vlad Buslov <[email protected]>

Cc Jamal Hadi Salim <[email protected]>

Cc Jiri Pirko <[email protected]>

Signed-off-by Cong Wang <[email protected]>

Reviewed-by Davide Caratti <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/sched/act_api.c |   14 --------------
 1 file changed, 14 deletions(-)

net/sched/act_api.c +0 ~~-14~~

@@ -706,13 +706,6 @@ int tcf_action_destroy(struct tc_action
 	return ret;
 }
 
-static int tcf_action_destroy_1(struct tc_action *a, int bind)
-{
-	struct tc_action *actions[] = { a, NULL };
-
-	return tcf_action_destroy(actions, bind);
-}
-
 static int tcf_action_put(struct tc_action *p)
 {
 	return __tcf_action_put(p, false);

@@ -932,13 +925,6 @@ struct tc_action *tcf_action_init_1(stru
 	if (err < 0)
 		goto err_mod;
 
-	if (TC_ACT_EXT_CMP(a->tcfa_action, TC_ACT_GOTO_CHAIN) &&
-	    !rcu_access_pointer(a->goto_chain)) {
-		tcf_action_destroy_1(a, bind);
-		NL_SET_ERR_MSG(extack, "can't use goto chain with NULL chain");
-		return ERR_PTR(-EINVAL);
-	}
-
 	if (!name && tb[TCA_ACT_COOKIE])
 		tcf_set_action_cookie(&a->act_cookie, cookie);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #18 lore raw

PATCH 18/408 r8169: fix data corruption issue on RTL8402

From: Heiner Kallweit <[email protected]>

[ Upstream commit ef9da46ddef071e1bbb943afbbe9b38771855554 ]

Petr reported that after resume from suspend RTL8402 partially truncates incoming packets, and re-initializing register RxConfig before the actual chip re-initialization sequence is needed to avoid the issue.

Reported-by Petr Tesarik <[email protected]>

Proposed-by Petr Tesarik <[email protected]>

Tested-by Petr Tesarik <[email protected]>

Signed-off-by Heiner Kallweit <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/realtek/r8169_main.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/net/ethernet/realtek/r8169_main.c +4 -0

@@ -5514,6 +5514,10 @@ static int rtl8169_change_mtu(struct net
 	dev->mtu = new_mtu;
 	netdev_update_features(dev);
 
+	/* Reportedly at least Asus X453MA truncates packets otherwise */
+	if (tp->mac_version == RTL_GIGA_MAC_VER_37)
+		rtl_init_rxcfg(tp);
+
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #19 lore raw

PATCH 19/408 cxgb4: handle 4-tuple PEDIT to NAT mode translation

From: Herat Ramani <[email protected]>

[ Upstream commit 2ef813b8f405db3f72202b6fcae40a628ab80a53 ]

The 4-tuple NAT offload via PEDIT always overwrites all the 4-tuple fields even if they had not been explicitly enabled. If any fields in the 4-tuple are not enabled, then the hardware overwrites the disabled fields with zeros, instead of ignoring them.

So, add a parser that can translate the enabled 4-tuple PEDIT fields to one of the NAT mode combinations supported by the hardware and hence avoid overwriting disabled fields to 0. Any rule with unsupported NAT mode combination is rejected.

Signed-off-by Herat Ramani <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c |  175 +++++++++++++++++--
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.h |   15 +
 2 files changed, 177 insertions(+), 13 deletions(-)

drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c +162 ~~-13~~

@@ -60,6 +60,89 @@ static struct ch_tc_pedit_fields pedits[
 	PEDIT_FIELDS(IP6_, DST_127_96, 4, nat_lip, 12),
 };
 
+static const struct cxgb4_natmode_config cxgb4_natmode_config_array[] = {
+	/* Default supported NAT modes */
+	{
+		.chip = CHELSIO_T5,
+		.flags = CXGB4_ACTION_NATMODE_NONE,
+		.natmode = NAT_MODE_NONE,
+	},
+	{
+		.chip = CHELSIO_T5,
+		.flags = CXGB4_ACTION_NATMODE_DIP,
+		.natmode = NAT_MODE_DIP,
+	},
+	{
+		.chip = CHELSIO_T5,
+		.flags = CXGB4_ACTION_NATMODE_DIP | CXGB4_ACTION_NATMODE_DPORT,
+		.natmode = NAT_MODE_DIP_DP,
+	},
+	{
+		.chip = CHELSIO_T5,
+		.flags = CXGB4_ACTION_NATMODE_DIP | CXGB4_ACTION_NATMODE_DPORT |
+			 CXGB4_ACTION_NATMODE_SIP,
+		.natmode = NAT_MODE_DIP_DP_SIP,
+	},
+	{
+		.chip = CHELSIO_T5,
+		.flags = CXGB4_ACTION_NATMODE_DIP | CXGB4_ACTION_NATMODE_DPORT |
+			 CXGB4_ACTION_NATMODE_SPORT,
+		.natmode = NAT_MODE_DIP_DP_SP,
+	},
+	{
+		.chip = CHELSIO_T5,
+		.flags = CXGB4_ACTION_NATMODE_SIP | CXGB4_ACTION_NATMODE_SPORT,
+		.natmode = NAT_MODE_SIP_SP,
+	},
+	{
+		.chip = CHELSIO_T5,
+		.flags = CXGB4_ACTION_NATMODE_DIP | CXGB4_ACTION_NATMODE_SIP |
+			 CXGB4_ACTION_NATMODE_SPORT,
+		.natmode = NAT_MODE_DIP_SIP_SP,
+	},
+	{
+		.chip = CHELSIO_T5,
+		.flags = CXGB4_ACTION_NATMODE_DIP | CXGB4_ACTION_NATMODE_SIP |
+			 CXGB4_ACTION_NATMODE_DPORT |
+			 CXGB4_ACTION_NATMODE_SPORT,
+		.natmode = NAT_MODE_ALL,
+	},
+	/* T6+ can ignore L4 ports when they're disabled. */
+	{
+		.chip = CHELSIO_T6,
+		.flags = CXGB4_ACTION_NATMODE_SIP,
+		.natmode = NAT_MODE_SIP_SP,
+	},
+	{
+		.chip = CHELSIO_T6,
+		.flags = CXGB4_ACTION_NATMODE_DIP | CXGB4_ACTION_NATMODE_SPORT,
+		.natmode = NAT_MODE_DIP_DP_SP,
+	},
+	{
+		.chip = CHELSIO_T6,
+		.flags = CXGB4_ACTION_NATMODE_DIP | CXGB4_ACTION_NATMODE_SIP,
+		.natmode = NAT_MODE_ALL,
+	},
+};
+
+static void cxgb4_action_natmode_tweak(struct ch_filter_specification *fs,
+				       u8 natmode_flags)
+{
+	u8 i = 0;
+
+	/* Translate the enabled NAT 4-tuple fields to one of the
+	 * hardware supported NAT mode configurations. This ensures
+	 * that we pick a valid combination, where the disabled fields
+	 * do not get overwritten to 0.
+	 */
+	for (i = 0; i < ARRAY_SIZE(cxgb4_natmode_config_array); i++) {
+		if (cxgb4_natmode_config_array[i].flags == natmode_flags) {
+			fs->nat_mode = cxgb4_natmode_config_array[i].natmode;
+			return;
+		}
+	}
+}
+
 static struct ch_tc_flower_entry *allocate_flower_entry(void)
 {
 	struct ch_tc_flower_entry *new = kzalloc(sizeof(*new), GFP_KERNEL);

@@ -287,7 +370,8 @@ static void offload_pedit(struct ch_filt
 }
 
 static void process_pedit_field(struct ch_filter_specification *fs, u32 val,
-				u32 mask, u32 offset, u8 htype)
+				u32 mask, u32 offset, u8 htype,
+				u8 *natmode_flags)
 {
 	switch (htype) {
 	case FLOW_ACT_MANGLE_HDR_TYPE_ETH:

@@ -312,68 +396,104 @@ static void process_pedit_field(struct c
 		switch (offset) {
 		case PEDIT_IP4_SRC:
 			offload_pedit(fs, val, mask, IP4_SRC);
+			*natmode_flags |= CXGB4_ACTION_NATMODE_SIP;
 			break;
 		case PEDIT_IP4_DST:
 			offload_pedit(fs, val, mask, IP4_DST);
+			*natmode_flags |= CXGB4_ACTION_NATMODE_DIP;
 		}
-		fs->nat_mode = NAT_MODE_ALL;
 		break;
 	case FLOW_ACT_MANGLE_HDR_TYPE_IP6:
 		switch (offset) {
 		case PEDIT_IP6_SRC_31_0:
 			offload_pedit(fs, val, mask, IP6_SRC_31_0);
+			*natmode_flags |= CXGB4_ACTION_NATMODE_SIP;
 			break;
 		case PEDIT_IP6_SRC_63_32:
 			offload_pedit(fs, val, mask, IP6_SRC_63_32);
+			*natmode_flags |=  CXGB4_ACTION_NATMODE_SIP;
 			break;
 		case PEDIT_IP6_SRC_95_64:
 			offload_pedit(fs, val, mask, IP6_SRC_95_64);
+			*natmode_flags |= CXGB4_ACTION_NATMODE_SIP;
 			break;
 		case PEDIT_IP6_SRC_127_96:
 			offload_pedit(fs, val, mask, IP6_SRC_127_96);
+			*natmode_flags |= CXGB4_ACTION_NATMODE_SIP;
 			break;
 		case PEDIT_IP6_DST_31_0:
 			offload_pedit(fs, val, mask, IP6_DST_31_0);
+			*natmode_flags |= CXGB4_ACTION_NATMODE_DIP;
 			break;
 		case PEDIT_IP6_DST_63_32:
 			offload_pedit(fs, val, mask, IP6_DST_63_32);
+			*natmode_flags |= CXGB4_ACTION_NATMODE_DIP;
 			break;
 		case PEDIT_IP6_DST_95_64:
 			offload_pedit(fs, val, mask, IP6_DST_95_64);
+			*natmode_flags |= CXGB4_ACTION_NATMODE_DIP;
 			break;
 		case PEDIT_IP6_DST_127_96:
 			offload_pedit(fs, val, mask, IP6_DST_127_96);
+			*natmode_flags |= CXGB4_ACTION_NATMODE_DIP;
 		}
-		fs->nat_mode = NAT_MODE_ALL;
 		break;
 	case FLOW_ACT_MANGLE_HDR_TYPE_TCP:
 		switch (offset) {
 		case PEDIT_TCP_SPORT_DPORT:
-			if (~mask & PEDIT_TCP_UDP_SPORT_MASK)
+			if (~mask & PEDIT_TCP_UDP_SPORT_MASK) {
 				fs->nat_fport = val;
-			else
+				*natmode_flags |= CXGB4_ACTION_NATMODE_SPORT;
+			} else {
 				fs->nat_lport = val >> 16;
+				*natmode_flags |= CXGB4_ACTION_NATMODE_DPORT;
+			}
 		}
-		fs->nat_mode = NAT_MODE_ALL;
 		break;
 	case FLOW_ACT_MANGLE_HDR_TYPE_UDP:
 		switch (offset) {
 		case PEDIT_UDP_SPORT_DPORT:
-			if (~mask & PEDIT_TCP_UDP_SPORT_MASK)
+			if (~mask & PEDIT_TCP_UDP_SPORT_MASK) {
 				fs->nat_fport = val;
-			else
+				*natmode_flags |= CXGB4_ACTION_NATMODE_SPORT;
+			} else {
 				fs->nat_lport = val >> 16;
+				*natmode_flags |= CXGB4_ACTION_NATMODE_DPORT;
+			}
 		}
-		fs->nat_mode = NAT_MODE_ALL;
+		break;
 	}
 }
 
+static int cxgb4_action_natmode_validate(struct net_device *dev,
+					 struct adapter *adap, u8 natmode_flags)
+{
+	u8 i = 0;
+
+	/* Extract the NAT mode to enable based on what 4-tuple fields
+	 * are enabled to be overwritten. This ensures that the
+	 * disabled fields don't get overwritten to 0.
+	 */
+	for (i = 0; i < ARRAY_SIZE(cxgb4_natmode_config_array); i++) {
+		const struct cxgb4_natmode_config *c;
+
+		c = &cxgb4_natmode_config_array[i];
+		if (CHELSIO_CHIP_VERSION(adap->params.chip) >= c->chip &&
+		    natmode_flags == c->flags)
+			return 0;
+	}
+	netdev_err(dev, "%s: Unsupported NAT mode 4-tuple combination\n",
+		   __func__);
+	return -EOPNOTSUPP;
+}
+
 static void cxgb4_process_flow_actions(struct net_device *in,
 				       struct flow_cls_offload *cls,
 				       struct ch_filter_specification *fs)
 {
 	struct flow_rule *rule = flow_cls_offload_flow_rule(cls);
 	struct flow_action_entry *act;
+	u8 natmode_flags = 0;
 	int i;
 
 	flow_action_for_each(i, act, &rule->action) {

@@ -424,13 +544,17 @@ static void cxgb4_process_flow_actions(s
 			val = act->mangle.val;
 			offset = act->mangle.offset;
 
-			process_pedit_field(fs, val, mask, offset, htype);
+			process_pedit_field(fs, val, mask, offset, htype,
+					    &natmode_flags);
 			}
 			break;
 		default:
 			break;
 		}
 	}
+	if (natmode_flags)
+		cxgb4_action_natmode_tweak(fs, natmode_flags);
+
 }
 
 static bool valid_l4_mask(u32 mask)

@@ -447,7 +571,8 @@ static bool valid_l4_mask(u32 mask)
 }
 
 static bool valid_pedit_action(struct net_device *dev,
-			       const struct flow_action_entry *act)
+			       const struct flow_action_entry *act,
+			       u8 *natmode_flags)
 {
 	u32 mask, offset;
 	u8 htype;

@@ -472,7 +597,10 @@ static bool valid_pedit_action(struct ne
 	case FLOW_ACT_MANGLE_HDR_TYPE_IP4:
 		switch (offset) {
 		case PEDIT_IP4_SRC:
+			*natmode_flags |= CXGB4_ACTION_NATMODE_SIP;
+			break;
 		case PEDIT_IP4_DST:
+			*natmode_flags |= CXGB4_ACTION_NATMODE_DIP;
 			break;
 		default:
 			netdev_err(dev, "%s: Unsupported pedit field\n",

@@ -486,10 +614,13 @@ static bool valid_pedit_action(struct ne
 		case PEDIT_IP6_SRC_63_32:
 		case PEDIT_IP6_SRC_95_64:
 		case PEDIT_IP6_SRC_127_96:
+			*natmode_flags |= CXGB4_ACTION_NATMODE_SIP;
+			break;
 		case PEDIT_IP6_DST_31_0:
 		case PEDIT_IP6_DST_63_32:
 		case PEDIT_IP6_DST_95_64:
 		case PEDIT_IP6_DST_127_96:
+			*natmode_flags |= CXGB4_ACTION_NATMODE_DIP;
 			break;
 		default:
 			netdev_err(dev, "%s: Unsupported pedit field\n",

@@ -505,6 +636,10 @@ static bool valid_pedit_action(struct ne
 					   __func__);
 				return false;
 			}
+			if (~mask & PEDIT_TCP_UDP_SPORT_MASK)
+				*natmode_flags |= CXGB4_ACTION_NATMODE_SPORT;
+			else
+				*natmode_flags |= CXGB4_ACTION_NATMODE_DPORT;
 			break;
 		default:
 			netdev_err(dev, "%s: Unsupported pedit field\n",

@@ -520,6 +655,10 @@ static bool valid_pedit_action(struct ne
 					   __func__);
 				return false;
 			}
+			if (~mask & PEDIT_TCP_UDP_SPORT_MASK)
+				*natmode_flags |= CXGB4_ACTION_NATMODE_SPORT;
+			else
+				*natmode_flags |= CXGB4_ACTION_NATMODE_DPORT;
 			break;
 		default:
 			netdev_err(dev, "%s: Unsupported pedit field\n",

@@ -538,10 +677,12 @@ static int cxgb4_validate_flow_actions(s
 				       struct flow_cls_offload *cls)
 {
 	struct flow_rule *rule = flow_cls_offload_flow_rule(cls);
+	struct adapter *adap = netdev2adap(dev);
 	struct flow_action_entry *act;
 	bool act_redir = false;
 	bool act_pedit = false;
 	bool act_vlan = false;
+	u8 natmode_flags = 0;
 	int i;
 
 	flow_action_for_each(i, act, &rule->action) {

@@ -551,7 +692,6 @@ static int cxgb4_validate_flow_actions(s
 			/* Do nothing */
 			break;
 		case FLOW_ACTION_REDIRECT: {
-			struct adapter *adap = netdev2adap(dev);
 			struct net_device *n_dev, *target_dev;
 			unsigned int i;
 			bool found = false;

@@ -601,7 +741,8 @@ static int cxgb4_validate_flow_actions(s
 			}
 			break;
 		case FLOW_ACTION_MANGLE: {
-			bool pedit_valid = valid_pedit_action(dev, act);
+			bool pedit_valid = valid_pedit_action(dev, act,
+							      &natmode_flags);
 
 			if (!pedit_valid)
 				return -EOPNOTSUPP;

@@ -620,6 +761,14 @@ static int cxgb4_validate_flow_actions(s
 		return -EINVAL;
 	}
 
+	if (act_pedit) {
+		int ret;
+
+		ret = cxgb4_action_natmode_validate(dev, adap, natmode_flags);
+		if (ret)
+			return ret;
+	}
+
 	return 0;
 }

drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.h +15 -0

@@ -108,6 +108,21 @@ struct ch_tc_pedit_fields {
 #define PEDIT_TCP_SPORT_DPORT		0x0
 #define PEDIT_UDP_SPORT_DPORT		0x0
 
+enum cxgb4_action_natmode_flags {
+	CXGB4_ACTION_NATMODE_NONE = 0,
+	CXGB4_ACTION_NATMODE_DIP = (1 << 0),
+	CXGB4_ACTION_NATMODE_SIP = (1 << 1),
+	CXGB4_ACTION_NATMODE_DPORT = (1 << 2),
+	CXGB4_ACTION_NATMODE_SPORT = (1 << 3),
+};
+
+/* TC PEDIT action to NATMODE translation entry */
+struct cxgb4_natmode_config {
+	enum chip_type chip;
+	u8 flags;
+	u8 natmode;
+};
+
 int cxgb4_tc_flower_replace(struct net_device *dev,
 			    struct flow_cls_offload *cls);
 int cxgb4_tc_flower_destroy(struct net_device *dev,

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #20 lore raw

PATCH 20/408 binder: fix UAF when releasing todo list

From: Todd Kjos <[email protected]>

commit f3277cbfba763cd2826396521b9296de67cf1bbc upstream.

When releasing a thread todo list when tearing down a binder_proc, the following race was possible which could result in a use-after-free:

1.  Thread 1: enter binder_release_work from binder_thread_release
2.  Thread 2: binder_update_ref_for_handle() -> binder_dec_node_ilocked()
3.  Thread 2: dec nodeA --> 0 (will free node)
4.  Thread 1: ACQ inner_proc_lock
5.  Thread 2: block on inner_proc_lock
6.  Thread 1: dequeue work (BINDER_WORK_NODE, part of nodeA)
7.  Thread 1: REL inner_proc_lock
8.  Thread 2: ACQ inner_proc_lock
9.  Thread 2: todo list cleanup, but work was already dequeued

10. Thread 2: free node
11. Thread 2: REL inner_proc_lock
12. Thread 1: deref w->type (UAF)

The problem was that for a BINDER_WORK_NODE, the binder_work element must not be accessed after releasing the inner_proc_lock while processing the todo list elements since another thread might be handling a deref on the node containing the binder_work element leading to the node being freed.

Signed-off-by Todd Kjos <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Cc <[email protected]> # 4.14, 4.19, 5.4, 5.8

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/android/binder.c |   35 ++++++++++-------------------------
 1 file changed, 10 insertions(+), 25 deletions(-)

drivers/android/binder.c +10 ~~-25~~

@@ -227,7 +227,7 @@ static struct binder_transaction_log_ent
 struct binder_work {
 	struct list_head entry;
 
-	enum {
+	enum binder_work_type {
 		BINDER_WORK_TRANSACTION = 1,
 		BINDER_WORK_TRANSACTION_COMPLETE,
 		BINDER_WORK_RETURN_ERROR,

@@ -889,27 +889,6 @@ static struct binder_work *binder_dequeu
 	return w;
 }
 
-/**
- * binder_dequeue_work_head() - Dequeues the item at head of list
- * @proc:         binder_proc associated with list
- * @list:         list to dequeue head
- *
- * Removes the head of the list if there are items on the list
- *
- * Return: pointer dequeued binder_work, NULL if list was empty
- */
-static struct binder_work *binder_dequeue_work_head(
-					struct binder_proc *proc,
-					struct list_head *list)
-{
-	struct binder_work *w;
-
-	binder_inner_proc_lock(proc);
-	w = binder_dequeue_work_head_ilocked(list);
-	binder_inner_proc_unlock(proc);
-	return w;
-}
-
 static void
 binder_defer_work(struct binder_proc *proc, enum binder_deferred_state defer);
 static void binder_free_thread(struct binder_thread *thread);

@@ -4591,13 +4570,17 @@ static void binder_release_work(struct b
 				struct list_head *list)
 {
 	struct binder_work *w;
+	enum binder_work_type wtype;
 
 	while (1) {
-		w = binder_dequeue_work_head(proc, list);
+		binder_inner_proc_lock(proc);
+		w = binder_dequeue_work_head_ilocked(list);
+		wtype = w ? w->type : 0;
+		binder_inner_proc_unlock(proc);
 		if (!w)
 			return;
 
-		switch (w->type) {
+		switch (wtype) {
 		case BINDER_WORK_TRANSACTION: {
 			struct binder_transaction *t;

@@ -4631,9 +4614,11 @@ static void binder_release_work(struct b
 			kfree(death);
 			binder_stats_deleted(BINDER_STAT_DEATH);
 		} break;
+		case BINDER_WORK_NODE:
+			break;
 		default:
 			pr_err("unexpected work type, %d, not freed\n",
-			       w->type);
+			       wtype);
 			break;
 		}
 	}

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #21 lore raw

PATCH 21/408 ALSA: bebob: potential info leak in hwdep_read()

From: Dan Carpenter <[email protected]>

commit b41c15f4e1c1f1657da15c482fa837c1b7384452 upstream.

The "count" variable needs to be capped on every path so that we don't copy too much information to the user.

Fixes 618eabeae711 ("ALSA: bebob: Add hwdep interface")

Acked-by Takashi Sakamoto <[email protected]>

Link https://lore.kernel.org/r/20201007074928.GA2529578@mwanda open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/firewire/bebob/bebob_hwdep.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

sound/firewire/bebob/bebob_hwdep.c +1 -2

@@ -36,12 +36,11 @@ hwdep_read(struct snd_hwdep *hwdep, char
 	}
 
 	memset(&event, 0, sizeof(event));
+	count = min_t(long, count, sizeof(event.lock_status));
 	if (bebob->dev_lock_changed) {
 		event.lock_status.type = SNDRV_FIREWIRE_EVENT_LOCK_STATUS;
 		event.lock_status.status = (bebob->dev_lock_count > 0);
 		bebob->dev_lock_changed = false;
-
-		count = min_t(long, count, sizeof(event.lock_status));
 	}
 
 	spin_unlock_irq(&bebob->lock);

Greg Kroah-Hartman

author maintainer

2020-10-27 17:47 UTC #22 lore raw

PATCH 22/408 ALSA: hda: fix jack detection with Realtek codecs when in D3

From: Kai Vehmanen <[email protected]>

commit a6e7d0a4bdb02a7a3ffe0b44aaa8842b7efdd056 upstream.

In case HDA controller becomes active, but codec is runtime suspended, jack detection is not successful and no interrupt is raised. This has been observed with multiple Realtek codecs and HDA controllers from different vendors. Bug does not occur if both codec and controller are active, or both are in suspend. Bug can be easily hit on desktop systems with no built-in speaker.

The problem can be fixed by powering up the codec once after every controller runtime resume. Even if codec goes back to suspend later, the jack detection will continue to work. Add a flag to 'hda_codec' to describe codecs that require this flow from the controller driver. Modify __azx_runtime_resume() to use pm_request_resume() to make the intent clearer.

Mark all Realtek codecs with the new forced_resume flag.

BugLink https://bugzilla.kernel.org/show_bug.cgi?id=209379

Cc Kailang Yang <[email protected]>

Co-developed-by Kai-Heng Feng <[email protected]>

Signed-off-by Kai-Heng Feng <[email protected]>

Signed-off-by Kai Vehmanen <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/sound/hda_codec.h     |    1 +
 sound/pci/hda/hda_intel.c     |   14 ++++++++------
 sound/pci/hda/patch_realtek.c |    1 +
 3 files changed, 10 insertions(+), 6 deletions(-)

include/sound/hda_codec.h +1 -0

@@ -254,6 +254,7 @@ struct hda_codec {
 	unsigned int force_pin_prefix:1; /* Add location prefix */
 	unsigned int link_down_at_suspend:1; /* link down at runtime suspend */
 	unsigned int relaxed_resume:1;	/* don't resume forcibly for jack */
+	unsigned int forced_resume:1; /* forced resume for jack */
 
 #ifdef CONFIG_PM
 	unsigned long power_on_acct;

sound/pci/hda/hda_intel.c +8 -6

@@ -1001,12 +1001,14 @@ static void __azx_runtime_resume(struct
 	azx_init_pci(chip);
 	hda_intel_init_chip(chip, true);
 
-	if (status && from_rt) {
-		list_for_each_codec(codec, &chip->bus)
-			if (!codec->relaxed_resume &&
-			    (status & (1 << codec->addr)))
-				schedule_delayed_work(&codec->jackpoll_work,
-						      codec->jackpoll_interval);
+	if (from_rt) {
+		list_for_each_codec(codec, &chip->bus) {
+			if (codec->relaxed_resume)
+				continue;
+
+			if (codec->forced_resume || (status & (1 << codec->addr)))
+				pm_request_resume(hda_codec_dev(codec));
+		}
 	}
 
 	/* power down again for link-controlled chips */

sound/pci/hda/patch_realtek.c +1 -0

@@ -1141,6 +1141,7 @@ static int alc_alloc_spec(struct hda_cod
 	codec->single_adc_amp = 1;
 	/* FIXME: do we need this for all Realtek codec models? */
 	codec->spdif_status_reset = 1;
+	codec->forced_resume = 1;
 	codec->patch_ops = alc_patch_ops;
 
 	err = alc_codec_rename_from_preset(codec);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #23 lore raw

PATCH 23/408 ALSA: hda/hdmi: fix incorrect locking in hdmi_pcm_close

From: Kai Vehmanen <[email protected]>

commit ce1558c285f9ad04c03b46833a028230771cc0a7 upstream.

A race exists between closing a PCM and update of ELD data. In hdmi_pcm_close(), hinfo->nid value is modified without taking spec->pcm_lock. If this happens concurrently while processing an ELD update in hdmi_pcm_setup_pin(), converter assignment may be done incorrectly.

This bug was found by hitting a WARN_ON in snd_hda_spdif_ctls_assign() in a HDMI receiver connection stress test:

[2739.684569] WARNING: CPU: 5 PID: 2090 at sound/pci/hda/patch_hdmi.c:1898 check_non_pcm_per_cvt+0x41/0x50 [snd_hda_codec_hdmi]
...
[2739.684707] Call Trace:
[2739.684720]  update_eld+0x121/0x5a0 [snd_hda_codec_hdmi]
[2739.684736]  hdmi_present_sense+0x21e/0x3b0 [snd_hda_codec_hdmi]
[2739.684750]  check_presence_and_report+0x81/0xd0 [snd_hda_codec_hdmi]
[2739.684842]  intel_audio_codec_enable+0x122/0x190 [i915]

Fixes 42b2987079ec ("ALSA: hda - hdmi playback without monitor in dynamic pcm bind mode")

Signed-off-by Kai Vehmanen <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_hdmi.c |   20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

sound/pci/hda/patch_hdmi.c +12 -8

@@ -2001,22 +2001,25 @@ static int hdmi_pcm_close(struct hda_pcm
 	int pinctl;
 	int err = 0;
 
+	mutex_lock(&spec->pcm_lock);
 	if (hinfo->nid) {
 		pcm_idx = hinfo_to_pcm_index(codec, hinfo);
-		if (snd_BUG_ON(pcm_idx < 0))
-			return -EINVAL;
+		if (snd_BUG_ON(pcm_idx < 0)) {
+			err = -EINVAL;
+			goto unlock;
+		}
 		cvt_idx = cvt_nid_to_cvt_index(codec, hinfo->nid);
-		if (snd_BUG_ON(cvt_idx < 0))
-			return -EINVAL;
+		if (snd_BUG_ON(cvt_idx < 0)) {
+			err = -EINVAL;
+			goto unlock;
+		}
 		per_cvt = get_cvt(spec, cvt_idx);
-
 		snd_BUG_ON(!per_cvt->assigned);
 		per_cvt->assigned = 0;
 		hinfo->nid = 0;
 
 		azx_stream(get_azx_dev(substream))->stripe = 0;
 
-		mutex_lock(&spec->pcm_lock);
 		snd_hda_spdif_ctls_unassign(codec, pcm_idx);
 		clear_bit(pcm_idx, &spec->pcm_in_use);
 		pin_idx = hinfo_to_pin_index(codec, hinfo);

@@ -2044,10 +2047,11 @@ static int hdmi_pcm_close(struct hda_pcm
 		per_pin->setup = false;
 		per_pin->channels = 0;
 		mutex_unlock(&per_pin->lock);
-	unlock:
-		mutex_unlock(&spec->pcm_lock);
 	}
 
+unlock:
+	mutex_unlock(&spec->pcm_lock);
+
 	return err;
 }

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #24 lore raw

PATCH 24/408 nvme-pci: disable the write zeros command for Intel 600P/P3100

From: David Milburn <[email protected]>

commit ce4cc3133dc72c31bd49ddcf22d0f9eeff47a761 upstream.

The write zeros command does not work with 4k range.

bash-4.4# ./blkdiscard /dev/nvme0n1p2
bash-4.4# strace -efallocate xfs_io -c "fzero 536895488 2048" /dev/nvme0n1p2 fallocate(3, FALLOC_FL_ZERO_RANGE, 536895488, 2048) = 0
+++ exited with 0 +++
bash-4.4# dd bs=1 if=/dev/nvme0n1p2 skip=536895488 count=512 | hexdump -C 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
00000200

bash-4.4# ./blkdiscard /dev/nvme0n1p2
bash-4.4# strace -efallocate xfs_io -c "fzero 536895488 4096" /dev/nvme0n1p2 fallocate(3, FALLOC_FL_ZERO_RANGE, 536895488, 4096) = 0
+++ exited with 0 +++
bash-4.4# dd bs=1 if=/dev/nvme0n1p2 skip=536895488 count=512 | hexdump -C

00000000  5c 61 5c b0 96 21 1b 5e  85 0c 07 32 9c 8c eb 3c  |\a\..!.^...2...<|
00000010  4a a2 06 ca 67 15 2d 8e  29 8d a8 a0 7e 46 8c 62  |J...g.-.)...~F.b|
00000020  bb 4c 6c c1 6b f5 ae a5  e4 a9 bc 93 4f 60 ff 7a  |.Ll.k.......O`.z|

Reported-by Eric Sandeen <[email protected]>

Signed-off-by David Milburn <[email protected]>

Tested-by Eric Sandeen <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

[ Fix-up for 5.4 since NVME_QUIRK_NO_TEMP_THRESH_CHANGE doesn't exist ]

Signed-off-by Jason Andryuk <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/nvme/host/pci.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/nvme/host/pci.c +2 -1

@@ -3110,7 +3110,8 @@ static const struct pci_device_id nvme_i
 				NVME_QUIRK_DEALLOCATE_ZEROES, },
 	{ PCI_VDEVICE(INTEL, 0xf1a5),	/* Intel 600P/P3100 */
 		.driver_data = NVME_QUIRK_NO_DEEPEST_PS |
-				NVME_QUIRK_MEDIUM_PRIO_SQ },
+				NVME_QUIRK_MEDIUM_PRIO_SQ |
+				NVME_QUIRK_DISABLE_WRITE_ZEROES, },
 	{ PCI_VDEVICE(INTEL, 0xf1a6),	/* Intel 760p/Pro 7600p */
 		.driver_data = NVME_QUIRK_IGNORE_DEV_SUBNQN, },
 	{ PCI_VDEVICE(INTEL, 0x5845),	/* Qemu emulated controller */

Greg Kroah-Hartman

author maintainer

2020-10-27 14:29 UTC #25 lore raw

PATCH 25/408 chelsio/chtls: fix socket lock

From: Vinay Kumar Yadav <[email protected]>

[ Upstream commit 0fb5f0160a36d7acaa8e84ce873af99f94b60484 ]

In chtls_sendpage() socket lock is released but not acquired, fix it by taking lock.

Fixes 36bedb3f2e5b ("crypto: chtls - Inline TLS record Tx")

Signed-off-by Vinay Kumar Yadav <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/crypto/chelsio/chtls/chtls_io.c |    1 +
 1 file changed, 1 insertion(+)

drivers/crypto/chelsio/chtls/chtls_io.c +1 -0

@@ -1210,6 +1210,7 @@ int chtls_sendpage(struct sock *sk, stru
 	copied = 0;
 	csk = rcu_dereference_sk_user_data(sk);
 	cdev = csk->cdev;
+	lock_sock(sk);
 	timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);
 
 	err = sk_stream_wait_connect(sk, &timeo);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:29 UTC #26 lore raw

PATCH 26/408 chelsio/chtls: correct netdevice for vlan interface

From: Vinay Kumar Yadav <[email protected]>

[ Upstream commit 81519d1f7df7ed1bd5b1397540c8884438f57ae2 ]

Check if netdevice is a vlan interface and find real vlan netdevice.

Fixes cc35c88ae4db ("crypto : chtls - CPL handler definition")

Signed-off-by Venkatesh Ellapu <[email protected]>

Signed-off-by Vinay Kumar Yadav <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/crypto/chelsio/chtls/chtls_cm.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/crypto/chelsio/chtls/chtls_cm.c +3 -0

@@ -1053,6 +1053,9 @@ static struct sock *chtls_recv_sock(stru
 	ndev = n->dev;
 	if (!ndev)
 		goto free_dst;
+	if (is_vlan_dev(ndev))
+		ndev = vlan_dev_real_dev(ndev);
+
 	port_id = cxgb4_port_idx(ndev);
 
 	csk = chtls_sock_create(cdev);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:29 UTC #27 lore raw

PATCH 27/408 chelsio/chtls: correct function return and return type

From: Vinay Kumar Yadav <[email protected]>

[ Upstream commit 8580a61aede28d441e1c80588803411ee86aa299 ]

csk_mem_free() should return true if send buffer is available, false otherwise.

Fixes 3b8305f5c844 ("crypto: chtls - wait for memory sendmsg, sendpage")

Signed-off-by Vinay Kumar Yadav <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/crypto/chelsio/chtls/chtls_io.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/crypto/chelsio/chtls/chtls_io.c +2 -2

@@ -910,9 +910,9 @@ static int tls_header_read(struct tls_hd
 	return (__force int)cpu_to_be16(thdr->length);
 }
 
-static int csk_mem_free(struct chtls_dev *cdev, struct sock *sk)
+static bool csk_mem_free(struct chtls_dev *cdev, struct sock *sk)
 {
-	return (cdev->max_host_sndbuf - sk->sk_wmem_queued);
+	return (cdev->max_host_sndbuf - sk->sk_wmem_queued > 0);
 }
 
 static int csk_wait_memory(struct chtls_dev *cdev,

Greg Kroah-Hartman

author maintainer

2020-10-27 17:44 UTC #28 lore raw

PATCH 28/408 ibmvnic: save changed mac address to adapter->mac_addr

From: Lijun Pan <[email protected]>

[ Upstream commit d9b0e599b2b892422f1cbc5d2658049b895b2b58 ]

After mac address change request completes successfully, the new mac address need to be saved to adapter->mac_addr as well as netdev->dev_addr. Otherwise, adapter->mac_addr still holds old data.

Fixes 62740e97881c ("net/ibmvnic: Update MAC address settings after adapter reset")

Signed-off-by Lijun Pan <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/ibm/ibmvnic.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/net/ethernet/ibm/ibmvnic.c +5 -0

@@ -4074,8 +4074,13 @@ static int handle_change_mac_rsp(union i
 		dev_err(dev, "Error %ld in CHANGE_MAC_ADDR_RSP\n", rc);
 		goto out;
 	}
+	/* crq->change_mac_addr.mac_addr is the requested one
+	 * crq->change_mac_addr_rsp.mac_addr is the returned valid one.
+	 */
 	ether_addr_copy(netdev->dev_addr,
 			&crq->change_mac_addr_rsp.mac_addr[0]);
+	ether_addr_copy(adapter->mac_addr,
+			&crq->change_mac_addr_rsp.mac_addr[0]);
 out:
 	complete(&adapter->fw_done);
 	return rc;

Greg Kroah-Hartman

author maintainer

2020-10-27 14:29 UTC #29 lore raw

PATCH 29/408 net: ftgmac100: Fix Aspeed ast2600 TX hang issue

From: Dylan Hung <[email protected]>

[ Upstream commit 137d23cea1c044b2d4853ac71bc68126b25fdbb2 ]

The new HW arbitration feature on Aspeed ast2600 will cause MAC TX to hang when handling scatter-gather DMA. Disable the problematic feature by setting MAC register 0x58 bit28 and bit27.

Fixes 39bfab8844a0 ("net: ftgmac100: Add support for DT phy-handle property")

Signed-off-by Dylan Hung <[email protected]>

Reviewed-by Joel Stanley <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/faraday/ftgmac100.c |    5 +++++
 drivers/net/ethernet/faraday/ftgmac100.h |    8 ++++++++
 2 files changed, 13 insertions(+)

drivers/net/ethernet/faraday/ftgmac100.c +5 -0

@@ -1807,6 +1807,11 @@ static int ftgmac100_probe(struct platfo
 		priv->rxdes0_edorr_mask = BIT(30);
 		priv->txdes0_edotr_mask = BIT(30);
 		priv->is_aspeed = true;
+		/* Disable ast2600 problematic HW arbitration */
+		if (of_device_is_compatible(np, "aspeed,ast2600-mac")) {
+			iowrite32(FTGMAC100_TM_DEFAULT,
+				  priv->base + FTGMAC100_OFFSET_TM);
+		}
 	} else {
 		priv->rxdes0_edorr_mask = BIT(15);
 		priv->txdes0_edotr_mask = BIT(15);

drivers/net/ethernet/faraday/ftgmac100.h +8 -0

@@ -170,6 +170,14 @@
 #define FTGMAC100_MACCR_SW_RST		(1 << 31)
 
 /*
+ * test mode control register
+ */
+#define FTGMAC100_TM_RQ_TX_VALID_DIS (1 << 28)
+#define FTGMAC100_TM_RQ_RR_IDLE_PREV (1 << 27)
+#define FTGMAC100_TM_DEFAULT                                                   \
+	(FTGMAC100_TM_RQ_TX_VALID_DIS | FTGMAC100_TM_RQ_RR_IDLE_PREV)
+
+/*
  * PHY control register
  */
 #define FTGMAC100_PHYCR_MDC_CYCTHR_MASK	0x3f

Greg Kroah-Hartman

author maintainer

2020-10-27 14:29 UTC #30 lore raw

PATCH 30/408 net: hdlc: In hdlc_rcv, check to make sure dev is an HDLC device

From: Xie He <[email protected]>

[ Upstream commit 01c4ceae0a38a0bdbfea6896f41efcd985a9c064 ]

The hdlc_rcv function is used as hdlc_packet_type.func to process any skb received in the kernel with skb->protocol == htons(ETH_P_HDLC). The purpose of this function is to provide second-stage processing for skbs not assigned a "real" L3 skb->protocol value in the first stage.

This function assumes the device from which the skb is received is an HDLC device (a device created by this module). It assumes that netdev_priv(dev) returns a pointer to "struct hdlc_device".

However, it is possible that some driver in the kernel (not necessarily in our control) submits a received skb with skb->protocol == htons(ETH_P_HDLC), from a non-HDLC device. In this case, the skb would still be received by hdlc_rcv. This will cause problems.

hdlc_rcv should be able to recognize and drop invalid skbs. It should first make sure "dev" is actually an HDLC device, before starting its processing. This patch adds this check to hdlc_rcv.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Cc Krzysztof Halasa <[email protected]>

Signed-off-by Xie He <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wan/hdlc.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

drivers/net/wan/hdlc.c +9 -1

@@ -46,7 +46,15 @@ static struct hdlc_proto *first_proto;
 static int hdlc_rcv(struct sk_buff *skb, struct net_device *dev,
 		    struct packet_type *p, struct net_device *orig_dev)
 {
-	struct hdlc_device *hdlc = dev_to_hdlc(dev);
+	struct hdlc_device *hdlc;
+
+	/* First make sure "dev" is an HDLC device */
+	if (!(dev->priv_flags & IFF_WAN_HDLC)) {
+		kfree_skb(skb);
+		return NET_RX_SUCCESS;
+	}
+
+	hdlc = dev_to_hdlc(dev);
 
 	if (!net_eq(dev_net(dev), &init_net)) {
 		kfree_skb(skb);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:29 UTC #31 lore raw

PATCH 31/408 net: hdlc_raw_eth: Clear the IFF_TX_SKB_SHARING flag after calling ether_setup

From: Xie He <[email protected]>

[ Upstream commit 5fce1e43e2d5bf2f7e3224d7b99b1c65ab2c26e2 ]

This driver calls ether_setup to set up the network device. The ether_setup function would add the IFF_TX_SKB_SHARING flag to the device. This flag indicates that it is safe to transmit shared skbs to the device.

However, this is not true. This driver may pad the frame (in eth_tx) before transmission, so the skb may be modified.

Fixes 550fd08c2ceb ("net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared")

Cc Neil Horman <[email protected]>

Cc Krzysztof Halasa <[email protected]>

Signed-off-by Xie He <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wan/hdlc_raw_eth.c |    1 +
 1 file changed, 1 insertion(+)

drivers/net/wan/hdlc_raw_eth.c +1 -0

@@ -99,6 +99,7 @@ static int raw_eth_ioctl(struct net_devi
 		old_qlen = dev->tx_queue_len;
 		ether_setup(dev);
 		dev->tx_queue_len = old_qlen;
+		dev->priv_flags &= ~IFF_TX_SKB_SHARING;
 		eth_hw_addr_random(dev);
 		call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE, dev);
 		netif_dormant_off(dev);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:30 UTC #32 lore raw

PATCH 32/408 net: Properly typecast int values to set sk_max_pacing_rate

From: Ke Li <[email protected]>

[ Upstream commit 700465fd338fe5df08a1b2e27fa16981f562547f ]

In setsockopt(SO_MAX_PACING_RATE) on 64bit systems, sk_max_pacing_rate, after extended from 'u32' to 'unsigned long', takes unintentionally hiked value whenever assigned from an 'int' value with MSB=1, due to binary sign extension in promoting s32 to u64, e.g. 0x80000000 becomes 0xFFFFFFFF80000000.

Thus inflated sk_max_pacing_rate causes subsequent getsockopt to return ~0U unexpectedly. It may also result in increased pacing rate.

Fix by explicitly casting the 'int' value to 'unsigned int' before assigning it to sk_max_pacing_rate, for zero extension to happen.

Fixes 76a9ebe811fb ("net: extend sk_pacing_rate to unsigned long")

Signed-off-by Ji Li <[email protected]>

Signed-off-by Ke Li <[email protected]>

Reviewed-by Eric Dumazet <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/core/filter.c |    3 ++-
 net/core/sock.c   |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

net/core/filter.c +2 -1

@@ -4270,7 +4270,8 @@ BPF_CALL_5(bpf_setsockopt, struct bpf_so
 				cmpxchg(&sk->sk_pacing_status,
 					SK_PACING_NONE,
 					SK_PACING_NEEDED);
-			sk->sk_max_pacing_rate = (val == ~0U) ? ~0UL : val;
+			sk->sk_max_pacing_rate = (val == ~0U) ?
+						 ~0UL : (unsigned int)val;
 			sk->sk_pacing_rate = min(sk->sk_pacing_rate,
 						 sk->sk_max_pacing_rate);
 			break;

net/core/sock.c +1 -1

@@ -1106,7 +1106,7 @@ set_rcvbuf:
 
 	case SO_MAX_PACING_RATE:
 		{
-		unsigned long ulval = (val == ~0U) ? ~0UL : val;
+		unsigned long ulval = (val == ~0U) ? ~0UL : (unsigned int)val;
 
 		if (sizeof(ulval) != sizeof(val) &&
 		    optlen >= sizeof(ulval) &&

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #33 lore raw

PATCH 33/408 net/sched: act_tunnel_key: fix OOB write in case of IPv6 ERSPAN tunnels

Link https://lore.kernel.org/r/36ebe969f6d13ff59912d6464a4356fe6f103766.1603231100.git.dcaratti@redhat.com open here

From: Davide Caratti <[email protected]>

[ Upstream commit a7a12b5a0f950bc6b9f7153390634ea798738db9 ]

the following command

 # tc action add action tunnel_key \

Quoted 1 line

set src_ip 2001:db8::1 dst_ip 2001:db8::2 id 10 erspan_opts 1:6789:0:0

generates the following splat:

 BUG: KASAN: slab-out-of-bounds in tunnel_key_copy_opts+0xcc9/0x1010 [act_tunnel_key]
 Write of size 4 at addr ffff88813f5f1cc8 by task tc/873

 CPU: 2 PID: 873 Comm: tc Not tainted 5.9.0+ #282
 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
 Call Trace:
  dump_stack+0x99/0xcb
  print_address_description.constprop.7+0x1e/0x230
  kasan_report.cold.13+0x37/0x7c
  tunnel_key_copy_opts+0xcc9/0x1010 [act_tunnel_key]
  tunnel_key_init+0x160c/0x1f40 [act_tunnel_key]
  tcf_action_init_1+0x5b5/0x850
  tcf_action_init+0x15d/0x370
  tcf_action_add+0xd9/0x2f0
  tc_ctl_action+0x29b/0x3a0
  rtnetlink_rcv_msg+0x341/0x8d0
  netlink_rcv_skb+0x120/0x380
  netlink_unicast+0x439/0x630
  netlink_sendmsg+0x719/0xbf0
  sock_sendmsg+0xe2/0x110
  ____sys_sendmsg+0x5ba/0x890
  ___sys_sendmsg+0xe9/0x160
  __sys_sendmsg+0xd3/0x170
  do_syscall_64+0x33/0x40
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
 RIP: 0033:0x7f872a96b338
 Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55
 RSP: 002b:00007ffffe367518 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
 RAX: ffffffffffffffda RBX: 000000005f8f5aed RCX: 00007f872a96b338
 RDX: 0000000000000000 RSI: 00007ffffe367580 RDI: 0000000000000003
 RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000001c
 R10: 000000000000000b R11: 0000000000000246 R12: 0000000000000001
 R13: 0000000000686760 R14: 0000000000000601 R15: 0000000000000000

 Allocated by task 873:
  kasan_save_stack+0x19/0x40
  __kasan_kmalloc.constprop.7+0xc1/0xd0
  __kmalloc+0x151/0x310
  metadata_dst_alloc+0x20/0x40
  tunnel_key_init+0xfff/0x1f40 [act_tunnel_key]
  tcf_action_init_1+0x5b5/0x850
  tcf_action_init+0x15d/0x370
  tcf_action_add+0xd9/0x2f0
  tc_ctl_action+0x29b/0x3a0
  rtnetlink_rcv_msg+0x341/0x8d0
  netlink_rcv_skb+0x120/0x380
  netlink_unicast+0x439/0x630
  netlink_sendmsg+0x719/0xbf0
  sock_sendmsg+0xe2/0x110
  ____sys_sendmsg+0x5ba/0x890
  ___sys_sendmsg+0xe9/0x160
  __sys_sendmsg+0xd3/0x170
  do_syscall_64+0x33/0x40
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

 The buggy address belongs to the object at ffff88813f5f1c00
  which belongs to the cache kmalloc-256 of size 256
 The buggy address is located 200 bytes inside of
  256-byte region [ffff88813f5f1c00, ffff88813f5f1d00)
 The buggy address belongs to the page:
 page:0000000011b48a19 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x13f5f0
 head:0000000011b48a19 order:1 compound_mapcount:0
 flags: 0x17ffffc0010200(slab|head)
 raw: 0017ffffc0010200 0000000000000000 0000000d00000001 ffff888107c43400
 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff88813f5f1b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff88813f5f1c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 >ffff88813f5f1c80: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
                                               ^
  ffff88813f5f1d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff88813f5f1d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

using IPv6 tunnels, act_tunnel_key allocates a fixed amount of memory for the tunnel metadata, but then it expects additional bytes to store tunnel specific metadata with tunnel_key_copy_opts().

Fix the arguments of __ipv6_tun_set_dst(), so that 'md_size' contains the size previously computed by tunnel_key_get_opts_len(), like it's done for IPv4 tunnels.

Fixes 0ed5269f9e41 ("net/sched: add tunnel option support to act_tunnel_key")

Reported-by Shuang Li <[email protected]>

Signed-off-by Davide Caratti <[email protected]>

Acked-by Cong Wang <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/sched/act_tunnel_key.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/sched/act_tunnel_key.c +1 -1

@@ -315,7 +315,7 @@ static int tunnel_key_init(struct net *n
 
 			metadata = __ipv6_tun_set_dst(&saddr, &daddr, tos, ttl, dst_port,
 						      0, flags,
-						      key_id, 0);
+						      key_id, opts_len);
 		} else {
 			NL_SET_ERR_MSG(extack, "Missing either ipv4 or ipv6 src and dst");
 			ret = -EINVAL;

Greg Kroah-Hartman

author maintainer

2020-10-27 14:30 UTC #34 lore raw

PATCH 34/408 nexthop: Fix performance regression in nexthop deletion

From: Ido Schimmel <[email protected]>

[ Upstream commit df6afe2f7c19349de2ee560dc62ea4d9ad3ff889 ]

While insertion of 16k nexthops all using the same netdev ('dummy10') takes less than a second, deletion takes about 130 seconds:

# time -p ip -b nexthop.batch
real 0.29
user 0.01
sys 0.15

# time -p ip link set dev dummy10 down
real 131.03
user 0.06
sys 0.52

This is because of repeated calls to synchronize_rcu() whenever a nexthop is removed from a nexthop group:

# /usr/share/bcc/tools/offcputime -p `pgrep -nx ip` -K
...
    b'finish_task_switch'
    b'schedule'
    b'schedule_timeout'
    b'wait_for_completion'
    b'__wait_rcu_gp'
    b'synchronize_rcu.part.0'
    b'synchronize_rcu'
    b'__remove_nexthop'
    b'remove_nexthop'
    b'nexthop_flush_dev'
    b'nh_netdev_event'
    b'raw_notifier_call_chain'
    b'call_netdevice_notifiers_info'
    b'__dev_notify_flags'
    b'dev_change_flags'
    b'do_setlink'
    b'__rtnl_newlink'
    b'rtnl_newlink'
    b'rtnetlink_rcv_msg'
    b'netlink_rcv_skb'
    b'rtnetlink_rcv'
    b'netlink_unicast'
    b'netlink_sendmsg'
    b'____sys_sendmsg'
    b'___sys_sendmsg'
    b'__sys_sendmsg'
    b'__x64_sys_sendmsg'
    b'do_syscall_64'
    b'entry_SYSCALL_64_after_hwframe'
    -                ip (277)
        126554955

Since nexthops are always deleted under RTNL, synchronize_net() can be used instead. It will call synchronize_rcu_expedited() which only blocks for several microseconds as opposed to multiple milliseconds like synchronize_rcu().

With this patch deletion of 16k nexthops takes less than a second:

# time -p ip link set dev dummy10 down
real 0.12
user 0.00
sys 0.04

Tested with fib_nexthops.sh which includes torture tests that prompted the initial change:

# ./fib_nexthops.sh
...
Tests passed: 134
Tests failed:   0

Fixes 90f33bffa382 ("nexthops: don't modify published nexthop groups")

Signed-off-by Ido Schimmel <[email protected]>

Reviewed-by Jesse Brandeburg <[email protected]>

Reviewed-by David Ahern <[email protected]>

Acked-by Nikolay Aleksandrov <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ipv4/nexthop.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/ipv4/nexthop.c +1 -1

@@ -763,7 +763,7 @@ static void remove_nexthop_from_groups(s
 		remove_nh_grp_entry(net, nhge, nlinfo);
 
 	/* make sure all see the newly published array before releasing rtnl */
-	synchronize_rcu();
+	synchronize_net();
 }
 
 static void remove_nexthop_group(struct nexthop *nh, struct nl_info *nlinfo)

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #35 lore raw

PATCH 35/408 nfc: Ensure presence of NFC_ATTR_FIRMWARE_NAME attribute in nfc_genl_fw_download()

From: Defang Bo <[email protected]>

[ Upstream commit 280e3ebdafb863b3cb50d5842f056267e15bf40c ]

Check that the NFC_ATTR_FIRMWARE_NAME attributes are provided by the netlink client prior to accessing them.This prevents potential unhandled NULL pointer dereference exceptions which can be triggered by malicious user-mode programs, if they omit one or both of these attributes.

Similar to commit a0323b979f81 ("nfc: Ensure presence of required attributes in the activate_target handler").

Fixes 9674da8759df ("NFC: Add firmware upload netlink command")

Signed-off-by Defang Bo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/nfc/netlink.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/nfc/netlink.c +1 -1

@@ -1225,7 +1225,7 @@ static int nfc_genl_fw_download(struct s
 	u32 idx;
 	char firmware_name[NFC_FIRMWARE_NAME_MAXSIZE + 1];
 
-	if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+	if (!info->attrs[NFC_ATTR_DEVICE_INDEX] || !info->attrs[NFC_ATTR_FIRMWARE_NAME])
 		return -EINVAL;
 
 	idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #36 lore raw

PATCH 36/408 r8169: fix operation under forced interrupt threading

From: Heiner Kallweit <[email protected]>

[ Upstream commit 424a646e072a887aa87283b53aa6f8b19c2a7bef ]

For several network drivers it was reported that using __napi_schedule_irqoff() is unsafe with forced threading. One way to fix this is switching back to __napi_schedule, but then we lose the benefit of the irqoff version in general. As stated by Eric it doesn't make sense to make the minimal hard irq handlers in drivers using NAPI a thread. Therefore ensure that the hard irq handler is never thread-ified.

Fixes 9a899a35b0d6 ("r8169: switch to napi_schedule_irqoff")

Link https://lkml.org/lkml/2020/10/18/19

Signed-off-by Heiner Kallweit <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/realtek/r8169_main.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

drivers/net/ethernet/realtek/r8169_main.c +4 -4

@@ -6418,7 +6418,7 @@ static int rtl8169_close(struct net_devi
 
 	phy_disconnect(tp->phydev);
 
-	pci_free_irq(pdev, 0, tp);
+	free_irq(pci_irq_vector(pdev, 0), tp);
 
 	dma_free_coherent(&pdev->dev, R8169_RX_RING_BYTES, tp->RxDescArray,
 			  tp->RxPhyAddr);

@@ -6469,8 +6469,8 @@ static int rtl_open(struct net_device *d
 
 	rtl_request_firmware(tp);
 
-	retval = pci_request_irq(pdev, 0, rtl8169_interrupt, NULL, tp,
-				 dev->name);
+	retval = request_irq(pci_irq_vector(pdev, 0), rtl8169_interrupt,
+			     IRQF_NO_THREAD | IRQF_SHARED, dev->name, tp);
 	if (retval < 0)
 		goto err_release_fw_2;

@@ -6503,7 +6503,7 @@ out:
 	return retval;
 
 err_free_irq:
-	pci_free_irq(pdev, 0, tp);
+	free_irq(pci_irq_vector(pdev, 0), tp);
 err_release_fw_2:
 	rtl_release_firmware(tp);
 	rtl8169_rx_clear(tp);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:30 UTC #37 lore raw

PATCH 37/408 selftests: forwarding: Add missing rp_filter configuration

From: Ido Schimmel <[email protected]>

[ Upstream commit 71a0e29e99405d89b695882d52eec60844173697 ]

When 'rp_filter' is configured in strict mode (1) the tests fail because packets received from the macvlan netdevs would not be forwarded through them on the reverse path.

Fix this by disabling the 'rp_filter', meaning no source validation is performed.

Fixes 1538812e0880 ("selftests: forwarding: Add a test for VXLAN asymmetric routing")

Fixes 438a4f5665b2 ("selftests: forwarding: Add a test for VXLAN symmetric routing")

Signed-off-by Ido Schimmel <[email protected]>

Reported-by Hangbin Liu <[email protected]>

Tested-by Hangbin Liu <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/testing/selftests/net/forwarding/vxlan_asymmetric.sh |   10 ++++++++++
 tools/testing/selftests/net/forwarding/vxlan_symmetric.sh  |   10 ++++++++++
 2 files changed, 20 insertions(+)

tools/testing/selftests/net/forwarding/vxlan_asymmetric.sh +10 -0

@@ -215,10 +215,16 @@ switch_create()
 
 	bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 10
 	bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 20
+
+	sysctl_set net.ipv4.conf.all.rp_filter 0
+	sysctl_set net.ipv4.conf.vlan10-v.rp_filter 0
+	sysctl_set net.ipv4.conf.vlan20-v.rp_filter 0
 }
 
 switch_destroy()
 {
+	sysctl_restore net.ipv4.conf.all.rp_filter
+
 	bridge fdb del 00:00:5e:00:01:01 dev br1 self local vlan 20
 	bridge fdb del 00:00:5e:00:01:01 dev br1 self local vlan 10

@@ -359,6 +365,10 @@ ns_switch_create()
 
 	bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 10
 	bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 20
+
+	sysctl_set net.ipv4.conf.all.rp_filter 0
+	sysctl_set net.ipv4.conf.vlan10-v.rp_filter 0
+	sysctl_set net.ipv4.conf.vlan20-v.rp_filter 0
 }
 export -f ns_switch_create

tools/testing/selftests/net/forwarding/vxlan_symmetric.sh +10 -0

@@ -237,10 +237,16 @@ switch_create()
 
 	bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 10
 	bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 20
+
+	sysctl_set net.ipv4.conf.all.rp_filter 0
+	sysctl_set net.ipv4.conf.vlan10-v.rp_filter 0
+	sysctl_set net.ipv4.conf.vlan20-v.rp_filter 0
 }
 
 switch_destroy()
 {
+	sysctl_restore net.ipv4.conf.all.rp_filter
+
 	bridge fdb del 00:00:5e:00:01:01 dev br1 self local vlan 20
 	bridge fdb del 00:00:5e:00:01:01 dev br1 self local vlan 10

@@ -402,6 +408,10 @@ ns_switch_create()
 
 	bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 10
 	bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 20
+
+	sysctl_set net.ipv4.conf.all.rp_filter 0
+	sysctl_set net.ipv4.conf.vlan10-v.rp_filter 0
+	sysctl_set net.ipv4.conf.vlan20-v.rp_filter 0
 }
 export -f ns_switch_create

Greg Kroah-Hartman

author maintainer

2020-10-27 14:30 UTC #38 lore raw

PATCH 38/408 selftests: rtnetlink: load fou module for kci_test_encap_fou() test

From: Po-Hsu Lin <[email protected]>

[ Upstream commit 26ebd6fed9bb3aa480c7c0f147ac0e7b11000f65 ]

The kci_test_encap_fou() test from kci_test_encap() in rtnetlink.sh needs the fou module to work. Otherwise it will fail with:

  $ ip netns exec "$testns" ip fou add port 7777 ipproto 47
  RTNETLINK answers: No such file or directory
  Error talking to the kernel

Add the CONFIG_NET_FOU into the config file as well. Which needs at least to be set as a loadable module.

Fixes 6227efc1a20b ("selftests: rtnetlink.sh: add vxlan and fou test cases")

Signed-off-by Po-Hsu Lin <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/testing/selftests/net/config       |    1 +
 tools/testing/selftests/net/rtnetlink.sh |    5 +++++
 2 files changed, 6 insertions(+)

tools/testing/selftests/net/config +1 -0

@@ -29,3 +29,4 @@ CONFIG_NET_SCH_FQ=m
 CONFIG_NET_SCH_ETF=m
 CONFIG_TEST_BLACKHOLE_DEV=m
 CONFIG_KALLSYMS=y
+CONFIG_NET_FOU=m

tools/testing/selftests/net/rtnetlink.sh +5 -0

@@ -521,6 +521,11 @@ kci_test_encap_fou()
 		return $ksft_skip
 	fi
 
+	if ! /sbin/modprobe -q -n fou; then
+		echo "SKIP: module fou is not found"
+		return $ksft_skip
+	fi
+	/sbin/modprobe -q fou
 	ip -netns "$testns" fou add port 7777 ipproto 47 2>/dev/null
 	if [ $? -ne 0 ];then
 		echo "FAIL: can't add fou port 7777, skipping test"

Greg Kroah-Hartman

author maintainer

2020-10-27 14:30 UTC #39 lore raw

PATCH 39/408 tcp: fix to update snd_wl1 in bulk receiver fast path

Link https://www.spinics.net/lists/netdev/msg692430.html

From: Neal Cardwell <[email protected]>

[ Upstream commit 18ded910b589839e38a51623a179837ab4cc3789 ]

In the header prediction fast path for a bulk data receiver, if no data is newly acknowledged then we do not call tcp_ack() and do not call tcp_ack_update_window(). This means that a bulk receiver that receives large amounts of data can have the incoming sequence numbers wrap, so that the check in tcp_may_update_window fails:
after(ack_seq, tp->snd_wl1)

If the incoming receive windows are zero in this state, and then the connection that was a bulk data receiver later wants to send data, that connection can find itself persistently rejecting the window updates in incoming ACKs. This means the connection can persistently fail to discover that the receive window has opened, which in turn means that the connection is unable to send anything, and the connection's sending process can get permanently "stuck".

The fix is to update snd_wl1 in the header prediction fast path for a bulk data receiver, so that it keeps up and does not see wrapping problems.

This fix is based on a very nice and thorough analysis and diagnosis by Apollon Oikonomopoulos (see link below).

This is a stable candidate but there is no Fixes tag here since the bug predates current git history. Just for fun: looks like the bug dates back to when header prediction was added in Linux v2.1.8 in Nov 1996. In that version tcp_rcv_established() was added, and the code only updates snd_wl1 in tcp_ack(), and in the new "Bulk data transfer:
receiver" code path it does not call tcp_ack(). This fix seems to apply cleanly at least as far back as v3.2.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Signed-off-by Neal Cardwell <[email protected]>

Reported-by Apollon Oikonomopoulos <[email protected]>

Tested-by Apollon Oikonomopoulos <[email protected]>

Acked-by Soheil Hassas Yeganeh <[email protected]>

Acked-by Yuchung Cheng <[email protected]>

Signed-off-by Eric Dumazet <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ipv4/tcp_input.c |    2 ++
 1 file changed, 2 insertions(+)

net/ipv4/tcp_input.c +2 -0

@@ -5696,6 +5696,8 @@ void tcp_rcv_established(struct sock *sk
 				tcp_data_snd_check(sk);
 				if (!inet_csk_ack_scheduled(sk))
 					goto no_ack;
+			} else {
+				tcp_update_wl(tp, TCP_SKB_CB(skb)->seq);
 			}
 
 			__tcp_ack_snd_check(sk, 0);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:30 UTC #40 lore raw

PATCH 40/408 icmp: randomize the global rate limiter

From: Eric Dumazet <[email protected]>

[ Upstream commit b38e7819cae946e2edf869e604af1e65a5d241c5 ]

Keyu Man reported that the ICMP rate limiter could be used by attackers to get useful signal. Details will be provided in an upcoming academic publication.

Our solution is to add some noise, so that the attackers no longer can get help from the predictable token bucket limiter.

Fixes 4cdf507d5452 ("icmp: add a global rate limitation")

Signed-off-by Eric Dumazet <[email protected]>

Reported-by Keyu Man <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 Documentation/networking/ip-sysctl.txt |    4 +++-
 net/ipv4/icmp.c                        |    7 +++++--
 2 files changed, 8 insertions(+), 3 deletions(-)

Documentation/networking/ip-sysctl.txt +3 -1

@@ -1000,12 +1000,14 @@ icmp_ratelimit - INTEGER
 icmp_msgs_per_sec - INTEGER
 	Limit maximal number of ICMP packets sent per second from this host.
 	Only messages whose type matches icmp_ratemask (see below) are
-	controlled by this limit.
+	controlled by this limit. For security reasons, the precise count
+	of messages per second is randomized.
 	Default: 1000
 
 icmp_msgs_burst - INTEGER
 	icmp_msgs_per_sec controls number of ICMP packets sent per second,
 	while icmp_msgs_burst controls the burst size of these packets.
+	For security reasons, the precise burst size is randomized.
 	Default: 50
 
 icmp_ratemask - INTEGER

net/ipv4/icmp.c +5 -2

@@ -239,7 +239,7 @@ static struct {
 /**
  * icmp_global_allow - Are we allowed to send one more ICMP message ?
  *
- * Uses a token bucket to limit our ICMP messages to sysctl_icmp_msgs_per_sec.
+ * Uses a token bucket to limit our ICMP messages to ~sysctl_icmp_msgs_per_sec.
  * Returns false if we reached the limit and can not send another packet.
  * Note: called with BH disabled
  */

@@ -267,7 +267,10 @@ bool icmp_global_allow(void)
 	}
 	credit = min_t(u32, icmp_global.credit + incr, sysctl_icmp_msgs_burst);
 	if (credit) {
-		credit--;
+		/* We want to use a credit of one in average, but need to randomize
+		 * it for security reasons.
+		 */
+		credit = max_t(int, credit - prandom_u32_max(3), 0);
 		rc = true;
 	}
 	WRITE_ONCE(icmp_global.credit, credit);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #41 lore raw

PATCH 41/408 ALSA: hda/realtek - The front Mic on a HP machine doesnt work

From: Jeremy Szu <[email protected]>

commit 148ebf548a1af366fc797fcc7d03f0bb92b12a79 upstream.

On a HP ZCentral, the front Mic could not be detected.

The codec of the HP ZCentrol is alc671 and it needs to override the pin configuration to enable the headset mic.

Signed-off-by Jeremy Szu <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |    1 +
 1 file changed, 1 insertion(+)

sound/pci/hda/patch_realtek.c +1 -0

@@ -9634,6 +9634,7 @@ static const struct snd_pci_quirk alc662
 	SND_PCI_QUIRK(0x1028, 0x0698, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1028, 0x069f, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800),
+	SND_PCI_QUIRK(0x103c, 0x873e, "HP", ALC671_FIXUP_HP_HEADSET_MIC2),
 	SND_PCI_QUIRK(0x1043, 0x1080, "Asus UX501VW", ALC668_FIXUP_HEADSET_MODE),
 	SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_ASUS_Nx50),
 	SND_PCI_QUIRK(0x1043, 0x13df, "Asus N550JX", ALC662_FIXUP_BASS_1A),

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #42 lore raw

PATCH 42/408 ALSA: hda/realtek - set mic to auto detect on a HP AIO machine

From: Hui Wang <[email protected]>

commit 13468bfa8c58731dc9ecda1cd9b22a191114f944 upstream.

Recently we enabled a HP AIO machine, we found the mic on the machine couldn't record any sound and it couldn't detect plugging and unplugging as well.

Through debugging we found the mic is set to manual detect mode, after setting it to auto detect mode, it could detect plugging and unplugging and could record sound.

Signed-off-by Hui Wang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

sound/pci/hda/patch_realtek.c +11 -0

@@ -6216,6 +6216,7 @@ enum {
 	ALC269_FIXUP_LEMOTE_A190X,
 	ALC256_FIXUP_INTEL_NUC8_RUGGED,
 	ALC255_FIXUP_XIAOMI_HEADSET_MIC,
+	ALC274_FIXUP_HP_MIC,
 };
 
 static const struct hda_fixup alc269_fixups[] = {

@@ -7595,6 +7596,14 @@ static const struct hda_fixup alc269_fix
 		.chained = true,
 		.chain_id = ALC289_FIXUP_ASUS_GA401
 	},
+	[ALC274_FIXUP_HP_MIC] = {
+		.type = HDA_FIXUP_VERBS,
+		.v.verbs = (const struct hda_verb[]) {
+			{ 0x20, AC_VERB_SET_COEF_INDEX, 0x45 },
+			{ 0x20, AC_VERB_SET_PROC_COEF, 0x5089 },
+			{ }
+		},
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {

@@ -7746,6 +7755,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x8729, "HP", ALC285_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x8736, "HP", ALC285_FIXUP_HP_GPIO_AMP_INIT),
+	SND_PCI_QUIRK(0x103c, 0x874e, "HP", ALC274_FIXUP_HP_MIC),
 	SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x877d, "HP", ALC236_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC),

@@ -8071,6 +8081,7 @@ static const struct hda_model_fixup alc2
 	{.id = ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE, .name = "alc256-medion-headset"},
 	{.id = ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, .name = "alc298-samsung-headphone"},
 	{.id = ALC255_FIXUP_XIAOMI_HEADSET_MIC, .name = "alc255-xiaomi-headset"},
+	{.id = ALC274_FIXUP_HP_MIC, .name = "alc274-hp-mic-detect"},
 	{}
 };
 #define ALC225_STANDARD_PINS \

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #43 lore raw

PATCH 43/408 ALSA: hda/realtek - Add mute Led support for HP Elitebook 845 G7

From: Qiu Wenbo <[email protected]>

commit 08befca40026136c14c3cd84f9e36c4cd20a358e upstream.

After installing archlinux, the mute led and micmute led are not working at all. This patch fix this issue by applying a fixup from similar model. These mute leds are confirmed working on HP Elitebook 845 G7.

Signed-off-by Qiu Wenbo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |    1 +
 1 file changed, 1 insertion(+)

sound/pci/hda/patch_realtek.c +1 -0

@@ -7756,6 +7756,7 @@ static const struct snd_pci_quirk alc269
 	SND_PCI_QUIRK(0x103c, 0x8729, "HP", ALC285_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x8736, "HP", ALC285_FIXUP_HP_GPIO_AMP_INIT),
 	SND_PCI_QUIRK(0x103c, 0x874e, "HP", ALC274_FIXUP_HP_MIC),
+	SND_PCI_QUIRK(0x103c, 0x8760, "HP", ALC285_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x877d, "HP", ALC236_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC),

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #44 lore raw

PATCH 44/408 ALSA: hda/realtek: Enable audio jacks of ASUS D700SA with ALC887

From: Jian-Hong Pan <[email protected]>

commit ca184355db8e60290fa34bf61c13308e6f4f50d3 upstream.

The ASUS D700SA desktop's audio (1043:2390) with ALC887 cannot detect the headset microphone and another headphone jack until ALC887_FIXUP_ASUS_HMIC and ALC887_FIXUP_ASUS_AUDIO quirks are applied. The NID 0x15 maps as the headset microphone and NID 0x19 maps as another headphone jack. Also need the function like alc887_fixup_asus_jack to enable the audio jacks.

Signed-off-by Jian-Hong Pan <[email protected]>

Signed-off-by Kailang Yang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/patch_realtek.c |   42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

sound/pci/hda/patch_realtek.c +42 -0

@@ -1921,6 +1921,8 @@ enum {
 	ALC1220_FIXUP_CLEVO_P950,
 	ALC1220_FIXUP_CLEVO_PB51ED,
 	ALC1220_FIXUP_CLEVO_PB51ED_PINS,
+	ALC887_FIXUP_ASUS_AUDIO,
+	ALC887_FIXUP_ASUS_HMIC,
 };
 
 static void alc889_fixup_coef(struct hda_codec *codec,

@@ -2133,6 +2135,31 @@ static void alc1220_fixup_clevo_pb51ed(s
 	alc_fixup_headset_mode_no_hp_mic(codec, fix, action);
 }
 
+static void alc887_asus_hp_automute_hook(struct hda_codec *codec,
+					 struct hda_jack_callback *jack)
+{
+	struct alc_spec *spec = codec->spec;
+	unsigned int vref;
+
+	snd_hda_gen_hp_automute(codec, jack);
+
+	if (spec->gen.hp_jack_present)
+		vref = AC_PINCTL_VREF_80;
+	else
+		vref = AC_PINCTL_VREF_HIZ;
+	snd_hda_set_pin_ctl(codec, 0x19, PIN_HP | vref);
+}
+
+static void alc887_fixup_asus_jack(struct hda_codec *codec,
+				     const struct hda_fixup *fix, int action)
+{
+	struct alc_spec *spec = codec->spec;
+	if (action != HDA_FIXUP_ACT_PROBE)
+		return;
+	snd_hda_set_pin_ctl_cache(codec, 0x1b, PIN_HP);
+	spec->gen.hp_automute_hook = alc887_asus_hp_automute_hook;
+}
+
 static const struct hda_fixup alc882_fixups[] = {
 	[ALC882_FIXUP_ABIT_AW9D_MAX] = {
 		.type = HDA_FIXUP_PINS,

@@ -2390,6 +2417,20 @@ static const struct hda_fixup alc882_fix
 		.chained = true,
 		.chain_id = ALC1220_FIXUP_CLEVO_PB51ED,
 	},
+	[ALC887_FIXUP_ASUS_AUDIO] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x15, 0x02a14150 }, /* use as headset mic, without its own jack detect */
+			{ 0x19, 0x22219420 },
+			{}
+		},
+	},
+	[ALC887_FIXUP_ASUS_HMIC] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc887_fixup_asus_jack,
+		.chained = true,
+		.chain_id = ALC887_FIXUP_ASUS_AUDIO,
+	},
 };
 
 static const struct snd_pci_quirk alc882_fixup_tbl[] = {

@@ -2423,6 +2464,7 @@ static const struct snd_pci_quirk alc882
 	SND_PCI_QUIRK(0x1043, 0x13c2, "Asus A7M", ALC882_FIXUP_EAPD),
 	SND_PCI_QUIRK(0x1043, 0x1873, "ASUS W90V", ALC882_FIXUP_ASUS_W90V),
 	SND_PCI_QUIRK(0x1043, 0x1971, "Asus W2JC", ALC882_FIXUP_ASUS_W2JC),
+	SND_PCI_QUIRK(0x1043, 0x2390, "Asus D700SA", ALC887_FIXUP_ASUS_HMIC),
 	SND_PCI_QUIRK(0x1043, 0x835f, "Asus Eee 1601", ALC888_FIXUP_EEE1601),
 	SND_PCI_QUIRK(0x1043, 0x84bc, "ASUS ET2700", ALC887_FIXUP_ASUS_BASS),
 	SND_PCI_QUIRK(0x1043, 0x8691, "ASUS ROG Ranger VIII", ALC882_FIXUP_GPIO3),

Greg Kroah-Hartman

author maintainer

2020-10-27 14:32 UTC #45 lore raw

PATCH 45/408 cifs: remove bogus debug code

From: Dan Carpenter <[email protected]>

commit d367cb960ce88914898cbfa43645c2e43ede9465 upstream.

The "end" pointer is either NULL or it points to the next byte to parse. If there isn't a next byte then dereferencing "end" is an off-by-one out of bounds error. And, of course, if it's NULL that leads to an Oops. Printing "*end" doesn't seem very useful so let's delete this code.

Also for the last debug statement, I noticed that it should be printing "sequence_end" instead of "end" so fix that as well.

Reported-by Dominik Maier <[email protected]>

Signed-off-by Steve French <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/asn1.c |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

fs/cifs/asn1.c +8 -8

@@ -530,8 +530,8 @@ decode_negTokenInit(unsigned char *secur
 		return 0;
 	} else if ((cls != ASN1_CTX) || (con != ASN1_CON)
 		   || (tag != ASN1_EOC)) {
-		cifs_dbg(FYI, "cls = %d con = %d tag = %d end = %p (%d) exit 0\n",
-			 cls, con, tag, end, *end);
+		cifs_dbg(FYI, "cls = %d con = %d tag = %d end = %p exit 0\n",
+			 cls, con, tag, end);
 		return 0;
 	}

@@ -541,8 +541,8 @@ decode_negTokenInit(unsigned char *secur
 		return 0;
 	} else if ((cls != ASN1_UNI) || (con != ASN1_CON)
 		   || (tag != ASN1_SEQ)) {
-		cifs_dbg(FYI, "cls = %d con = %d tag = %d end = %p (%d) exit 1\n",
-			 cls, con, tag, end, *end);
+		cifs_dbg(FYI, "cls = %d con = %d tag = %d end = %p exit 1\n",
+			 cls, con, tag, end);
 		return 0;
 	}

@@ -552,8 +552,8 @@ decode_negTokenInit(unsigned char *secur
 		return 0;
 	} else if ((cls != ASN1_CTX) || (con != ASN1_CON)
 		   || (tag != ASN1_EOC)) {
-		cifs_dbg(FYI, "cls = %d con = %d tag = %d end = %p (%d) exit 0\n",
-			 cls, con, tag, end, *end);
+		cifs_dbg(FYI, "cls = %d con = %d tag = %d end = %p exit 0\n",
+			 cls, con, tag, end);
 		return 0;
 	}

@@ -564,8 +564,8 @@ decode_negTokenInit(unsigned char *secur
 		return 0;
 	} else if ((cls != ASN1_UNI) || (con != ASN1_CON)
 		   || (tag != ASN1_SEQ)) {
-		cifs_dbg(FYI, "cls = %d con = %d tag = %d end = %p (%d) exit 1\n",
-			 cls, con, tag, end, *end);
+		cifs_dbg(FYI, "cls = %d con = %d tag = %d sequence_end = %p exit 1\n",
+			 cls, con, tag, sequence_end);
 		return 0;
 	}

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #46 lore raw

PATCH 46/408 cifs: Return the error from crypt_message when enc/dec key not found.

From: Shyam Prasad N <[email protected]>

commit 0bd294b55a5de442370c29fa53bab17aef3ff318 upstream.

In crypt_message, when smb2_get_enc_key returns error, we need to return the error back to the caller. If not, we end up processing the message further, causing a kernel oops due to unwarranted access of memory.

Call Trace:
smb3_receive_transform+0x120/0x870 [cifs]
cifs_demultiplex_thread+0xb53/0xc20 [cifs]
? cifs_handle_standard+0x190/0x190 [cifs]
kthread+0x116/0x130
? kthread_park+0x80/0x80
ret_from_fork+0x1f/0x30

Signed-off-by Shyam Prasad N <[email protected]>

Reviewed-by Pavel Shilovsky <[email protected]>

Reviewed-by Ronnie Sahlberg <[email protected]>

CC Stable <[email protected]>

Signed-off-by Steve French <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/smb2ops.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/cifs/smb2ops.c +1 -1

@@ -3707,7 +3707,7 @@ crypt_message(struct TCP_Server_Info *se
 	if (rc) {
 		cifs_server_dbg(VFS, "%s: Could not get %scryption key\n", __func__,
 			 enc ? "en" : "de");
-		return 0;
+		return rc;
 	}
 
 	rc = smb3_crypto_aead_allocate(server);

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #47 lore raw

PATCH 47/408 SMB3: Resolve data corruption of TCP server info fields

From: Rohith Surabattula <[email protected]>

commit 62593011247c8a8cfeb0c86aff84688b196727c2 upstream.

TCP server info field server->total_read is modified in parallel by demultiplex thread and decrypt offload worker thread. server->total_read is used in calculation to discard the remaining data of PDU which is not read into memory.

Because of parallel modification, server->total_read can get corrupted and can result in discarding the valid data of next PDU.

Signed-off-by Rohith Surabattula <[email protected]>

Reviewed-by Aurelien Aptel <[email protected]>

Reviewed-by Pavel Shilovsky <[email protected]>

CC Stable <[email protected]> #5.4+

Signed-off-by Steve French <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/smb2ops.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

fs/cifs/smb2ops.c +7 -5

@@ -3886,7 +3886,8 @@ smb3_is_transform_hdr(void *buf)
 static int
 decrypt_raw_data(struct TCP_Server_Info *server, char *buf,
 		 unsigned int buf_data_size, struct page **pages,
-		 unsigned int npages, unsigned int page_data_size)
+		 unsigned int npages, unsigned int page_data_size,
+		 bool is_offloaded)
 {
 	struct kvec iov[2];
 	struct smb_rqst rqst = {NULL};

@@ -3912,7 +3913,8 @@ decrypt_raw_data(struct TCP_Server_Info
 
 	memmove(buf, iov[1].iov_base, buf_data_size);
 
-	server->total_read = buf_data_size + page_data_size;
+	if (!is_offloaded)
+		server->total_read = buf_data_size + page_data_size;
 
 	return rc;
 }

@@ -4126,7 +4128,7 @@ static void smb2_decrypt_offload(struct
 	struct mid_q_entry *mid;
 
 	rc = decrypt_raw_data(dw->server, dw->buf, dw->server->vals->read_rsp_size,
-			      dw->ppages, dw->npages, dw->len);
+			      dw->ppages, dw->npages, dw->len, true);
 	if (rc) {
 		cifs_dbg(VFS, "error decrypting rc=%d\n", rc);
 		goto free_pages;

@@ -4232,7 +4234,7 @@ receive_encrypted_read(struct TCP_Server
 
 non_offloaded_decrypt:
 	rc = decrypt_raw_data(server, buf, server->vals->read_rsp_size,
-			      pages, npages, len);
+			      pages, npages, len, false);
 	if (rc)
 		goto free_pages;

@@ -4288,7 +4290,7 @@ receive_encrypted_standard(struct TCP_Se
 	server->total_read += length;
 
 	buf_size = pdu_length - sizeof(struct smb2_transform_hdr);
-	length = decrypt_raw_data(server, buf, buf_size, NULL, 0, 0);
+	length = decrypt_raw_data(server, buf, buf_size, NULL, 0, 0, false);
 	if (length)
 		return length;

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #48 lore raw

PATCH 48/408 KVM: nVMX: Reset the segment cache when stuffing guest segs

From: Sean Christopherson <[email protected]>

commit fc387d8daf3960c5e1bc18fa353768056f4fd394 upstream.

Explicitly reset the segment cache after stuffing guest segment regs in prepare_vmcs02_rare(). Although the cache is reset when switching to vmcs02, there is nothing that prevents KVM from re-populating the cache prior to writing vmcs02 with vmcs12's values. E.g. if the vCPU is preempted after switching to vmcs02 but before prepare_vmcs02_rare(), kvm_arch_vcpu_put() will dereference GUEST_SS_AR_BYTES via .get_cpl() and cache the stale vmcs02 value. While the current code base only caches stale data in the preemption case, it's theoretically possible future code could read a segment register during the nested flow itself, i.e. this isn't technically illegal behavior in kvm_arch_vcpu_put(), although it did introduce the bug.

This manifests as an unexpected nested VM-Enter failure when running with unrestricted guest disabled if the above preemption case coincides with L1 switching L2's CPL, e.g. when switching from a L2 vCPU at CPL3 to to a L2 vCPU at CPL0. stack_segment_valid() will see the new SS_SEL but the old SS_AR_BYTES and incorrectly mark the guest state as invalid due to SS.dpl != SS.rpl.

Don't bother updating the cache even though prepare_vmcs02_rare() writes every segment. With unrestricted guest, guest segments are almost never read, let alone L2 guest segments. On the other hand, populating the cache requires a large number of memory writes, i.e. it's unlikely to be a net win. Updating the cache would be a win when unrestricted guest is not supported, as guest_state_valid() will immediately cache all segment registers. But, nested virtualization without unrestricted guest is dirt slow, saving some VMREADs won't change that, and every CPU manufactured in the last decade supports unrestricted guest. In other words, the extra (minor) complexity isn't worth the trouble.

Note, kvm_arch_vcpu_put() may see stale data when querying guest CPL depending on when preemption occurs. This is "ok" in that the usage is imperfect by nature, i.e. it's used heuristically to improve performance but doesn't affect functionality. kvm_arch_vcpu_put() could be "fixed" by also disabling preemption while loading segments, but that's pointless and misleading as reading state from kvm_sched_{in,out}() is guaranteed to see stale data in one form or another. E.g. even if all the usage of regs_avail is fixed to call kvm_register_mark_available() after the associated state is set, the individual state might still be stale with respect to the overall vCPU state. I.e. making functional decisions in an asynchronous hook is doomed from the get go. Thankfully KVM doesn't do that.

Fixes de63ad4cf4973 ("KVM: X86: implement the logic for spinlock optimization")

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/vmx/nested.c |    2 ++
 1 file changed, 2 insertions(+)

arch/x86/kvm/vmx/nested.c +2 -0

@@ -2231,6 +2231,8 @@ static void prepare_vmcs02_rare(struct v
 		vmcs_writel(GUEST_TR_BASE, vmcs12->guest_tr_base);
 		vmcs_writel(GUEST_GDTR_BASE, vmcs12->guest_gdtr_base);
 		vmcs_writel(GUEST_IDTR_BASE, vmcs12->guest_idtr_base);
+
+		vmx->segment_cache.bitmask = 0;
 	}
 
 	if (!hv_evmcs || !(hv_evmcs->hv_clean_fields &

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #49 lore raw

PATCH 49/408 KVM: nVMX: Reload vmcs01 if getting vmcs12s pages fails

From: Sean Christopherson <[email protected]>

commit b89d5ad00e789967a5e2c5335f75c48755bebd88 upstream.

Reload vmcs01 when bailing from nested_vmx_enter_non_root_mode() as KVM expects vmcs01 to be loaded when is_guest_mode() is false.

Fixes 671ddc700fd08 ("KVM: nVMX: Don't leak L1 MMIO regions to L2")

Cc Dan Cross <[email protected]>

Cc Jim Mattson <[email protected]>

Cc Peter Shier <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/vmx/nested.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

arch/x86/kvm/vmx/nested.c +3 -1

@@ -3096,8 +3096,10 @@ enum nvmx_vmentry_status nested_vmx_ente
 	prepare_vmcs02_early(vmx, vmcs12);
 
 	if (from_vmentry) {
-		if (unlikely(!nested_get_vmcs12_pages(vcpu)))
+		if (unlikely(!nested_get_vmcs12_pages(vcpu))) {
+			vmx_switch_vmcs(vcpu, &vmx->vmcs01);
 			return NVMX_VMENTRY_KVM_INTERNAL_ERROR;
+		}
 
 		if (nested_vmx_check_vmentry_hw(vcpu)) {
 			vmx_switch_vmcs(vcpu, &vmx->vmcs01);

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #50 lore raw

PATCH 50/408 KVM: x86/mmu: Commit zap of remaining invalid pages when recovering lpages

From: Sean Christopherson <[email protected]>

commit e89505698c9f70125651060547da4ff5046124fc upstream.

Call kvm_mmu_commit_zap_page() after exiting the "prepare zap" loop in kvm_recover_nx_lpages() to finish zapping pages in the unlikely event that the loop exited due to lpage_disallowed_mmu_pages being empty. Because the recovery thread drops mmu_lock() when rescheduling, it's possible that lpage_disallowed_mmu_pages could be emptied by a different thread without to_zap reaching zero despite to_zap being derived from the number of disallowed lpages.

Fixes 1aa9b9572b105 ("kvm: x86: mmu: Recovery of shattered NX large pages")

Cc Junaid Shahid <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/mmu.c |    1 +
 1 file changed, 1 insertion(+)

arch/x86/kvm/mmu.c +1 -0

@@ -6453,6 +6453,7 @@ static void kvm_recover_nx_lpages(struct
 				cond_resched_lock(&kvm->mmu_lock);
 		}
 	}
+	kvm_mmu_commit_zap_page(kvm, &invalid_list);
 
 	spin_unlock(&kvm->mmu_lock);
 	srcu_read_unlock(&kvm->srcu, rcu_idx);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:32 UTC #51 lore raw

PATCH 51/408 KVM: SVM: Initialize prev_ga_tag before use

From: Suravee Suthikulpanit <[email protected]>

commit f6426ab9c957e97418ac5b0466538792767b1738 upstream.

The function amd_ir_set_vcpu_affinity makes use of the parameter struct amd_iommu_pi_data.prev_ga_tag to determine if it should delete struct amd_iommu_pi_data from a list when not running in AVIC mode.

However, prev_ga_tag is initialized only when AVIC is enabled. The non-zero uninitialized value can cause unintended code path, which ends up making use of the struct vcpu_svm.ir_list and ir_list_lock without being initialized (since they are intended only for the AVIC case).

This triggers NULL pointer dereference bug in the function vm_ir_list_del with the following call trace:

    svm_update_pi_irte+0x3c2/0x550 [kvm_amd]
    ? proc_create_single_data+0x41/0x50
    kvm_arch_irq_bypass_add_producer+0x40/0x60 [kvm]
    __connect+0x5f/0xb0 [irqbypass]
    irq_bypass_register_producer+0xf8/0x120 [irqbypass]
    vfio_msi_set_vector_signal+0x1de/0x2d0 [vfio_pci]
    vfio_msi_set_block+0x77/0xe0 [vfio_pci]
    vfio_pci_set_msi_trigger+0x25c/0x2f0 [vfio_pci]
    vfio_pci_set_irqs_ioctl+0x88/0xb0 [vfio_pci]
    vfio_pci_ioctl+0x2ea/0xed0 [vfio_pci]
    ? alloc_file_pseudo+0xa5/0x100
    vfio_device_fops_unl_ioctl+0x26/0x30 [vfio]
    ? vfio_device_fops_unl_ioctl+0x26/0x30 [vfio]
    __x64_sys_ioctl+0x96/0xd0
    do_syscall_64+0x37/0x80
    entry_SYSCALL_64_after_hwframe+0x44/0xa9

Therefore, initialize prev_ga_tag to zero before use. This should be safe because ga_tag value 0 is invalid (see function avic_vm_init).

Fixes dfa20099e26e ("KVM: SVM: Refactor AVIC vcpu initialization into avic_init_vcpu()")

Signed-off-by Suravee Suthikulpanit <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/svm.c |    1 +
 1 file changed, 1 insertion(+)

arch/x86/kvm/svm.c +1 -0

@@ -5383,6 +5383,7 @@ static int svm_update_pi_irte(struct kvm
 			 * - Tell IOMMU to use legacy mode for this interrupt.
 			 * - Retrieve ga_tag of prior interrupt remapping data.
 			 */
+			pi.prev_ga_tag = 0;
 			pi.is_guest_mode = false;
 			ret = irq_set_vcpu_affinity(host_irq, &pi);

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #52 lore raw

PATCH 52/408 ima: Dont ignore errors from crypto_shash_update()

From: Roberto Sassu <[email protected]>

commit 60386b854008adc951c470067f90a2d85b5d520f upstream.

Errors returned by crypto_shash_update() are not checked in ima_calc_boot_aggregate_tfm() and thus can be overwritten at the next iteration of the loop. This patch adds a check after calling crypto_shash_update() and returns immediately if the result is not zero.

Fixes 3323eec921efd ("integrity: IMA as an integrity service provider")

Signed-off-by Roberto Sassu <[email protected]>

Signed-off-by Mimi Zohar <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 security/integrity/ima/ima_crypto.c |    2 ++
 1 file changed, 2 insertions(+)

security/integrity/ima/ima_crypto.c +2 -0

@@ -688,6 +688,8 @@ static int ima_calc_boot_aggregate_tfm(c
 		/* now accumulate with current aggregate */
 		rc = crypto_shash_update(shash, d.digest,
 					 crypto_shash_digestsize(tfm));
+		if (rc != 0)
+			return rc;
 	}
 	if (!rc)
 		crypto_shash_final(shash, digest);

Greg Kroah-Hartman

author maintainer

2020-10-27 14:32 UTC #53 lore raw

PATCH 53/408 crypto: algif_aead - Do not set MAY_BACKLOG on the async path

From: Herbert Xu <[email protected]>

commit cbdad1f246dd98e6c9c32a6e5212337f542aa7e0 upstream.

The async path cannot use MAY_BACKLOG because it is not meant to block, which is what MAY_BACKLOG does. On the other hand, both the sync and async paths can make use of MAY_SLEEP.

Fixes 83094e5e9e49 ("crypto: af_alg - add async support to...")

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 crypto/algif_aead.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

crypto/algif_aead.c +4 -3

@@ -78,7 +78,7 @@ static int crypto_aead_copy_sgl(struct c
 	SYNC_SKCIPHER_REQUEST_ON_STACK(skreq, null_tfm);
 
 	skcipher_request_set_sync_tfm(skreq, null_tfm);
-	skcipher_request_set_callback(skreq, CRYPTO_TFM_REQ_MAY_BACKLOG,
+	skcipher_request_set_callback(skreq, CRYPTO_TFM_REQ_MAY_SLEEP,
 				      NULL, NULL);
 	skcipher_request_set_crypt(skreq, src, dst, len, NULL);

@@ -291,19 +291,20 @@ static int _aead_recvmsg(struct socket *
 		areq->outlen = outlen;
 
 		aead_request_set_callback(&areq->cra_u.aead_req,
-					  CRYPTO_TFM_REQ_MAY_BACKLOG,
+					  CRYPTO_TFM_REQ_MAY_SLEEP,
 					  af_alg_async_cb, areq);
 		err = ctx->enc ? crypto_aead_encrypt(&areq->cra_u.aead_req) :
 				 crypto_aead_decrypt(&areq->cra_u.aead_req);
 
 		/* AIO operation in progress */
-		if (err == -EINPROGRESS || err == -EBUSY)
+		if (err == -EINPROGRESS)
 			return -EIOCBQUEUED;
 
 		sock_put(sk);
 	} else {
 		/* Synchronous operation */
 		aead_request_set_callback(&areq->cra_u.aead_req,
+					  CRYPTO_TFM_REQ_MAY_SLEEP |
 					  CRYPTO_TFM_REQ_MAY_BACKLOG,
 					  crypto_req_done, &ctx->wait);
 		err = crypto_wait_req(ctx->enc ?

Greg Kroah-Hartman

author maintainer

2020-10-27 14:32 UTC #54 lore raw

PATCH 54/408 crypto: caam/qi - add fallback for XTS with more than 8B IV

From: Andrei Botila <[email protected]>

commit 83e8aa9121380b23ebae6e413962fa2a7b52cf92 upstream.

A hardware limitation exists for CAAM until Era 9 which restricts the accelerator to IVs with only 8 bytes. When CAAM has a lower era a fallback is necessary to process 16 bytes IV.

Fixes b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms")

Cc <[email protected]> # v4.12+

Signed-off-by Andrei Botila <[email protected]>

Reviewed-by Horia Geantă <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/crypto/caam/Kconfig      |    1 
 drivers/crypto/caam/caamalg_qi.c |   70 ++++++++++++++++++++++++++++++++++++---
 2 files changed, 67 insertions(+), 4 deletions(-)

drivers/crypto/caam/Kconfig +1 -0

@@ -112,6 +112,7 @@ config CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI
 	select CRYPTO_AUTHENC
 	select CRYPTO_BLKCIPHER
 	select CRYPTO_DES
+	select CRYPTO_XTS
 	help
 	  Selecting this will use CAAM Queue Interface (QI) for sending
 	  & receiving crypto jobs to/from CAAM. This gives better performance

drivers/crypto/caam/caamalg_qi.c +66 -4

131 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #55 lore raw

PATCH 55/408 EDAC/i5100: Fix error handling order in i5100_init_one()

From: Dinghao Liu <[email protected]>

[ Upstream commit 857a3139bd8be4f702c030c8ca06f3fd69c1741a ]

When pci_get_device_func() fails, the driver doesn't need to execute pci_dev_put(). mci should still be freed, though, to prevent a memory leak. When pci_enable_device() fails, the error injection PCI device "einj" doesn't need to be disabled either.

[ bp: Massage commit message, rename label to "bail_mc_free". ]

Fixes 52608ba205461 ("i5100_edac: probe for device 19 function 0")

Signed-off-by Dinghao Liu <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/edac/i5100_edac.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

drivers/edac/i5100_edac.c +5 -6

index 251f2b692785d..0c72daa519ffa 100644
@@ -1074,16 +1074,15 @@ static int i5100_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
 				    PCI_DEVICE_ID_INTEL_5100_19, 0);
 	if (!einj) {
 		ret = -ENODEV;
-		goto bail_einj;
+		goto bail_mc_free;
 	}
 
 	rc = pci_enable_device(einj);
 	if (rc < 0) {
 		ret = rc;
-		goto bail_disable_einj;
+		goto bail_einj;
 	}
 
-
 	mci->pdev = &pdev->dev;
 
 	priv = mci->pvt_info;

@@ -1149,14 +1148,14 @@ static int i5100_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
 bail_scrub:
 	priv->scrub_enable = 0;
 	cancel_delayed_work_sync(&(priv->i5100_scrubbing));
-	edac_mc_free(mci);
-
-bail_disable_einj:
 	pci_disable_device(einj);
 
 bail_einj:
 	pci_dev_put(einj);
 
+bail_mc_free:
+	edac_mc_free(mci);
+
 bail_disable_ch1:
 	pci_disable_device(ch1mm);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #56 lore raw

PATCH 56/408 EDAC/aspeed: Fix handling of platform_get_irq() error

From: Krzysztof Kozlowski <[email protected]>

[ Upstream commit afce6996943be265fa39240b67025cfcb1bcdfb1 ]

platform_get_irq() returns a negative error number on error. In such a case, comparison to 0 would pass the check therefore check the return value properly, whether it is negative.

[ bp: Massage commit message. ]

Fixes 9b7e6242ee4e ("EDAC, aspeed: Add an Aspeed AST2500 EDAC driver")

Signed-off-by Krzysztof Kozlowski <[email protected]>

Reviewed-by Stefan Schaeckeler <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/edac/aspeed_edac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/edac/aspeed_edac.c +2 -2

index 5634437bb39d2..66669f9d690be 100644
@@ -209,8 +209,8 @@ static int config_irq(void *ctx, struct platform_device *pdev)
 	/* register interrupt handler */
 	irq = platform_get_irq(pdev, 0);
 	dev_dbg(&pdev->dev, "got irq %d\n", irq);
-	if (!irq)
-		return -ENODEV;
+	if (irq < 0)
+		return irq;
 
 	rc = devm_request_irq(&pdev->dev, irq, mcr_isr, IRQF_TRIGGER_HIGH,
 			      DRV_NAME, ctx);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #57 lore raw

PATCH 57/408 EDAC/ti: Fix handling of platform_get_irq() error

From: Krzysztof Kozlowski <[email protected]>

[ Upstream commit 66077adb70a2a9e92540155b2ace33ec98299c90 ]

platform_get_irq() returns a negative error number on error. In such a case, comparison to 0 would pass the check therefore check the return value properly, whether it is negative.

[ bp: Massage commit message. ]

Fixes 86a18ee21e5e ("EDAC, ti: Add support for TI keystone and DRA7xx EDAC")

Signed-off-by Krzysztof Kozlowski <[email protected]>

Reviewed-by Tero Kristo <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/edac/ti_edac.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/edac/ti_edac.c +2 -1

index 6ac26d1b929f0..3247689467435 100644
@@ -278,7 +278,8 @@ static int ti_edac_probe(struct platform_device *pdev)
 
 	/* add EMIF ECC error handler */
 	error_irq = platform_get_irq(pdev, 0);
-	if (!error_irq) {
+	if (error_irq < 0) {
+		ret = error_irq;
 		edac_printk(KERN_ERR, EDAC_MOD_NAME,
 			    "EMIF irq number not defined.\n");
 		goto err;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #58 lore raw

PATCH 58/408 perf/x86/intel/ds: Fix x86_pmu_stop warning for large PEBS

From: Kan Liang <[email protected]>

[ Upstream commit 35d1ce6bec133679ff16325d335217f108b84871 ]

A warning as below may be triggered when sampling with large PEBS.

[  410.411250] perf: interrupt took too long (72145 > 71975), lowering
kernel.perf_event_max_sample_rate to 2000
[  410.724923] ------------[ cut here ]------------
[  410.729822] WARNING: CPU: 0 PID: 16397 at arch/x86/events/core.c:1422
x86_pmu_stop+0x95/0xa0
[  410.933811]  x86_pmu_del+0x50/0x150
[  410.937304]  event_sched_out.isra.0+0xbc/0x210
[  410.941751]  group_sched_out.part.0+0x53/0xd0
[  410.946111]  ctx_sched_out+0x193/0x270
[  410.949862]  __perf_event_task_sched_out+0x32c/0x890
[  410.954827]  ? set_next_entity+0x98/0x2d0
[  410.958841]  __schedule+0x592/0x9c0
[  410.962332]  schedule+0x5f/0xd0
[  410.965477]  exit_to_usermode_loop+0x73/0x120
[  410.969837]  prepare_exit_to_usermode+0xcd/0xf0
[  410.974369]  ret_from_intr+0x2a/0x3a
[  410.977946] RIP: 0033:0x40123c
[  411.079661] ---[ end trace bc83adaea7bb664a ]---

In the non-overflow context, e.g., context switch, with large PEBS, perf may stop an event twice. An example is below.

//max_samples_per_tick is adjusted to 2
//NMI is triggered
intel_pmu_handle_irq()

     handle_pmi_common()
       drain_pebs()
         __intel_pmu_pebs_event()
           perf_event_overflow()
             __perf_event_account_interrupt()
               hwc->interrupts = 1
               return 0
  //A context switch happens right after the NMI.
  //In the same tick, the perf_throttled_seq is not changed.
  perf_event_task_sched_out()
     perf_pmu_sched_task()
       intel_pmu_drain_pebs_buffer()
         __intel_pmu_pebs_event()
           perf_event_overflow()
             __perf_event_account_interrupt()
               ++hwc->interrupts >= max_samples_per_tick
               return 1
           x86_pmu_stop();  # First stop
     perf_event_context_sched_out()
       task_ctx_sched_out()
         ctx_sched_out()
           event_sched_out()
             x86_pmu_del()
               x86_pmu_stop();  # Second stop and trigger the warning

Perf should only invoke the perf_event_overflow() in the overflow context.

Current drain_pebs() is called from:
- handle_pmi_common() -- overflow context
- intel_pmu_pebs_sched_task() -- non-overflow context
- intel_pmu_pebs_disable() -- non-overflow context
- intel_pmu_auto_reload_read() -- possible overflow context
With PERF_SAMPLE_READ + PERF_FORMAT_GROUP, the function may be invoked in the NMI handler. But, before calling the function, the PEBS buffer has already been drained. The __intel_pmu_pebs_event() will not be called in the possible overflow context.

To fix the issue, an indicator is required to distinguish between the overflow context aka handle_pmi_common() and other cases. The dummy regs pointer can be used as the indicator.

In the non-overflow context, perf should treat the last record the same as other PEBS records, and doesn't invoke the generic overflow handler.

Fixes 21509084f999 ("perf/x86/intel: Handle multiple records in the PEBS buffer")

Reported-by Like Xu <[email protected]>

Signed-off-by Kan Liang <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Tested-by Like Xu <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/events/intel/ds.c | 32 ++++++++++++++++++++------------
 1 file changed, 20 insertions(+), 12 deletions(-)

arch/x86/events/intel/ds.c +20 ~~-12~~

index e5ad97a823426..1aaba2c8a9ba6 100644
@@ -669,9 +669,7 @@ int intel_pmu_drain_bts_buffer(void)
 
 static inline void intel_pmu_drain_pebs_buffer(void)
 {
-	struct pt_regs regs;
-
-	x86_pmu.drain_pebs(&regs);
+	x86_pmu.drain_pebs(NULL);
 }
 
 /*

@@ -1736,6 +1734,7 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
 	struct x86_perf_regs perf_regs;
 	struct pt_regs *regs = &perf_regs.regs;
 	void *at = get_next_pebs_record_by_bit(base, top, bit);
+	struct pt_regs dummy_iregs;
 
 	if (hwc->flags & PERF_X86_EVENT_AUTO_RELOAD) {
 		/*

@@ -1748,6 +1747,9 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
 	} else if (!intel_pmu_save_and_restart(event))
 		return;
 
+	if (!iregs)
+		iregs = &dummy_iregs;
+
 	while (count > 1) {
 		setup_sample(event, iregs, at, &data, regs);
 		perf_event_output(event, &data, regs);

@@ -1757,16 +1759,22 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
 	}
 
 	setup_sample(event, iregs, at, &data, regs);
-
-	/*
-	 * All but the last records are processed.
-	 * The last one is left to be able to call the overflow handler.
-	 */
-	if (perf_event_overflow(event, &data, regs)) {
-		x86_pmu_stop(event, 0);
-		return;
+	if (iregs == &dummy_iregs) {
+		/*
+		 * The PEBS records may be drained in the non-overflow context,
+		 * e.g., large PEBS + context switch. Perf should treat the
+		 * last record the same as other PEBS records, and doesn't
+		 * invoke the generic overflow handler.
+		 */
+		perf_event_output(event, &data, regs);
+	} else {
+		/*
+		 * All but the last records are processed.
+		 * The last one is left to be able to call the overflow handler.
+		 */
+		if (perf_event_overflow(event, &data, regs))
+			x86_pmu_stop(event, 0);
 	}
-
 }
 
 static void intel_pmu_drain_pebs_core(struct pt_regs *iregs)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #59 lore raw

PATCH 59/408 x86/fpu: Allow multiple bits in clearcpuid= parameter

From: Arvind Sankar <[email protected]>

[ Upstream commit 0a4bb5e5507a585532cc413125b921c8546fc39f ]

Commit

0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument")

changed clearcpuid parsing from __setup() to cmdline_find_option(). While the __setup() function would have been called for each clearcpuid= parameter on the command line, cmdline_find_option() will only return the last one, so the change effectively made it impossible to disable more than one bit.

Allow a comma-separated list of bit numbers as the argument for clearcpuid to allow multiple bits to be disabled again. Log the bits being disabled for informational purposes.

Also fix the check on the return value of cmdline_find_option(). It returns -1 when the option is not found, so testing as a boolean is incorrect.

Fixes 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as early XSAVE argument")

Signed-off-by Arvind Sankar <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 .../admin-guide/kernel-parameters.txt         |  2 +-
 arch/x86/kernel/fpu/init.c                    | 30 ++++++++++++++-----
 2 files changed, 23 insertions(+), 9 deletions(-)

Documentation/admin-guide/kernel-parameters.txt +1 -1

index 13984b6cc3225..988a0d2535b25 100644
@@ -567,7 +567,7 @@
 			loops can be debugged more effectively on production
 			systems.
 
-	clearcpuid=BITNUM [X86]
+	clearcpuid=BITNUM[,BITNUM...] [X86]
 			Disable CPUID feature X for the kernel. See
 			arch/x86/include/asm/cpufeatures.h for the valid bit
 			numbers. Note the Linux specific bits are not necessarily

arch/x86/kernel/fpu/init.c +22 -8

index 6ce7e0a23268f..b271da0fa2193 100644
@@ -242,9 +242,9 @@ static void __init fpu__init_system_ctx_switch(void)
  */
 static void __init fpu__init_parse_early_param(void)
 {
-	char arg[32];
+	char arg[128];
 	char *argptr = arg;
-	int bit;
+	int arglen, res, bit;
 
 #ifdef CONFIG_X86_32
 	if (cmdline_find_option_bool(boot_command_line, "no387"))

@@ -267,12 +267,26 @@ static void __init fpu__init_parse_early_param(void)
 	if (cmdline_find_option_bool(boot_command_line, "noxsaves"))
 		setup_clear_cpu_cap(X86_FEATURE_XSAVES);
 
-	if (cmdline_find_option(boot_command_line, "clearcpuid", arg,
-				sizeof(arg)) &&
-	    get_option(&argptr, &bit) &&
-	    bit >= 0 &&
-	    bit < NCAPINTS * 32)
-		setup_clear_cpu_cap(bit);
+	arglen = cmdline_find_option(boot_command_line, "clearcpuid", arg, sizeof(arg));
+	if (arglen <= 0)
+		return;
+
+	pr_info("Clearing CPUID bits:");
+	do {
+		res = get_option(&argptr, &bit);
+		if (res == 0 || res == 3)
+			break;
+
+		/* If the argument was too long, the last bit may be cut off */
+		if (res == 1 && arglen >= sizeof(arg))
+			break;
+
+		if (bit >= 0 && bit < NCAPINTS * 32) {
+			pr_cont(" " X86_CAP_FMT, x86_cap_flag(bit));
+			setup_clear_cpu_cap(bit);
+		}
+	} while (res == 2);
+	pr_cont("\n");
 }
 
 /*

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:46 UTC #60 lore raw

PATCH 60/408 drivers/perf: xgene_pmu: Fix uninitialized resource struct

From: Mark Salter <[email protected]>

[ Upstream commit a76b8236edcf5b785d044b930f9e14ad02b4a484 ]

This splat was reported on newer Fedora kernels booting on certain X-gene based machines:

xgene-pmu APMC0D83:00: X-Gene PMU version 3

 Unable to handle kernel read from unreadable memory at virtual \
 address 0000000000004006
 ...
 Call trace:
  string+0x50/0x100
  vsnprintf+0x160/0x750
  devm_kvasprintf+0x5c/0xb4
  devm_kasprintf+0x54/0x60
  __devm_ioremap_resource+0xdc/0x1a0
  devm_ioremap_resource+0x14/0x20
  acpi_get_pmu_hw_inf.isra.0+0x84/0x15c
  acpi_pmu_dev_add+0xbc/0x21c
  acpi_ns_walk_namespace+0x16c/0x1e4
  acpi_walk_namespace+0xb4/0xfc
  xgene_pmu_probe_pmu_dev+0x7c/0xe0
  xgene_pmu_probe.part.0+0x2c0/0x310
  xgene_pmu_probe+0x54/0x64
  platform_drv_probe+0x60/0xb4
  really_probe+0xe8/0x4a0
  driver_probe_device+0xe4/0x100
  device_driver_attach+0xcc/0xd4
  __driver_attach+0xb0/0x17c
  bus_for_each_dev+0x6c/0xb0
  driver_attach+0x30/0x40
  bus_add_driver+0x154/0x250
  driver_register+0x84/0x140
  __platform_driver_register+0x54/0x60
  xgene_pmu_driver_init+0x28/0x34
  do_one_initcall+0x40/0x204
  do_initcalls+0x104/0x144
  kernel_init_freeable+0x198/0x210
  kernel_init+0x20/0x12c
  ret_from_fork+0x10/0x18
 Code: 91000400 110004e1 eb08009f 540000c0 (38646846)
 ---[ end trace f08c10566496a703 ]---

This is due to use of an uninitialized local resource struct in the xgene pmu driver. The thunderx2_pmu driver avoids this by using the resource list constructed by acpi_dev_get_resources() rather than using a callback from that function. The callback in the xgene driver didn't fully initialize the resource. So get rid of the callback and search the resource list as done by thunderx2.

Fixes 832c927d119b ("perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver")

Signed-off-by Mark Salter <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/perf/xgene_pmu.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

drivers/perf/xgene_pmu.c +17 ~~-15~~

index 328aea9f6be32..50b37f8f5c7ff 100644
@@ -1459,17 +1459,6 @@ static char *xgene_pmu_dev_name(struct device *dev, u32 type, int id)
 }
 
 #if defined(CONFIG_ACPI)
-static int acpi_pmu_dev_add_resource(struct acpi_resource *ares, void *data)
-{
-	struct resource *res = data;
-
-	if (ares->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32)
-		acpi_dev_resource_memory(ares, res);
-
-	/* Always tell the ACPI core to skip this resource */
-	return 1;
-}
-
 static struct
 xgene_pmu_dev_ctx *acpi_get_pmu_hw_inf(struct xgene_pmu *xgene_pmu,
 				       struct acpi_device *adev, u32 type)

@@ -1481,6 +1470,7 @@ xgene_pmu_dev_ctx *acpi_get_pmu_hw_inf(struct xgene_pmu *xgene_pmu,
 	struct hw_pmu_info *inf;
 	void __iomem *dev_csr;
 	struct resource res;
+	struct resource_entry *rentry;
 	int enable_bit;
 	int rc;

@@ -1489,11 +1479,23 @@ xgene_pmu_dev_ctx *acpi_get_pmu_hw_inf(struct xgene_pmu *xgene_pmu,
 		return NULL;
 
 	INIT_LIST_HEAD(&resource_list);
-	rc = acpi_dev_get_resources(adev, &resource_list,
-				    acpi_pmu_dev_add_resource, &res);
+	rc = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
+	if (rc <= 0) {
+		dev_err(dev, "PMU type %d: No resources found\n", type);
+		return NULL;
+	}
+
+	list_for_each_entry(rentry, &resource_list, node) {
+		if (resource_type(rentry->res) == IORESOURCE_MEM) {
+			res = *rentry->res;
+			rentry = NULL;
+			break;
+		}
+	}
 	acpi_dev_free_resource_list(&resource_list);
-	if (rc < 0) {
-		dev_err(dev, "PMU type %d: No resource address found\n", type);
+
+	if (rentry) {
+		dev_err(dev, "PMU type %d: No memory resource found\n", type);
 		return NULL;
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:44 UTC #61 lore raw

PATCH 61/408 drivers/perf: thunderx2_pmu: Fix memory resource error handling

From: Mark Salter <[email protected]>

[ Upstream commit 688494a407d1419a6b158c644b262c61cde39f48 ]

In tx2_uncore_pmu_init_dev(), a call to acpi_dev_get_resources() is used to create a list _CRS resources which is searched for the device base address. There is an error check following this:

if (!rentry->res)
return NULL

In no case, will rentry->res be NULL, so the test is useless. Even if the test worked, it comes before the resource list memory is freed. None of this really matters as long as the ACPI table has the memory resource. Let's clean it up so that it makes sense and will give a meaningful error should firmware leave out the memory resource.

Fixes 69c32972d593 ("drivers/perf: Add Cavium ThunderX2 SoC UNCORE PMU driver")

Signed-off-by Mark Salter <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/perf/thunderx2_pmu.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/perf/thunderx2_pmu.c +5 -2

index 9e1c3c7eeba9b..170ccb164c604 100644
@@ -627,14 +627,17 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
 	list_for_each_entry(rentry, &list, node) {
 		if (resource_type(rentry->res) == IORESOURCE_MEM) {
 			res = *rentry->res;
+			rentry = NULL;
 			break;
 		}
 	}
+	acpi_dev_free_resource_list(&list);
 
-	if (!rentry->res)
+	if (rentry) {
+		dev_err(dev, "PMU type %d: Fail to find resource\n", type);
 		return NULL;
+	}
 
-	acpi_dev_free_resource_list(&list);
 	base = devm_ioremap_resource(dev, &res);
 	if (IS_ERR(base)) {
 		dev_err(dev, "PMU type %d: Fail to map resource\n", type);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:44 UTC #62 lore raw

PATCH 62/408 sched/fair: Fix wrong cpu selecting from isolated domain

From: Xunlei Pang <[email protected]>

[ Upstream commit df3cb4ea1fb63ff326488efd671ba3c39034255e ]

We've met problems that occasionally tasks with full cpumask (e.g. by putting it into a cpuset or setting to full affinity) were migrated to our isolated cpus in production environment.

After some analysis, we found that it is due to the current select_idle_smt() not considering the sched_domain mask.

Steps to reproduce on my 31-CPU hyperthreads machine:
1. with boot parameter: "isolcpus=domain,2-31" (thread lists: 0,16 and 1,17)
2. cgcreate -g cpu:test; cgexec -g cpu:test "test_threads"
3. some threads will be migrated to the isolated cpu16~17.

Fix it by checking the valid domain mask in select_idle_smt().

Fixes 10e2f1acd010 ("sched/core: Rewrite and improve select_idle_siblings())

Reported-by Wetp Zhang <[email protected]>

Signed-off-by Xunlei Pang <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Reviewed-by Jiang Biao <[email protected]>

Reviewed-by Vincent Guittot <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 kernel/sched/fair.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

kernel/sched/fair.c +5 -4

index b02a83ff40687..dddaf61378f62 100644
@@ -5936,7 +5936,7 @@ static int select_idle_core(struct task_struct *p, struct sched_domain *sd, int
 /*
  * Scan the local SMT mask for idle CPUs.
  */
-static int select_idle_smt(struct task_struct *p, int target)
+static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int target)
 {
 	int cpu, si_cpu = -1;

@@ -5944,7 +5944,8 @@ static int select_idle_smt(struct task_struct *p, int target)
 		return -1;
 
 	for_each_cpu(cpu, cpu_smt_mask(target)) {
-		if (!cpumask_test_cpu(cpu, p->cpus_ptr))
+		if (!cpumask_test_cpu(cpu, p->cpus_ptr) ||
+		    !cpumask_test_cpu(cpu, sched_domain_span(sd)))
 			continue;
 		if (available_idle_cpu(cpu))
 			return cpu;

@@ -5962,7 +5963,7 @@ static inline int select_idle_core(struct task_struct *p, struct sched_domain *s
 	return -1;
 }
 
-static inline int select_idle_smt(struct task_struct *p, int target)
+static inline int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int target)
 {
 	return -1;
 }

@@ -6072,7 +6073,7 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target)
 	if ((unsigned)i < nr_cpumask_bits)
 		return i;
 
-	i = select_idle_smt(p, target);
+	i = select_idle_smt(p, sd, target);
 	if ((unsigned)i < nr_cpumask_bits)
 		return i;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:44 UTC #63 lore raw

PATCH 63/408 perf/x86/intel/uncore: Update Ice Lake uncore units

From: Kan Liang <[email protected]>

[ Upstream commit 8f5d41f3a0f495435c88ebba8fc150c931c10fef ]

There are some updates for the Icelake model specific uncore performance monitors. (The update can be found at 10th generation intel core processors families specification update Revision 004, ICL068)

1) Counter 0 of ARB uncore unit is not available for software use
2) The global 'enable bit' (bit 29) and 'freeze bit' (bit 31) of MSR_UNC_PERF_GLOBAL_CTRL cannot be used to control counter behavior. Needs to use local enable in event select MSR.

Accessing the modified bit/registers will be ignored by HW. Users may observe inaccurate results with the current code.

The changes of the MSR_UNC_PERF_GLOBAL_CTRL imply that groups cannot be read atomically anymore. Although the error of the result for a group becomes a bit bigger, it still far lower than not using a group. The group support is still kept. Only Remove the *_box() related implementation.

Since the counter 0 of ARB uncore unit is not available, update the MSR address for the ARB uncore unit.

There is no change for IMC uncore unit, which only include free-running counters.

Fixes 6e394376ee89 ("perf/x86/intel/uncore: Add Intel Icelake uncore support")

Signed-off-by Kan Liang <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/events/intel/uncore_snb.c | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

arch/x86/events/intel/uncore_snb.c +25 -4

index c37cb12d0ef68..ad9798bd89cf6 100644
@@ -110,6 +110,10 @@
 #define ICL_UNC_CBO_0_PER_CTR0			0x702
 #define ICL_UNC_CBO_MSR_OFFSET			0x8
 
+/* ICL ARB register */
+#define ICL_UNC_ARB_PER_CTR			0x3b1
+#define ICL_UNC_ARB_PERFEVTSEL			0x3b3
+
 DEFINE_UNCORE_FORMAT_ATTR(event, event, "config:0-7");
 DEFINE_UNCORE_FORMAT_ATTR(umask, umask, "config:8-15");
 DEFINE_UNCORE_FORMAT_ATTR(edge, edge, "config:18");

@@ -297,6 +301,12 @@ void skl_uncore_cpu_init(void)
 	snb_uncore_arb.ops = &skl_uncore_msr_ops;
 }
 
+static struct intel_uncore_ops icl_uncore_msr_ops = {
+	.disable_event	= snb_uncore_msr_disable_event,
+	.enable_event	= snb_uncore_msr_enable_event,
+	.read_counter	= uncore_msr_read_counter,
+};
+
 static struct intel_uncore_type icl_uncore_cbox = {
 	.name		= "cbox",
 	.num_counters   = 4,

@@ -305,7 +315,7 @@ static struct intel_uncore_type icl_uncore_cbox = {
 	.event_ctl	= SNB_UNC_CBO_0_PERFEVTSEL0,
 	.event_mask	= SNB_UNC_RAW_EVENT_MASK,
 	.msr_offset	= ICL_UNC_CBO_MSR_OFFSET,
-	.ops		= &skl_uncore_msr_ops,
+	.ops		= &icl_uncore_msr_ops,
 	.format_group	= &snb_uncore_format_group,
 };

@@ -334,13 +344,25 @@ static struct intel_uncore_type icl_uncore_clockbox = {
 	.single_fixed	= 1,
 	.event_mask	= SNB_UNC_CTL_EV_SEL_MASK,
 	.format_group	= &icl_uncore_clock_format_group,
-	.ops		= &skl_uncore_msr_ops,
+	.ops		= &icl_uncore_msr_ops,
 	.event_descs	= icl_uncore_events,
 };
 
+static struct intel_uncore_type icl_uncore_arb = {
+	.name		= "arb",
+	.num_counters   = 1,
+	.num_boxes	= 1,
+	.perf_ctr_bits	= 44,
+	.perf_ctr	= ICL_UNC_ARB_PER_CTR,
+	.event_ctl	= ICL_UNC_ARB_PERFEVTSEL,
+	.event_mask	= SNB_UNC_RAW_EVENT_MASK,
+	.ops		= &icl_uncore_msr_ops,
+	.format_group	= &snb_uncore_format_group,
+};
+
 static struct intel_uncore_type *icl_msr_uncores[] = {
 	&icl_uncore_cbox,
-	&snb_uncore_arb,
+	&icl_uncore_arb,
 	&icl_uncore_clockbox,
 	NULL,
 };

@@ -358,7 +380,6 @@ void icl_uncore_cpu_init(void)
 {
 	uncore_msr_uncores = icl_msr_uncores;
 	icl_uncore_cbox.num_boxes = icl_get_cbox_num();
-	snb_uncore_arb.ops = &skl_uncore_msr_ops;
 }
 
 enum {

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:44 UTC #64 lore raw

PATCH 64/408 perf/x86/intel/uncore: Reduce the number of CBOX counters

From: Kan Liang <[email protected]>

[ Upstream commit ee139385432e919f4d1f59b80edbc073cdae1391 ]

An oops is triggered by the fuzzy test.

[  327.853081] unchecked MSR access error: RDMSR from 0x70c at rIP:
0xffffffffc082c820 (uncore_msr_read_counter+0x10/0x50 [intel_uncore])
[  327.853083] Call Trace:
[  327.853085]  <IRQ>
[  327.853089]  uncore_pmu_event_start+0x85/0x170 [intel_uncore]
[  327.853093]  uncore_pmu_event_add+0x1a4/0x410 [intel_uncore]
[  327.853097]  ? event_sched_in.isra.118+0xca/0x240

There are 2 GP counters for each CBOX, but the current code claims 4 counters. Accessing the invalid registers triggers the oops.

Fixes 6e394376ee89 ("perf/x86/intel/uncore: Add Intel Icelake uncore support")

Signed-off-by Kan Liang <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/events/intel/uncore_snb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/events/intel/uncore_snb.c +1 -1

index ad9798bd89cf6..aec6e63c6a04a 100644
@@ -309,7 +309,7 @@ static struct intel_uncore_ops icl_uncore_msr_ops = {
 
 static struct intel_uncore_type icl_uncore_cbox = {
 	.name		= "cbox",
-	.num_counters   = 4,
+	.num_counters   = 2,
 	.perf_ctr_bits	= 44,
 	.perf_ctr	= ICL_UNC_CBO_0_PER_CTR0,
 	.event_ctl	= SNB_UNC_CBO_0_PERFEVTSEL0,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #65 lore raw

PATCH 65/408 x86/nmi: Fix nmi_handle() duration miscalculation

From: Libing Zhou <[email protected]>

[ Upstream commit f94c91f7ba3ba7de2bc8aa31be28e1abb22f849e ]

When nmi_check_duration() is checking the time an NMI handler took to execute, the whole_msecs value used should be read from the @duration argument, not from the ->max_duration, the latter being used to store the current maximal duration.

[ bp: Rewrite commit message. ]

Fixes 248ed51048c4 ("x86/nmi: Remove irq_work from the long duration NMI handler")

Signed-off-by Libing Zhou <[email protected]>

Cc Changbin Du <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/kernel/nmi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

arch/x86/kernel/nmi.c +2 -3

index 54c21d6abd5ac..5bb001c0c771a 100644
@@ -106,7 +106,6 @@ fs_initcall(nmi_warning_debugfs);
 
 static void nmi_check_duration(struct nmiaction *action, u64 duration)
 {
-	u64 whole_msecs = READ_ONCE(action->max_duration);
 	int remainder_ns, decimal_msecs;
 
 	if (duration < nmi_longest_ns || duration < action->max_duration)

@@ -114,12 +113,12 @@ static void nmi_check_duration(struct nmiaction *action, u64 duration)
 
 	action->max_duration = duration;
 
-	remainder_ns = do_div(whole_msecs, (1000 * 1000));
+	remainder_ns = do_div(duration, (1000 * 1000));
 	decimal_msecs = remainder_ns / 1000;
 
 	printk_ratelimited(KERN_INFO
 		"INFO: NMI handler (%ps) took too long to run: %lld.%03d msecs\n",
-		action->handler, whole_msecs, decimal_msecs);
+		action->handler, duration, decimal_msecs);
 }
 
 static int nmi_handle(unsigned int type, struct pt_regs *regs)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #66 lore raw

PATCH 66/408 x86/events/amd/iommu: Fix sizeof mismatch

From: Colin Ian King <[email protected]>

[ Upstream commit 59d5396a4666195f89a67e118e9e627ddd6f53a1 ]

An incorrect sizeof is being used, struct attribute ** is not correct, it should be struct attribute *. Note that since ** is the same size as
* this is not causing any issues. Improve this fix by using sizeof(*attrs) as this allows us to not even reference the type of the pointer.

Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)")

Fixes 51686546304f ("x86/events/amd/iommu: Fix sysfs perf attribute groups")

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/events/amd/iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/events/amd/iommu.c +1 -1

index fb616203ce427..be50ef8572cce 100644
@@ -379,7 +379,7 @@ static __init int _init_events_attrs(void)
 	while (amd_iommu_v2_event_descs[i].attr.attr.name)
 		i++;
 
-	attrs = kcalloc(i + 1, sizeof(struct attribute **), GFP_KERNEL);
+	attrs = kcalloc(i + 1, sizeof(*attrs), GFP_KERNEL);
 	if (!attrs)
 		return -ENOMEM;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #67 lore raw

PATCH 67/408 crypto: algif_skcipher - EBUSY on aio should be an error

From: Herbert Xu <[email protected]>

[ Upstream commit 2a05b029c1ee045b886ebf9efef9985ca23450de ]

I removed the MAY_BACKLOG flag on the aio path a while ago but the error check still incorrectly interpreted EBUSY as success. This may cause the submitter to wait for a request that will never complete.

Fixes dad419970637 ("crypto: algif_skcipher - Do not set...")

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 crypto/algif_skcipher.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

crypto/algif_skcipher.c +1 -1

index 81c4022285a7c..30069a92a9b22 100644
@@ -123,7 +123,7 @@ static int _skcipher_recvmsg(struct socket *sock, struct msghdr *msg,
 			crypto_skcipher_decrypt(&areq->cra_u.skcipher_req);
 
 		/* AIO operation in progress */
-		if (err == -EINPROGRESS || err == -EBUSY)
+		if (err == -EINPROGRESS)
 			return -EIOCBQUEUED;
 
 		sock_put(sk);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #68 lore raw

PATCH 68/408 crypto: mediatek - Fix wrong return value in mtk_desc_ring_alloc()

From: Tianjia Zhang <[email protected]>

[ Upstream commit 8cbde6c6a6d2b1599ff90f932304aab7e32fce89 ]

In case of memory allocation failure, a negative error code should be returned.

Fixes 785e5c616c849 ("crypto: mediatek - Add crypto driver support for some MediaTek chips")

Cc Ryder Lee <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/crypto/mediatek/mtk-platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/crypto/mediatek/mtk-platform.c +2 -2

index 7e3ad085b5bdd..ef4339e84d034 100644
@@ -442,7 +442,7 @@ static void mtk_desc_dma_free(struct mtk_cryp *cryp)
 static int mtk_desc_ring_alloc(struct mtk_cryp *cryp)
 {
 	struct mtk_ring **ring = cryp->ring;
-	int i, err = ENOMEM;
+	int i;
 
 	for (i = 0; i < MTK_RING_MAX; i++) {
 		ring[i] = kzalloc(sizeof(**ring), GFP_KERNEL);

@@ -476,7 +476,7 @@ static int mtk_desc_ring_alloc(struct mtk_cryp *cryp)
 				  ring[i]->cmd_base, ring[i]->cmd_dma);
 		kfree(ring[i]);
 	}
-	return err;
+	return -ENOMEM;
 }
 
 static int mtk_crypto_probe(struct platform_device *pdev)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #69 lore raw

PATCH 69/408 crypto: ixp4xx - Fix the size used in a dma_free_coherent() call

From: Christophe JAILLET <[email protected]>

[ Upstream commit f7ade9aaf66bd5599690acf0597df2c0f6cd825a ]

Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()', in 'setup_crypt_desc()'.

Fixes 81bef0150074 ("crypto: ixp4xx - Hardware crypto support for IXP4xx CPUs")

Signed-off-by Christophe JAILLET <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/crypto/ixp4xx_crypto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/crypto/ixp4xx_crypto.c +1 -1

index 9181523ba7607..acaa504d5a798 100644
@@ -527,7 +527,7 @@ static void release_ixp_crypto(struct device *dev)
 
 	if (crypt_virt) {
 		dma_free_coherent(dev,
-			NPE_QLEN_TOTAL * sizeof( struct crypt_ctl),
+			NPE_QLEN * sizeof(struct crypt_ctl),
 			crypt_virt, crypt_phys);
 	}
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #70 lore raw

PATCH 70/408 crypto: picoxcell - Fix potential race condition bug

From: Madhuparna Bhowmik <[email protected]>

[ Upstream commit 64f4a62e3b17f1e473f971127c2924cae42afc82 ]

engine->stat_irq_thresh was initialized after device_create_file() in the probe function, the initialization may race with call to spacc_stat_irq_thresh_store() which updates engine->stat_irq_thresh, therefore initialize it before creating the file in probe function.

Found by Linux Driver Verification project (linuxtesting.org).

Fixes ce92136843cb ("crypto: picoxcell - add support for the...")

Signed-off-by Madhuparna Bhowmik <[email protected]>

Acked-by Jamie Iles <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/crypto/picoxcell_crypto.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

drivers/crypto/picoxcell_crypto.c +4 -5

index 2680e1525db58..13ecbb0e58528 100644
@@ -1697,11 +1697,6 @@ static int spacc_probe(struct platform_device *pdev)
 		goto err_clk_put;
 	}
 
-	ret = device_create_file(&pdev->dev, &dev_attr_stat_irq_thresh);
-	if (ret)
-		goto err_clk_disable;
-
-
 	/*
 	 * Use an IRQ threshold of 50% as a default. This seems to be a
 	 * reasonable trade off of latency against throughput but can be

@@ -1709,6 +1704,10 @@ static int spacc_probe(struct platform_device *pdev)
 	 */
 	engine->stat_irq_thresh = (engine->fifo_sz / 2);
 
+	ret = device_create_file(&pdev->dev, &dev_attr_stat_irq_thresh);
+	if (ret)
+		goto err_clk_disable;
+
 	/*
 	 * Configure the interrupts. We only use the STAT_CNT interrupt as we
 	 * only submit a new packet for processing when we complete another in

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #71 lore raw

PATCH 71/408 media: tuner-simple: fix regression in simple_set_radio_freq

From: Tom Rix <[email protected]>

[ Upstream commit 505bfc2a142f12ce7bc7a878b44abc3496f2e747 ]

clang static analysis reports this problem

tuner-simple.c:714:13: warning: Assigned value is
garbage or undefined

        buffer[1] = buffer[3];
                  ^ ~~~~~~~~~

In simple_set_radio_freq buffer[3] used to be done in-function with a switch of tuner type, now done by a call to simple_radio_bandswitch which has this case

	case TUNER_TENA_9533_DI:
	case TUNER_YMEC_TVF_5533MF:
		tuner_dbg("This tuner doesn't ...
		return 0;

which does not set buffer[3]. In the old logic, this case would have returned 0 from simple_set_radio_freq.

Recover this old behavior by returning an error for this codition. Since the old simple_set_radio_freq behavior returned a 0, do the same.

Fixes c7a9f3aa1e1b ("V4L/DVB (7129): tuner-simple: move device-specific code into three separate functions")

Signed-off-by Tom Rix <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/tuners/tuner-simple.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/media/tuners/tuner-simple.c +3 -2

index b6e70fada3fb2..8fb186b25d6af 100644
@@ -500,7 +500,7 @@ static int simple_radio_bandswitch(struct dvb_frontend *fe, u8 *buffer)
 	case TUNER_TENA_9533_DI:
 	case TUNER_YMEC_TVF_5533MF:
 		tuner_dbg("This tuner doesn't have FM. Most cards have a TEA5767 for FM\n");
-		return 0;
+		return -EINVAL;
 	case TUNER_PHILIPS_FM1216ME_MK3:
 	case TUNER_PHILIPS_FM1236_MK3:
 	case TUNER_PHILIPS_FMD1216ME_MK3:

@@ -702,7 +702,8 @@ static int simple_set_radio_freq(struct dvb_frontend *fe,
 		    TUNER_RATIO_SELECT_50; /* 50 kHz step */
 
 	/* Bandswitch byte */
-	simple_radio_bandswitch(fe, &buffer[0]);
+	if (simple_radio_bandswitch(fe, &buffer[0]))
+		return 0;
 
 	/* Convert from 1/16 kHz V4L steps to 1/20 MHz (=50 kHz) PLL steps
 	   freq * (1 Mhz / 16000 V4L steps) * (20 PLL steps / 1 MHz) =

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:31 UTC #72 lore raw

PATCH 72/408 media: Revert "media: exynos4-is: Add missed check for pinctrl_lookup_state()"

From: Sylwester Nawrocki <[email protected]>

[ Upstream commit 00d21f325d58567d81d9172096692d0a9ea7f725 ]

The "idle" pinctrl state is optional as documented in the DT binding. The change introduced by the commit being reverted makes that pinctrl state mandatory and breaks initialization of the whole media driver, since the "idle" state is not specified in any mainline dts.

This reverts commit 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()") to fix the regression.

Fixes 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()")

Signed-off-by Sylwester Nawrocki <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/exynos4-is/media-dev.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

drivers/media/platform/exynos4-is/media-dev.c +1 -3

index 9c31d950cddf7..2f90607c3797d 100644
@@ -1268,11 +1268,9 @@ static int fimc_md_get_pinctrl(struct fimc_md *fmd)
 	if (IS_ERR(pctl->state_default))
 		return PTR_ERR(pctl->state_default);
 
+	/* PINCTRL_STATE_IDLE is optional */
 	pctl->state_idle = pinctrl_lookup_state(pctl->pinctrl,
 					PINCTRL_STATE_IDLE);
-	if (IS_ERR(pctl->state_idle))
-		return PTR_ERR(pctl->state_idle);
-
 	return 0;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #73 lore raw

PATCH 73/408 media: ov5640: Correct Bit Div register in clock tree diagram

From: Paul Kocialkowski <[email protected]>

[ Upstream commit 4c85f628f6639e3e3e0a7788416154f28dfcae4f ]

Although the code is correct and doing the right thing, the clock diagram showed the wrong register for the bit divider, which had me doubting the understanding of the tree. Fix this to avoid doubts in the future.

Signed-off-by Paul Kocialkowski <[email protected]>

Fixes aa2882481cada ("media: ov5640: Adjust the clock based on the expected rate")

Acked-by Jacopo Mondi <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/ov5640.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/media/i2c/ov5640.c +1 -1

index 266e947572c1e..b21ddbd514465 100644
@@ -740,7 +740,7 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16 reg,
  *               +->| PLL Root Div | - reg 0x3037, bit 4
  *                  +-+------------+
  *                    |  +---------+
- *                    +->| Bit Div | - reg 0x3035, bits 0-3
+ *                    +->| Bit Div | - reg 0x3034, bits 0-3
  *                       +-+-------+
  *                         |  +-------------+
  *                         +->| SCLK Div    | - reg 0x3108, bits 0-1

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:44 UTC #74 lore raw

PATCH 74/408 media: m5mols: Check function pointer in m5mols_sensor_power

From: Tom Rix <[email protected]>

[ Upstream commit 52438c4463ac904d14bf3496765e67750766f3a6 ]

clang static analysis reports this error

m5mols_core.c:767:4: warning: Called function pointer
is null (null dereference) [core.CallAndMessage]

    info->set_power(&client->dev, 0);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In other places, the set_power ptr is checked.
So add a check.

Fixes bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP")

Signed-off-by Tom Rix <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/m5mols/m5mols_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/media/i2c/m5mols/m5mols_core.c +2 -1

index de295114ca482..21666d705e372 100644
@@ -764,7 +764,8 @@ static int m5mols_sensor_power(struct m5mols_info *info, bool enable)
 
 		ret = regulator_bulk_enable(ARRAY_SIZE(supplies), supplies);
 		if (ret) {
-			info->set_power(&client->dev, 0);
+			if (info->set_power)
+				info->set_power(&client->dev, 0);
 			return ret;
 		}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:44 UTC #75 lore raw

PATCH 75/408 media: uvcvideo: Set media controller entity functions

From: Laurent Pinchart <[email protected]>

[ Upstream commit d6834b4b58d110814aaf3469e7fd87d34ae5ae81 ]

The media controller core prints a warning when an entity is registered without a function being set. This affects the uvcvideo driver, as the warning was added without first addressing the issue in existing drivers. The problem is harmless, but unnecessarily worries users. Fix it by mapping UVC entity types to MC entity functions as accurately as possible using the existing functions.

Fixes b50bde4e476d ("[media] v4l2-subdev: use MEDIA_ENT_T_UNKNOWN for new subdevs")

Reviewed-by Kieran Bingham <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/usb/uvc/uvc_entity.c | 35 ++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

drivers/media/usb/uvc/uvc_entity.c +35 -0

index b4499cddeffe5..ca3a9c2eec271 100644
@@ -73,10 +73,45 @@ static int uvc_mc_init_entity(struct uvc_video_chain *chain,
 	int ret;
 
 	if (UVC_ENTITY_TYPE(entity) != UVC_TT_STREAMING) {
+		u32 function;
+
 		v4l2_subdev_init(&entity->subdev, &uvc_subdev_ops);
 		strscpy(entity->subdev.name, entity->name,
 			sizeof(entity->subdev.name));
 
+		switch (UVC_ENTITY_TYPE(entity)) {
+		case UVC_VC_SELECTOR_UNIT:
+			function = MEDIA_ENT_F_VID_MUX;
+			break;
+		case UVC_VC_PROCESSING_UNIT:
+		case UVC_VC_EXTENSION_UNIT:
+			/* For lack of a better option. */
+			function = MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER;
+			break;
+		case UVC_COMPOSITE_CONNECTOR:
+		case UVC_COMPONENT_CONNECTOR:
+			function = MEDIA_ENT_F_CONN_COMPOSITE;
+			break;
+		case UVC_SVIDEO_CONNECTOR:
+			function = MEDIA_ENT_F_CONN_SVIDEO;
+			break;
+		case UVC_ITT_CAMERA:
+			function = MEDIA_ENT_F_CAM_SENSOR;
+			break;
+		case UVC_TT_VENDOR_SPECIFIC:
+		case UVC_ITT_VENDOR_SPECIFIC:
+		case UVC_ITT_MEDIA_TRANSPORT_INPUT:
+		case UVC_OTT_VENDOR_SPECIFIC:
+		case UVC_OTT_DISPLAY:
+		case UVC_OTT_MEDIA_TRANSPORT_OUTPUT:
+		case UVC_EXTERNAL_VENDOR_SPECIFIC:
+		default:
+			function = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN;
+			break;
+		}
+
+		entity->subdev.entity.function = function;
+
 		ret = media_entity_pads_init(&entity->subdev.entity,
 					entity->num_pads, entity->pads);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #76 lore raw

PATCH 76/408 media: uvcvideo: Silence shift-out-of-bounds warning

From: Laurent Pinchart <[email protected]>

[ Upstream commit 171994e498a0426cbe17f874c5c6af3c0af45200 ]

UBSAN reports a shift-out-of-bounds warning in uvc_get_le_value(). The report is correct, but the issue should be harmless as the computed value isn't used when the shift is negative. This may however cause incorrect behaviour if a negative shift could generate adverse side effects (such as a trap on some architectures for instance).

Regardless of whether that may happen or not, silence the warning as a full WARN backtrace isn't nice.

Reported-by Bart Van Assche <[email protected]>

Fixes c0efd232929c ("V4L/DVB (8145a): USB Video Class driver")

Reviewed-by Bart Van Assche <[email protected]>

Tested-by Bart Van Assche <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/usb/uvc/uvc_ctrl.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

drivers/media/usb/uvc/uvc_ctrl.c +5 -1

index e399b9fad7574..a30a8a731eda8 100644
@@ -773,12 +773,16 @@ static s32 uvc_get_le_value(struct uvc_control_mapping *mapping,
 	offset &= 7;
 	mask = ((1LL << bits) - 1) << offset;
 
-	for (; bits > 0; data++) {
+	while (1) {
 		u8 byte = *data & mask;
 		value |= offset > 0 ? (byte >> offset) : (byte << (-offset));
 		bits -= 8 - (offset > 0 ? offset : 0);
+		if (bits <= 0)
+			break;
+
 		offset -= 8;
 		mask = (1 << bits) - 1;
+		data++;
 	}
 
 	/* Sign-extend the value if needed. */

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #77 lore raw

PATCH 77/408 media: staging/intel-ipu3: css: Correctly reset some memory

From: Christophe JAILLET <[email protected]>

[ Upstream commit 08913a8e458e03f886a1a1154a6501fcb9344c39 ]

The intent here is to reset the whole 'scaler_coeffs_luma' array, not just the first element.

Fixes e11110a5b744 ("media: staging/intel-ipu3: css: Compute and program ccs")

Signed-off-by Christophe JAILLET <[email protected]>

Reviewed-by Bingbu Cao <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/staging/media/ipu3/ipu3-css-params.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/staging/media/ipu3/ipu3-css-params.c +1 -1

index 4533dacad4beb..ef3b5d07137a1 100644
@@ -161,7 +161,7 @@ imgu_css_scaler_calc(u32 input_width, u32 input_height, u32 target_width,
 
 	memset(&cfg->scaler_coeffs_chroma, 0,
 	       sizeof(cfg->scaler_coeffs_chroma));
-	memset(&cfg->scaler_coeffs_luma, 0, sizeof(*cfg->scaler_coeffs_luma));
+	memset(&cfg->scaler_coeffs_luma, 0, sizeof(cfg->scaler_coeffs_luma));
 	do {
 		phase_step_correction++;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #78 lore raw

PATCH 78/408 media: omap3isp: Fix memleak in isp_probe

From: Dinghao Liu <[email protected]>

[ Upstream commit d8fc21c17099635e8ebd986d042be65a6c6b5bd0 ]

When devm_ioremap_resource() fails, isp should be
freed just like other error paths in isp_probe.

Fixes 8644cdf972dd6 ("[media] omap3isp: Replace many MMIO regions by two")

Signed-off-by Dinghao Liu <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/omap3isp/isp.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/media/platform/omap3isp/isp.c +4 -2

index 327c5716922ac..dce6b3685e135 100644
@@ -2330,8 +2330,10 @@ static int isp_probe(struct platform_device *pdev)
 		mem = platform_get_resource(pdev, IORESOURCE_MEM, i);
 		isp->mmio_base[map_idx] =
 			devm_ioremap_resource(isp->dev, mem);
-		if (IS_ERR(isp->mmio_base[map_idx]))
-			return PTR_ERR(isp->mmio_base[map_idx]);
+		if (IS_ERR(isp->mmio_base[map_idx])) {
+			ret = PTR_ERR(isp->mmio_base[map_idx]);
+			goto error;
+		}
 	}
 
 	ret = isp_get_clocks(isp);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:43 UTC #79 lore raw

PATCH 79/408 media: i2c: ov5640: Remain in power down for DVP mode unless streaming

From: Lad Prabhakar <[email protected]>

[ Upstream commit 3b987d70e903962eb8c5961ba166c345a49d1a0b ]

Keep the sensor in software power down mode and wake up only in ov5640_set_stream_dvp() callback.

Signed-off-by Lad Prabhakar <[email protected]>

Reviewed-by Biju Das <[email protected]>

Tested-by Jacopo Mondi <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/ov5640.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

drivers/media/i2c/ov5640.c +16 -3

index b21ddbd514465..065f9706db7e5 100644
@@ -34,6 +34,8 @@
 #define OV5640_REG_SYS_RESET02		0x3002
 #define OV5640_REG_SYS_CLOCK_ENABLE02	0x3006
 #define OV5640_REG_SYS_CTRL0		0x3008
+#define OV5640_REG_SYS_CTRL0_SW_PWDN	0x42
+#define OV5640_REG_SYS_CTRL0_SW_PWUP	0x02
 #define OV5640_REG_CHIP_ID		0x300a
 #define OV5640_REG_IO_MIPI_CTRL00	0x300e
 #define OV5640_REG_PAD_OUTPUT_ENABLE01	0x3017

@@ -1109,6 +1111,12 @@ static int ov5640_load_regs(struct ov5640_dev *sensor,
 		val = regs->val;
 		mask = regs->mask;
 
+		/* remain in power down mode for DVP */
+		if (regs->reg_addr == OV5640_REG_SYS_CTRL0 &&
+		    val == OV5640_REG_SYS_CTRL0_SW_PWUP &&
+		    sensor->ep.bus_type != V4L2_MBUS_CSI2_DPHY)
+			continue;
+
 		if (mask)
 			ret = ov5640_mod_reg(sensor, reg_addr, mask, val);
 		else

@@ -1286,9 +1294,14 @@ static int ov5640_set_stream_dvp(struct ov5640_dev *sensor, bool on)
 	 * PAD OUTPUT ENABLE 02
 	 * - [7:2]:	D[5:0] output enable
 	 */
-	return ov5640_write_reg(sensor,
-				OV5640_REG_PAD_OUTPUT_ENABLE02,
-				on ? 0xfc : 0);
+	ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT_ENABLE02,
+			       on ? 0xfc : 0);
+	if (ret)
+		return ret;
+
+	return ov5640_write_reg(sensor, OV5640_REG_SYS_CTRL0, on ?
+				OV5640_REG_SYS_CTRL0_SW_PWUP :
+				OV5640_REG_SYS_CTRL0_SW_PWDN);
 }
 
 static int ov5640_set_stream_mipi(struct ov5640_dev *sensor, bool on)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:41 UTC #80 lore raw

PATCH 80/408 media: i2c: ov5640: Separate out mipi configuration from s_power

From: Lad Prabhakar <[email protected]>

[ Upstream commit b1751ae652fb95919c08df5bdd739ccf9886158a ]

In preparation for adding DVP configuration in s_power callback move mipi configuration into separate function

Signed-off-by Lad Prabhakar <[email protected]>

Reviewed-by Biju Das <[email protected]>

Tested-by Jacopo Mondi <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/ov5640.c | 116 +++++++++++++++++++------------------
 1 file changed, 60 insertions(+), 56 deletions(-)

drivers/media/i2c/ov5640.c +60 ~~-56~~

index 065f9706db7e5..3c6ad2dd9c0e1 100644
@@ -2000,6 +2000,61 @@ static void ov5640_set_power_off(struct ov5640_dev *sensor)
 	clk_disable_unprepare(sensor->xclk);
 }
 
+static int ov5640_set_power_mipi(struct ov5640_dev *sensor, bool on)
+{
+	int ret;
+
+	if (!on) {
+		/* Reset MIPI bus settings to their default values. */
+		ov5640_write_reg(sensor, OV5640_REG_IO_MIPI_CTRL00, 0x58);
+		ov5640_write_reg(sensor, OV5640_REG_MIPI_CTRL00, 0x04);
+		ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00, 0x00);
+		return 0;
+	}
+
+	/*
+	 * Power up MIPI HS Tx and LS Rx; 2 data lanes mode
+	 *
+	 * 0x300e = 0x40
+	 * [7:5] = 010	: 2 data lanes mode (see FIXME note in
+	 *		  "ov5640_set_stream_mipi()")
+	 * [4] = 0	: Power up MIPI HS Tx
+	 * [3] = 0	: Power up MIPI LS Rx
+	 * [2] = 0	: MIPI interface disabled
+	 */
+	ret = ov5640_write_reg(sensor, OV5640_REG_IO_MIPI_CTRL00, 0x40);
+	if (ret)
+		return ret;
+
+	/*
+	 * Gate clock and set LP11 in 'no packets mode' (idle)
+	 *
+	 * 0x4800 = 0x24
+	 * [5] = 1	: Gate clock when 'no packets'
+	 * [2] = 1	: MIPI bus in LP11 when 'no packets'
+	 */
+	ret = ov5640_write_reg(sensor, OV5640_REG_MIPI_CTRL00, 0x24);
+	if (ret)
+		return ret;
+
+	/*
+	 * Set data lanes and clock in LP11 when 'sleeping'
+	 *
+	 * 0x3019 = 0x70
+	 * [6] = 1	: MIPI data lane 2 in LP11 when 'sleeping'
+	 * [5] = 1	: MIPI data lane 1 in LP11 when 'sleeping'
+	 * [4] = 1	: MIPI clock lane in LP11 when 'sleeping'
+	 */
+	ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00, 0x70);
+	if (ret)
+		return ret;
+
+	/* Give lanes some time to coax into LP11 state. */
+	usleep_range(500, 1000);
+
+	return 0;
+}
+
 static int ov5640_set_power(struct ov5640_dev *sensor, bool on)
 {
 	int ret = 0;

@@ -2012,67 +2067,16 @@ static int ov5640_set_power(struct ov5640_dev *sensor, bool on)
 		ret = ov5640_restore_mode(sensor);
 		if (ret)
 			goto power_off;
+	}
 
-		/* We're done here for DVP bus, while CSI-2 needs setup. */
-		if (sensor->ep.bus_type != V4L2_MBUS_CSI2_DPHY)
-			return 0;
-
-		/*
-		 * Power up MIPI HS Tx and LS Rx; 2 data lanes mode
-		 *
-		 * 0x300e = 0x40
-		 * [7:5] = 010	: 2 data lanes mode (see FIXME note in
-		 *		  "ov5640_set_stream_mipi()")
-		 * [4] = 0	: Power up MIPI HS Tx
-		 * [3] = 0	: Power up MIPI LS Rx
-		 * [2] = 0	: MIPI interface disabled
-		 */
-		ret = ov5640_write_reg(sensor,
-				       OV5640_REG_IO_MIPI_CTRL00, 0x40);
-		if (ret)
-			goto power_off;
-
-		/*
-		 * Gate clock and set LP11 in 'no packets mode' (idle)
-		 *
-		 * 0x4800 = 0x24
-		 * [5] = 1	: Gate clock when 'no packets'
-		 * [2] = 1	: MIPI bus in LP11 when 'no packets'
-		 */
-		ret = ov5640_write_reg(sensor,
-				       OV5640_REG_MIPI_CTRL00, 0x24);
-		if (ret)
-			goto power_off;
-
-		/*
-		 * Set data lanes and clock in LP11 when 'sleeping'
-		 *
-		 * 0x3019 = 0x70
-		 * [6] = 1	: MIPI data lane 2 in LP11 when 'sleeping'
-		 * [5] = 1	: MIPI data lane 1 in LP11 when 'sleeping'
-		 * [4] = 1	: MIPI clock lane in LP11 when 'sleeping'
-		 */
-		ret = ov5640_write_reg(sensor,
-				       OV5640_REG_PAD_OUTPUT00, 0x70);
+	if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY) {
+		ret = ov5640_set_power_mipi(sensor, on);
 		if (ret)
 			goto power_off;
+	}
 
-		/* Give lanes some time to coax into LP11 state. */
-		usleep_range(500, 1000);
-
-	} else {
-		if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY) {
-			/* Reset MIPI bus settings to their default values. */
-			ov5640_write_reg(sensor,
-					 OV5640_REG_IO_MIPI_CTRL00, 0x58);
-			ov5640_write_reg(sensor,
-					 OV5640_REG_MIPI_CTRL00, 0x04);
-			ov5640_write_reg(sensor,
-					 OV5640_REG_PAD_OUTPUT00, 0x00);
-		}
-
+	if (!on)
 		ov5640_set_power_off(sensor);
-	}
 
 	return 0;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:32 UTC #81 lore raw

PATCH 81/408 media: i2c: ov5640: Enable data pins on poweron for DVP mode

From: Lad Prabhakar <[email protected]>

[ Upstream commit 576f5d4ba8f672953513280510abf9a736b015cc ]

During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP mode with rcar-vin bridge noticed the capture worked fine for the first run (with yavta), but for subsequent runs the bridge driver waited for the frame to be captured. Debugging further noticed the data lines were enabled/disabled in stream on/off callback and dumping the register contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct values, but yet frame capturing failed.

To get around this issue data lines are enabled in s_power callback. (Also the sensor remains in power down mode if not streaming so power consumption shouldn't be affected)

Fixes f22996db44e2d ("media: ov5640: add support of DVP parallel interface")

Signed-off-by Lad Prabhakar <[email protected]>

Reviewed-by Biju Das <[email protected]>

Tested-by Jacopo Mondi <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/ov5640.c | 73 +++++++++++++++++++++-----------------
 1 file changed, 40 insertions(+), 33 deletions(-)

drivers/media/i2c/ov5640.c +40 ~~-33~~

index 3c6ad2dd9c0e1..be6c882dd1d54 100644
@@ -274,8 +274,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct v4l2_ctrl *ctrl)
 /* YUV422 UYVY VGA@30fps */
 static const struct reg_value ov5640_init_setting_30fps_VGA[] = {
 	{0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0},
-	{0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0},
-	{0x3630, 0x36, 0, 0},
+	{0x3103, 0x03, 0, 0}, {0x3630, 0x36, 0, 0},
 	{0x3631, 0x0e, 0, 0}, {0x3632, 0xe2, 0, 0}, {0x3633, 0x12, 0, 0},
 	{0x3621, 0xe0, 0, 0}, {0x3704, 0xa0, 0, 0}, {0x3703, 0x5a, 0, 0},
 	{0x3715, 0x78, 0, 0}, {0x3717, 0x01, 0, 0}, {0x370b, 0x60, 0, 0},

@@ -1272,33 +1271,6 @@ static int ov5640_set_stream_dvp(struct ov5640_dev *sensor, bool on)
 	if (ret)
 		return ret;
 
-	/*
-	 * enable VSYNC/HREF/PCLK DVP control lines
-	 * & D[9:6] DVP data lines
-	 *
-	 * PAD OUTPUT ENABLE 01
-	 * - 6:		VSYNC output enable
-	 * - 5:		HREF output enable
-	 * - 4:		PCLK output enable
-	 * - [3:0]:	D[9:6] output enable
-	 */
-	ret = ov5640_write_reg(sensor,
-			       OV5640_REG_PAD_OUTPUT_ENABLE01,
-			       on ? 0x7f : 0);
-	if (ret)
-		return ret;
-
-	/*
-	 * enable D[5:0] DVP data lines
-	 *
-	 * PAD OUTPUT ENABLE 02
-	 * - [7:2]:	D[5:0] output enable
-	 */
-	ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT_ENABLE02,
-			       on ? 0xfc : 0);
-	if (ret)
-		return ret;
-
 	return ov5640_write_reg(sensor, OV5640_REG_SYS_CTRL0, on ?
 				OV5640_REG_SYS_CTRL0_SW_PWUP :
 				OV5640_REG_SYS_CTRL0_SW_PWDN);

@@ -2055,6 +2027,40 @@ static int ov5640_set_power_mipi(struct ov5640_dev *sensor, bool on)
 	return 0;
 }
 
+static int ov5640_set_power_dvp(struct ov5640_dev *sensor, bool on)
+{
+	int ret;
+
+	if (!on) {
+		/* Reset settings to their default values. */
+		ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT_ENABLE01, 0x00);
+		ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT_ENABLE02, 0x00);
+		return 0;
+	}
+
+	/*
+	 * enable VSYNC/HREF/PCLK DVP control lines
+	 * & D[9:6] DVP data lines
+	 *
+	 * PAD OUTPUT ENABLE 01
+	 * - 6:		VSYNC output enable
+	 * - 5:		HREF output enable
+	 * - 4:		PCLK output enable
+	 * - [3:0]:	D[9:6] output enable
+	 */
+	ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT_ENABLE01, 0x7f);
+	if (ret)
+		return ret;
+
+	/*
+	 * enable D[5:0] DVP data lines
+	 *
+	 * PAD OUTPUT ENABLE 02
+	 * - [7:2]:	D[5:0] output enable
+	 */
+	return ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT_ENABLE02, 0xfc);
+}
+
 static int ov5640_set_power(struct ov5640_dev *sensor, bool on)
 {
 	int ret = 0;

@@ -2069,11 +2075,12 @@ static int ov5640_set_power(struct ov5640_dev *sensor, bool on)
 			goto power_off;
 	}
 
-	if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY) {
+	if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY)
 		ret = ov5640_set_power_mipi(sensor, on);
-		if (ret)
-			goto power_off;
-	}
+	else
+		ret = ov5640_set_power_dvp(sensor, on);
+	if (ret)
+		goto power_off;
 
 	if (!on)
 		ov5640_set_power_off(sensor);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #82 lore raw

PATCH 82/408 media: rcar_drif: Fix fwnode reference leak when parsing DT

From: Laurent Pinchart <[email protected]>

[ Upstream commit cdd4f7824994c9254acc6e415750529ea2d2cfe0 ]

The fwnode reference corresponding to the endpoint is leaked in an error path of the rcar_drif_parse_subdevs() function. Fix it, and reorganize fwnode reference handling in the function to release references early, simplifying error paths.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/rcar_drif.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

drivers/media/platform/rcar_drif.c +5 ~~-11~~

index 0f267a237b424..208ff260b0c10 100644
@@ -1223,28 +1223,22 @@ static int rcar_drif_parse_subdevs(struct rcar_drif_sdr *sdr)
 	if (!ep)
 		return 0;
 
+	/* Get the endpoint properties */
+	rcar_drif_get_ep_properties(sdr, ep);
+
 	fwnode = fwnode_graph_get_remote_port_parent(ep);
+	fwnode_handle_put(ep);
 	if (!fwnode) {
 		dev_warn(sdr->dev, "bad remote port parent\n");
-		fwnode_handle_put(ep);
 		return -EINVAL;
 	}
 
 	sdr->ep.asd.match.fwnode = fwnode;
 	sdr->ep.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
 	ret = v4l2_async_notifier_add_subdev(notifier, &sdr->ep.asd);
-	if (ret) {
-		fwnode_handle_put(fwnode);
-		return ret;
-	}
-
-	/* Get the endpoint properties */
-	rcar_drif_get_ep_properties(sdr, ep);
-
 	fwnode_handle_put(fwnode);
-	fwnode_handle_put(ep);
 
-	return 0;
+	return ret;
 }
 
 /* Check if the given device is the primary bond */

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #83 lore raw

PATCH 83/408 media: rcar_drif: Allocate v4l2_async_subdev dynamically

From: Laurent Pinchart <[email protected]>

[ Upstream commit 468e986dac0e94194334ca6d0abf3af8c250792e ]

v4l2_async_notifier_add_subdev() requires the asd to be allocated dynamically, but the rcar-drif driver embeds it in the rcar_drif_graph_ep structure. This causes memory corruption when the notifier is destroyed at remove time with v4l2_async_notifier_cleanup().

Fix this issue by registering the asd with v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically internally.

Fixes d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev")

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/rcar_drif.c | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

drivers/media/platform/rcar_drif.c +6 ~~-12~~

index 208ff260b0c10..af3c8d405509e 100644
@@ -185,7 +185,6 @@ struct rcar_drif_frame_buf {
 /* OF graph endpoint's V4L2 async data */
 struct rcar_drif_graph_ep {
 	struct v4l2_subdev *subdev;	/* Async matched subdev */
-	struct v4l2_async_subdev asd;	/* Async sub-device descriptor */
 };
 
 /* DMA buffer */

@@ -1105,12 +1104,6 @@ static int rcar_drif_notify_bound(struct v4l2_async_notifier *notifier,
 	struct rcar_drif_sdr *sdr =
 		container_of(notifier, struct rcar_drif_sdr, notifier);
 
-	if (sdr->ep.asd.match.fwnode !=
-	    of_fwnode_handle(subdev->dev->of_node)) {
-		rdrif_err(sdr, "subdev %s cannot bind\n", subdev->name);
-		return -EINVAL;
-	}
-
 	v4l2_set_subdev_hostdata(subdev, sdr);
 	sdr->ep.subdev = subdev;
 	rdrif_dbg(sdr, "bound asd %s\n", subdev->name);

@@ -1214,7 +1207,7 @@ static int rcar_drif_parse_subdevs(struct rcar_drif_sdr *sdr)
 {
 	struct v4l2_async_notifier *notifier = &sdr->notifier;
 	struct fwnode_handle *fwnode, *ep;
-	int ret;
+	struct v4l2_async_subdev *asd;
 
 	v4l2_async_notifier_init(notifier);

@@ -1233,12 +1226,13 @@ static int rcar_drif_parse_subdevs(struct rcar_drif_sdr *sdr)
 		return -EINVAL;
 	}
 
-	sdr->ep.asd.match.fwnode = fwnode;
-	sdr->ep.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
-	ret = v4l2_async_notifier_add_subdev(notifier, &sdr->ep.asd);
+	asd = v4l2_async_notifier_add_fwnode_subdev(notifier, fwnode,
+						    sizeof(*asd));
 	fwnode_handle_put(fwnode);
+	if (IS_ERR(asd))
+		return PTR_ERR(asd);
 
-	return ret;
+	return 0;
 }
 
 /* Check if the given device is the primary bond */

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:34 UTC #84 lore raw

PATCH 84/408 media: rcar-csi2: Allocate v4l2_async_subdev dynamically

From: Laurent Pinchart <[email protected]>

[ Upstream commit 2cac7cbfb4099980e78244359ab9c6f056d6a7ec ]

v4l2_async_notifier_add_subdev() requires the asd to be allocated dynamically, but the rcar-csi2 driver embeds it in the rcar_csi2 structure. This causes memory corruption when the notifier is destroyed at remove time with v4l2_async_notifier_cleanup().

Fix this issue by registering the asd with v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically internally.

Fixes 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver")

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/rcar-vin/rcar-csi2.c | 24 +++++++++------------
 1 file changed, 10 insertions(+), 14 deletions(-)

drivers/media/platform/rcar-vin/rcar-csi2.c +10 ~~-14~~

index c14af1b929dff..d27eccfa57cae 100644
@@ -361,7 +361,6 @@ struct rcar_csi2 {
 	struct media_pad pads[NR_OF_RCAR_CSI2_PAD];
 
 	struct v4l2_async_notifier notifier;
-	struct v4l2_async_subdev asd;
 	struct v4l2_subdev *remote;
 
 	struct v4l2_mbus_framefmt mf;

@@ -810,6 +809,8 @@ static int rcsi2_parse_v4l2(struct rcar_csi2 *priv,
 
 static int rcsi2_parse_dt(struct rcar_csi2 *priv)
 {
+	struct v4l2_async_subdev *asd;
+	struct fwnode_handle *fwnode;
 	struct device_node *ep;
 	struct v4l2_fwnode_endpoint v4l2_ep = { .bus_type = 0 };
 	int ret;

@@ -833,24 +834,19 @@ static int rcsi2_parse_dt(struct rcar_csi2 *priv)
 		return ret;
 	}
 
-	priv->asd.match.fwnode =
-		fwnode_graph_get_remote_endpoint(of_fwnode_handle(ep));
-	priv->asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
-
+	fwnode = fwnode_graph_get_remote_endpoint(of_fwnode_handle(ep));
 	of_node_put(ep);
 
-	v4l2_async_notifier_init(&priv->notifier);
-
-	ret = v4l2_async_notifier_add_subdev(&priv->notifier, &priv->asd);
-	if (ret) {
-		fwnode_handle_put(priv->asd.match.fwnode);
-		return ret;
-	}
+	dev_dbg(priv->dev, "Found '%pOF'\n", to_of_node(fwnode));
 
+	v4l2_async_notifier_init(&priv->notifier);
 	priv->notifier.ops = &rcar_csi2_notify_ops;
 
-	dev_dbg(priv->dev, "Found '%pOF'\n",
-		to_of_node(priv->asd.match.fwnode));
+	asd = v4l2_async_notifier_add_fwnode_subdev(&priv->notifier, fwnode,
+						    sizeof(*asd));
+	fwnode_handle_put(fwnode);
+	if (IS_ERR(asd))
+		return PTR_ERR(asd);
 
 	ret = v4l2_async_subdev_notifier_register(&priv->subdev,
 						  &priv->notifier);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:38 UTC #85 lore raw

PATCH 85/408 crypto: omap-sham - fix digcnt register handling with export/import

From: Tero Kristo <[email protected]>

[ Upstream commit 3faf757bad75f3fc1b2736f0431e295a073a7423 ]

Running export/import for hashes in peculiar order (mostly done by openssl) can mess up the internal book keeping of the OMAP SHA core. Fix by forcibly writing the correct DIGCNT back to hardware. This issue was noticed while transitioning to openssl 1.1 support.

Fixes 0d373d603202 ("crypto: omap-sham - Add OMAP4/AM33XX SHAM Support")

Signed-off-by Tero Kristo <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/crypto/omap-sham.c | 3 +++
 1 file changed, 3 insertions(+)

drivers/crypto/omap-sham.c +3 -0

index aba5db3c0588f..d7c0c982ba433 100644
@@ -453,6 +453,9 @@ static void omap_sham_write_ctrl_omap4(struct omap_sham_dev *dd, size_t length,
 	struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
 	u32 val, mask;
 
+	if (likely(ctx->digcnt))
+		omap_sham_write(dd, SHA_REG_DIGCNT(dd), ctx->digcnt);
+
 	/*
 	 * Setting ALGO_CONST only for the first iteration and
 	 * CLOSE_HASH only for the last one. Note that flags mode bits

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #86 lore raw

PATCH 86/408 hwmon: (pmbus/max34440) Fix status register reads for MAX344{51,60,61}

From: Guenter Roeck <[email protected]>

[ Upstream commit 6c094b31ea2ad773824362ba0fccb88d36f8d32d ]

Starting with MAX34451, the chips of this series support STATUS_IOUT and STATUS_TEMPERATURE commands, and no longer report over-current and over-temperature status with STATUS_MFR_SPECIFIC.

Fixes 7a001dbab4ade ("hwmon: (pmbus/max34440) Add support for MAX34451.")

Fixes 50115ac9b6f35 ("hwmon: (pmbus/max34440) Add support for MAX34460 and MAX34461")

Reported-by Steve Foreman <[email protected]>

Cc Steve Foreman <[email protected]>

Signed-off-by Guenter Roeck <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hwmon/pmbus/max34440.c | 3 ---
 1 file changed, 3 deletions(-)

drivers/hwmon/pmbus/max34440.c +0 -3

index 5c63a66007293..e22617def70bf 100644
@@ -387,7 +387,6 @@ static struct pmbus_driver_info max34440_info[] = {
 		.func[18] = PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
 		.func[19] = PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
 		.func[20] = PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
-		.read_byte_data = max34440_read_byte_data,
 		.read_word_data = max34440_read_word_data,
 		.write_word_data = max34440_write_word_data,
 	},

@@ -418,7 +417,6 @@ static struct pmbus_driver_info max34440_info[] = {
 		.func[15] = PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
 		.func[16] = PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
 		.func[17] = PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
-		.read_byte_data = max34440_read_byte_data,
 		.read_word_data = max34440_read_word_data,
 		.write_word_data = max34440_write_word_data,
 	},

@@ -454,7 +452,6 @@ static struct pmbus_driver_info max34440_info[] = {
 		.func[19] = PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
 		.func[20] = PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
 		.func[21] = PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
-		.read_byte_data = max34440_read_byte_data,
 		.read_word_data = max34440_read_word_data,
 		.write_word_data = max34440_write_word_data,
 	},

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #87 lore raw

PATCH 87/408 cypto: mediatek - fix leaks in mtk_desc_ring_alloc

From: Xiaoliang Pang <[email protected]>

[ Upstream commit 228d284aac61283cde508a925d666f854b57af63 ]

In the init loop, if an error occurs in function 'dma_alloc_coherent', then goto the err_cleanup section, after run i--,
in the array ring, the struct mtk_ring with index i will not be released, causing memory leaks

Fixes 785e5c616c849 ("crypto: mediatek - Add crypto driver support for some MediaTek chips")

Cc Ryder Lee <[email protected]>

Signed-off-by Xiaoliang Pang <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/crypto/mediatek/mtk-platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/crypto/mediatek/mtk-platform.c +2 -2

index ef4339e84d034..efce3a83b35a8 100644
@@ -469,13 +469,13 @@ static int mtk_desc_ring_alloc(struct mtk_cryp *cryp)
 	return 0;
 
 err_cleanup:
-	for (; i--; ) {
+	do {
 		dma_free_coherent(cryp->dev, MTK_DESC_RING_SZ,
 				  ring[i]->res_base, ring[i]->res_dma);
 		dma_free_coherent(cryp->dev, MTK_DESC_RING_SZ,
 				  ring[i]->cmd_base, ring[i]->cmd_dma);
 		kfree(ring[i]);
-	}
+	} while (i--);
 	return -ENOMEM;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #88 lore raw

PATCH 88/408 media: mx2_emmaprp: Fix memleak in emmaprp_probe

From: Dinghao Liu <[email protected]>

[ Upstream commit 21d387b8d372f859d9e87fdcc7c3b4a432737f4d ]

When platform_get_irq() fails, we should release
vfd and unregister pcdev->v4l2_dev just like the
subsequent error paths.

Fixes d4e192cc44914 ("media: mx2_emmaprp: Check for platform_get_irq() error")

Signed-off-by Dinghao Liu <[email protected]>

Reviewed-by Fabio Estevam <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/mx2_emmaprp.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/media/platform/mx2_emmaprp.c +5 -2

index 27779b75df543..ac112cf06ab31 100644
@@ -852,8 +852,11 @@ static int emmaprp_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, pcdev);
 
 	irq = platform_get_irq(pdev, 0);
-	if (irq < 0)
-		return irq;
+	if (irq < 0) {
+		ret = irq;
+		goto rel_vdev;
+	}
+
 	ret = devm_request_irq(&pdev->dev, irq, emmaprp_irq, 0,
 			       dev_name(&pdev->dev), pcdev);
 	if (ret)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #89 lore raw

PATCH 89/408 media: tc358743: initialize variable

From: Tom Rix <[email protected]>

[ Upstream commit 274cf92d5dff5c2fec1a518078542ffe70d07646 ]

clang static analysis flags this error

tc358743.c:1468:9: warning: Branch condition evaluates
to a garbage value

        return handled ? IRQ_HANDLED : IRQ_NONE;
               ^~~~~~~

handled should be initialized to false.

Fixes d747b806abf4 ("[media] tc358743: add direct interrupt handling")

Signed-off-by Tom Rix <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/tc358743.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/media/i2c/tc358743.c +1 -1

index dbbab75f135ec..211caade9f998 100644
@@ -1461,7 +1461,7 @@ static int tc358743_isr(struct v4l2_subdev *sd, u32 status, bool *handled)
 static irqreturn_t tc358743_irq_handler(int irq, void *dev_id)
 {
 	struct tc358743_state *state = dev_id;
-	bool handled;
+	bool handled = false;
 
 	tc358743_isr(&state->sd, 0, &handled);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:42 UTC #90 lore raw

PATCH 90/408 media: tc358743: cleanup tc358743_cec_isr

From: Tom Rix <[email protected]>

[ Upstream commit 877cb8a444dad2304e891294afb0915fe3c278d6 ]

tc358743_cec_isr is misnammed, it is not the main isr. So rename it to be consistent with its siblings, tc358743_cec_handler.

It also does not check if its input parameter 'handled' is is non NULL like its siblings, so add a check.

Fixes a0ec8d1dc42e ("media: tc358743: add CEC support")

Signed-off-by Tom Rix <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/i2c/tc358743.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

drivers/media/i2c/tc358743.c +7 -5

index 211caade9f998..cff99cf61ed4d 100644
@@ -919,8 +919,8 @@ static const struct cec_adap_ops tc358743_cec_adap_ops = {
 	.adap_monitor_all_enable = tc358743_cec_adap_monitor_all_enable,
 };
 
-static void tc358743_cec_isr(struct v4l2_subdev *sd, u16 intstatus,
-			     bool *handled)
+static void tc358743_cec_handler(struct v4l2_subdev *sd, u16 intstatus,
+				 bool *handled)
 {
 	struct tc358743_state *state = to_state(sd);
 	unsigned int cec_rxint, cec_txint;

@@ -953,7 +953,8 @@ static void tc358743_cec_isr(struct v4l2_subdev *sd, u16 intstatus,
 			cec_transmit_attempt_done(state->cec_adap,
 						  CEC_TX_STATUS_ERROR);
 		}
-		*handled = true;
+		if (handled)
+			*handled = true;
 	}
 	if ((intstatus & MASK_CEC_RINT) &&
 	    (cec_rxint & MASK_CECRIEND)) {

@@ -968,7 +969,8 @@ static void tc358743_cec_isr(struct v4l2_subdev *sd, u16 intstatus,
 			msg.msg[i] = v & 0xff;
 		}
 		cec_received_msg(state->cec_adap, &msg);
-		*handled = true;
+		if (handled)
+			*handled = true;
 	}
 	i2c_wr16(sd, INTSTATUS,
 		 intstatus & (MASK_CEC_RINT | MASK_CEC_TINT));

@@ -1432,7 +1434,7 @@ static int tc358743_isr(struct v4l2_subdev *sd, u32 status, bool *handled)
 
 #ifdef CONFIG_VIDEO_TC358743_CEC
 	if (intstatus & (MASK_CEC_RINT | MASK_CEC_TINT)) {
-		tc358743_cec_isr(sd, intstatus, handled);
+		tc358743_cec_handler(sd, intstatus, handled);
 		i2c_wr16(sd, INTSTATUS,
 			 intstatus & (MASK_CEC_RINT | MASK_CEC_TINT));
 		intstatus &= ~(MASK_CEC_RINT | MASK_CEC_TINT);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:42 UTC #91 lore raw

PATCH 91/408 media: rcar-vin: Fix a reference count leak.

From: Qiushi Wu <[email protected]>

[ Upstream commit aaffa0126a111d65f4028c503c76192d4cc93277 ]

pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails.

Fixes 90dedce9bc54 ("media: rcar-vin: add function to manipulate Gen3 chsel value")

Signed-off-by Qiushi Wu <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/rcar-vin/rcar-dma.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/media/platform/rcar-vin/rcar-dma.c +3 -1

index 3cb29b2e0b2b1..e5f6360801082 100644
@@ -1334,8 +1334,10 @@ int rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)
 	int ret;
 
 	ret = pm_runtime_get_sync(vin->dev);
-	if (ret < 0)
+	if (ret < 0) {
+		pm_runtime_put_noidle(vin->dev);
 		return ret;
+	}
 
 	/* Make register writes take effect immediately. */
 	vnmc = rvin_read(vin, VNMC_REG);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:42 UTC #92 lore raw

PATCH 92/408 media: rockchip/rga: Fix a reference count leak.

From: Qiushi Wu <[email protected]>

[ Upstream commit 884d638e0853c4b5f01eb6d048fc3b6239012404 ]

pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails.

Fixes f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support")

Signed-off-by Qiushi Wu <[email protected]>

Reviewed-by Heiko Stuebner <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/rockchip/rga/rga-buf.c | 1 +
 1 file changed, 1 insertion(+)

drivers/media/platform/rockchip/rga/rga-buf.c +1 -0

index 36b821ccc1dba..bf9a75b75083b 100644
@@ -81,6 +81,7 @@ static int rga_buf_start_streaming(struct vb2_queue *q, unsigned int count)
 
 	ret = pm_runtime_get_sync(rga->dev);
 	if (ret < 0) {
+		pm_runtime_put_noidle(rga->dev);
 		rga_buf_return_buffers(q, VB2_BUF_STATE_QUEUED);
 		return ret;
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:42 UTC #93 lore raw

PATCH 93/408 media: platform: fcp: Fix a reference count leak.

From: Qiushi Wu <[email protected]>

[ Upstream commit 63e36a381d92a9cded97e90d481ee22566557dd1 ]

Fixes 6eaafbdb668b ("[media] v4l: rcar-fcp: Keep the coding style consistent")

Signed-off-by Qiushi Wu <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/rcar-fcp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/media/platform/rcar-fcp.c +3 -1

index 5c6b00737fe75..05c712e00a2a7 100644
@@ -103,8 +103,10 @@ int rcar_fcp_enable(struct rcar_fcp_device *fcp)
 		return 0;
 
 	ret = pm_runtime_get_sync(fcp->dev);
-	if (ret < 0)
+	if (ret < 0) {
+		pm_runtime_put_noidle(fcp->dev);
 		return ret;
+	}
 
 	return 0;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:42 UTC #94 lore raw

PATCH 94/408 media: camss: Fix a reference count leak.

From: Qiushi Wu <[email protected]>

[ Upstream commit d0675b67b42eb4f1a840d1513b5b00f78312f833 ]

pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if PM runtime put is not called in error handling paths. Thus call pm_runtime_put_sync() if pm_runtime_get_sync() fails.

Fixes 02afa816dbbf ("media: camss: Add basic runtime PM support")

Signed-off-by Qiushi Wu <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/qcom/camss/camss-csiphy.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/media/platform/qcom/camss/camss-csiphy.c +3 -1

index 008afb85023be..3c5b9082ad723 100644
@@ -176,8 +176,10 @@ static int csiphy_set_power(struct v4l2_subdev *sd, int on)
 		int ret;
 
 		ret = pm_runtime_get_sync(dev);
-		if (ret < 0)
+		if (ret < 0) {
+			pm_runtime_put_sync(dev);
 			return ret;
+		}
 
 		ret = csiphy_set_clock_rates(csiphy);
 		if (ret < 0) {

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #95 lore raw

PATCH 95/408 media: s5p-mfc: Fix a reference count leak

From: Qiushi Wu <[email protected]>

[ Upstream commit 78741ce98c2e36188e2343434406b0e0bc50b0e7 ]

Fixes c5086f130a77 ("[media] s5p-mfc: Use clock gating only on MFC v5 hardware")

Signed-off-by Qiushi Wu <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/media/platform/s5p-mfc/s5p_mfc_pm.c +3 -1

index 7d52431c2c837..62d2320a72186 100644
@@ -79,8 +79,10 @@ int s5p_mfc_power_on(void)
 	int i, ret = 0;
 
 	ret = pm_runtime_get_sync(pm->device);
-	if (ret < 0)
+	if (ret < 0) {
+		pm_runtime_put_noidle(pm->device);
 		return ret;
+	}
 
 	/* clock control */
 	for (i = 0; i < pm->num_clocks; i++) {

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:42 UTC #96 lore raw

PATCH 96/408 media: stm32-dcmi: Fix a reference count leak

From: Qiushi Wu <[email protected]>

[ Upstream commit 88f50a05f907d96a27a9ce3cc9e8cbb91a6f0f22 ]

Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count if pm_runtime_put is not called in error handling paths. Thus replace the jump target "err_release_buffers" by "err_pm_putw".

Fixes 152e0bf60219 ("media: stm32-dcmi: add power saving support")

Signed-off-by Qiushi Wu <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/stm32/stm32-dcmi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

drivers/media/platform/stm32/stm32-dcmi.c +1 -3

index 9392e3409fba0..d41475f56ab54 100644
@@ -733,7 +733,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 	if (ret < 0) {
 		dev_err(dcmi->dev, "%s: Failed to start streaming, cannot get sync (%d)\n",
 			__func__, ret);
-		goto err_release_buffers;
+		goto err_pm_put;
 	}
 
 	ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);

@@ -837,8 +837,6 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 
 err_pm_put:
 	pm_runtime_put(dcmi->dev);
-
-err_release_buffers:
 	spin_lock_irq(&dcmi->irqlock);
 	/*
 	 * Return all buffers to vb2 in QUEUED state.

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:41 UTC #97 lore raw

PATCH 97/408 media: ti-vpe: Fix a missing check and reference count leak

From: Qiushi Wu <[email protected]>

[ Upstream commit 7dae2aaaf432767ca7aa11fa84643a7c2600dbdd ]

pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if pm_runtime_put_noidle() is not called in error handling paths. And also, when the call of function vpe_runtime_get() failed, we won't call vpe_runtime_put().
Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails inside vpe_runtime_get().

Fixes 4571912743ac ("[media] v4l: ti-vpe: Add VPE mem to mem driver")

Signed-off-by Qiushi Wu <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/platform/ti-vpe/vpe.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/media/platform/ti-vpe/vpe.c +2 -0

index 8b14ba4a3d9ea..817bd13370eff 100644
@@ -2435,6 +2435,8 @@ static int vpe_runtime_get(struct platform_device *pdev)
 
 	r = pm_runtime_get_sync(&pdev->dev);
 	WARN_ON(r < 0);
+	if (r)
+		pm_runtime_put_noidle(&pdev->dev);
 	return r < 0 ? r : 0;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #98 lore raw

PATCH 98/408 regulator: resolve supply after creating regulator

Link https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl open here

From: Michał Mirosław <[email protected]>

[ Upstream commit aea6cb99703e17019e025aa71643b4d3e0a24413 ]

When creating a new regulator its supply cannot create the sysfs link because the device is not yet published. Remove early supply resolving since it will be done later anyway. This makes the following error disappear and the symlinks get created instead.

DCDC_REG1: supplied by VSYS
VSYS: could not add device link regulator.3 err -2

Note: It doesn't fix the problem for bypassed regulators, though.

Fixes 45389c47526d ("regulator: core: Add early supply resolution for regulators")

Signed-off-by Michał Mirosław <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/regulator/core.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

drivers/regulator/core.c +13 -8

index 55fc80de5ef16..ee850cffe1542 100644
@@ -5158,15 +5158,20 @@ regulator_register(const struct regulator_desc *regulator_desc,
 	else if (regulator_desc->supply_name)
 		rdev->supply_name = regulator_desc->supply_name;
 
-	/*
-	 * Attempt to resolve the regulator supply, if specified,
-	 * but don't return an error if we fail because we will try
-	 * to resolve it again later as more regulators are added.
-	 */
-	if (regulator_resolve_supply(rdev))
-		rdev_dbg(rdev, "unable to resolve supply\n");
-
 	ret = set_machine_constraints(rdev, constraints);
+	if (ret == -EPROBE_DEFER) {
+		/* Regulator might be in bypass mode and so needs its supply
+		 * to set the constraints */
+		/* FIXME: this currently triggers a chicken-and-egg problem
+		 * when creating -SUPPLY symlink in sysfs to a regulator
+		 * that is just being created */
+		ret = regulator_resolve_supply(rdev);
+		if (!ret)
+			ret = set_machine_constraints(rdev, constraints);
+		else
+			rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
+				 ERR_PTR(ret));
+	}
 	if (ret < 0)
 		goto wash;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #99 lore raw

PATCH 99/408 pinctrl: bcm: fix kconfig dependency warning when !GPIOLIB

From: Necip Fazil Yildiran <[email protected]>

[ Upstream commit 513034d8b089b9a49dab57845aee70e830fe7334 ]

When PINCTRL_BCM2835 is enabled and GPIOLIB is disabled, it results in the following Kbuild warning:

WARNING: unmet direct dependencies detected for GPIOLIB_IRQCHIP
Depends on [n]: GPIOLIB [=n]
Selected by [y]:
- PINCTRL_BCM2835 [=y] && PINCTRL [=y] && OF [=y] && (ARCH_BCM2835 [=n] || ARCH_BRCMSTB [=n] || COMPILE_TEST [=y])

The reason is that PINCTRL_BCM2835 selects GPIOLIB_IRQCHIP without depending on or selecting GPIOLIB while GPIOLIB_IRQCHIP is subordinate to GPIOLIB.

Honor the kconfig menu hierarchy to remove kconfig dependency warnings.

Fixes 85ae9e512f43 ("pinctrl: bcm2835: switch to GPIOLIB_IRQCHIP")

Signed-off-by Necip Fazil Yildiran <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pinctrl/bcm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

drivers/pinctrl/bcm/Kconfig +1 -0

index dcf7df797af75..0ed14de0134cf 100644
@@ -23,6 +23,7 @@ config PINCTRL_BCM2835
 	select PINMUX
 	select PINCONF
 	select GENERIC_PINCONF
+	select GPIOLIB
 	select GPIOLIB_IRQCHIP
 	default ARCH_BCM2835 || ARCH_BRCMSTB
 	help

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:34 UTC #100 lore raw

PATCH 100/408 spi: spi-s3c64xx: swap s3c64xx_spi_set_cs() and s3c64xx_enable_datapath()

From: Łukasz Stelmach <[email protected]>

[ Upstream commit 581e2b41977dfc2d4c26c8e976f89c43bb92f9bf ]

Fix issues with DMA transfers bigger than 512 bytes on Exynos3250. Without the patches such transfers fail to complete. This solution to the problem is found in the vendor kernel for ARTIK5 boards based on Exynos3250.

Reviewed-by Krzysztof Kozlowski <[email protected]>

Signed-off-by Łukasz Stelmach <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/spi/spi-s3c64xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/spi/spi-s3c64xx.c +2 -2

index 7b7151ec14c8a..322f75f89c713 100644
@@ -678,11 +678,11 @@ static int s3c64xx_spi_transfer_one(struct spi_master *master,
 		sdd->state &= ~RXBUSY;
 		sdd->state &= ~TXBUSY;
 
-		s3c64xx_enable_datapath(sdd, xfer, use_dma);
-
 		/* Start the signals */
 		s3c64xx_spi_set_cs(spi, true);
 
+		s3c64xx_enable_datapath(sdd, xfer, use_dma);
+
 		spin_unlock_irqrestore(&sdd->lock, flags);
 
 		if (use_dma)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:34 UTC #101 lore raw

PATCH 101/408 spi: spi-s3c64xx: Check return values

From: Łukasz Stelmach <[email protected]>

[ Upstream commit 2f4db6f705c5cba85d23836c19b44d9687dc1334 ]

Check return values in prepare_dma() and s3c64xx_spi_config() and propagate errors upwards.

Fixes 788437273fa8 ("spi: s3c64xx: move to generic dmaengine API")

Reviewed-by Krzysztof Kozlowski <[email protected]>

Signed-off-by Łukasz Stelmach <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/spi/spi-s3c64xx.c | 50 ++++++++++++++++++++++++++++++++-------
 1 file changed, 41 insertions(+), 9 deletions(-)

drivers/spi/spi-s3c64xx.c +41 -9

index 322f75f89c713..1d948fee1a039 100644
@@ -122,6 +122,7 @@
 
 struct s3c64xx_spi_dma_data {
 	struct dma_chan *ch;
+	dma_cookie_t cookie;
 	enum dma_transfer_direction direction;
 };

@@ -264,12 +265,13 @@ static void s3c64xx_spi_dmacb(void *data)
 	spin_unlock_irqrestore(&sdd->lock, flags);
 }
 
-static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
+static int prepare_dma(struct s3c64xx_spi_dma_data *dma,
 			struct sg_table *sgt)
 {
 	struct s3c64xx_spi_driver_data *sdd;
 	struct dma_slave_config config;
 	struct dma_async_tx_descriptor *desc;
+	int ret;
 
 	memset(&config, 0, sizeof(config));

@@ -293,12 +295,24 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
 
 	desc = dmaengine_prep_slave_sg(dma->ch, sgt->sgl, sgt->nents,
 				       dma->direction, DMA_PREP_INTERRUPT);
+	if (!desc) {
+		dev_err(&sdd->pdev->dev, "unable to prepare %s scatterlist",
+			dma->direction == DMA_DEV_TO_MEM ? "rx" : "tx");
+		return -ENOMEM;
+	}
 
 	desc->callback = s3c64xx_spi_dmacb;
 	desc->callback_param = dma;
 
-	dmaengine_submit(desc);
+	dma->cookie = dmaengine_submit(desc);
+	ret = dma_submit_error(dma->cookie);
+	if (ret) {
+		dev_err(&sdd->pdev->dev, "DMA submission failed");
+		return -EIO;
+	}
+
 	dma_async_issue_pending(dma->ch);
+	return 0;
 }
 
 static void s3c64xx_spi_set_cs(struct spi_device *spi, bool enable)

@@ -348,11 +362,12 @@ static bool s3c64xx_spi_can_dma(struct spi_master *master,
 	return xfer->len > (FIFO_LVL_MASK(sdd) >> 1) + 1;
 }
 
-static void s3c64xx_enable_datapath(struct s3c64xx_spi_driver_data *sdd,
+static int s3c64xx_enable_datapath(struct s3c64xx_spi_driver_data *sdd,
 				    struct spi_transfer *xfer, int dma_mode)
 {
 	void __iomem *regs = sdd->regs;
 	u32 modecfg, chcfg;
+	int ret = 0;
 
 	modecfg = readl(regs + S3C64XX_SPI_MODE_CFG);
 	modecfg &= ~(S3C64XX_SPI_MODE_TXDMA_ON | S3C64XX_SPI_MODE_RXDMA_ON);

@@ -378,7 +393,7 @@ static void s3c64xx_enable_datapath(struct s3c64xx_spi_driver_data *sdd,
 		chcfg |= S3C64XX_SPI_CH_TXCH_ON;
 		if (dma_mode) {
 			modecfg |= S3C64XX_SPI_MODE_TXDMA_ON;
-			prepare_dma(&sdd->tx_dma, &xfer->tx_sg);
+			ret = prepare_dma(&sdd->tx_dma, &xfer->tx_sg);
 		} else {
 			switch (sdd->cur_bpw) {
 			case 32:

@@ -410,12 +425,17 @@ static void s3c64xx_enable_datapath(struct s3c64xx_spi_driver_data *sdd,
 			writel(((xfer->len * 8 / sdd->cur_bpw) & 0xffff)
 					| S3C64XX_SPI_PACKET_CNT_EN,
 					regs + S3C64XX_SPI_PACKET_CNT);
-			prepare_dma(&sdd->rx_dma, &xfer->rx_sg);
+			ret = prepare_dma(&sdd->rx_dma, &xfer->rx_sg);
 		}
 	}
 
+	if (ret)
+		return ret;
+
 	writel(modecfg, regs + S3C64XX_SPI_MODE_CFG);
 	writel(chcfg, regs + S3C64XX_SPI_CH_CFG);
+
+	return 0;
 }
 
 static u32 s3c64xx_spi_wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,

@@ -548,9 +568,10 @@ static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
 	return 0;
 }
 
-static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
+static int s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
 {
 	void __iomem *regs = sdd->regs;
+	int ret;
 	u32 val;
 
 	/* Disable Clock */

@@ -598,7 +619,9 @@ static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
 
 	if (sdd->port_conf->clk_from_cmu) {
 		/* The src_clk clock is divided internally by 2 */
-		clk_set_rate(sdd->src_clk, sdd->cur_speed * 2);
+		ret = clk_set_rate(sdd->src_clk, sdd->cur_speed * 2);
+		if (ret)
+			return ret;
 	} else {
 		/* Configure Clock */
 		val = readl(regs + S3C64XX_SPI_CLK_CFG);

@@ -612,6 +635,8 @@ static void s3c64xx_spi_config(struct s3c64xx_spi_driver_data *sdd)
 		val |= S3C64XX_SPI_ENCLK_ENABLE;
 		writel(val, regs + S3C64XX_SPI_CLK_CFG);
 	}
+
+	return 0;
 }
 
 #define XFER_DMAADDR_INVALID DMA_BIT_MASK(32)

@@ -654,7 +679,9 @@ static int s3c64xx_spi_transfer_one(struct spi_master *master,
 		sdd->cur_bpw = bpw;
 		sdd->cur_speed = speed;
 		sdd->cur_mode = spi->mode;
-		s3c64xx_spi_config(sdd);
+		status = s3c64xx_spi_config(sdd);
+		if (status)
+			return status;
 	}
 
 	if (!is_polling(sdd) && (xfer->len > fifo_len) &&

@@ -681,10 +708,15 @@ static int s3c64xx_spi_transfer_one(struct spi_master *master,
 		/* Start the signals */
 		s3c64xx_spi_set_cs(spi, true);
 
-		s3c64xx_enable_datapath(sdd, xfer, use_dma);
+		status = s3c64xx_enable_datapath(sdd, xfer, use_dma);
 
 		spin_unlock_irqrestore(&sdd->lock, flags);
 
+		if (status) {
+			dev_err(&spi->dev, "failed to enable data path for transfer: %d\n", status);
+			break;
+		}
+
 		if (use_dma)
 			status = s3c64xx_wait_for_dma(sdd, xfer);
 		else

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:32 UTC #102 lore raw

PATCH 102/408 blk-mq: move cancel of hctx->run_work to the front of blk_exit_queue

From: Yang Yang <[email protected]>

[ Upstream commit 47ce030b7ac5a5259a9a5919f230b52497afc31a ]

blk_exit_queue will free elevator_data, while blk_mq_run_work_fn will access it. Move cancel of hctx->run_work to the front of blk_exit_queue to avoid use-after-free.

Fixes 1b97871b501f ("blk-mq: move cancel of hctx->run_work into blk_mq_hw_sysfs_release")

Signed-off-by Yang Yang <[email protected]>

Reviewed-by Ming Lei <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 block/blk-mq-sysfs.c | 2 --
 block/blk-sysfs.c    | 9 ++++++++-
 2 files changed, 8 insertions(+), 3 deletions(-)

block/blk-mq-sysfs.c +0 -2

index a09ab0c3d074d..5dafd7a8ec913 100644
@@ -36,8 +36,6 @@ static void blk_mq_hw_sysfs_release(struct kobject *kobj)
 	struct blk_mq_hw_ctx *hctx = container_of(kobj, struct blk_mq_hw_ctx,
 						  kobj);
 
-	cancel_delayed_work_sync(&hctx->run_work);
-
 	if (hctx->flags & BLK_MQ_F_BLOCKING)
 		cleanup_srcu_struct(hctx->srcu);
 	blk_free_flush_queue(hctx->fq);

block/blk-sysfs.c +8 -1

index 46f5198be0173..bf33570da5ac7 100644
@@ -891,9 +891,16 @@ static void __blk_release_queue(struct work_struct *work)
 
 	blk_free_queue_stats(q->stats);
 
-	if (queue_is_mq(q))
+	if (queue_is_mq(q)) {
+		struct blk_mq_hw_ctx *hctx;
+		int i;
+
 		cancel_delayed_work_sync(&q->requeue_work);
 
+		queue_for_each_hw_ctx(q, hctx, i)
+			cancel_delayed_work_sync(&hctx->run_work);
+	}
+
 	blk_exit_queue(q);
 
 	blk_queue_free_zone_bitmaps(q);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #103 lore raw

PATCH 103/408 ath10k: provide survey info as accumulated data

From: Venkateswara Naralasetty <[email protected]>

[ Upstream commit 720e5c03e5cb26d33d97f55192b791bb48478aa5 ]

It is expected that the returned counters by .get_survey are monotonic increasing. But the data from ath10k gets reset to zero regularly. Channel active/busy time are then showing incorrect values (less than previous or sometimes zero) for the currently active channel during successive survey dump commands.

example:

  $ iw dev wlan0 survey dump
  Survey data from wlan0
  	frequency:                      5180 MHz [in use]
  	channel active time:            54995 ms
  	channel busy time:              432 ms
  	channel receive time:           0 ms
  	channel transmit time:          59 ms
  ...

  $ iw dev wlan0 survey dump
  Survey data from wlan0
  	frequency:                      5180 MHz [in use]
  	channel active time:            32592 ms
  	channel busy time:              254 ms
  	channel receive time:           0 ms
  	channel transmit time:          0 ms
  ...

The correct way to handle this is to use the non-clearing WMI_BSS_SURVEY_REQ_TYPE_READ wmi_bss_survey_req_type. The firmware will then accumulate the survey data and handle wrap arounds.

Tested-on: QCA9984 hw1.0 10.4-3.5.3-00057
Tested-on: QCA988X hw2.0 10.2.4-1.0-00047
Tested-on: QCA9888 hw2.0 10.4-3.9.0.2-00024
Tested-on: QCA4019 hw1.0 10.4-3.6-00140

Fixes fa7937e3d5c2 ("ath10k: update bss channel survey information")

Signed-off-by Venkateswara Naralasetty <[email protected]>

Tested-by Markus Theil <[email protected]>

Tested-by John Deere <[email protected]>

[[email protected]: adjust commit message]

Signed-off-by Sven Eckelmann <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/ath/ath10k/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wireless/ath/ath10k/mac.c +1 -1

index d373602a80145..915ba2a7f7448 100644
@@ -7131,7 +7131,7 @@ ath10k_mac_update_bss_chan_survey(struct ath10k *ar,
 				  struct ieee80211_channel *channel)
 {
 	int ret;
-	enum wmi_bss_survey_req_type type = WMI_BSS_SURVEY_REQ_TYPE_READ_CLEAR;
+	enum wmi_bss_survey_req_type type = WMI_BSS_SURVEY_REQ_TYPE_READ;
 
 	lockdep_assert_held(&ar->conf_mutex);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #104 lore raw

PATCH 104/408 drm/vkms: fix xrgb on compute crc

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Melissa Wen <[email protected]>

[ Upstream commit 0986191186128b10b6bbfa5220fc587ed5725e49 ]

The previous memset operation was not correctly zeroing the alpha channel to compute the crc, and as a result, the IGT subtest kms_cursor_crc/pipe-A-cursor-alpha-transparent fails.

Fixes db7f419c06d7c ("drm/vkms: Compute CRC with Cursor Plane")

Signed-off-by Melissa Wen <[email protected]>

Signed-off-by Daniel Vetter <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/vkms/vkms_composer.c +1 -1

index d5585695c64d1..45d6ebbdbdb22 100644
@@ -33,7 +33,7 @@ static uint32_t compute_crc(void *vaddr_out, struct vkms_composer *composer)
 				     + (i * composer->pitch)
 				     + (j * composer->cpp);
 			/* XRGB format ignores Alpha channel */
-			memset(vaddr_out + src_offset + 24, 0,  8);
+			bitmap_clear(vaddr_out + src_offset, 24, 8);
 			crc = crc32_le(crc, vaddr_out + src_offset,
 				       sizeof(u32));
 		}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #105 lore raw

PATCH 105/408 Bluetooth: hci_uart: Cancel init work before unregistering

From: Samuel Holland <[email protected]>

[ Upstream commit 3b799254cf6f481460719023d7a18f46651e5e7f ]

If hci_uart_tty_close() or hci_uart_unregister_device() is called while hu->init_ready is scheduled, hci_register_dev() could be called after the hci_uart is torn down. Avoid this by ensuring the work is complete or canceled before checking the HCI_UART_REGISTERED flag.

Fixes 9f2aee848fe6 ("Bluetooth: Add delayed init sequence support for UART controllers")

Signed-off-by Samuel Holland <[email protected]>

Signed-off-by Marcel Holtmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/bluetooth/hci_ldisc.c  | 1 +
 drivers/bluetooth/hci_serdev.c | 2 ++
 2 files changed, 3 insertions(+)

drivers/bluetooth/hci_ldisc.c +1 -0

index 85a30fb9177bb..f83d67eafc9f0 100644
@@ -538,6 +538,7 @@ static void hci_uart_tty_close(struct tty_struct *tty)
 		clear_bit(HCI_UART_PROTO_READY, &hu->flags);
 		percpu_up_write(&hu->proto_lock);
 
+		cancel_work_sync(&hu->init_ready);
 		cancel_work_sync(&hu->write_work);
 
 		if (hdev) {

drivers/bluetooth/hci_serdev.c +2 -0

index ad2f26cb2622e..5b9aa73ff2b7f 100644
@@ -357,6 +357,8 @@ void hci_uart_unregister_device(struct hci_uart *hu)
 	struct hci_dev *hdev = hu->hdev;
 
 	clear_bit(HCI_UART_PROTO_READY, &hu->flags);
+
+	cancel_work_sync(&hu->init_ready);
 	if (test_bit(HCI_UART_REGISTERED, &hu->flags))
 		hci_unregister_dev(hdev);
 	hci_free_dev(hdev);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #106 lore raw

PATCH 106/408 drm/amd/display: Fix wrong return value in dm_update_plane_state()

From: Tianjia Zhang <[email protected]>

[ Upstream commit c35376137e940c3389df2726a92649c01a9844b4 ]

On an error exit path, a negative error code should be returned instead of a positive return value.

Fixes 9e869063b0021 ("drm/amd/display: Move iteration out of dm_update_planes")

Cc Leo Li <[email protected]>

Signed-off-by Alex Deucher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +1 -2

index 2384aa018993d..7c58085031732 100644
@@ -6984,8 +6984,7 @@ static int dm_update_plane_state(struct dc *dc,
 				dm_old_plane_state->dc_state,
 				dm_state->context)) {
 
-			ret = EINVAL;
-			return ret;
+			return -EINVAL;
 		}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:41 UTC #107 lore raw

PATCH 107/408 drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel

From: Laurent Pinchart <[email protected]>

[ Upstream commit f098f168e91ca915c6cf8aa316136af647792f2f ]

The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel, set the bus format to MEDIA_BUS_FMT_RGB666_1X18.

Fixes 725c9d40f3fe ("drm/panel: Add support for OrtusTech COM43H4M85ULC panel")

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Signed-off-by Sam Ravnborg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/panel/panel-simple.c +1 -1

index 6d9656323a3f4..14f5c79299cc0 100644
@@ -2387,7 +2387,7 @@ static const struct panel_desc ortustech_com43h4m85ulc = {
 		.width = 56,
 		.height = 93,
 	},
-	.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+	.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
 	.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
 };

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:41 UTC #108 lore raw

PATCH 108/408 ath6kl: prevent potential array overflow in ath6kl_add_new_sta()

From: Dan Carpenter <[email protected]>

[ Upstream commit 54f9ab7b870934b70e5a21786d951fbcf663970f ]

The value for "aid" comes from skb->data so Smatch marks it as untrusted. If it's invalid then it can result in an out of bounds array access in ath6kl_add_new_sta().

Fixes 572e27c00c9d ("ath6kl: Fix AP mode connect event parsing and TIM updates")

Link https://lore.kernel.org/r/20200813141315.GB457408@mwanda open here

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/ath/ath6kl/main.c | 3 +++
 1 file changed, 3 insertions(+)

drivers/net/wireless/ath/ath6kl/main.c +3 -0

index 5e7ea838a9218..814131a0680a4 100644
@@ -430,6 +430,9 @@ void ath6kl_connect_ap_mode_sta(struct ath6kl_vif *vif, u16 aid, u8 *mac_addr,
 
 	ath6kl_dbg(ATH6KL_DBG_TRC, "new station %pM aid=%d\n", mac_addr, aid);
 
+	if (aid < 1 || aid > AP_MAX_NUM_STA)
+		return;
+
 	if (assoc_req_len > sizeof(struct ieee80211_hdr_3addr)) {
 		struct ieee80211_mgmt *mgmt =
 			(struct ieee80211_mgmt *) assoc_info;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #109 lore raw

PATCH 109/408 ath9k: Fix potential out of bounds in ath9k_htc_txcompletion_cb()

From: Dan Carpenter <[email protected]>

[ Upstream commit 2705cd7558e718a7240c64eb0afb2edad5f8c190 ]

The value of "htc_hdr->endpoint_id" comes from skb->data so Smatch marks it as untrusted so we have to check it before using it as an array offset.

This is similar to a bug that syzkaller found in commit e4ff08a4d727 ("ath9k: Fix use-after-free Write in ath9k_htc_rx_msg") so it is probably a real issue.

Fixes fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.")

Link https://lore.kernel.org/r/20200813141253.GA457408@mwanda open here

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/ath/ath9k/htc_hst.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/net/wireless/ath/ath9k/htc_hst.c +2 -0

index d2e062eaf5614..510e61e97dbcb 100644
@@ -339,6 +339,8 @@ void ath9k_htc_txcompletion_cb(struct htc_target *htc_handle,
 
 	if (skb) {
 		htc_hdr = (struct htc_frame_hdr *) skb->data;
+		if (htc_hdr->endpoint_id >= ARRAY_SIZE(htc_handle->endpoint))
+			goto ret;
 		endpoint = &htc_handle->endpoint[htc_hdr->endpoint_id];
 		skb_pull(skb, sizeof(struct htc_frame_hdr));

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #110 lore raw

PATCH 110/408 ath10k: Fix the size used in a dma_free_coherent() call in an error handling path

From: Christophe JAILLET <[email protected]>

[ Upstream commit 454530a9950b5a26d4998908249564cedfc4babc ]

Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()'.

Fixes 1863008369ae ("ath10k: fix shadow register implementation for WCN3990")

Signed-off-by Christophe JAILLET <[email protected]>

Reviewed-by Rakesh Pillai <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/ath/ath10k/ce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wireless/ath/ath10k/ce.c +1 -1

index eca87f7c5b6c1..01e05af5ae085 100644
@@ -1555,7 +1555,7 @@ ath10k_ce_alloc_src_ring(struct ath10k *ar, unsigned int ce_id,
 		ret = ath10k_ce_alloc_shadow_base(ar, src_ring, nentries);
 		if (ret) {
 			dma_free_coherent(ar->dev,
-					  (nentries * sizeof(struct ce_desc_64) +
+					  (nentries * sizeof(struct ce_desc) +
 					   CE_DESC_RING_ALIGN),
 					  src_ring->base_addr_owner_space_unaligned,
 					  base_addr);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #111 lore raw

PATCH 111/408 wcn36xx: Fix reported 802.11n rx_highest rate wcn3660/wcn3680

From: Bryan O'Donoghue <[email protected]>

[ Upstream commit 3b9fb6791e7113679b1eb472e6ce1659e80f5797 ]

Qualcomm's document "80-WL007-1 Rev. J" states that the highest rx rate for the WCN3660 and WCN3680 on MCS 7 is 150 Mbps not the 72 Mbps stated here.

This patch fixes the data-rate declared in the 5GHz table.

Fixes 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680

hardware")

Signed-off-by Bryan O'Donoghue <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/ath/wcn36xx/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wireless/ath/wcn36xx/main.c +1 -1

index ad051f34e65b2..46ae4ec4ad47d 100644
@@ -163,7 +163,7 @@ static struct ieee80211_supported_band wcn_band_5ghz = {
 		.ampdu_density = IEEE80211_HT_MPDU_DENSITY_16,
 		.mcs = {
 			.rx_mask = { 0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0, },
-			.rx_highest = cpu_to_le16(72),
+			.rx_highest = cpu_to_le16(150),
 			.tx_params = IEEE80211_HT_MCS_TX_DEFINED,
 		}
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #112 lore raw

PATCH 112/408 ASoC: qcom: lpass-platform: fix memory leak

From: Rohit kumar <[email protected]>

[ Upstream commit 5fd188215d4eb52703600d8986b22311099a5940 ]

lpass_pcm_data is never freed. Free it in close
ops to avoid memory leak.

Fixes 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage")

Signed-off-by Rohit kumar <[email protected]>

Reviewed-by Srinivas Kandagatla <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/soc/qcom/lpass-platform.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

sound/soc/qcom/lpass-platform.c +2 -1

index 4c745baa39f73..9acaef81dd74c 100644
@@ -61,7 +61,7 @@ static int lpass_platform_pcmops_open(struct snd_pcm_substream *substream)
 	int ret, dma_ch, dir = substream->stream;
 	struct lpass_pcm_data *data;
 
-	data = devm_kzalloc(soc_runtime->dev, sizeof(*data), GFP_KERNEL);
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return -ENOMEM;

@@ -119,6 +119,7 @@ static int lpass_platform_pcmops_close(struct snd_pcm_substream *substream)
 	if (v->free_dma_channel)
 		v->free_dma_channel(drvdata, data->dma_ch);
 
+	kfree(data);
 	return 0;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:37 UTC #113 lore raw

PATCH 113/408 ASoC: qcom: lpass-cpu: fix concurrency issue

From: Rohit kumar <[email protected]>

[ Upstream commit 753a6e17942f6f425ca622e1610625998312ad89 ]

i2sctl register value is set to 0 during hw_free(). This impacts any ongoing concurrent session on the same i2s port. As trigger() stop already resets enable bit to 0, there is no need of explicit hw_free. Removing it to fix the issue.

Fixes 80beab8e1d86 ("ASoC: qcom: Add LPASS CPU DAI driver")

Signed-off-by Rohit kumar <[email protected]>

Reviewed-by Srinivas Kandagatla <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/soc/qcom/lpass-cpu.c | 16 ----------------
 1 file changed, 16 deletions(-)

sound/soc/qcom/lpass-cpu.c +0 ~~-16~~

index dbce7e92baf3c..c5d6952a4a33f 100644
@@ -174,21 +174,6 @@ static int lpass_cpu_daiops_hw_params(struct snd_pcm_substream *substream,
 	return 0;
 }
 
-static int lpass_cpu_daiops_hw_free(struct snd_pcm_substream *substream,
-		struct snd_soc_dai *dai)
-{
-	struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
-	int ret;
-
-	ret = regmap_write(drvdata->lpaif_map,
-			   LPAIF_I2SCTL_REG(drvdata->variant, dai->driver->id),
-			   0);
-	if (ret)
-		dev_err(dai->dev, "error writing to i2sctl reg: %d\n", ret);
-
-	return ret;
-}
-
 static int lpass_cpu_daiops_prepare(struct snd_pcm_substream *substream,
 		struct snd_soc_dai *dai)
 {

@@ -269,7 +254,6 @@ const struct snd_soc_dai_ops asoc_qcom_lpass_cpu_dai_ops = {
 	.startup	= lpass_cpu_daiops_startup,
 	.shutdown	= lpass_cpu_daiops_shutdown,
 	.hw_params	= lpass_cpu_daiops_hw_params,
-	.hw_free	= lpass_cpu_daiops_hw_free,
 	.prepare	= lpass_cpu_daiops_prepare,
 	.trigger	= lpass_cpu_daiops_trigger,
 };

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #114 lore raw

PATCH 114/408 brcmfmac: check ndev pointer

From: Tom Rix <[email protected]>

[ Upstream commit 9c9f015bc9f8839831c7ba0a6d731a3853c464e2 ]

Clang static analysis reports this error

brcmfmac/core.c:490:4: warning: Dereference of null pointer

        (*ifp)->ndev->stats.rx_errors++;
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In this block of code

	if (ret || !(*ifp) || !(*ifp)->ndev) {
		if (ret != -ENODATA && *ifp)
			(*ifp)->ndev->stats.rx_errors++;
		brcmu_pkt_buf_free_skb(skb);
		return -ENODATA;
	}

(*ifp)->ndev being NULL is caught as an error
But then it is used to report the error.

So add a check before using it.

Fixes 91b632803ee4 ("brcmfmac: Use net_device_stats from struct net_device")

Signed-off-by Tom Rix <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c +1 -1

index 85cf96461ddeb..e9bb8dbdc9aa8 100644
@@ -483,7 +483,7 @@ static int brcmf_rx_hdrpull(struct brcmf_pub *drvr, struct sk_buff *skb,
 	ret = brcmf_proto_hdrpull(drvr, true, skb, ifp);
 
 	if (ret || !(*ifp) || !(*ifp)->ndev) {
-		if (ret != -ENODATA && *ifp)
+		if (ret != -ENODATA && *ifp && (*ifp)->ndev)
 			(*ifp)->ndev->stats.rx_errors++;
 		brcmu_pkt_buf_free_skb(skb);
 		return -ENODATA;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #115 lore raw

PATCH 115/408 mwifiex: Do not use GFP_KERNEL in atomic context

From: Christophe JAILLET <[email protected]>

[ Upstream commit d2ab7f00f4321370a8ee14e5630d4349fdacc42e ]

A possible call chain is as follow:

  mwifiex_sdio_interrupt                            (sdio.c)
    --> mwifiex_main_process                        (main.c)
      --> mwifiex_process_cmdresp                   (cmdevt.c)
        --> mwifiex_process_sta_cmdresp             (sta_cmdresp.c)
          --> mwifiex_ret_802_11_scan               (scan.c)
            --> mwifiex_parse_single_response_buf   (scan.c)

'mwifiex_sdio_interrupt()' is an interrupt function.

Also note that 'mwifiex_ret_802_11_scan()' already uses GFP_ATOMIC.

So use GFP_ATOMIC instead of GFP_KERNEL when memory is allocated in 'mwifiex_parse_single_response_buf()'.

Fixes 7c6fa2a843c5 ("mwifiex: use cfg80211 dynamic scan table and cfg80211_get_bss API")

Fixes 601216e12c65e ("mwifiex: process RX packets in SDIO IRQ thread directly")

Signed-off-by Christophe JAILLET <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/marvell/mwifiex/scan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wireless/marvell/mwifiex/scan.c +1 -1

index 59f0651d148bb..629af26675cf1 100644
@@ -1891,7 +1891,7 @@ mwifiex_parse_single_response_buf(struct mwifiex_private *priv, u8 **bss_info,
 					    chan, CFG80211_BSS_FTYPE_UNKNOWN,
 					    bssid, timestamp,
 					    cap_info_bitmap, beacon_period,
-					    ie_buf, ie_len, rssi, GFP_KERNEL);
+					    ie_buf, ie_len, rssi, GFP_ATOMIC);
 			if (bss) {
 				bss_priv = (struct mwifiex_bss_priv *)bss->priv;
 				bss_priv->band = band;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #116 lore raw

PATCH 116/408 staging: rtl8192u: Do not use GFP_KERNEL in atomic context

From: Christophe JAILLET <[email protected]>

[ Upstream commit acac75bb451fd39344eb54fad6602dfc9482e970 ]

'rtl8192_irq_rx_tasklet()' is a tasklet initialized in 'rtl8192_init_priv_task()'.

Quoted 1 line

From this function it is possible to allocate some memory with the

GFP_KERNEL flag, which is not allowed in the atomic context of a tasklet.

Use GFP_ATOMIC instead.

The call chain is:

  rtl8192_irq_rx_tasklet            (in r8192U_core.c)
    --> rtl8192_rx_nomal            (in r8192U_core.c)
      --> ieee80211_rx              (in ieee80211/ieee80211_rx.c)
        --> RxReorderIndicatePacket (in ieee80211/ieee80211_rx.c)

Fixes 79a5ccd97209 ("staging: rtl8192u: fix large frame size compiler warning")

Signed-off-by Christophe JAILLET <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c +1 -1

index 5c33bcb0db2ee..00e34c392a388 100644
@@ -585,7 +585,7 @@ static void RxReorderIndicatePacket(struct ieee80211_device *ieee,
 
 	prxbIndicateArray = kmalloc_array(REORDER_WIN_SIZE,
 					  sizeof(struct ieee80211_rxb *),
-					  GFP_KERNEL);
+					  GFP_ATOMIC);
 	if (!prxbIndicateArray)
 		return;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:38 UTC #117 lore raw

PATCH 117/408 drm/gma500: fix error check

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Tom Rix <[email protected]>

[ Upstream commit cdd296cdae1af2d27dae3fcfbdf12c5252ab78cf ]

Reviewing this block of code in cdv_intel_dp_init()

ret = cdv_intel_dp_aux_native_read(gma_encoder, DP_DPCD_REV, ...

cdv_intel_edp_panel_vdd_off(gma_encoder);

if (ret == 0) {
	/* if this fails, presume the device is a ghost */
	DRM_INFO("failed to retrieve link info, disabling eDP\n");
	drm_encoder_cleanup(encoder);
	cdv_intel_dp_destroy(connector);
	goto err_priv;
} else {

The (ret == 0) is not strict enough. cdv_intel_dp_aux_native_read() returns > 0 on success otherwise it is failure.

So change to <=

Fixes d112a8163f83 ("gma500/cdv: Add eDP support")

Signed-off-by Tom Rix <[email protected]>

Signed-off-by Patrik Jakobsson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/gma500/cdv_intel_dp.c +1 -1

index 570b59520fd13..2ff4b35151bf8 100644
@@ -2120,7 +2120,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct psb_intel_mode_device *mode_dev
 					       intel_dp->dpcd,
 					       sizeof(intel_dp->dpcd));
 		cdv_intel_edp_panel_vdd_off(gma_encoder);
-		if (ret == 0) {
+		if (ret <= 0) {
 			/* if this fails, presume the device is a ghost */
 			DRM_INFO("failed to retrieve link info, disabling eDP\n");
 			cdv_intel_dp_encoder_destroy(encoder);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:38 UTC #118 lore raw

PATCH 118/408 scsi: qla4xxx: Fix an error handling path in qla4xxx_get_host_stats()

From: Christophe JAILLET <[email protected]>

[ Upstream commit 574918e69720fe62ab3eb42ec3750230c8d16b06 ]

Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()'.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 4161cee52df8 ("[SCSI] qla4xxx: Add host statistics support")

Signed-off-by Christophe JAILLET <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/qla4xxx/ql4_os.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/qla4xxx/ql4_os.c +1 -1

index 5504ab11decc7..df43cf6405a8e 100644
@@ -1220,7 +1220,7 @@ static int qla4xxx_get_host_stats(struct Scsi_Host *shost, char *buf, int len)
 			le64_to_cpu(ql_iscsi_stats->iscsi_sequence_error);
 exit_host_stats:
 	if (ql_iscsi_stats)
-		dma_free_coherent(&ha->pdev->dev, host_stats_size,
+		dma_free_coherent(&ha->pdev->dev, stats_size,
 				  ql_iscsi_stats, iscsi_stats_dma);
 
 	ql4_printk(KERN_INFO, ha, "%s: Get host stats done\n",

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #119 lore raw

PATCH 119/408 scsi: qla2xxx: Fix wrong return value in qlt_chk_unresolv_exchg()

From: Tianjia Zhang <[email protected]>

[ Upstream commit bbf2d06a9d767718bfe6028d6288c03edb98554a ]

In the case of a failed retry, a positive value EIO is returned here. I think this is a typo error. It is necessary to return an error value.

[mkp: caller checks != 0 but the rest of the file uses -Exxx so fix this up to be consistent]

Link https://lore.kernel.org/r/[email protected] open here

Fixes 0691094ff3f2 ("scsi: qla2xxx: Add logic to detect ABTS hang and response completion")

Cc Quinn Tran <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/qla2xxx/qla_target.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/qla2xxx/qla_target.c +1 -1

index a7acc266cec06..d84d95cac2a13 100644
@@ -5677,7 +5677,7 @@ static int qlt_chk_unresolv_exchg(struct scsi_qla_host *vha,
 		/* found existing exchange */
 		qpair->retry_term_cnt++;
 		if (qpair->retry_term_cnt >= 5) {
-			rc = EIO;
+			rc = -EIO;
 			qpair->retry_term_cnt = 0;
 			ql_log(ql_log_warn, vha, 0xffff,
 			    "Unable to send ABTS Respond. Dumping firmware.\n");

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:36 UTC #120 lore raw

PATCH 120/408 scsi: qla2xxx: Fix wrong return value in qla_nvme_register_hba()

From: Tianjia Zhang <[email protected]>

[ Upstream commit ca4fb89a3d714a770e9c73c649da830f3f4a5326 ]

On an error exit path, a negative error code should be returned instead of a positive return value.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 8777e4314d39 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine")

Cc Quinn Tran <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/qla2xxx/qla_nvme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/qla2xxx/qla_nvme.c +1 -1

index f4815a4084d8c..11656e864fca9 100644
@@ -682,7 +682,7 @@ int qla_nvme_register_hba(struct scsi_qla_host *vha)
 	struct nvme_fc_port_template *tmpl;
 	struct qla_hw_data *ha;
 	struct nvme_fc_port_info pinfo;
-	int ret = EINVAL;
+	int ret = -EINVAL;
 
 	if (!IS_ENABLED(CONFIG_NVME_FC))
 		return ret;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #121 lore raw

PATCH 121/408 scsi: csiostor: Fix wrong return value in csio_hw_prep_fw()

From: Tianjia Zhang <[email protected]>

[ Upstream commit 44f4daf8678ae5f08c93bbe70792f90cd88e4649 ]

On an error exit path, a negative error code should be returned instead of a positive return value.

Link https://lore.kernel.org/r/[email protected] open here

Fixes f40e74ffa3de ("csiostor:firmware upgrade fix")

Cc Praveen Madhavan <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/csiostor/csio_hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/csiostor/csio_hw.c +1 -1

index e519238864758..1b6f9351b43f9 100644
@@ -2384,7 +2384,7 @@ static int csio_hw_prep_fw(struct csio_hw *hw, struct fw_info *fw_info,
 			FW_HDR_FW_VER_MICRO_G(c), FW_HDR_FW_VER_BUILD_G(c),
 			FW_HDR_FW_VER_MAJOR_G(k), FW_HDR_FW_VER_MINOR_G(k),
 			FW_HDR_FW_VER_MICRO_G(k), FW_HDR_FW_VER_BUILD_G(k));
-		ret = EINVAL;
+		ret = -EINVAL;
 		goto bye;
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:38 UTC #122 lore raw

PATCH 122/408 backlight: sky81452-backlight: Fix refcount imbalance on error

From: [email protected] <[email protected]>

[ Upstream commit b7a4f80bc316a56d6ec8750e93e66f42431ed960 ]

When of_property_read_u32_array() returns an error code, a pairing refcount decrement is needed to keep np's refcount balanced.

Fixes f705806c9f355 ("backlight: Add support Skyworks SKY81452 backlight driver")

Signed-off-by Dinghao Liu <[email protected]>

Reviewed-by Daniel Thompson <[email protected]>

Signed-off-by Lee Jones <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/video/backlight/sky81452-backlight.c | 1 +
 1 file changed, 1 insertion(+)

drivers/video/backlight/sky81452-backlight.c +1 -0

index 2355f00f57732..1f6301375fd33 100644
@@ -196,6 +196,7 @@ static struct sky81452_bl_platform_data *sky81452_bl_parse_dt(
 					num_entry);
 		if (ret < 0) {
 			dev_err(dev, "led-sources node is invalid.\n");
+			of_node_put(np);
 			return ERR_PTR(-EINVAL);
 		}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #123 lore raw

PATCH 123/408 staging: emxx_udc: Fix passing of NULL to dma_alloc_coherent()

From: Alex Dewar <[email protected]>

[ Upstream commit cc34073c6248e9cec801bf690d1455f264d12357 ]

In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(), though, strangely, NULL is passed as the struct device* argument. Pass the UDC's device instead. Fix up the corresponding call to dma_free_coherent() in the same way.

Build-tested on x86 only.

Fixes 33aa8d45a4fe ("staging: emxx_udc: Add Emma Mobile USB Gadget driver")

Reported-by Dan Carpenter <[email protected]>

Signed-off-by Alex Dewar <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/staging/emxx_udc/emxx_udc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/staging/emxx_udc/emxx_udc.c +2 -2

index 147481bf680c3..a6c893ddbf280 100644
@@ -2594,7 +2594,7 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep,
 
 	if (req->unaligned) {
 		if (!ep->virt_buf)
-			ep->virt_buf = dma_alloc_coherent(NULL, PAGE_SIZE,
+			ep->virt_buf = dma_alloc_coherent(udc->dev, PAGE_SIZE,
 							  &ep->phys_buf,
 							  GFP_ATOMIC | GFP_DMA);
 		if (ep->epnum > 0)  {

@@ -3153,7 +3153,7 @@ static int nbu2ss_drv_remove(struct platform_device *pdev)
 	for (i = 0; i < NUM_ENDPOINTS; i++) {
 		ep = &udc->ep[i];
 		if (ep->virt_buf)
-			dma_free_coherent(NULL, PAGE_SIZE, (void *)ep->virt_buf,
+			dma_free_coherent(udc->dev, PAGE_SIZE, (void *)ep->virt_buf,
 					  ep->phys_buf);
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:33 UTC #124 lore raw

PATCH 124/408 VMCI: check return value of get_user_pages_fast() for errors

From: Alex Dewar <[email protected]>

[ Upstream commit 90ca6333fd65f318c47bff425e1ea36c0a5539f6 ]

In a couple of places in qp_host_get_user_memory(), get_user_pages_fast() is called without properly checking for errors. If e.g. -EFAULT is returned, this negative value will then be passed on to qp_release_pages(), which expects a u64 as input.

Fix this by only calling qp_release_pages() when we have a positive number returned.

Fixes 06164d2b72aa ("VMCI: queue pairs implementation.")

Signed-off-by Alex Dewar <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/misc/vmw_vmci/vmci_queue_pair.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

drivers/misc/vmw_vmci/vmci_queue_pair.c +6 -4

index 8531ae7811956..c49065887e8f5 100644
@@ -657,8 +657,9 @@ static int qp_host_get_user_memory(u64 produce_uva,
 	if (retval < (int)produce_q->kernel_if->num_pages) {
 		pr_debug("get_user_pages_fast(produce) failed (retval=%d)",
 			retval);
-		qp_release_pages(produce_q->kernel_if->u.h.header_page,
-				 retval, false);
+		if (retval > 0)
+			qp_release_pages(produce_q->kernel_if->u.h.header_page,
+					retval, false);
 		err = VMCI_ERROR_NO_MEM;
 		goto out;
 	}

@@ -670,8 +671,9 @@ static int qp_host_get_user_memory(u64 produce_uva,
 	if (retval < (int)consume_q->kernel_if->num_pages) {
 		pr_debug("get_user_pages_fast(consume) failed (retval=%d)",
 			retval);
-		qp_release_pages(consume_q->kernel_if->u.h.header_page,
-				 retval, false);
+		if (retval > 0)
+			qp_release_pages(consume_q->kernel_if->u.h.header_page,
+					retval, false);
 		qp_release_pages(produce_q->kernel_if->u.h.header_page,
 				 produce_q->kernel_if->num_pages, false);
 		err = VMCI_ERROR_NO_MEM;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #125 lore raw

PATCH 125/408 mm/error_inject: Fix allow_error_inject function signatures.

Link https://lore.kernel.org/bpf/[email protected] open here

From: Alexei Starovoitov <[email protected]>

[ Upstream commit 76cd61739fd107a7f7ec4c24a045e98d8ee150f0 ]

'static' and 'static noinline' function attributes make no guarantees that gcc/clang won't optimize them. The compiler may decide to inline 'static' function and in such case ALLOW_ERROR_INJECT becomes meaningless. The compiler could have inlined __add_to_page_cache_locked() in one callsite and didn't inline in another. In such case injecting errors into it would cause unpredictable behavior. It's worse with 'static noinline' which won't be inlined, but it still can be optimized. Like the compiler may decide to remove one argument or constant propagate the value depending on the callsite.

To avoid such issues make sure that these functions are global noinline.

Fixes af3b854492f3 ("mm/page_alloc.c: allow error injection")

Fixes cfcbfb1382db ("mm/filemap.c: enable error injection at add_to_page_cache()")

Signed-off-by Alexei Starovoitov <[email protected]>

Signed-off-by Daniel Borkmann <[email protected]>

Reviewed-by Josef Bacik <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 mm/filemap.c    | 8 ++++----
 mm/page_alloc.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

mm/filemap.c +4 -4

index 51b2cb5aa5030..db542b4948838 100644
@@ -847,10 +847,10 @@ int replace_page_cache_page(struct page *old, struct page *new, gfp_t gfp_mask)
 }
 EXPORT_SYMBOL_GPL(replace_page_cache_page);
 
-static int __add_to_page_cache_locked(struct page *page,
-				      struct address_space *mapping,
-				      pgoff_t offset, gfp_t gfp_mask,
-				      void **shadowp)
+noinline int __add_to_page_cache_locked(struct page *page,
+					struct address_space *mapping,
+					pgoff_t offset, gfp_t gfp_mask,
+					void **shadowp)
 {
 	XA_STATE(xas, &mapping->i_pages, offset);
 	int huge = PageHuge(page);

mm/page_alloc.c +1 -1

index aff0bb4629bdf..2640f67410044 100644
@@ -3385,7 +3385,7 @@ static inline bool __should_fail_alloc_page(gfp_t gfp_mask, unsigned int order)
 
 #endif /* CONFIG_FAIL_PAGE_ALLOC */
 
-static noinline bool should_fail_alloc_page(gfp_t gfp_mask, unsigned int order)
+noinline bool should_fail_alloc_page(gfp_t gfp_mask, unsigned int order)
 {
 	return __should_fail_alloc_page(gfp_mask, order);
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:40 UTC #126 lore raw

PATCH 126/408 drm: panel: Fix bpc for OrtusTech COM43H4M85ULC panel

From: Laurent Pinchart <[email protected]>

[ Upstream commit 3b8095169982ff4ec2a1b4be61b7224bbef23b48 ]

The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel. Commit f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel") has fixed the bus formats, but forgot to address the bpc value. Set it to 6.

Fixes f098f168e91c ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel")

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Signed-off-by Sam Ravnborg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/panel/panel-simple.c +1 -1

index 14f5c79299cc0..f0ea782df836d 100644
@@ -2382,7 +2382,7 @@ static const struct drm_display_mode ortustech_com43h4m85ulc_mode  = {
 static const struct panel_desc ortustech_com43h4m85ulc = {
 	.modes = &ortustech_com43h4m85ulc_mode,
 	.num_modes = 1,
-	.bpc = 8,
+	.bpc = 6,
 	.size = {
 		.width = 56,
 		.height = 93,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:39 UTC #127 lore raw

PATCH 127/408 drm/crc-debugfs: Fix memleak in crc_control_write

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Dinghao Liu <[email protected]>

[ Upstream commit f7ec68b341dbd5da13d4c65ce444dcd605f1c42e ]

When verify_crc_source() fails, source needs to be freed. However, current code is returning directly and ends up leaking memory.

Fixes d5cc15a0c66e ("drm: crc: Introduce verify_crc_source callback")

Signed-off-by Dinghao Liu <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

[danvet: change Fixes: tag per Laurent's review]

Signed-off-by Daniel Vetter <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/drm_debugfs_crc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/gpu/drm/drm_debugfs_crc.c +3 -1

index 6a626c82e264b..f6598c5a9a879 100644
@@ -144,8 +144,10 @@ static ssize_t crc_control_write(struct file *file, const char __user *ubuf,
 		source[len - 1] = '\0';
 
 	ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
-	if (ret)
+	if (ret) {
+		kfree(source);
 		return ret;
+	}
 
 	spin_lock_irq(&crc->lock);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:39 UTC #128 lore raw

PATCH 128/408 binder: Remove bogus warning on failed same-process transaction

From: Jann Horn <[email protected]>

[ Upstream commit e8b8ae7ce32e17a5c29f0289e9e2a39c7dcaa1b8 ]

While binder transactions with the same binder_proc as sender and recipient are forbidden, transactions with the same task_struct as sender and recipient are possible (even though currently there is a weird check in binder_transaction() that rejects them in the target==0 case). Therefore, task_struct identities can't be used to distinguish whether the caller is running in the context of the sender or the recipient.

Since I see no easy way to make this WARN_ON() useful and correct, let's just remove it.

Fixes 44d8047f1d87 ("binder: use standard functions to allocate fds")

Reported-by [email protected]

Acked-by Christian Brauner <[email protected]>

Acked-by Todd Kjos <[email protected]>

Signed-off-by Jann Horn <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/android/binder.c | 2 --
 1 file changed, 2 deletions(-)

drivers/android/binder.c +0 -2

index 0f56a82615389..b62b1ab6bb699 100644
@@ -2326,8 +2326,6 @@ static void binder_transaction_buffer_release(struct binder_proc *proc,
 			 * file is done when the transaction is torn
 			 * down.
 			 */
-			WARN_ON(failed_at &&
-				proc->tsk == current->group_leader);
 		} break;
 		case BINDER_TYPE_PTR:
 			/*

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:34 UTC #129 lore raw

PATCH 129/408 tty: serial: earlycon dependency

From: Tong Zhang <[email protected]>

[ Upstream commit 0fb9342d06b0f667b915ba58bfefc030e534a218 ]

parse_options() in drivers/tty/serial/earlycon.c calls uart_parse_earlycon in drivers/tty/serial/serial_core.c therefore selecting SERIAL_EARLYCON should automatically select SERIAL_CORE, otherwise will result in symbol not found error during linking if SERIAL_CORE is not configured as builtin

Fixes 9aac5887595b ("tty/serial: add generic serial earlycon")

Signed-off-by Tong Zhang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/tty/serial/Kconfig | 1 +
 1 file changed, 1 insertion(+)

drivers/tty/serial/Kconfig +1 -0

index 67a9eb3f94cec..a9751a83d5dbb 100644
@@ -10,6 +10,7 @@ menu "Serial drivers"
 
 config SERIAL_EARLYCON
 	bool
+	depends on SERIAL_CORE
 	help
 	  Support for early consoles with the earlycon parameter. This enables
 	  the console before standard serial driver is probed. The console is

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:39 UTC #130 lore raw

PATCH 130/408 tty: hvcs: Dont NULL tty->driver_data until hvcs_cleanup()

From: Tyrel Datwyler <[email protected]>

[ Upstream commit 63ffcbdad738e3d1c857027789a2273df3337624 ]

The code currently NULLs tty->driver_data in hvcs_close() with the intent of informing the next call to hvcs_open() that device needs to be reconfigured. However, when hvcs_cleanup() is called we copy hvcsd from tty->driver_data which was previoulsy NULLed by hvcs_close() and our call to tty_port_put(&hvcsd->port) doesn't actually do anything since &hvcsd->port ends up translating to NULL by chance. This has the side effect that when hvcs_remove() is called we have one too many port references preventing hvcs_destuct_port() from ever being called. This also prevents us from reusing the /dev/hvcsX node in a future hvcs_probe() and we can eventually run out of /dev/hvcsX devices.

Fix this by waiting to NULL tty->driver_data in hvcs_cleanup().

Fixes 27bf7c43a19c ("TTY: hvcs, add tty install")

Signed-off-by Tyrel Datwyler <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/tty/hvc/hvcs.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

drivers/tty/hvc/hvcs.c +7 -7

index ee0604cd9c6b2..0c498b20d8cb5 100644
@@ -1218,13 +1218,6 @@ static void hvcs_close(struct tty_struct *tty, struct file *filp)
 
 		tty_wait_until_sent(tty, HVCS_CLOSE_WAIT);
 
-		/*
-		 * This line is important because it tells hvcs_open that this
-		 * device needs to be re-configured the next time hvcs_open is
-		 * called.
-		 */
-		tty->driver_data = NULL;
-
 		free_irq(irq, hvcsd);
 		return;
 	} else if (hvcsd->port.count < 0) {

@@ -1239,6 +1232,13 @@ static void hvcs_cleanup(struct tty_struct * tty)
 {
 	struct hvcs_struct *hvcsd = tty->driver_data;
 
+	/*
+	 * This line is important because it tells hvcs_open that this
+	 * device needs to be re-configured the next time hvcs_open is
+	 * called.
+	 */
+	tty->driver_data = NULL;
+
 	tty_port_put(&hvcsd->port);
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #131 lore raw

PATCH 131/408 pty: do tty_flip_buffer_push without port->lock in pty_write

From: Artem Savkov <[email protected]>

[ Upstream commit 71a174b39f10b4b93223d374722aa894b5d8a82e ]

b6da31b2c07c "tty: Fix data race in tty_insert_flip_string_fixed_flag" puts tty_flip_buffer_push under port->lock introducing the following possible circular locking dependency:

[30129.876566] ======================================================
[30129.876566] WARNING: possible circular locking dependency detected
[30129.876567] 5.9.0-rc2+ #3 Tainted: G S      W
[30129.876568] ------------------------------------------------------
[30129.876568] sysrq.sh/1222 is trying to acquire lock:
[30129.876569] ffffffff92c39480 (console_owner){....}-{0:0}, at: console_unlock+0x3fe/0xa90

[30129.876572] but task is already holding lock:
[30129.876572] ffff888107cb9018 (&pool->lock/1){-.-.}-{2:2}, at: show_workqueue_state.cold.55+0x15b/0x6ca

[30129.876576] which lock already depends on the new lock.

[30129.876577] the existing dependency chain (in reverse order) is:

[30129.876578] -> #3 (&pool->lock/1){-.-.}-{2:2}:
[30129.876581]        _raw_spin_lock+0x30/0x70
[30129.876581]        __queue_work+0x1a3/0x10f0
[30129.876582]        queue_work_on+0x78/0x80
[30129.876582]        pty_write+0x165/0x1e0
[30129.876583]        n_tty_write+0x47f/0xf00
[30129.876583]        tty_write+0x3d6/0x8d0
[30129.876584]        vfs_write+0x1a8/0x650

[30129.876588] -> #2 (&port->lock#2){-.-.}-{2:2}:
[30129.876590]        _raw_spin_lock_irqsave+0x3b/0x80
[30129.876591]        tty_port_tty_get+0x1d/0xb0
[30129.876592]        tty_port_default_wakeup+0xb/0x30
[30129.876592]        serial8250_tx_chars+0x3d6/0x970
[30129.876593]        serial8250_handle_irq.part.12+0x216/0x380
[30129.876593]        serial8250_default_handle_irq+0x82/0xe0
[30129.876594]        serial8250_interrupt+0xdd/0x1b0
[30129.876595]        __handle_irq_event_percpu+0xfc/0x850

[30129.876602] -> #1 (&port->lock){-.-.}-{2:2}:
[30129.876605]        _raw_spin_lock_irqsave+0x3b/0x80
[30129.876605]        serial8250_console_write+0x12d/0x900
[30129.876606]        console_unlock+0x679/0xa90
[30129.876606]        register_console+0x371/0x6e0
[30129.876607]        univ8250_console_init+0x24/0x27
[30129.876607]        console_init+0x2f9/0x45e

[30129.876609] -> #0 (console_owner){....}-{0:0}:
[30129.876611]        __lock_acquire+0x2f70/0x4e90
[30129.876612]        lock_acquire+0x1ac/0xad0
[30129.876612]        console_unlock+0x460/0xa90
[30129.876613]        vprintk_emit+0x130/0x420
[30129.876613]        printk+0x9f/0xc5
[30129.876614]        show_pwq+0x154/0x618
[30129.876615]        show_workqueue_state.cold.55+0x193/0x6ca
[30129.876615]        __handle_sysrq+0x244/0x460
[30129.876616]        write_sysrq_trigger+0x48/0x4a
[30129.876616]        proc_reg_write+0x1a6/0x240
[30129.876617]        vfs_write+0x1a8/0x650

[30129.876619] other info that might help us debug this:

[30129.876620] Chain exists of:
[30129.876621]   console_owner --> &port->lock#2 --> &pool->lock/1

[30129.876625]  Possible unsafe locking scenario:

[30129.876626]        CPU0                    CPU1
[30129.876626]        ----                    ----
[30129.876627]   lock(&pool->lock/1);
[30129.876628]                                lock(&port->lock#2);
[30129.876630]                                lock(&pool->lock/1);
[30129.876631]   lock(console_owner);

[30129.876633]  *** DEADLOCK ***

[30129.876634] 5 locks held by sysrq.sh/1222:
[30129.876634]  #0: ffff8881d3ce0470 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x359/0x650
[30129.876637]  #1: ffffffff92c612c0 (rcu_read_lock){....}-{1:2}, at: __handle_sysrq+0x4d/0x460
[30129.876640]  #2: ffffffff92c612c0 (rcu_read_lock){....}-{1:2}, at: show_workqueue_state+0x5/0xf0
[30129.876642]  #3: ffff888107cb9018 (&pool->lock/1){-.-.}-{2:2}, at: show_workqueue_state.cold.55+0x15b/0x6ca
[30129.876645]  #4: ffffffff92c39980 (console_lock){+.+.}-{0:0}, at: vprintk_emit+0x123/0x420

[30129.876648] stack backtrace:
[30129.876649] CPU: 3 PID: 1222 Comm: sysrq.sh Tainted: G S      W         5.9.0-rc2+ #3
[30129.876649] Hardware name: Intel Corporation 2012 Client Platform/Emerald Lake 2, BIOS ACRVMBY1.86C.0078.P00.1201161002 01/16/2012
[30129.876650] Call Trace:
[30129.876650]  dump_stack+0x9d/0xe0
[30129.876651]  check_noncircular+0x34f/0x410
[30129.876653]  __lock_acquire+0x2f70/0x4e90
[30129.876656]  lock_acquire+0x1ac/0xad0
[30129.876658]  console_unlock+0x460/0xa90
[30129.876660]  vprintk_emit+0x130/0x420
[30129.876660]  printk+0x9f/0xc5
[30129.876661]  show_pwq+0x154/0x618
[30129.876662]  show_workqueue_state.cold.55+0x193/0x6ca
[30129.876664]  __handle_sysrq+0x244/0x460
[30129.876665]  write_sysrq_trigger+0x48/0x4a
[30129.876665]  proc_reg_write+0x1a6/0x240
[30129.876666]  vfs_write+0x1a8/0x650

It looks like the commit was aimed to protect tty_insert_flip_string and there is no need for tty_flip_buffer_push to be under this lock.

Fixes b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag")

Signed-off-by Artem Savkov <[email protected]>

Acked-by Jiri Slaby <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/tty/pty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/tty/pty.c +1 -1

index 00099a8439d21..c6a1d8c4e6894 100644
@@ -120,10 +120,10 @@ static int pty_write(struct tty_struct *tty, const unsigned char *buf, int c)
 		spin_lock_irqsave(&to->port->lock, flags);
 		/* Stuff the data into the input queue of the other end */
 		c = tty_insert_flip_string(to->port, buf, c);
+		spin_unlock_irqrestore(&to->port->lock, flags);
 		/* And shovel */
 		if (c)
 			tty_flip_buffer_push(to->port);
-		spin_unlock_irqrestore(&to->port->lock, flags);
 	}
 	return c;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:39 UTC #132 lore raw

PATCH 132/408 pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()

From: Hans de Goede <[email protected]>

[ Upstream commit 181f4d2f44463fe09fe4df02e03095cb87151c29 ]

According to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency.

So assuming e.g. a 16 bit counter this means that if base_unit is set to 1, after 65535 input clock-cycles the counter has been increased from 0 to 65535 and it will overflow on the next cycle, so it will overflow after every 65536 clock cycles and thus the calculations done in pwm_lpss_prepare() should use 65536 and not 65535.

This commit fixes this. Note this also aligns the calculations in pwm_lpss_prepare() with those in pwm_lpss_get_state().

Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit"). The next patch in this series really fixes the potential overflow of the base_unit value.

Fixes 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Acked-by Uwe Kleine-König <[email protected]>

Acked-by Thierry Reding <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pwm/pwm-lpss.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/pwm/pwm-lpss.c +3 -3

index 75bbfe5f3bc29..16f32576b320c 100644
@@ -93,7 +93,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm,
 	 * The equation is:
 	 * base_unit = round(base_unit_range * freq / c)
 	 */
-	base_unit_range = BIT(lpwm->info->base_unit_bits) - 1;
+	base_unit_range = BIT(lpwm->info->base_unit_bits);
 	freq *= base_unit_range;
 
 	base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);

@@ -104,8 +104,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm,
 
 	orig_ctrl = ctrl = pwm_lpss_read(pwm);
 	ctrl &= ~PWM_ON_TIME_DIV_MASK;
-	ctrl &= ~(base_unit_range << PWM_BASE_UNIT_SHIFT);
-	base_unit &= base_unit_range;
+	ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
+	base_unit &= (base_unit_range - 1);
 	ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
 	ctrl |= on_time_div;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:39 UTC #133 lore raw

PATCH 133/408 pwm: lpss: Add range limit check for the base_unit register value

From: Hans de Goede <[email protected]>

[ Upstream commit ef9f60daab309558c8bb3e086a9a11ee40bd6061 ]

When the user requests a high enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value of 0.

But according to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. Adding 0 to the counter is a no-op. The data-sheet even explicitly states that writing 0 to the base_unit bits will result in the PWM outputting a continuous 0 signal.

When the user requestes a low enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value which is bigger then base_unit_range - 1. Currently the codes for this deals with this by applying a mask:

	base_unit &= (base_unit_range - 1);

But this means that we let the value overflow the range, we throw away the higher bits and store whatever value is left in the lower bits into the register leading to a random output frequency, rather then clamping the output frequency to the highest frequency which the hardware can do.

This commit fixes both issues by clamping the base_unit value to be between 1 and (base_unit_range - 1).

Fixes 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Acked-by Thierry Reding <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pwm/pwm-lpss.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/pwm/pwm-lpss.c +2 -1

index 16f32576b320c..d77cec2769b76 100644
@@ -97,6 +97,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm,
 	freq *= base_unit_range;
 
 	base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
+	/* base_unit must not be 0 and we also want to avoid overflowing it */
+	base_unit = clamp_val(base_unit, 1, base_unit_range - 1);
 
 	on_time_div = 255ULL * duty_ns;
 	do_div(on_time_div, period_ns);

@@ -105,7 +107,6 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, struct pwm_device *pwm,
 	orig_ctrl = ctrl = pwm_lpss_read(pwm);
 	ctrl &= ~PWM_ON_TIME_DIV_MASK;
 	ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
-	base_unit &= (base_unit_range - 1);
 	ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
 	ctrl |= on_time_div;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:34 UTC #134 lore raw

PATCH 134/408 drivers/virt/fsl_hypervisor: Fix error handling path

From: Souptick Joarder <[email protected]>

[ Upstream commit 7f360bec37857bfd5a48cef21d86f58a09a3df63 ]

First, when memory allocation for sg_list_unaligned failed, there is a bug of calling put_pages() as we haven't pinned any pages.

Second, if get_user_pages_fast() failed we should unpin num_pinned pages.

This will address both.

As part of these changes, minor update in documentation.

Fixes 6db7199407ca ("drivers/virt: introduce Freescale hypervisor management driver")

Signed-off-by Souptick Joarder <[email protected]>

Reviewed-by Dan Carpenter <[email protected]>

Reviewed-by John Hubbard <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/virt/fsl_hypervisor.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

drivers/virt/fsl_hypervisor.c +8 -9

index 93d5bebf9572a..fb292f9cf29df 100644
@@ -157,7 +157,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)
 
 	unsigned int i;
 	long ret = 0;
-	int num_pinned; /* return value from get_user_pages() */
+	int num_pinned = 0; /* return value from get_user_pages_fast() */
 	phys_addr_t remote_paddr; /* The next address in the remote buffer */
 	uint32_t count; /* The number of bytes left to copy */

@@ -174,7 +174,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)
 		return -EINVAL;
 
 	/*
-	 * The array of pages returned by get_user_pages() covers only
+	 * The array of pages returned by get_user_pages_fast() covers only
 	 * page-aligned memory.  Since the user buffer is probably not
 	 * page-aligned, we need to handle the discrepancy.
 	 *

@@ -224,7 +224,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)
 
 	/*
 	 * 'pages' is an array of struct page pointers that's initialized by
-	 * get_user_pages().
+	 * get_user_pages_fast().
 	 */
 	pages = kcalloc(num_pages, sizeof(struct page *), GFP_KERNEL);
 	if (!pages) {

@@ -241,7 +241,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)
 	if (!sg_list_unaligned) {
 		pr_debug("fsl-hv: could not allocate S/G list\n");
 		ret = -ENOMEM;
-		goto exit;
+		goto free_pages;
 	}
 	sg_list = PTR_ALIGN(sg_list_unaligned, sizeof(struct fh_sg_list));

@@ -250,7 +250,6 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)
 		num_pages, param.source != -1 ? FOLL_WRITE : 0, pages);
 
 	if (num_pinned != num_pages) {
-		/* get_user_pages() failed */
 		pr_debug("fsl-hv: could not lock source buffer\n");
 		ret = (num_pinned < 0) ? num_pinned : -EFAULT;
 		goto exit;

@@ -292,13 +291,13 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user *p)
 		virt_to_phys(sg_list), num_pages);
 
 exit:
-	if (pages) {
-		for (i = 0; i < num_pages; i++)
-			if (pages[i])
-				put_page(pages[i]);
+	if (pages && (num_pinned > 0)) {
+		for (i = 0; i < num_pinned; i++)
+			put_page(pages[i]);
 	}
 
 	kfree(sg_list_unaligned);
+free_pages:
 	kfree(pages);
 
 	if (!ret)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:38 UTC #135 lore raw

PATCH 135/408 video: fbdev: vga16fb: fix setting of pixclock because a pass-by-value error

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Colin Ian King <[email protected]>

[ Upstream commit c72fab81ceaa54408b827a2f0486d9a0f4be34cf ]

The pixclock is being set locally because it is being passed as a pass-by-value argument rather than pass-by-reference, so the computed pixclock is never being set in var->pixclock. Fix this by passing by reference.

[This dates back to 2002, I found the offending commit from the git history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git ]

Addresses-Coverity: ("Unused value")

Signed-off-by Colin Ian King <[email protected]>

Cc Daniel Vetter <[email protected]>

Cc Jani Nikula <[email protected]>

[b.zolnierkie: minor patch summary fixup]

[b.zolnierkie: removed "Fixes:" tag (not in upstream tree)]

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/video/fbdev/vga16fb.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

drivers/video/fbdev/vga16fb.c +7 -7

index 4b83109202b1c..3c4d20618de4c 100644
@@ -243,7 +243,7 @@ static void vga16fb_update_fix(struct fb_info *info)
 }
 
 static void vga16fb_clock_chip(struct vga16fb_par *par,
-			       unsigned int pixclock,
+			       unsigned int *pixclock,
 			       const struct fb_info *info,
 			       int mul, int div)
 {

@@ -259,14 +259,14 @@ static void vga16fb_clock_chip(struct vga16fb_par *par,
 		{     0 /* bad */,    0x00, 0x00}};
 	int err;
 
-	pixclock = (pixclock * mul) / div;
+	*pixclock = (*pixclock * mul) / div;
 	best = vgaclocks;
-	err = pixclock - best->pixclock;
+	err = *pixclock - best->pixclock;
 	if (err < 0) err = -err;
 	for (ptr = vgaclocks + 1; ptr->pixclock; ptr++) {
 		int tmp;
 
-		tmp = pixclock - ptr->pixclock;
+		tmp = *pixclock - ptr->pixclock;
 		if (tmp < 0) tmp = -tmp;
 		if (tmp < err) {
 			err = tmp;

@@ -275,7 +275,7 @@ static void vga16fb_clock_chip(struct vga16fb_par *par,
 	}
 	par->misc |= best->misc;
 	par->clkdiv = best->seq_clock_mode;
-	pixclock = (best->pixclock * div) / mul;		
+	*pixclock = (best->pixclock * div) / mul;
 }
 			       
 #define FAIL(X) return -EINVAL

@@ -497,10 +497,10 @@ static int vga16fb_check_var(struct fb_var_screeninfo *var,
 
 	if (mode & MODE_8BPP)
 		/* pixel clock == vga clock / 2 */
-		vga16fb_clock_chip(par, var->pixclock, info, 1, 2);
+		vga16fb_clock_chip(par, &var->pixclock, info, 1, 2);
 	else
 		/* pixel clock == vga clock */
-		vga16fb_clock_chip(par, var->pixclock, info, 1, 1);
+		vga16fb_clock_chip(par, &var->pixclock, info, 1, 1);
 	
 	var->red.offset = var->green.offset = var->blue.offset = 
 	var->transp.offset = 0;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:38 UTC #136 lore raw

PATCH 136/408 video: fbdev: sis: fix null ptr dereference

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Tom Rix <[email protected]>

[ Upstream commit ad6f93e9cd56f0b10e9b22e3e137d17a1a035242 ]

Clang static analysis reports this representative error

init.c:2501:18: warning: Array access (from variable 'queuedata') results
in a null pointer dereference

      templ |= ((queuedata[i] & 0xc0) << 3);

This is the problem block of code

   if(ModeNo > 0x13) {
      ...
      if(SiS_Pr->ChipType == SIS_730) {
	 queuedata = &FQBQData730[0];
      } else {
	 queuedata = &FQBQData[0];
      }

} else {

queuedata is not set in the else block

Reviewing the old code, the arrays FQBQData730 and FQBQData were used directly.

So hoist the setting of queuedata out of the if-else block.

Fixes 544393fe584d ("[PATCH] sisfb update")

Signed-off-by Tom Rix <[email protected]>

Cc Thomas Winischhofer <[email protected]>

Cc Andrew Morton <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/video/fbdev/sis/init.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

drivers/video/fbdev/sis/init.c +5 -6

index dfe3eb769638b..fde27feae5d0c 100644
@@ -2428,6 +2428,11 @@ SiS_SetCRT1FIFO_630(struct SiS_Private *SiS_Pr, unsigned short ModeNo,
 
    i = 0;
 
+	if (SiS_Pr->ChipType == SIS_730)
+		queuedata = &FQBQData730[0];
+	else
+		queuedata = &FQBQData[0];
+
    if(ModeNo > 0x13) {
 
       /* Get VCLK  */

@@ -2445,12 +2450,6 @@ SiS_SetCRT1FIFO_630(struct SiS_Private *SiS_Pr, unsigned short ModeNo,
       /* Get half colordepth */
       colorth = colortharray[(SiS_Pr->SiS_ModeType - ModeEGA)];
 
-      if(SiS_Pr->ChipType == SIS_730) {
-	 queuedata = &FQBQData730[0];
-      } else {
-	 queuedata = &FQBQData[0];
-      }
-
       do {
 	 templ = SiS_CalcDelay2(SiS_Pr, queuedata[i]) * VCLK * colorth;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:34 UTC #137 lore raw

PATCH 137/408 video: fbdev: radeon: Fix memleak in radeonfb_pci_register

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Dinghao Liu <[email protected]>

[ Upstream commit fe6c6a4af2be8c15bac77f7ea160f947c04840d1 ]

When radeon_kick_out_firmware_fb() fails, info should be freed just like the subsequent error paths.

Fixes 069ee21a82344 ("fbdev: Fix loading of module radeonfb on PowerMac")

Signed-off-by Dinghao Liu <[email protected]>

Reviewed-by Mathieu Malaterre <[email protected]>

Cc Kangjie Lu <[email protected]>

Cc Benjamin Herrenschmidt <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/video/fbdev/aty/radeon_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/video/fbdev/aty/radeon_base.c +1 -1

index 4ca07866f2f66..5dda824d0da3f 100644
@@ -2323,7 +2323,7 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
 
 	ret = radeon_kick_out_firmware_fb(pdev);
 	if (ret)
-		return ret;
+		goto err_release_fb;
 
 	/* request the mem regions */
 	ret = pci_request_region(pdev, 0, "radeonfb framebuffer");

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:38 UTC #138 lore raw

PATCH 138/408 ASoC: fsl: imx-es8328: add missing put_device() call in imx_es8328_probe()

From: Yu Kuai <[email protected]>

[ Upstream commit e525db7e4b44c5b2b5aac0dad24e23cb58c54d22 ]

if of_find_device_by_node() succeed, imx_es8328_probe() doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation.

Fixes 7e7292dba215 ("ASoC: fsl: add imx-es8328 machine driver")

Signed-off-by Yu Kuai <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/soc/fsl/imx-es8328.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

sound/soc/fsl/imx-es8328.c +7 -5

index 15a27a2cd0cae..fad1eb6253d53 100644
@@ -145,13 +145,13 @@ static int imx_es8328_probe(struct platform_device *pdev)
 	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
 	if (!data) {
 		ret = -ENOMEM;
-		goto fail;
+		goto put_device;
 	}
 
 	comp = devm_kzalloc(dev, 3 * sizeof(*comp), GFP_KERNEL);
 	if (!comp) {
 		ret = -ENOMEM;
-		goto fail;
+		goto put_device;
 	}
 
 	data->dev = dev;

@@ -182,12 +182,12 @@ static int imx_es8328_probe(struct platform_device *pdev)
 	ret = snd_soc_of_parse_card_name(&data->card, "model");
 	if (ret) {
 		dev_err(dev, "Unable to parse card name\n");
-		goto fail;
+		goto put_device;
 	}
 	ret = snd_soc_of_parse_audio_routing(&data->card, "audio-routing");
 	if (ret) {
 		dev_err(dev, "Unable to parse routing: %d\n", ret);
-		goto fail;
+		goto put_device;
 	}
 	data->card.num_links = 1;
 	data->card.owner = THIS_MODULE;

@@ -196,10 +196,12 @@ static int imx_es8328_probe(struct platform_device *pdev)
 	ret = snd_soc_register_card(&data->card);
 	if (ret) {
 		dev_err(dev, "Unable to register: %d\n", ret);
-		goto fail;
+		goto put_device;
 	}
 
 	platform_set_drvdata(pdev, data);
+put_device:
+	put_device(&ssi_pdev->dev);
 fail:
 	of_node_put(ssi_np);
 	of_node_put(codec_np);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #139 lore raw

PATCH 139/408 HID: roccat: add bounds checking in kone_sysfs_write_settings()

From: Dan Carpenter <[email protected]>

[ Upstream commit d4f98dbfe717490e771b6e701904bfcf4b4557f0 ]

This code doesn't check if "settings->startup_profile" is within bounds and that could result in an out of bounds array access. What the code does do is it checks if the settings can be written to the firmware, so it's possible that the firmware has a bounds check? It's safer and easier to verify when the bounds checking is done in the kernel.

Fixes 14bf62cde794 ("HID: add driver for Roccat Kone gaming mouse")

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hid/hid-roccat-kone.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

drivers/hid/hid-roccat-kone.c +16 -7

index 1a6e600197d0b..509b9bb1362cb 100644
@@ -294,31 +294,40 @@ static ssize_t kone_sysfs_write_settings(struct file *fp, struct kobject *kobj,
 	struct kone_device *kone = hid_get_drvdata(dev_get_drvdata(dev));
 	struct usb_device *usb_dev = interface_to_usbdev(to_usb_interface(dev));
 	int retval = 0, difference, old_profile;
+	struct kone_settings *settings = (struct kone_settings *)buf;
 
 	/* I need to get my data in one piece */
 	if (off != 0 || count != sizeof(struct kone_settings))
 		return -EINVAL;
 
 	mutex_lock(&kone->kone_lock);
-	difference = memcmp(buf, &kone->settings, sizeof(struct kone_settings));
+	difference = memcmp(settings, &kone->settings,
+			    sizeof(struct kone_settings));
 	if (difference) {
-		retval = kone_set_settings(usb_dev,
-				(struct kone_settings const *)buf);
-		if (retval) {
-			mutex_unlock(&kone->kone_lock);
-			return retval;
+		if (settings->startup_profile < 1 ||
+		    settings->startup_profile > 5) {
+			retval = -EINVAL;
+			goto unlock;
 		}
 
+		retval = kone_set_settings(usb_dev, settings);
+		if (retval)
+			goto unlock;
+
 		old_profile = kone->settings.startup_profile;
-		memcpy(&kone->settings, buf, sizeof(struct kone_settings));
+		memcpy(&kone->settings, settings, sizeof(struct kone_settings));
 
 		kone_profile_activated(kone, kone->settings.startup_profile);
 
 		if (kone->settings.startup_profile != old_profile)
 			kone_profile_report(kone, kone->settings.startup_profile);
 	}
+unlock:
 	mutex_unlock(&kone->kone_lock);
 
+	if (retval)
+		return retval;
+
 	return sizeof(struct kone_settings);
 }
 static BIN_ATTR(settings, 0660, kone_sysfs_read_settings,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:34 UTC #140 lore raw

PATCH 140/408 drm/msm: Avoid div-by-zero in dpu_crtc_atomic_check()

From: Stephen Boyd <[email protected]>

[ Upstream commit 22f760941844dbcee6ee446e1896532f6dff01ef ]

The cstate->num_mixers member is only set to a non-zero value once dpu_encoder_virt_mode_set() is called, but the atomic check function can be called by userspace before that. Let's avoid the div-by-zero here and inside _dpu_crtc_setup_lm_bounds() by skipping this part of the atomic check if dpu_encoder_virt_mode_set() hasn't been called yet. This fixes an UBSAN warning:

 UBSAN: Undefined behaviour in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:860:31
 division by zero
 CPU: 7 PID: 409 Comm: frecon Tainted: G S                5.4.31 #128
 Hardware name: Google Trogdor (rev0) (DT)
 Call trace:
  dump_backtrace+0x0/0x14c
  show_stack+0x20/0x2c
  dump_stack+0xa0/0xd8
  __ubsan_handle_divrem_overflow+0xec/0x110
  dpu_crtc_atomic_check+0x97c/0x9d4
  drm_atomic_helper_check_planes+0x160/0x1c8
  drm_atomic_helper_check+0x54/0xbc
  drm_atomic_check_only+0x6a8/0x880
  drm_atomic_commit+0x20/0x5c
  drm_atomic_helper_set_config+0x98/0xa0
  drm_mode_setcrtc+0x308/0x5dc
  drm_ioctl_kernel+0x9c/0x114
  drm_ioctl+0x2ac/0x4b0
  drm_compat_ioctl+0xe8/0x13c
  __arm64_compat_sys_ioctl+0x184/0x324
  el0_svc_common+0xa4/0x154
  el0_svc_compat_handler+0x

Cc Abhinav Kumar <[email protected]>

Cc Jeykumar Sankaran <[email protected]>

Cc Jordan Crouse <[email protected]>

Cc Sean Paul <[email protected]>

Fixes 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")

Signed-off-by Stephen Boyd <[email protected]>

Reviewed-by Abhinav Kumar <[email protected]>

Tested-by Sai Prakash Ranjan <[email protected]>

Signed-off-by Rob Clark <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c +5 -3

index 36c85c05b7cf7..4aed5e9a84a45 100644
@@ -819,7 +819,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
 	struct drm_plane *plane;
 	struct drm_display_mode *mode;
 
-	int cnt = 0, rc = 0, mixer_width, i, z_pos;
+	int cnt = 0, rc = 0, mixer_width = 0, i, z_pos;
 
 	struct dpu_multirect_plane_states multirect_plane[DPU_STAGE_MAX * 2];
 	int multirect_count = 0;

@@ -852,9 +852,11 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
 
 	memset(pipe_staged, 0, sizeof(pipe_staged));
 
-	mixer_width = mode->hdisplay / cstate->num_mixers;
+	if (cstate->num_mixers) {
+		mixer_width = mode->hdisplay / cstate->num_mixers;
 
-	_dpu_crtc_setup_lm_bounds(crtc, state);
+		_dpu_crtc_setup_lm_bounds(crtc, state);
+	}
 
 	crtc_rect.x2 = mode->hdisplay;
 	crtc_rect.y2 = mode->vdisplay;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:38 UTC #141 lore raw

PATCH 141/408 drm/panfrost: Ensure GPU quirks are always initialised

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Steven Price <[email protected]>

[ Upstream commit 8c3c818c23a5bbce6ff180dd2ee04415241df77c ]

The GPU 'CONFIG' registers used to work around hardware issues are cleared on reset so need to be programmed every time the GPU is reset. However panfrost_device_reset() failed to do this.

To avoid this in future instead move the call to panfrost_gpu_init_quirks() to panfrost_gpu_power_on() so that the regsiters are always programmed just before the cores are powered.

Fixes f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")

Signed-off-by Steven Price <[email protected]>

Reviewed-by Alyssa Rosenzweig <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/panfrost/panfrost_gpu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/gpu/drm/panfrost/panfrost_gpu.c +2 -1

index 8822ec13a0d61..1431db13ec788 100644
@@ -304,6 +304,8 @@ void panfrost_gpu_power_on(struct panfrost_device *pfdev)
 	int ret;
 	u32 val;
 
+	panfrost_gpu_init_quirks(pfdev);
+
 	/* Just turn on everything for now */
 	gpu_write(pfdev, L2_PWRON_LO, pfdev->features.l2_present);
 	ret = readl_relaxed_poll_timeout(pfdev->iomem + L2_READY_LO,

@@ -357,7 +359,6 @@ int panfrost_gpu_init(struct panfrost_device *pfdev)
 		return err;
 	}
 
-	panfrost_gpu_init_quirks(pfdev);
 	panfrost_gpu_power_on(pfdev);
 
 	return 0;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:34 UTC #142 lore raw

PATCH 142/408 iomap: Clear page error before beginning a write

From: Matthew Wilcox (Oracle) <[email protected]>

[ Upstream commit e6e7ca92623a43156100306861272e04d46385fc ]

If we find a page in write_begin which is !Uptodate, we need to clear any error on the page before starting to read data into it. This matches how filemap_fault(), do_read_cache_page() and generic_file_buffered_read() handle PageError on !Uptodate pages. When calling iomap_set_range_uptodate() in __iomap_write_begin(), blocks were not being marked as uptodate.

This was found with generic/127 and a specially modified kernel which would fail (some) readahead I/Os. The test read some bytes in a prior page which caused readahead to extend into page 0x34. There was a subsequent write to page 0x34, followed by a read to page 0x34. Because the blocks were still marked as !Uptodate, the read caused all blocks to be re-read, overwriting the write. With this change, and the next one, the bytes which were written are marked as being Uptodate, so even though the page is still marked as !Uptodate, the blocks containing the written data are not re-read from storage.

Fixes 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads")

Signed-off-by Matthew Wilcox (Oracle) <[email protected]>

Reviewed-by Darrick J. Wong <[email protected]>

Signed-off-by Darrick J. Wong <[email protected]>

Reviewed-by Christoph Hellwig <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/iomap/buffered-io.c | 1 +
 1 file changed, 1 insertion(+)

fs/iomap/buffered-io.c +1 -0

index a30ea7ecb790a..80867a1a94f26 100644
@@ -559,6 +559,7 @@ __iomap_write_begin(struct inode *inode, loff_t pos, unsigned len,
 
 	if (PageUptodate(page))
 		return 0;
+	ClearPageError(page);
 
 	do {
 		iomap_adjust_read_range(inode, iop, &block_start,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #143 lore raw

PATCH 143/408 pinctrl: mcp23s08: Fix mcp23x17_regmap initialiser

From: Thomas Preston <[email protected]>

[ Upstream commit b445f6237744df5e8d4f56f8733b2108c611220a ]

The mcp23x17_regmap is initialised with structs named "mcp23x16". However, the mcp23s08 driver doesn't support the MCP23016 device yet, so this appears to be a typo.

Fixes 8f38910ba4f6 ("pinctrl: mcp23s08: switch to regmap caching")

Signed-off-by Thomas Preston <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pinctrl/pinctrl-mcp23s08.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

drivers/pinctrl/pinctrl-mcp23s08.c +11 ~~-11~~

index 3a235487e38d7..676ff9a4459e3 100644
@@ -122,7 +122,7 @@ static const struct regmap_config mcp23x08_regmap = {
 	.max_register = MCP_OLAT,
 };
 
-static const struct reg_default mcp23x16_defaults[] = {
+static const struct reg_default mcp23x17_defaults[] = {
 	{.reg = MCP_IODIR << 1,		.def = 0xffff},
 	{.reg = MCP_IPOL << 1,		.def = 0x0000},
 	{.reg = MCP_GPINTEN << 1,	.def = 0x0000},

@@ -133,23 +133,23 @@ static const struct reg_default mcp23x16_defaults[] = {
 	{.reg = MCP_OLAT << 1,		.def = 0x0000},
 };
 
-static const struct regmap_range mcp23x16_volatile_range = {
+static const struct regmap_range mcp23x17_volatile_range = {
 	.range_min = MCP_INTF << 1,
 	.range_max = MCP_GPIO << 1,
 };
 
-static const struct regmap_access_table mcp23x16_volatile_table = {
-	.yes_ranges = &mcp23x16_volatile_range,
+static const struct regmap_access_table mcp23x17_volatile_table = {
+	.yes_ranges = &mcp23x17_volatile_range,
 	.n_yes_ranges = 1,
 };
 
-static const struct regmap_range mcp23x16_precious_range = {
+static const struct regmap_range mcp23x17_precious_range = {
 	.range_min = MCP_GPIO << 1,
 	.range_max = MCP_GPIO << 1,
 };
 
-static const struct regmap_access_table mcp23x16_precious_table = {
-	.yes_ranges = &mcp23x16_precious_range,
+static const struct regmap_access_table mcp23x17_precious_table = {
+	.yes_ranges = &mcp23x17_precious_range,
 	.n_yes_ranges = 1,
 };

@@ -159,10 +159,10 @@ static const struct regmap_config mcp23x17_regmap = {
 
 	.reg_stride = 2,
 	.max_register = MCP_OLAT << 1,
-	.volatile_table = &mcp23x16_volatile_table,
-	.precious_table = &mcp23x16_precious_table,
-	.reg_defaults = mcp23x16_defaults,
-	.num_reg_defaults = ARRAY_SIZE(mcp23x16_defaults),
+	.volatile_table = &mcp23x17_volatile_table,
+	.precious_table = &mcp23x17_precious_table,
+	.reg_defaults = mcp23x17_defaults,
+	.num_reg_defaults = ARRAY_SIZE(mcp23x17_defaults),
 	.cache_type = REGCACHE_FLAT,
 	.val_format_endian = REGMAP_ENDIAN_LITTLE,
 };

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:38 UTC #144 lore raw

PATCH 144/408 pinctrl: mcp23s08: Fix mcp23x17 precious range

[0] https://ww1.microchip.com/downloads/en/DeviceDoc/20001952C.pdf

From: Thomas Preston <[email protected]>

[ Upstream commit b9b7fb29433b906635231d0a111224efa009198c ]

On page 23 of the datasheet [0] it says "The register remains unchanged until the interrupt is cleared via a read of INTCAP or GPIO." Include INTCAPA and INTCAPB registers in precious range, so that they aren't accidentally cleared when we read via debugfs.

Fixes 8f38910ba4f6 ("pinctrl: mcp23s08: switch to regmap caching")

Signed-off-by Thomas Preston <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/pinctrl/pinctrl-mcp23s08.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/pinctrl/pinctrl-mcp23s08.c +1 -1

index 676ff9a4459e3..d8bcbefcba890 100644
@@ -144,7 +144,7 @@ static const struct regmap_access_table mcp23x17_volatile_table = {
 };
 
 static const struct regmap_range mcp23x17_precious_range = {
-	.range_min = MCP_GPIO << 1,
+	.range_min = MCP_INTCAP << 1,
 	.range_max = MCP_GPIO << 1,
 };

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #145 lore raw

PATCH 145/408 net/mlx5: Dont call timecounter cyc2time directly from 1PPS flow

From: Eran Ben Elisha <[email protected]>

[ Upstream commit 0d2ffdc8d4002a62de31ff7aa3bef28c843c3cbe ]

Before calling timecounter_cyc2time(), clock->lock must be taken. Use mlx5_timecounter_cyc2time instead which guarantees a safe access.

Fixes afc98a0b46d8 ("net/mlx5: Update ptp_clock_event foreach PPS event")

Signed-off-by Eran Ben Elisha <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c +3 -2

index 75fc283cacc36..492ff2ef9a404 100644
@@ -498,8 +498,9 @@ static int mlx5_pps_event(struct notifier_block *nb,
 	switch (clock->ptp_info.pin_config[pin].func) {
 	case PTP_PF_EXTTS:
 		ptp_event.index = pin;
-		ptp_event.timestamp = timecounter_cyc2time(&clock->tc,
-					be64_to_cpu(eqe->data.pps.time_stamp));
+		ptp_event.timestamp =
+			mlx5_timecounter_cyc2time(clock,
+						  be64_to_cpu(eqe->data.pps.time_stamp));
 		if (clock->pps_info.enabled) {
 			ptp_event.type = PTP_CLOCK_PPSUSR;
 			ptp_event.pps_times.ts_real =

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:35 UTC #146 lore raw

PATCH 146/408 scsi: mpt3sas: Fix sync irqs

From: Tomas Henzl <[email protected]>

[ Upstream commit 45181eab8ba79ed7a41b549f00500c0093828521 ]

_base_process_reply_queue() called from _base_interrupt() may schedule a new irq poll. Fix this by calling synchronize_irq() first.

Also ensure that enable_irq() is called only when necessary to avoid "Unbalanced enable for IRQ..." errors.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 320e77acb327 ("scsi: mpt3sas: Irq poll to avoid CPU hard lockups")

Acked-by Sreekanth Reddy <[email protected]>

Signed-off-by Tomas Henzl <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

drivers/scsi/mpt3sas/mpt3sas_base.c +9 -5

index b7e44634d0dc2..3d58d24de6b61 100644
@@ -1708,18 +1708,22 @@ mpt3sas_base_sync_reply_irqs(struct MPT3SAS_ADAPTER *ioc)
 		/* TMs are on msix_index == 0 */
 		if (reply_q->msix_index == 0)
 			continue;
+		synchronize_irq(pci_irq_vector(ioc->pdev, reply_q->msix_index));
 		if (reply_q->irq_poll_scheduled) {
 			/* Calling irq_poll_disable will wait for any pending
 			 * callbacks to have completed.
 			 */
 			irq_poll_disable(&reply_q->irqpoll);
 			irq_poll_enable(&reply_q->irqpoll);
-			reply_q->irq_poll_scheduled = false;
-			reply_q->irq_line_enable = true;
-			enable_irq(reply_q->os_irq);
-			continue;
+			/* check how the scheduled poll has ended,
+			 * clean up only if necessary
+			 */
+			if (reply_q->irq_poll_scheduled) {
+				reply_q->irq_poll_scheduled = false;
+				reply_q->irq_line_enable = true;
+				enable_irq(reply_q->os_irq);
+			}
 		}
-		synchronize_irq(pci_irq_vector(ioc->pdev, reply_q->msix_index));
 	}
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:37 UTC #147 lore raw

PATCH 147/408 net: stmmac: use netif_tx_start|stop_all_queues() function

From: Ong Boon Leong <[email protected]>

[ Upstream commit 9f19306d166688a73356aa636c62e698bf2063cc ]

The current implementation of stmmac_stop_all_queues() and stmmac_start_all_queues() will not work correctly when the value of tx_queues_to_use is changed through ethtool -L DEVNAME rx N tx M command.

Also, netif_tx_start|stop_all_queues() are only needed in driver open() and close() only.

Fixes c22a3f48 net: stmmac: adding multiple napi mechanism

Signed-off-by Ong Boon Leong <[email protected]>

Signed-off-by Voon Weifeng <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 33 +------------------
 1 file changed, 1 insertion(+), 32 deletions(-)

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +1 ~~-32~~

index 982be75fde833..189cdb7633671 100644
@@ -175,32 +175,6 @@ static void stmmac_enable_all_queues(struct stmmac_priv *priv)
 	}
 }
 
-/**
- * stmmac_stop_all_queues - Stop all queues
- * @priv: driver private structure
- */
-static void stmmac_stop_all_queues(struct stmmac_priv *priv)
-{
-	u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
-	u32 queue;
-
-	for (queue = 0; queue < tx_queues_cnt; queue++)
-		netif_tx_stop_queue(netdev_get_tx_queue(priv->dev, queue));
-}
-
-/**
- * stmmac_start_all_queues - Start all queues
- * @priv: driver private structure
- */
-static void stmmac_start_all_queues(struct stmmac_priv *priv)
-{
-	u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
-	u32 queue;
-
-	for (queue = 0; queue < tx_queues_cnt; queue++)
-		netif_tx_start_queue(netdev_get_tx_queue(priv->dev, queue));
-}
-
 static void stmmac_service_event_schedule(struct stmmac_priv *priv)
 {
 	if (!test_bit(STMMAC_DOWN, &priv->state) &&

@@ -2737,7 +2711,7 @@ static int stmmac_open(struct net_device *dev)
 	}
 
 	stmmac_enable_all_queues(priv);
-	stmmac_start_all_queues(priv);
+	netif_tx_start_all_queues(priv->dev);
 
 	return 0;

@@ -2778,8 +2752,6 @@ static int stmmac_release(struct net_device *dev)
 	phylink_stop(priv->phylink);
 	phylink_disconnect_phy(priv->phylink);
 
-	stmmac_stop_all_queues(priv);
-
 	stmmac_disable_all_queues(priv);
 
 	for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++)

@@ -4770,7 +4742,6 @@ int stmmac_suspend(struct device *dev)
 	mutex_lock(&priv->lock);
 
 	netif_device_detach(ndev);
-	stmmac_stop_all_queues(priv);
 
 	stmmac_disable_all_queues(priv);

@@ -4883,8 +4854,6 @@ int stmmac_resume(struct device *dev)
 
 	stmmac_enable_all_queues(priv);
 
-	stmmac_start_all_queues(priv);
-
 	mutex_unlock(&priv->lock);
 
 	if (!device_may_wakeup(priv->device)) {

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:37 UTC #148 lore raw

PATCH 148/408 cpufreq: armada-37xx: Add missing MODULE_DEVICE_TABLE

From: Pali Rohár <[email protected]>

[ Upstream commit c942d1542f1bc5001216fabce9cb8ffbe515777e ]

CONFIG_ARM_ARMADA_37XX_CPUFREQ is tristate option and therefore this cpufreq driver can be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE which generates correct modalias for automatic loading of this cpufreq driver when is compiled as an external module.

Reviewed-by Andrew Lunn <[email protected]>

Signed-off-by Pali Rohár <[email protected]>

Fixes 92ce45fb875d7 ("cpufreq: Add DVFS support for Armada 37xx")

[ Viresh: Added __maybe_unused ]

Signed-off-by Viresh Kumar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/cpufreq/armada-37xx-cpufreq.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/cpufreq/armada-37xx-cpufreq.c +6 -0

index df1c941260d14..b4af4094309b0 100644
@@ -484,6 +484,12 @@ static int __init armada37xx_cpufreq_driver_init(void)
 /* late_initcall, to guarantee the driver is loaded after A37xx clock driver */
 late_initcall(armada37xx_cpufreq_driver_init);
 
+static const struct of_device_id __maybe_unused armada37xx_cpufreq_of_match[] = {
+	{ .compatible = "marvell,armada-3700-nb-pm" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, armada37xx_cpufreq_of_match);
+
 MODULE_AUTHOR("Gregory CLEMENT <[email protected]>");
 MODULE_DESCRIPTION("Armada 37xx cpufreq driver");
 MODULE_LICENSE("GPL");

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:36 UTC #149 lore raw

PATCH 149/408 drm: mxsfb: check framebuffer pitch

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Stefan Agner <[email protected]>

[ Upstream commit d5a0c816900419105a12e7471bf074319dfa34be ]

The lcdif IP does not support a framebuffer pitch (stride) other than framebuffer width. Check for equality and reject the framebuffer otherwise.

This prevents a distorted picture when using 640x800 and running the Mesa graphics stack. Mesa tries to use a cache aligned stride, which leads at that particular resolution to width != stride. Currently Mesa has no fallback behavior, but rejecting this configuration allows userspace to handle the issue correctly.

Fixes 45d59d704080 ("drm: Add new driver for MXSFB controller")

Signed-off-by Stefan Agner <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

drivers/gpu/drm/mxsfb/mxsfb_drv.c +20 -1

index e8506335cd155..1694a7deb9133 100644
@@ -26,6 +26,7 @@
 #include <drm/drm_drv.h>
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_fb_helper.h>
+#include <drm/drm_fourcc.h>
 #include <drm/drm_gem_cma_helper.h>
 #include <drm/drm_gem_framebuffer_helper.h>
 #include <drm/drm_irq.h>

@@ -87,8 +88,26 @@ void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
 		clk_disable_unprepare(mxsfb->clk_axi);
 }
 
+static struct drm_framebuffer *
+mxsfb_fb_create(struct drm_device *dev, struct drm_file *file_priv,
+		const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+	const struct drm_format_info *info;
+
+	info = drm_get_format_info(dev, mode_cmd);
+	if (!info)
+		return ERR_PTR(-EINVAL);
+
+	if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
+		dev_dbg(dev->dev, "Invalid pitch: fb width must match pitch\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	return drm_gem_fb_create(dev, file_priv, mode_cmd);
+}
+
 static const struct drm_mode_config_funcs mxsfb_mode_config_funcs = {
-	.fb_create		= drm_gem_fb_create,
+	.fb_create		= mxsfb_fb_create,
 	.atomic_check		= drm_atomic_helper_check,
 	.atomic_commit		= drm_atomic_helper_commit,
 };

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:36 UTC #150 lore raw

PATCH 150/408 coresight: etm4x: Handle unreachable sink in perf mode

From: Suzuki K Poulose <[email protected]>

[ Upstream commit 859d510e58dac94f0b204b7b5cccafbc130d2291 ]

If the specified/hinted sink is not reachable from a subset of the CPUs, we could end up unable to trace the event on those CPUs. This is the best effort we could do until we support 1:1 configurations. Fail gracefully in such cases avoiding a WARN_ON, which can be easily triggered by the user on certain platforms (Arm N1SDP), with the following trace paths :

CPU0

      \
       -- Funnel0 --> ETF0 -->
      /                        \
 CPU1                           \
                                  MainFunnel
 CPU2                           /
      \                        /
       -- Funnel1 --> ETF1 -->
      /

CPU1

$ perf record --per-thread -e cs_etm/@ETF0/u -- <app>

could trigger the following WARNING, when the event is scheduled on CPU2.

[10919.513250] ------------[ cut here ]------------
[10919.517861] WARNING: CPU: 2 PID: 24021 at

drivers/hwtracing/coresight/coresight-etm-perf.c:316 etm_event_start+0xf8/0x100
...

[10919.564403] CPU: 2 PID: 24021 Comm: perf Not tainted 5.8.0+ #24
[10919.570308] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--)
[10919.575865] pc : etm_event_start+0xf8/0x100
[10919.580034] lr : etm_event_start+0x80/0x100
[10919.584202] sp : fffffe001932f940
[10919.587502] x29: fffffe001932f940 x28: fffffc834995f800
[10919.592799] x27: 0000000000000000 x26: fffffe0011f3ced0
[10919.598095] x25: fffffc837fce244c x24: fffffc837fce2448
[10919.603391] x23: 0000000000000002 x22: fffffc8353529c00
[10919.608688] x21: fffffc835bb31000 x20: 0000000000000000
[10919.613984] x19: fffffc837fcdcc70 x18: 0000000000000000
[10919.619281] x17: 0000000000000000 x16: 0000000000000000
[10919.624577] x15: 0000000000000000 x14: 00000000000009f8
[10919.629874] x13: 00000000000009f8 x12: 0000000000000018
[10919.635170] x11: 0000000000000000 x10: 0000000000000000
[10919.640467] x9 : fffffe00108cd168 x8 : 0000000000000000
[10919.645763] x7 : 0000000000000020 x6 : 0000000000000001
[10919.651059] x5 : 0000000000000002 x4 : 0000000000000001
[10919.656356] x3 : 0000000000000000 x2 : 0000000000000000
[10919.661652] x1 : fffffe836eb40000 x0 : 0000000000000000
[10919.666949] Call trace:
[10919.669382]  etm_event_start+0xf8/0x100
[10919.673203]  etm_event_add+0x40/0x60
[10919.676765]  event_sched_in.isra.134+0xcc/0x210
[10919.681281]  merge_sched_in+0xb0/0x2a8
[10919.685017]  visit_groups_merge.constprop.140+0x15c/0x4b8
[10919.690400]  ctx_sched_in+0x15c/0x170
[10919.694048]  perf_event_sched_in+0x6c/0xa0
[10919.698130]  ctx_resched+0x60/0xa0
[10919.701517]  perf_event_exec+0x288/0x2f0
[10919.705425]  begin_new_exec+0x4c8/0xf58
[10919.709247]  load_elf_binary+0x66c/0xf30
[10919.713155]  exec_binprm+0x15c/0x450
[10919.716716]  __do_execve_file+0x508/0x748
[10919.720711]  __arm64_sys_execve+0x40/0x50
[10919.724707]  do_el0_svc+0xf4/0x1b8
[10919.728095]  el0_sync_handler+0xf8/0x124
[10919.732003]  el0_sync+0x140/0x180

Even though we don't support using separate sinks for the ETMs yet (e.g, for 1:1 configurations), we should at least honor the user's choice and handle the limitations gracefully, by simply skipping the tracing on ETMs which can't reach the requested sink.

Fixes f9d81a657bb8 ("coresight: perf: Allow tracing on hotplugged CPUs")

Cc Mathieu Poirier <[email protected]>

Cc Mike Leach <[email protected]>

Reported-by Jeremy Linton <[email protected]>

Tested-by Jeremy Linton <[email protected]>

Signed-off-by Suzuki K Poulose <[email protected]>

Signed-off-by Mathieu Poirier <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

drivers/hwtracing/coresight/coresight-etm-perf.c +10 -0

index 84f1dcb698272..c4b9898e28418 100644
@@ -310,6 +310,16 @@ static void etm_event_start(struct perf_event *event, int flags)
 	if (!event_data)
 		goto fail;
 
+	/*
+	 * Check if this ETM is allowed to trace, as decided
+	 * at etm_setup_aux(). This could be due to an unreachable
+	 * sink from this ETM. We can't do much in this case if
+	 * the sink was specified or hinted to the driver. For
+	 * now, simply don't record anything on this ETM.
+	 */
+	if (!cpumask_test_cpu(cpu, &event_data->mask))
+		goto fail_end_stop;
+
 	path = etm_event_cpu_path(event_data, cpu);
 	/* We need a sink, no need to continue without one */
 	sink = coresight_get_sink(path);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:36 UTC #151 lore raw

PATCH 151/408 xhci: dont create endpoint debugfs entry before ring buffer is set.

From: Mathias Nyman <[email protected]>

[ Upstream commit 167657a1bb5fcde53ac304ce6c564bd90a2f9185 ]

Make sure xHC completes the configure endpoint command and xhci driver sets the ring pointers correctly before we create the user readable debugfs file.

In theory there was a small gap where a user could have read the debugfs file and cause a NULL pointer dereference error as ring pointer was not yet set, in practise we want this change to simplify the upcoming streams debugfs support.

Fixes 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver")

Signed-off-by Mathias Nyman <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/host/xhci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/usb/host/xhci.c +1 -2

index bad154f446f8d..0d10ede581cbd 100644
@@ -1915,8 +1915,6 @@ static int xhci_add_endpoint(struct usb_hcd *hcd, struct usb_device *udev,
 	ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
 	trace_xhci_add_endpoint(ep_ctx);
 
-	xhci_debugfs_create_endpoint(xhci, virt_dev, ep_index);
-
 	xhci_dbg(xhci, "add ep 0x%x, slot id %d, new drop flags = %#x, new add flags = %#x\n",
 			(unsigned int) ep->desc.bEndpointAddress,
 			udev->slot_id,

@@ -2949,6 +2947,7 @@ static int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
 		xhci_check_bw_drop_ep_streams(xhci, virt_dev, i);
 		virt_dev->eps[i].ring = virt_dev->eps[i].new_ring;
 		virt_dev->eps[i].new_ring = NULL;
+		xhci_debugfs_create_endpoint(xhci, virt_dev, i);
 	}
 command_cleanup:
 	kfree(command->completion);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:31 UTC #152 lore raw

PATCH 152/408 net: dsa: rtl8366: Check validity of passed VLANs

From: Linus Walleij <[email protected]>

[ Upstream commit 6641a2c42b0a307b7638d10e5d4b90debc61389d ]

The rtl8366_set_vlan() and rtl8366_set_pvid() get invalid VLANs tossed at it, especially VLAN0, something the hardware and driver cannot handle. Check validity and bail out like we do in the other callbacks.

Reviewed-by Florian Fainelli <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/dsa/rtl8366.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/net/dsa/rtl8366.c +6 -0

index 99cdb2f18fa2f..a62d76a048dfa 100644
@@ -43,6 +43,9 @@ int rtl8366_set_vlan(struct realtek_smi *smi, int vid, u32 member,
 	int ret;
 	int i;
 
+	if (!smi->ops->is_vlan_valid(smi, vid))
+		return -EINVAL;
+
 	dev_dbg(smi->dev,
 		"setting VLAN%d 4k members: 0x%02x, untagged: 0x%02x\n",
 		vid, member, untag);

@@ -118,6 +121,9 @@ int rtl8366_set_pvid(struct realtek_smi *smi, unsigned int port,
 	int ret;
 	int i;
 
+	if (!smi->ops->is_vlan_valid(smi, vid))
+		return -EINVAL;
+
 	/* Try to find an existing MC entry for this VID */
 	for (i = 0; i < smi->num_vlan_mc; i++) {
 		ret = smi->ops->get_vlan_mc(smi, i, &vlanmc);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:36 UTC #153 lore raw

PATCH 153/408 net: dsa: rtl8366: Refactor VLAN/PVID init

From: Linus Walleij <[email protected]>

[ Upstream commit 7e1301ed1881447d2a25f9c6423738c33cbca133 ]

The VLANs and PVIDs on the RTL8366 utilizes a "member configuration" (MC) which is largely unexplained in the code.

This set-up requires a special ordering: rtl8366_set_pvid() must be called first, followed by rtl8366_set_vlan(), else the MC will not be properly allocated. Relax this by factoring out the code obtaining an MC and reuse the helper in both rtl8366_set_pvid() and rtl8366_set_vlan() so we remove this strict ordering requirement.

In the process, add some better comments and debug prints so people who read the code understand what is going on.

Reviewed-by Florian Fainelli <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/dsa/realtek-smi-core.h |   4 +-
 drivers/net/dsa/rtl8366.c          | 273 +++++++++++++++--------------
 2 files changed, 146 insertions(+), 131 deletions(-)

drivers/net/dsa/realtek-smi-core.h +3 -1

index 9a63b51e1d82f..6f2dab7e33d65 100644
@@ -25,6 +25,9 @@ struct rtl8366_mib_counter {
 	const char	*name;
 };
 
+/**
+ * struct rtl8366_vlan_mc - Virtual LAN member configuration
+ */
 struct rtl8366_vlan_mc {
 	u16	vid;
 	u16	untag;

@@ -119,7 +122,6 @@ int realtek_smi_setup_mdio(struct realtek_smi *smi);
 int rtl8366_mc_is_used(struct realtek_smi *smi, int mc_index, int *used);
 int rtl8366_set_vlan(struct realtek_smi *smi, int vid, u32 member,
 		     u32 untag, u32 fid);
-int rtl8366_get_pvid(struct realtek_smi *smi, int port, int *val);
 int rtl8366_set_pvid(struct realtek_smi *smi, unsigned int port,
 		     unsigned int vid);
 int rtl8366_enable_vlan4k(struct realtek_smi *smi, bool enable);

drivers/net/dsa/rtl8366.c +143 ~~-130~~

332 lines not on this page · raw message

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:35 UTC #154 lore raw

PATCH 154/408 net: dsa: rtl8366: Skip PVID setting if not requested

From: Linus Walleij <[email protected]>

[ Upstream commit 3dfe8dde093a07e82fa472c0f8c29a7f6a2006a5 ]

We go to lengths to determine whether the PVID should be set for this port or not, and then fail to take it into account. Fix this oversight.

Fixes d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver")

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/dsa/rtl8366.c | 3 +++
 1 file changed, 3 insertions(+)

drivers/net/dsa/rtl8366.c +3 -0

index b941d45edd641..49c626a336803 100644
@@ -436,6 +436,9 @@ void rtl8366_vlan_add(struct dsa_switch *ds, int port,
 				"failed to set up VLAN %04x",
 				vid);
 
+		if (!pvid)
+			continue;
+
 		ret = rtl8366_set_pvid(smi, port, vid);
 		if (ret)
 			dev_err(smi->dev,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:35 UTC #155 lore raw

PATCH 155/408 net: wilc1000: clean up resource in error path of init mon interface

From: Huang Guobin <[email protected]>

[ Upstream commit 55bd149978679742374c800e56e8f6bc74378bbe ]

The wilc_wfi_init_mon_int() forgets to clean up resource when register_netdevice() failed. Add the missed call to fix it. And the return value of netdev_priv can't be NULL, so remove the unnecessary error handling.

Fixes 588713006ea4 ("staging: wilc1000: avoid the use of 'wilc_wfi_mon' static variable")

Reported-by Hulk Robot <[email protected]>

Signed-off-by Huang Guobin <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/staging/wilc1000/wilc_mon.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/staging/wilc1000/wilc_mon.c +1 -2

index d6f14f69ad64e..017e8e91334f1 100644
@@ -236,11 +236,10 @@ struct net_device *wilc_wfi_init_mon_interface(struct wilc *wl,
 
 	if (register_netdevice(wl->monitor_dev)) {
 		netdev_err(real_dev, "register_netdevice failed\n");
+		free_netdev(wl->monitor_dev);
 		return NULL;
 	}
 	priv = netdev_priv(wl->monitor_dev);
-	if (!priv)
-		return NULL;
 
 	priv->real_ndev = real_dev;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:37 UTC #156 lore raw

PATCH 156/408 ASoC: tlv320aic32x4: Fix bdiv clock rate derivation

From: Miquel Raynal <[email protected]>

[ Upstream commit 40b37136287ba6b34aa2f1f6123f3d6d205dc2f0 ]

Current code expects a single channel to be always used. Fix this situation by forwarding the number of channels used. Then fix the derivation of the bdiv clock rate.

Fixes 96c3bb00239d ("ASoC: tlv320aic32x4: Dynamically Determine Clocking")

Signed-off-by Miquel Raynal <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/soc/codecs/tlv320aic32x4.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

sound/soc/codecs/tlv320aic32x4.c +6 -3

index 68165de1c8dea..7a1ffbaf48be5 100644
@@ -662,7 +662,7 @@ static int aic32x4_set_processing_blocks(struct snd_soc_component *component,
 }
 
 static int aic32x4_setup_clocks(struct snd_soc_component *component,
-				unsigned int sample_rate)
+				unsigned int sample_rate, unsigned int channels)
 {
 	u8 aosr;
 	u16 dosr;

@@ -750,7 +750,9 @@ static int aic32x4_setup_clocks(struct snd_soc_component *component,
 							dosr);
 
 						clk_set_rate(clocks[5].clk,
-							sample_rate * 32);
+							sample_rate * 32 *
+							channels);
+
 						return 0;
 					}
 				}

@@ -772,7 +774,8 @@ static int aic32x4_hw_params(struct snd_pcm_substream *substream,
 	u8 iface1_reg = 0;
 	u8 dacsetup_reg = 0;
 
-	aic32x4_setup_clocks(component, params_rate(params));
+	aic32x4_setup_clocks(component, params_rate(params),
+			     params_channels(params));
 
 	switch (params_width(params)) {
 	case 16:

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #157 lore raw

PATCH 157/408 net: dsa: rtl8366rb: Support all 4096 VLANs

From: Linus Walleij <[email protected]>

[ Upstream commit a7920efdd86d8a0d74402dbc80ead03b023294ba ]

There is an off-by-one error in rtl8366rb_is_vlan_valid() making VLANs 0..4094 valid while it should be 1..4095. Fix it.

Fixes d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver")

Reviewed-by Florian Fainelli <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/dsa/rtl8366rb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/dsa/rtl8366rb.c +1 -1

index f5cc8b0a7c74c..7f731bf369980 100644
@@ -1269,7 +1269,7 @@ static bool rtl8366rb_is_vlan_valid(struct realtek_smi *smi, unsigned int vlan)
 	if (smi->vlan4k_enabled)
 		max = RTL8366RB_NUM_VIDS - 1;
 
-	if (vlan == 0 || vlan >= max)
+	if (vlan == 0 || vlan > max)
 		return false;
 
 	return true;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #158 lore raw

PATCH 158/408 spi: omap2-mcspi: Improve performance waiting for CHSTAT

From: Aswath Govindraju <[email protected]>

[ Upstream commit 7b1d96813317358312440d0d07abbfbeb0ef8d22 ]

This reverts commit 13d515c796 (spi: omap2-mcspi: Switch to readl_poll_timeout()).

The amount of time spent polling for the MCSPI_CHSTAT bits to be set on AM335x-icev2 platform is less than 1us (about 0.6us) in most cases, with or without using DMA. So, in most cases the function need not sleep. Also, setting the sleep_usecs to zero would not be optimal here because ktime_add_us() used in readl_poll_timeout() is slower compared to the direct addition used after the revert. So, it is sub-optimal to use readl_poll_timeout in this case.

When DMA is not enabled, this revert results in an increase of about 27% in throughput and decrease of about 20% in CPU usage. However, the CPU usage and throughput are almost the same when used with DMA.

Therefore, fix this by reverting the commit which switched to using readl_poll_timeout().

Fixes 13d515c796ad ("spi: omap2-mcspi: Switch to readl_poll_timeout()")

Signed-off-by Aswath Govindraju <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/spi/spi-omap2-mcspi.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

drivers/spi/spi-omap2-mcspi.c +13 -4

index 4433cb4de564e..7646b4b56bed9 100644
@@ -24,7 +24,6 @@
 #include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/gcd.h>
-#include <linux/iopoll.h>
 
 #include <linux/spi/spi.h>
 #include <linux/gpio.h>

@@ -348,9 +347,19 @@ static void omap2_mcspi_set_fifo(const struct spi_device *spi,
 
 static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
 {
-	u32 val;
-
-	return readl_poll_timeout(reg, val, val & bit, 1, MSEC_PER_SEC);
+	unsigned long timeout;
+
+	timeout = jiffies + msecs_to_jiffies(1000);
+	while (!(readl_relaxed(reg) & bit)) {
+		if (time_after(jiffies, timeout)) {
+			if (!(readl_relaxed(reg) & bit))
+				return -ETIMEDOUT;
+			else
+				return 0;
+		}
+		cpu_relax();
+	}
+	return 0;
 }
 
 static int mcspi_wait_for_completion(struct  omap2_mcspi *mcspi,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #159 lore raw

PATCH 159/408 ath6kl: wmi: prevent a shift wrapping bug in ath6kl_wmi_delete_pstream_cmd()

From: Dan Carpenter <[email protected]>

[ Upstream commit 6a950755cec1a90ddaaff3e4acb5333617441c32 ]

The "tsid" is a user controlled u8 which comes from debugfs. Values more than 15 are invalid because "active_tsids" is a 16 bit variable. If the value of "tsid" is more than 31 then that leads to a shift wrapping bug.

Fixes 8fffd9e5ec9e ("ath6kl: Implement support for QOS-enable and QOS-disable from userspace")

Link https://lore.kernel.org/r/20200918142732.GA909725@mwanda open here

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wireless/ath/ath6kl/wmi.c | 5 +++++
 1 file changed, 5 insertions(+)

drivers/net/wireless/ath/ath6kl/wmi.c +5 -0

index 2382c6c46851e..c610fe21c85c0 100644
@@ -2645,6 +2645,11 @@ int ath6kl_wmi_delete_pstream_cmd(struct wmi *wmi, u8 if_idx, u8 traffic_class,
 		return -EINVAL;
 	}
 
+	if (tsid >= 16) {
+		ath6kl_err("invalid tsid: %d\n", tsid);
+		return -EINVAL;
+	}
+
 	skb = ath6kl_wmi_get_new_buf(sizeof(*cmd));
 	if (!skb)
 		return -ENOMEM;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:37 UTC #160 lore raw

PATCH 160/408 dmaengine: dmatest: Check list for emptiness before access its last entry

From: Andy Shevchenko <[email protected]>

[ Upstream commit b28de385b71abf31ce68ec0387638bee26ae9024 ]

After writing a garbage to the channel we get an Oops in dmatest_chan_set() due to access to last entry in the empty list.

[  212.670672] BUG: unable to handle page fault for address: fffffff000000020
[  212.677562] #PF: supervisor read access in kernel mode
[  212.682702] #PF: error_code(0x0000) - not-present page
...
[  212.710074] RIP: 0010:dmatest_chan_set+0x149/0x2d0 [dmatest]
[  212.715739] Code: e8 cc f9 ff ff 48 8b 1d 0d 55 00 00 48 83 7b 10 00 0f 84 63 01 00 00 48 c7 c7 d0 65 4d c0 e8 ee 4a f5 e1 48 89 c6 48 8b 43 10 <48> 8b 40 20 48 8b 78 58 48 85 ff 0f 84 f5 00 00 00 e8 b1 41 f5 e1

Fix this by checking list for emptiness before accessing its last entry.

Fixes d53513d5dc28 ("dmaengine: dmatest: Add support for multi channel testing")

Cc Vladimir Murzin <[email protected]>

Signed-off-by Andy Shevchenko <[email protected]>

Tested-by Peter Ujfalusi <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/dma/dmatest.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

drivers/dma/dmatest.c +2 -3

index 62d9825a49e9d..238936e2dfe2d 100644
@@ -1218,15 +1218,14 @@ static int dmatest_chan_set(const char *val, const struct kernel_param *kp)
 	add_threaded_test(info);
 
 	/* Check if channel was added successfully */
-	dtc = list_last_entry(&info->channels, struct dmatest_chan, node);
-
-	if (dtc->chan) {
+	if (!list_empty(&info->channels)) {
 		/*
 		 * if new channel was not successfully added, revert the
 		 * "test_channel" string to the name of the last successfully
 		 * added channel. exception for when users issues empty string
 		 * to channel parameter.
 		 */
+		dtc = list_last_entry(&info->channels, struct dmatest_chan, node);
 		if ((strcmp(dma_chan_name(dtc->chan), strim(test_channel)) != 0)
 		    && (strcmp("", strim(test_channel)) != 0)) {
 			ret = -EINVAL;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:37 UTC #161 lore raw

PATCH 161/408 misc: mic: scif: Fix error handling path

From: Souptick Joarder <[email protected]>

[ Upstream commit a81072a9c0ae734b7889929b0bc070fe3f353f0e ]

Inside __scif_pin_pages(), when map_flags != SCIF_MAP_KERNEL it will call pin_user_pages_fast() to map nr_pages. However, pin_user_pages_fast() might fail with a return value -ERRNO.

The return value is stored in pinned_pages->nr_pages. which in turn is passed to unpin_user_pages(), which expects pinned_pages->nr_pages >=0, else disaster.

Fix this by assigning pinned_pages->nr_pages to 0 if pin_user_pages_fast() returns -ERRNO.

Fixes ba612aa8b487 ("misc: mic: SCIF memory registration and unregistration")

Cc John Hubbard <[email protected]>

Cc Ira Weiny <[email protected]>

Cc Dan Carpenter <[email protected]>

Reviewed-by John Hubbard <[email protected]>

Signed-off-by Souptick Joarder <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/misc/mic/scif/scif_rma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/misc/mic/scif/scif_rma.c +2 -2

index 01e27682ea303..a486c6c7f4077 100644
@@ -1381,6 +1381,8 @@ int __scif_pin_pages(void *addr, size_t len, int *out_prot,
 				(prot & SCIF_PROT_WRITE) ? FOLL_WRITE : 0,
 				pinned_pages->pages);
 		if (nr_pages != pinned_pages->nr_pages) {
+			if (pinned_pages->nr_pages < 0)
+				pinned_pages->nr_pages = 0;
 			if (try_upgrade) {
 				if (ulimit)
 					__scif_dec_pinned_vm_lock(mm, nr_pages);

@@ -1400,7 +1402,6 @@ int __scif_pin_pages(void *addr, size_t len, int *out_prot,
 
 	if (pinned_pages->nr_pages < nr_pages) {
 		err = -EFAULT;
-		pinned_pages->nr_pages = nr_pages;
 		goto dec_pinned;
 	}

@@ -1413,7 +1414,6 @@ int __scif_pin_pages(void *addr, size_t len, int *out_prot,
 		__scif_dec_pinned_vm_lock(mm, nr_pages);
 	/* Something went wrong! Rollback */
 error_unmap:
-	pinned_pages->nr_pages = nr_pages;
 	scif_destroy_pinned_pages(pinned_pages);
 	*pages = NULL;
 	dev_dbg(scif_info.mdev.this_device,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 17:37 UTC #162 lore raw

PATCH 162/408 ALSA: seq: oss: Avoid mutex lock for a long-time ioctl

From: Takashi Iwai <[email protected]>

[ Upstream commit 2759caad2600d503c3b0ed800e7e03d2cd7a4c05 ]

Recently we applied a fix to cover the whole OSS sequencer ioctls with the mutex for dealing with the possible races. This works fine in general, but in theory, this may lead to unexpectedly long stall if an ioctl like SNDCTL_SEQ_SYNC is issued and an event with the far future timestamp was queued.

For fixing such a potential stall, this patch changes the mutex lock applied conditionally excluding such an ioctl command. Also, change the mutex_lock() with the interruptible version for user to allow escaping from the big-hammer mutex.

Fixes 80982c7e834e ("ALSA: seq: oss: Serialize ioctls")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 sound/core/seq/oss/seq_oss.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

sound/core/seq/oss/seq_oss.c +5 -2

index c8b9c0b315d8f..250a92b187265 100644
@@ -174,9 +174,12 @@ odev_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 	if (snd_BUG_ON(!dp))
 		return -ENXIO;
 
-	mutex_lock(&register_mutex);
+	if (cmd != SNDCTL_SEQ_SYNC &&
+	    mutex_lock_interruptible(&register_mutex))
+		return -ERESTARTSYS;
 	rc = snd_seq_oss_ioctl(dp, cmd, arg);
-	mutex_unlock(&register_mutex);
+	if (cmd != SNDCTL_SEQ_SYNC)
+		mutex_unlock(&register_mutex);
 	return rc;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #163 lore raw

PATCH 163/408 usb: dwc2: Fix parameter type in function pointer prototype

Link https://github.com/ClangBuiltLinux/linux/issues/1107

From: Nathan Chancellor <[email protected]>

[ Upstream commit 362b9398c962c9ec563653444e15ef9032ef3a90 ]

When booting up on a Raspberry Pi 4 with Control Flow Integrity checking enabled, the following warning/panic happens:

[    1.626435] CFI failure (target: dwc2_set_bcm_params+0x0/0x4):
[    1.632408] WARNING: CPU: 0 PID: 32 at kernel/cfi.c:30 __cfi_check_fail+0x54/0x5c
[    1.640021] Modules linked in:
[    1.643137] CPU: 0 PID: 32 Comm: kworker/0:1 Not tainted 5.8.0-rc6-next-20200724-00051-g89ba619726de #1
[    1.652693] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[    1.658637] Workqueue: events deferred_probe_work_func
[    1.663870] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--)
[    1.669542] pc : __cfi_check_fail+0x54/0x5c
[    1.673798] lr : __cfi_check_fail+0x54/0x5c
[    1.678050] sp : ffff8000102bbaa0
[    1.681419] x29: ffff8000102bbaa0 x28: ffffab09e21c7000
[    1.686829] x27: 0000000000000402 x26: ffff0000f6e7c228
[    1.692238] x25: 00000000fb7cdb0d x24: 0000000000000005
[    1.697647] x23: ffffab09e2515000 x22: ffffab09e069a000
[    1.703055] x21: 4c550309df1cf4c1 x20: ffffab09e2433c60
[    1.708462] x19: ffffab09e160dc50 x18: ffff0000f6e8cc78
[    1.713870] x17: 0000000000000041 x16: ffffab09e0bce6f8
[    1.719278] x15: ffffab09e1c819b7 x14: 0000000000000003
[    1.724686] x13: 00000000ffffefff x12: 0000000000000000
[    1.730094] x11: 0000000000000000 x10: 00000000ffffffff
[    1.735501] x9 : c932f7abfc4bc600 x8 : c932f7abfc4bc600
[    1.740910] x7 : 077207610770075f x6 : ffff0000f6c38f00
[    1.746317] x5 : 0000000000000000 x4 : 0000000000000000
[    1.751723] x3 : 0000000000000000 x2 : 0000000000000000
[    1.757129] x1 : ffff8000102bb7d8 x0 : 0000000000000032
[    1.762539] Call trace:
[    1.765030]  __cfi_check_fail+0x54/0x5c
[    1.768938]  __cfi_check+0x5fa6c/0x66afc
[    1.772932]  dwc2_init_params+0xd74/0xd78
[    1.777012]  dwc2_driver_probe+0x484/0x6ec
[    1.781180]  platform_drv_probe+0xb4/0x100
[    1.785350]  really_probe+0x228/0x63c
[    1.789076]  driver_probe_device+0x80/0xc0
[    1.793247]  __device_attach_driver+0x114/0x160
[    1.797857]  bus_for_each_drv+0xa8/0x128
[    1.801851]  __device_attach.llvm.14901095709067289134+0xc0/0x170
[    1.808050]  bus_probe_device+0x44/0x100
[    1.812044]  deferred_probe_work_func+0x78/0xb8
[    1.816656]  process_one_work+0x204/0x3c4
[    1.820736]  worker_thread+0x2f0/0x4c4
[    1.824552]  kthread+0x174/0x184
[    1.827837]  ret_from_fork+0x10/0x18

CFI validates that all indirect calls go to a function with the same exact function pointer prototype. In this case, dwc2_set_bcm_params is the target, which has a parameter of type 'struct dwc2_hsotg *', but it is being implicitly cast to have a parameter of type 'void *' because that is the set_params function pointer prototype. Make the function pointer protoype match the definitions so that there is no more violation.

Fixes 7de1debcd2de ("usb: dwc2: Remove platform static params")

Signed-off-by Nathan Chancellor <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/dwc2/params.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/dwc2/params.c +1 -1

index 31e090ac9f1ec..6d3812678b8c6 100644
@@ -846,7 +846,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
 int dwc2_init_params(struct dwc2_hsotg *hsotg)
 {
 	const struct of_device_id *match;
-	void (*set_params)(void *data);
+	void (*set_params)(struct dwc2_hsotg *data);
 
 	dwc2_set_default_params(hsotg);
 	dwc2_get_device_properties(hsotg);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #164 lore raw

PATCH 164/408 quota: clear padding in v2r1_mem2diskdqb()

From: Eric Dumazet <[email protected]>

[ Upstream commit 3d3dc274ce736227e3197868ff749cff2f175f63 ]

Freshly allocated memory contains garbage, better make sure to init all struct v2r1_disk_dqblk fields to avoid KMSAN report:

BUG: KMSAN: uninit-value in qtree_entry_unused+0x137/0x1b0 fs/quota/quota_tree.c:218
CPU: 0 PID: 23373 Comm: syz-executor.1 Not tainted 5.9.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x21c/0x280 lib/dump_stack.c:118
 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:122
 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:219
 qtree_entry_unused+0x137/0x1b0 fs/quota/quota_tree.c:218
 v2r1_mem2diskdqb+0x43d/0x710 fs/quota/quota_v2.c:285
 qtree_write_dquot+0x226/0x870 fs/quota/quota_tree.c:394
 v2_write_dquot+0x1ad/0x280 fs/quota/quota_v2.c:333
 dquot_commit+0x4af/0x600 fs/quota/dquot.c:482
 ext4_write_dquot fs/ext4/super.c:5934 [inline]
 ext4_mark_dquot_dirty+0x4d8/0x6a0 fs/ext4/super.c:5985
 mark_dquot_dirty fs/quota/dquot.c:347 [inline]
 mark_all_dquot_dirty fs/quota/dquot.c:385 [inline]
 dquot_alloc_inode+0xc05/0x12b0 fs/quota/dquot.c:1755
 __ext4_new_inode+0x8204/0x9d70 fs/ext4/ialloc.c:1155
 ext4_tmpfile+0x41a/0x850 fs/ext4/namei.c:2686
 vfs_tmpfile+0x2a2/0x570 fs/namei.c:3283
 do_tmpfile fs/namei.c:3316 [inline]
 path_openat+0x4035/0x6a90 fs/namei.c:3359
 do_filp_open+0x2b8/0x710 fs/namei.c:3395
 do_sys_openat2+0xa88/0x1140 fs/open.c:1168
 do_sys_open fs/open.c:1184 [inline]
 __do_compat_sys_openat fs/open.c:1242 [inline]
 __se_compat_sys_openat+0x2a4/0x310 fs/open.c:1240
 __ia32_compat_sys_openat+0x56/0x70 fs/open.c:1240
 do_syscall_32_irqs_on arch/x86/entry/common.c:80 [inline]
 __do_fast_syscall_32+0x129/0x180 arch/x86/entry/common.c:139
 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:162
 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:205
 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
RIP: 0023:0xf7ff4549
Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000f55cd0cc EFLAGS: 00000296 ORIG_RAX: 0000000000000127
RAX: ffffffffffffffda RBX: 00000000ffffff9c RCX: 0000000020000000
RDX: 0000000000410481 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

Uninit was created at:

 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:143 [inline]
 kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:126
 kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:80
 slab_alloc_node mm/slub.c:2907 [inline]
 slab_alloc mm/slub.c:2916 [inline]
 __kmalloc+0x2bb/0x4b0 mm/slub.c:3982
 kmalloc include/linux/slab.h:559 [inline]
 getdqbuf+0x56/0x150 fs/quota/quota_tree.c:52
 qtree_write_dquot+0xf2/0x870 fs/quota/quota_tree.c:378
 v2_write_dquot+0x1ad/0x280 fs/quota/quota_v2.c:333
 dquot_commit+0x4af/0x600 fs/quota/dquot.c:482
 ext4_write_dquot fs/ext4/super.c:5934 [inline]
 ext4_mark_dquot_dirty+0x4d8/0x6a0 fs/ext4/super.c:5985
 mark_dquot_dirty fs/quota/dquot.c:347 [inline]
 mark_all_dquot_dirty fs/quota/dquot.c:385 [inline]
 dquot_alloc_inode+0xc05/0x12b0 fs/quota/dquot.c:1755
 __ext4_new_inode+0x8204/0x9d70 fs/ext4/ialloc.c:1155
 ext4_tmpfile+0x41a/0x850 fs/ext4/namei.c:2686
 vfs_tmpfile+0x2a2/0x570 fs/namei.c:3283
 do_tmpfile fs/namei.c:3316 [inline]
 path_openat+0x4035/0x6a90 fs/namei.c:3359
 do_filp_open+0x2b8/0x710 fs/namei.c:3395
 do_sys_openat2+0xa88/0x1140 fs/open.c:1168
 do_sys_open fs/open.c:1184 [inline]
 __do_compat_sys_openat fs/open.c:1242 [inline]
 __se_compat_sys_openat+0x2a4/0x310 fs/open.c:1240
 __ia32_compat_sys_openat+0x56/0x70 fs/open.c:1240
 do_syscall_32_irqs_on arch/x86/entry/common.c:80 [inline]
 __do_fast_syscall_32+0x129/0x180 arch/x86/entry/common.c:139
 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:162
 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:205
 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c

Fixes 498c60153ebb ("quota: Implement quota format with 64-bit space and inode limits")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Eric Dumazet <[email protected]>

Cc Jan Kara <[email protected]>

Signed-off-by Jan Kara <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/quota/quota_v2.c | 1 +
 1 file changed, 1 insertion(+)

fs/quota/quota_v2.c +1 -0

index 53429c29c7842..276c27fb99280 100644
@@ -284,6 +284,7 @@ static void v2r1_mem2diskdqb(void *dp, struct dquot *dquot)
 	d->dqb_curspace = cpu_to_le64(m->dqb_curspace);
 	d->dqb_btime = cpu_to_le64(m->dqb_btime);
 	d->dqb_id = cpu_to_le32(from_kqid(&init_user_ns, dquot->dq_id));
+	d->dqb_pad = 0;
 	if (qtree_entry_unused(info, dp))
 		d->dqb_itime = cpu_to_le64(1);
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #165 lore raw

PATCH 165/408 slimbus: core: check get_addr before removing laddr ida

From: Srinivas Kandagatla <[email protected]>

[ Upstream commit f97769fde678e111a1b7b165b380d8a3dfe54f4e ]

logical address can be either assigned by the SLIMBus controller or the core. Core uses IDA in cases where get_addr callback is not provided by the controller.
Core already has this check while allocating IDR, however during absence reporting this is not checked. This patch fixes this issue.

Fixes 46a2bb5a7f7e ("slimbus: core: Add slim controllers support")

Signed-off-by Srinivas Kandagatla <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/slimbus/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/slimbus/core.c +2 -2

index 63ee96eb58c68..42a233fc5dc6c 100644
@@ -327,8 +327,8 @@ void slim_report_absent(struct slim_device *sbdev)
 	mutex_lock(&ctrl->lock);
 	sbdev->is_laddr_valid = false;
 	mutex_unlock(&ctrl->lock);
-
-	ida_simple_remove(&ctrl->laddr_ida, sbdev->laddr);
+	if (!ctrl->get_laddr)
+		ida_simple_remove(&ctrl->laddr_ida, sbdev->laddr);
 	slim_device_update_status(sbdev, SLIM_DEVICE_STATUS_DOWN);
 }
 EXPORT_SYMBOL_GPL(slim_report_absent);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:35 UTC #166 lore raw

PATCH 166/408 slimbus: core: do not enter to clock pause mode in core

From: Srinivas Kandagatla <[email protected]>

[ Upstream commit df2c471c4ae07e18a0396db670dca2ef867c5153 ]

Let the controller logic decide when to enter into clock pause mode! Entering in to pause mode during unregistration does not really make sense as the controller is totally going down at that point in time.

Fixes 4b14e62ad3c9e ("slimbus: Add support for 'clock-pause' feature")

Signed-off-by Srinivas Kandagatla <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/slimbus/core.c | 2 --
 1 file changed, 2 deletions(-)

drivers/slimbus/core.c +0 -2

index 42a233fc5dc6c..130c798921b5d 100644
@@ -302,8 +302,6 @@ int slim_unregister_controller(struct slim_controller *ctrl)
 {
 	/* Remove all clients */
 	device_for_each_child(ctrl->dev, NULL, slim_ctrl_remove_device);
-	/* Enter Clock Pause */
-	slim_ctrl_clk_pause(ctrl, false, 0);
 	ida_simple_remove(&ctrl_ida, ctrl->id);
 
 	return 0;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-10-27 14:36 UTC #167 lore raw

PATCH 167/408 slimbus: qcom-ngd-ctrl: disable ngd in qmi server down callback