Skip to contentSkip to conversation

4.18.10-stable review

PATCH In review Greg Kroah-Hartman 10 participants 262 messages Sep 24, 2018 – Oct 9, 2018 Page 2 of 2

Subsystems (15)
lore
Share & tools
lore
author maintainer
#170 lore raw

PATCH 166/235 sched/core: Use smp_mb() in wake_woken_function()

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Andrea Parri <[email protected]>

[ Upstream commit 76e079fefc8f62bd9b2cd2950814d1ee806e31a5 ]

wake_woken_function() synchronizes with wait_woken() as follows:

[wait_woken] [wake_woken_function]

  entry->flags &= ~wq_flag_woken;    condition = true;
  smp_mb();                          smp_wmb();
  if (condition)                     wq_entry->flags |= wq_flag_woken;
     break;

This commit replaces the above smp_wmb() with an smp_mb() in order to guarantee that either wait_woken() sees the wait condition being true or the store to wq_entry->flags in woken_wake_function() follows the store in wait_woken() in the coherence order (so that the former can eventually be observed by wait_woken()).

The commit also fixes a comment associated to set_current_state() in wait_woken(): the comment pairs the barrier in set_current_state() to the above smp_wmb(), while the actual pairing involves the barrier in set_current_state() and the barrier executed by the try_to_wake_up() in wake_woken_function().

---
 kernel/sched/wait.c |   47 +++++++++++++++++++++--------------------------
 1 file changed, 21 insertions(+), 26 deletions(-)
kernel/sched/wait.c +21 -26
@@ -392,35 +392,36 @@ static inline bool is_kthread_should_sto
  *     if (condition)
  *         break;
  *
- *     p->state = mode;				condition = true;
- *     smp_mb(); // A				smp_wmb(); // C
- *     if (!wq_entry->flags & WQ_FLAG_WOKEN)	wq_entry->flags |= WQ_FLAG_WOKEN;
- *         schedule()				try_to_wake_up();
- *     p->state = TASK_RUNNING;		    ~~~~~~~~~~~~~~~~~~
- *     wq_entry->flags &= ~WQ_FLAG_WOKEN;		condition = true;
- *     smp_mb() // B				smp_wmb(); // C
- *						wq_entry->flags |= WQ_FLAG_WOKEN;
- * }
- * remove_wait_queue(&wq_head, &wait);
+ *     // in wait_woken()			// in woken_wake_function()
  *
+ *     p->state = mode;				wq_entry->flags |= WQ_FLAG_WOKEN;
+ *     smp_mb(); // A				try_to_wake_up():
+ *     if (!(wq_entry->flags & WQ_FLAG_WOKEN))	   <full barrier>
+ *         schedule()				   if (p->state & mode)
+ *     p->state = TASK_RUNNING;			      p->state = TASK_RUNNING;
+ *     wq_entry->flags &= ~WQ_FLAG_WOKEN;	~~~~~~~~~~~~~~~~~~
+ *     smp_mb(); // B				condition = true;
+ * }						smp_mb(); // C
+ * remove_wait_queue(&wq_head, &wait);		wq_entry->flags |= WQ_FLAG_WOKEN;
  */
 long wait_woken(struct wait_queue_entry *wq_entry, unsigned mode, long timeout)
 {
-	set_current_state(mode); /* A */
 	/*
-	 * The above implies an smp_mb(), which matches with the smp_wmb() from
-	 * woken_wake_function() such that if we observe WQ_FLAG_WOKEN we must
-	 * also observe all state before the wakeup.
+	 * The below executes an smp_mb(), which matches with the full barrier
+	 * executed by the try_to_wake_up() in woken_wake_function() such that
+	 * either we see the store to wq_entry->flags in woken_wake_function()
+	 * or woken_wake_function() sees our store to current->state.
 	 */
+	set_current_state(mode); /* A */
 	if (!(wq_entry->flags & WQ_FLAG_WOKEN) && !is_kthread_should_stop())
 		timeout = schedule_timeout(timeout);
 	__set_current_state(TASK_RUNNING);
 
 	/*
-	 * The below implies an smp_mb(), it too pairs with the smp_wmb() from
-	 * woken_wake_function() such that we must either observe the wait
-	 * condition being true _OR_ WQ_FLAG_WOKEN such that we will not miss
-	 * an event.
+	 * The below executes an smp_mb(), which matches with the smp_mb() (C)
+	 * in woken_wake_function() such that either we see the wait condition
+	 * being true or the store to wq_entry->flags in woken_wake_function()
+	 * follows ours in the coherence order.
 	 */
 	smp_store_mb(wq_entry->flags, wq_entry->flags & ~WQ_FLAG_WOKEN); /* B */
 
@@ -430,14 +431,8 @@ EXPORT_SYMBOL(wait_woken);
 
 int woken_wake_function(struct wait_queue_entry *wq_entry, unsigned mode, int sync, void *key)
 {
-	/*
-	 * Although this function is called under waitqueue lock, LOCK
-	 * doesn't imply write barrier and the users expects write
-	 * barrier semantics on wakeup functions.  The following
-	 * smp_wmb() is equivalent to smp_wmb() in try_to_wake_up()
-	 * and is paired with smp_store_mb() in wait_woken().
-	 */
-	smp_wmb(); /* C */
+	/* Pairs with the smp_store_mb() in wait_woken(). */
+	smp_mb(); /* C */
 	wq_entry->flags |= WQ_FLAG_WOKEN;
 
 	return default_wake_function(wq_entry, mode, sync, key);
author maintainer
#171 lore raw

PATCH 167/235 efi/esrt: Only call efi_mem_reserve() for boot services memory

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Ard Biesheuvel <[email protected]>

[ Upstream commit 61f0d55569463a1af897117ff47d202b0ccb2e24 ]

The following commit:

7e1550b8f208 ("efi: Drop type and attribute checks in efi_mem_desc_lookup()")

refactored the implementation of efi_mem_desc_lookup() so that the type check is moved to the callers, one of which is the x86 version of efi_arch_mem_reserve(), where we added a modified check that only takes EFI_BOOT_SERVICES_DATA regions into account.

This is reasonable, since it is the only memory type that requires this, but doing so uncovered some unexpected behavior in the ESRT code, which permits the ESRT table to reside in other types of memory than what the UEFI spec mandates (i.e., EFI_BOOT_SERVICES_DATA), and unconditionally calls efi_mem_reserve() on the region in question. This may result in errors such as

esrt: Reserving ESRT space from 0x000000009c810318 to 0x000000009c810350.
efi: Failed to lookup EFI memory descriptor for 0x000000009c810318

when the ESRT table is not in EFI_BOOT_SERVICES_DATA memory, but we try to reserve it nonetheless.

So make the call to efi_mem_reserve() conditional on the memory type.

---
 drivers/firmware/efi/esrt.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/firmware/efi/esrt.c +2 -1
@@ -326,7 +326,8 @@ void __init efi_esrt_init(void)
 
 	end = esrt_data + size;
 	pr_info("Reserving ESRT space from %pa to %pa.\n", &esrt_data, &end);
-	efi_mem_reserve(esrt_data, esrt_data_size);
+	if (md.type == EFI_BOOT_SERVICES_DATA)
+		efi_mem_reserve(esrt_data, esrt_data_size);
 
 	pr_debug("esrt-init: loaded.\n");
 }
author maintainer
#172 lore raw

PATCH 168/235 net: hns3: Reset net device with rtnl_lock

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Huazhong Tan <[email protected]>

[ Upstream commit 6d4fab39533f1bcd933d82d1667ceea93e4de260 ]

Since current locking was not covering certain code where netdev was being accessed or manipulated, this patch fixes it.

---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +2 -3
@@ -2825,15 +2825,13 @@ static void hclge_clear_reset_cause(stru
 static void hclge_reset(struct hclge_dev *hdev)
 {
 	/* perform reset of the stack & ae device for a client */
-
+	rtnl_lock();
 	hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
 
 	if (!hclge_reset_wait(hdev)) {
-		rtnl_lock();
 		hclge_notify_client(hdev, HNAE3_UNINIT_CLIENT);
 		hclge_reset_ae_dev(hdev->ae_dev);
 		hclge_notify_client(hdev, HNAE3_INIT_CLIENT);
-		rtnl_unlock();
 
 		hclge_clear_reset_cause(hdev);
 	} else {
@@ -2843,6 +2841,7 @@ static void hclge_reset(struct hclge_dev
 	}
 
 	hclge_notify_client(hdev, HNAE3_UP_CLIENT);
+	rtnl_unlock();
 }
 
 static void hclge_reset_event(struct hnae3_handle *handle)
author maintainer
#173 lore raw

PATCH 169/235 net: hns3: Fix for reset_level default assignment probelm

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Yunsheng Lin <[email protected]>

[ Upstream commit 82b5321460005ac5d34996e17f5a51a4004a1e14 ]

handle->reset_level is assigned to HNAE3_NONE_RESET when client is initialized, if a tx timeout happens right after initialization, then handle->reset_level is not resetted to HNAE3_FUNC_RESET in hclge_reset_event, which will cause reset event not properly handled problem.

This patch fixes it by setting handle->reset_level properly when client is initialized.

Fixes 6d4c3981a8d8 ("net: hns3: Changes to make enet watchdog timeout func common for PF/VF")
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +5 -1
@@ -3081,7 +3081,6 @@ static int hns3_client_init(struct hnae3
 	priv->dev = &pdev->dev;
 	priv->netdev = netdev;
 	priv->ae_handle = handle;
-	priv->ae_handle->reset_level = HNAE3_NONE_RESET;
 	priv->ae_handle->last_reset_time = jiffies;
 	priv->tx_timeout_count = 0;
 
@@ -3102,6 +3101,11 @@ static int hns3_client_init(struct hnae3
 	/* Carrier off reporting is important to ethtool even BEFORE open */
 	netif_carrier_off(netdev);
 
+	if (handle->flags & HNAE3_SUPPORT_VF)
+		handle->reset_level = HNAE3_VF_RESET;
+	else
+		handle->reset_level = HNAE3_FUNC_RESET;
+
 	ret = hns3_get_ring_config(priv);
 	if (ret) {
 		ret = -ENOMEM;
author maintainer
#174 lore raw

PATCH 170/235 ARM: hisi: handle of_iomap and fix missing of_node_put

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Nicholas Mc Guire <[email protected]>

[ Upstream commit d396cb185c0337aae5664b250cdd9a73f6eb1503 ]

Relying on an unchecked of_iomap() which can return NULL is problematic here, an explicit check seems mandatory. Also the call to of_find_compatible_node() returns a device node with refcount incremented therefor an explicit of_node_put() is needed here.

Fixes commit 22bae4290457 ("ARM: hi3xxx: add hotplug support")
---
 arch/arm/mach-hisi/hotplug.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)
arch/arm/mach-hisi/hotplug.c +13 -6
@@ -148,13 +148,20 @@ static int hi3xxx_hotplug_init(void)
 	struct device_node *node;
 
 	node = of_find_compatible_node(NULL, NULL, "hisilicon,sysctrl");
-	if (node) {
-		ctrl_base = of_iomap(node, 0);
-		id = HI3620_CTRL;
-		return 0;
+	if (!node) {
+		id = ERROR_CTRL;
+		return -ENOENT;
 	}
-	id = ERROR_CTRL;
-	return -ENOENT;
+
+	ctrl_base = of_iomap(node, 0);
+	of_node_put(node);
+	if (!ctrl_base) {
+		id = ERROR_CTRL;
+		return -ENOMEM;
+	}
+
+	id = HI3620_CTRL;
+	return 0;
 }
 
 void hi3xxx_set_cpu(int cpu, bool enable)
author maintainer
#175 lore raw

PATCH 171/235 ARM: hisi: fix error handling and missing of_node_put

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Nicholas Mc Guire <[email protected]>

[ Upstream commit 9f30b5ae0585ca5234fe979294b8f897299dec99 ]

of_iomap() can return NULL which seems critical here and thus should be explicitly flagged so that the cause of system halting can be understood. As of_find_compatible_node() is returning a device node with refcount incremented it must be explicitly decremented here.

Fixes commit 7fda91e73155 ("ARM: hisi: enable smp for HiP01")
---
 arch/arm/mach-hisi/hotplug.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm/mach-hisi/hotplug.c +4 -4
@@ -226,10 +226,10 @@ void hip01_set_cpu(int cpu, bool enable)
 
 	if (!ctrl_base) {
 		np = of_find_compatible_node(NULL, NULL, "hisilicon,hip01-sysctrl");
-		if (np)
-			ctrl_base = of_iomap(np, 0);
-		else
-			BUG();
+		BUG_ON(!np);
+		ctrl_base = of_iomap(np, 0);
+		of_node_put(np);
+		BUG_ON(!ctrl_base);
 	}
 
 	if (enable) {
author maintainer
#176 lore raw

PATCH 172/235 net: hns3: Fix return value error in hns3_reset_notify_down_enet

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Huazhong Tan <[email protected]>

[ Upstream commit 6b1385cc251ae9f26b720fa5c8c00bf19af336ae ]

When doing reset, netdev has not been brought up is not an error, it means that we do not need do the stop operation, so just return zero.

Fixes 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +1 -1
@@ -3422,7 +3422,7 @@ static int hns3_reset_notify_down_enet(s
 	struct net_device *ndev = kinfo->netdev;
 
 	if (!netif_running(ndev))
-		return -EIO;
+		return 0;
 
 	return hns3_nic_net_stop(ndev);
 }
author maintainer
#177 lore raw

PATCH 173/235 ARM: hisi: check of_iomap and fix missing of_node_put

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Nicholas Mc Guire <[email protected]>

[ Upstream commit 81646a3d39ef14749301374a3a0b8311384cd412 ]

of_find_compatible_node() returns a device node with refcount incremented and thus needs an explicit of_node_put(). Further relying on an unchecked of_iomap() which can return NULL is problematic here, after all ctrl_base is critical enough for hix5hd2_set_cpu() to call BUG() if not available so a check seems mandated here.

0002 Fixes: commit 06cc5c1d4d73 ("ARM: hisi: enable hix5hd2 SoC")

---
 arch/arm/mach-hisi/hotplug.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)
arch/arm/mach-hisi/hotplug.c +9 -5
@@ -180,11 +180,15 @@ static bool hix5hd2_hotplug_init(void)
 	struct device_node *np;
 
 	np = of_find_compatible_node(NULL, NULL, "hisilicon,cpuctrl");
-	if (np) {
-		ctrl_base = of_iomap(np, 0);
-		return true;
-	}
-	return false;
+	if (!np)
+		return false;
+
+	ctrl_base = of_iomap(np, 0);
+	of_node_put(np);
+	if (!ctrl_base)
+		return false;
+
+	return true;
 }
 
 void hix5hd2_set_cpu(int cpu, bool enable)
author maintainer
#178 lore raw

PATCH 174/235 liquidio: fix hang when re-binding VF host drv after running DPDK VF driver

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Rick Farrington <[email protected]>

[ Upstream commit ac13d6d8eaded15c67265eafc32f439ea3a0ac4a ]

When configuring SLI_PKTn_OUTPUT_CONTROL, VF driver was assuming that IPTR mode was disabled by reset, which was not true. Since DPDK driver had set IPTR mode previously, the VF driver (which uses buf-ptr-only mode) was not properly handling DROQ packets (i.e. it saw zero-length packets).

This represented an invalid hardware configuration which the driver could not handle.

---
 drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c |    3 +++
 drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c |    3 +++
 2 files changed, 6 insertions(+)
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c +3 -0
@@ -493,6 +493,9 @@ static void cn23xx_pf_setup_global_outpu
 	for (q_no = srn; q_no < ern; q_no++) {
 		reg_val = octeon_read_csr(oct, CN23XX_SLI_OQ_PKT_CONTROL(q_no));
 
+		/* clear IPTR */
+		reg_val &= ~CN23XX_PKT_OUTPUT_CTL_IPTR;
+
 		/* set DPTR */
 		reg_val |= CN23XX_PKT_OUTPUT_CTL_DPTR;
 
drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c +3 -0
@@ -165,6 +165,9 @@ static void cn23xx_vf_setup_global_outpu
 		reg_val =
 		    octeon_read_csr(oct, CN23XX_VF_SLI_OQ_PKT_CONTROL(q_no));
 
+		/* clear IPTR */
+		reg_val &= ~CN23XX_PKT_OUTPUT_CTL_IPTR;
+
 		/* set DPTR */
 		reg_val |= CN23XX_PKT_OUTPUT_CTL_DPTR;
 
author maintainer
#179 lore raw

PATCH 175/235 gpu: ipu-v3: csi: pass back mbus_code_to_bus_cfg error codes

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Enrico Scholz <[email protected]>

[ Upstream commit d36d0e6309dd8137cf438cbb680e72eb63c81425 ]

mbus_code_to_bus_cfg() can fail on unknown mbus codes; pass back the error to the caller.

---
 drivers/gpu/ipu-v3/ipu-csi.c |   20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)
drivers/gpu/ipu-v3/ipu-csi.c +16 -4
@@ -318,13 +318,17 @@ static int mbus_code_to_bus_cfg(struct i
 /*
  * Fill a CSI bus config struct from mbus_config and mbus_framefmt.
  */
-static void fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
+static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
 				 struct v4l2_mbus_config *mbus_cfg,
 				 struct v4l2_mbus_framefmt *mbus_fmt)
 {
+	int ret;
+
 	memset(csicfg, 0, sizeof(*csicfg));
 
-	mbus_code_to_bus_cfg(csicfg, mbus_fmt->code);
+	ret = mbus_code_to_bus_cfg(csicfg, mbus_fmt->code);
+	if (ret < 0)
+		return ret;
 
 	switch (mbus_cfg->type) {
 	case V4L2_MBUS_PARALLEL:
@@ -356,6 +360,8 @@ static void fill_csi_bus_cfg(struct ipu_
 		/* will never get here, keep compiler quiet */
 		break;
 	}
+
+	return 0;
 }
 
 int ipu_csi_init_interface(struct ipu_csi *csi,
@@ -365,8 +371,11 @@ int ipu_csi_init_interface(struct ipu_cs
 	struct ipu_csi_bus_config cfg;
 	unsigned long flags;
 	u32 width, height, data = 0;
+	int ret;
 
-	fill_csi_bus_cfg(&cfg, mbus_cfg, mbus_fmt);
+	ret = fill_csi_bus_cfg(&cfg, mbus_cfg, mbus_fmt);
+	if (ret < 0)
+		return ret;
 
 	/* set default sensor frame width and height */
 	width = mbus_fmt->width;
@@ -587,11 +596,14 @@ int ipu_csi_set_mipi_datatype(struct ipu
 	struct ipu_csi_bus_config cfg;
 	unsigned long flags;
 	u32 temp;
+	int ret;
 
 	if (vc > 3)
 		return -EINVAL;
 
-	mbus_code_to_bus_cfg(&cfg, mbus_fmt->code);
+	ret = mbus_code_to_bus_cfg(&cfg, mbus_fmt->code);
+	if (ret < 0)
+		return ret;
 
 	spin_lock_irqsave(&csi->lock, flags);
 
author maintainer
#180 lore raw

PATCH 176/235 ASoC: hdmi-codec: fix routing

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Russell King <[email protected]>

[ Upstream commit d30e23d69981a4b665f5ce8711335df986576389 ]

Commit 943fa0228252 ("ASoC: hdmi-codec: Use different name for playback streams") broke hdmi-codec's routing between it's output "TX" widget and the S/PDIF or I2S streams by renaming the streams.

Whether an error occurs or not is dependent on whether there is another widget called "Playback" registered by some other component - if there is, that widget will be (incorrectly) bound to the HDMI codec's "TX" output widget. If we end up connecting "TX" incorrectly, it can result in components not being started, causing no audio output.

Since the I2S and S/PDIF streams now have different names, we can't use a static route at component level to describe the relationship, so arrange to dynamically create the route when the DAI driver is probed.

Fixes 943fa0228252 ("ASoC: hdmi-codec: Use different name for playback streams")
---
 sound/soc/codecs/hdmi-codec.c |   21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)
sound/soc/codecs/hdmi-codec.c +15 -6
@@ -291,10 +291,6 @@ static const struct snd_soc_dapm_widget
 	SND_SOC_DAPM_OUTPUT("TX"),
 };
 
-static const struct snd_soc_dapm_route hdmi_routes[] = {
-	{ "TX", NULL, "Playback" },
-};
-
 enum {
 	DAI_ID_I2S = 0,
 	DAI_ID_SPDIF,
@@ -689,9 +685,23 @@ static int hdmi_codec_pcm_new(struct snd
 	return snd_ctl_add(rtd->card->snd_card, kctl);
 }
 
+static int hdmi_dai_probe(struct snd_soc_dai *dai)
+{
+	struct snd_soc_dapm_context *dapm;
+	struct snd_soc_dapm_route route = {
+		.sink = "TX",
+		.source = dai->driver->playback.stream_name,
+	};
+
+	dapm = snd_soc_component_get_dapm(dai->component);
+
+	return snd_soc_dapm_add_routes(dapm, &route, 1);
+}
+
 static const struct snd_soc_dai_driver hdmi_i2s_dai = {
 	.name = "i2s-hifi",
 	.id = DAI_ID_I2S,
+	.probe = hdmi_dai_probe,
 	.playback = {
 		.stream_name = "I2S Playback",
 		.channels_min = 2,
@@ -707,6 +717,7 @@ static const struct snd_soc_dai_driver h
 static const struct snd_soc_dai_driver hdmi_spdif_dai = {
 	.name = "spdif-hifi",
 	.id = DAI_ID_SPDIF,
+	.probe = hdmi_dai_probe,
 	.playback = {
 		.stream_name = "SPDIF Playback",
 		.channels_min = 2,
@@ -733,8 +744,6 @@ static int hdmi_of_xlate_dai_id(struct s
 static const struct snd_soc_component_driver hdmi_driver = {
 	.dapm_widgets		= hdmi_widgets,
 	.num_dapm_widgets	= ARRAY_SIZE(hdmi_widgets),
-	.dapm_routes		= hdmi_routes,
-	.num_dapm_routes	= ARRAY_SIZE(hdmi_routes),
 	.of_xlate_dai_id	= hdmi_of_xlate_dai_id,
 	.idle_bias_on		= 1,
 	.use_pmdown_time	= 1,
author maintainer
#181 lore raw

PATCH 177/235 gpiolib: dont allow userspace to set values of input lines

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Bartosz Golaszewski <[email protected]>

[ Upstream commit e5332d5437764f775cf4e3b8ca3bf592af063a02 ]

User space can currently both read and set values of input lines using the character device. This was not allowed by the old sysfs interface nor is it a correct behavior.

Check the first descriptor in the set for the OUT flag when asked to set values and return -EPERM if the line is input.

---
 drivers/gpio/gpiolib.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/gpio/gpiolib.c +7 -1
@@ -449,7 +449,13 @@ static long linehandle_ioctl(struct file
 
 		return 0;
 	} else if (cmd == GPIOHANDLE_SET_LINE_VALUES_IOCTL) {
-		/* TODO: check if descriptors are really output */
+		/*
+		 * All line descriptors were created at once with the same
+		 * flags so just check if the first one is really output.
+		 */
+		if (!test_bit(FLAG_IS_OUT, &lh->descs[0]->flags))
+			return -EPERM;
+
 		if (copy_from_user(&ghd, ip, sizeof(ghd)))
 			return -EFAULT;
 
#182 lore raw

Re: [PATCH 4.18 177/235] gpiolib: dont allow userspace to set values of input lines

pon., 24 wrz 2018 o 14:41 Greg Kroah-Hartman
<[email protected]> napisał(a):

Quoted 33 lines

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Bartosz Golaszewski <[email protected]>

[ Upstream commit e5332d5437764f775cf4e3b8ca3bf592af063a02 ]

User space can currently both read and set values of input lines using the character device. This was not allowed by the old sysfs interface nor is it a correct behavior.

Check the first descriptor in the set for the OUT flag when asked to set values and return -EPERM if the line is input.

---
 drivers/gpio/gpiolib.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/gpio/gpiolib.c +0 -1
@@ -449,7 +449,13 @@ static long linehandle_ioctl(struct file
 
                return 0;
        } else if (cmd == GPIOHANDLE_SET_LINE_VALUES_IOCTL) {
-               /* TODO: check if descriptors are really output */

drivers/gpio/gpiolib.c static long linehandle_ioctl(struct file · line 461

Quoted 10 lines
drivers/gpio/gpiolib.c +7 -0
+               /*
+                * All line descriptors were created at once with the same
+                * flags so just check if the first one is really output.
+                */
+               if (!test_bit(FLAG_IS_OUT, &lh->descs[0]->flags))
+                       return -EPERM;
+
                if (copy_from_user(&ghd, ip, sizeof(ghd)))
                        return -EFAULT;
 

Hi Greg,

FYI Linus suggested that we don't send this one for stable:
https://lkml.org/lkml/2018/7/20/1065

Best regards,
Bartosz Golaszewski

author maintainer
#183 lore raw

Re: [PATCH 4.18 177/235] gpiolib: dont allow userspace to set values of input lines

Quoted 48 lines · Bartosz Golaszewski

pon., 24 wrz 2018 o 14:41 Greg Kroah-Hartman
<[email protected]> napisał(a):

Quoted 33 lines

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Bartosz Golaszewski <[email protected]>

[ Upstream commit e5332d5437764f775cf4e3b8ca3bf592af063a02 ]

User space can currently both read and set values of input lines using the character device. This was not allowed by the old sysfs interface nor is it a correct behavior.

Check the first descriptor in the set for the OUT flag when asked to set values and return -EPERM if the line is input.

---
 drivers/gpio/gpiolib.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/gpio/gpiolib.c +0 -1
@@ -449,7 +449,13 @@ static long linehandle_ioctl(struct file
 
                return 0;
        } else if (cmd == GPIOHANDLE_SET_LINE_VALUES_IOCTL) {
-               /* TODO: check if descriptors are really output */

drivers/gpio/gpiolib.c static long linehandle_ioctl(struct file · line 461

Quoted 10 lines
drivers/gpio/gpiolib.c +7 -0
+               /*
+                * All line descriptors were created at once with the same
+                * flags so just check if the first one is really output.
+                */
+               if (!test_bit(FLAG_IS_OUT, &lh->descs[0]->flags))
+                       return -EPERM;
+
                if (copy_from_user(&ghd, ip, sizeof(ghd)))
                        return -EFAULT;
 

Hi Greg,

Quoted 2 lines

FYI Linus suggested that we don't send this one for stable:
https://lkml.org/lkml/2018/7/20/1065

Ok, that was hard to dig out. This was sent as review last week. I'll go drop it, thanks for letting me know.

greg k-h

author maintainer
#184 lore raw

PATCH 178/235 serial: 8250: of: Correct of_platform_serial_setup() error handling

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Alexander Sverdlin <[email protected]>

[ Upstream commit b29330d829042512fabb2bfa3bbfa32df1115594 ]

Don't dispose IRQ mapping before it has been created.

Fixes aa9594740 ("serial: 8250_of: Add IO space support")
---
 drivers/tty/serial/8250/8250_of.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/8250/8250_of.c +1 -1
@@ -124,7 +124,7 @@ static int of_platform_serial_setup(stru
 				dev_warn(&ofdev->dev, "unsupported reg-io-width (%d)\n",
 					 prop);
 				ret = -EINVAL;
-				goto err_dispose;
+				goto err_unprepare;
 			}
 		}
 		port->flags |= UPF_IOREMAP;
author maintainer
#185 lore raw

PATCH 179/235 tty: fix termios input-speed encoding when using BOTHER

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Johan Hovold <[email protected]>

[ Upstream commit 1cee38f0363a88db374e50b232ca17b9a4c12fa0 ]

When the termios CIBAUD bits are left unset (i.e. B0), we use the same output and input speed and should leave CIBAUD unchanged.

When the user requests a rate using BOTHER and c_ospeed which the driver cannot set exactly, the driver can report back the actual baud rate using tty_termios_encode_baud_rate(). If this rate is close enough to a standard rate however, we could end up setting CIBAUD to a Bfoo value despite the user having left it unset.

This in turn could lead to an unexpected input rate being set on subsequent termios updates.

Fix this by using a zero tolerance value also for the input rate when CIBAUD is clear so that the matching logic works as expected.

Fixes 78137e3b34e1 ("[PATCH] tty: improve encode_baud_rate logic")
---
 drivers/tty/tty_baudrate.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/tty/tty_baudrate.c +7 -3
@@ -157,16 +157,20 @@ void tty_termios_encode_baud_rate(struct
 	termios->c_ospeed = obaud;
 
 #ifdef BOTHER
+	if ((termios->c_cflag >> IBSHIFT) & CBAUD)
+		ibinput = 1;	/* An input speed was specified */
+
 	/* If the user asked for a precise weird speed give a precise weird
 	   answer. If they asked for a Bfoo speed they may have problems
 	   digesting non-exact replies so fuzz a bit */
 
-	if ((termios->c_cflag & CBAUD) == BOTHER)
+	if ((termios->c_cflag & CBAUD) == BOTHER) {
 		oclose = 0;
+		if (!ibinput)
+			iclose = 0;
+	}
 	if (((termios->c_cflag >> IBSHIFT) & CBAUD) == BOTHER)
 		iclose = 0;
-	if ((termios->c_cflag >> IBSHIFT) & CBAUD)
-		ibinput = 1;	/* An input speed was specified */
 #endif
 	termios->c_cflag &= ~CBAUD;
 
author maintainer
#186 lore raw

PATCH 180/235 tty: fix termios input-speed encoding

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Johan Hovold <[email protected]>

[ Upstream commit fada18c48d774b9e837928ecdce6a5d5fdd11ee7 ]

Make sure to clear the CIBAUD bits before OR-ing the new mask when encoding the termios input baud rate.

This could otherwise lead to an incorrect input rate being reported back and incidentally set on subsequent termios updates.

Fixes edc6afc54968 ("[PATCH] tty: switch to ktermios and new framework")
---
 drivers/tty/tty_baudrate.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/tty/tty_baudrate.c +3 -0
@@ -173,6 +173,9 @@ void tty_termios_encode_baud_rate(struct
 		iclose = 0;
 #endif
 	termios->c_cflag &= ~CBAUD;
+#ifdef IBSHIFT
+	termios->c_cflag &= ~(CBAUD << IBSHIFT);
+#endif
 
 	/*
 	 *	Our goal is to find a close match to the standard baud rate
author maintainer
#187 lore raw

PATCH 181/235 mmc: sdhci-of-esdhc: set proper dma mask for ls104x chips

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Laurentiu Tudor <[email protected]>

[ Upstream commit 5552d7ad596c3fea953f40fef74170ce0760c04d ]

SDHCI controller in ls1043a and ls1046a generate 40-bit wide addresses when doing DMA. Make sure that the corresponding dma mask is correctly configured.

Context: when enabling smmu on these chips the following problem is
encountered: the smmu input address size is 48 bits so the dma mappings for sdhci end up 48-bit wide. However, on these chips sdhci only use 40-bits of that address size when doing dma.
So you end up with a 48-bit address translation in smmu but the device generates transactions with clipped 40-bit addresses, thus smmu context faults are triggered. Setting up the correct dma mask fixes this situation.

---
 drivers/mmc/host/sdhci-of-esdhc.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/mmc/host/sdhci-of-esdhc.c +6 -0
@@ -22,6 +22,7 @@
 #include <linux/sys_soc.h>
 #include <linux/clk.h>
 #include <linux/ktime.h>
+#include <linux/dma-mapping.h>
 #include <linux/mmc/host.h>
 #include "sdhci-pltfm.h"
 #include "sdhci-esdhc.h"
@@ -427,6 +428,11 @@ static void esdhc_of_adma_workaround(str
 static int esdhc_of_enable_dma(struct sdhci_host *host)
 {
 	u32 value;
+	struct device *dev = mmc_dev(host->mmc);
+
+	if (of_device_is_compatible(dev->of_node, "fsl,ls1043a-esdhc") ||
+	    of_device_is_compatible(dev->of_node, "fsl,ls1046a-esdhc"))
+		dma_set_mask_and_coherent(dev, DMA_BIT_MASK(40));
 
 	value = sdhci_readl(host, ESDHC_DMA_SYSCTL);
 	value |= ESDHC_DMA_SNOOP;
author maintainer
#188 lore raw

PATCH 182/235 mmc: tegra: prevent HS200 on Tegra 3

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Stefan Agner <[email protected]>

[ Upstream commit 127407e36f4fe3a1d5e8b9998b479956ce83a7dc ]

The stack assumes that SDHC controller which support SD3.0 (SDR104) do support HS200. This is not the case for Tegra 3, which does support SD 3.0
but only supports eMMC spec 4.41.

Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not support HS200.

Note that commit 156e14b126ff ("mmc: sdhci: fix caps2 for HS200") added the tie between SD3.0 (SDR104) and HS200. I don't think that this is necessarly true. It is fully legitimate to support SD3.0 and not support HS200. The quirk naming suggests something is broken in the controller, but this is not the case: The controller simply does not support HS200.

Fixes 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes")
---
 drivers/mmc/host/sdhci-tegra.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/mmc/host/sdhci-tegra.c +2 -1
@@ -334,7 +334,8 @@ static const struct sdhci_pltfm_data sdh
 		  SDHCI_QUIRK_NO_HISPD_BIT |
 		  SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
 		  SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
-	.quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+	.quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN |
+		   SDHCI_QUIRK2_BROKEN_HS200,
 	.ops  = &tegra_sdhci_ops,
 };
 
author maintainer
#189 lore raw

PATCH 183/235 mmc: sdhci: do not try to use 3.3V signaling if not supported

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Stefan Agner <[email protected]>

[ Upstream commit 1b5190c2e74c47ebe4bcecf7a072358ad9f1feaa ]

For eMMC devices it is valid to only support 1.8V signaling. When vqmmc is set to a fixed 1.8V regulator the stack tries to set 3.3V initially and prints the following warning:
mmc1: Switching to 3.3V signalling voltage failed

Clear the MMC_SIGNAL_VOLTAGE_330 flag in case 3.3V is signaling is not available. This prevents the stack from even trying to use 3.3V signaling and avoids the above warning.

---
 drivers/mmc/host/sdhci.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/mmc/host/sdhci.c +8 -1
@@ -3734,14 +3734,21 @@ int sdhci_setup_host(struct sdhci_host *
 	    mmc_gpio_get_cd(host->mmc) < 0)
 		mmc->caps |= MMC_CAP_NEEDS_POLL;
 
-	/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
 	if (!IS_ERR(mmc->supply.vqmmc)) {
 		ret = regulator_enable(mmc->supply.vqmmc);
+
+		/* If vqmmc provides no 1.8V signalling, then there's no UHS */
 		if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 1700000,
 						    1950000))
 			host->caps1 &= ~(SDHCI_SUPPORT_SDR104 |
 					 SDHCI_SUPPORT_SDR50 |
 					 SDHCI_SUPPORT_DDR50);
+
+		/* In eMMC case vqmmc might be a fixed 1.8V regulator */
+		if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 2700000,
+						    3600000))
+			host->flags &= ~SDHCI_SIGNALING_330;
+
 		if (ret) {
 			pr_warn("%s: Failed to enable vqmmc regulator: %d\n",
 				mmc_hostname(mmc), ret);
author maintainer
#190 lore raw

PATCH 184/235 drm/nouveau: Fix runtime PM leak in drm_open()

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Lyude Paul <[email protected]>

[ Upstream commit 922a8c82fafdec99688bbaea6c5889f562a42cdc ]

Noticed this as I was skimming through, if we fail to allocate memory for cli we'll end up returning without dropping the runtime PM ref we got. Additionally, we'll even return the wrong return code! (ret most likely will == 0 here, we want -ENOMEM).

---
 drivers/gpu/drm/nouveau/nouveau_drm.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nouveau_drm.c +4 -2
@@ -908,8 +908,10 @@ nouveau_drm_open(struct drm_device *dev,
 	get_task_comm(tmpname, current);
 	snprintf(name, sizeof(name), "%s[%d]", tmpname, pid_nr(fpriv->pid));
 
-	if (!(cli = kzalloc(sizeof(*cli), GFP_KERNEL)))
-		return ret;
+	if (!(cli = kzalloc(sizeof(*cli), GFP_KERNEL))) {
+		ret = -ENOMEM;
+		goto done;
+	}
 
 	ret = nouveau_cli_init(drm, name, cli);
 	if (ret)
author maintainer
#191 lore raw

PATCH 185/235 drm/nouveau/debugfs: Wake up GPU before doing any reclocking

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Karol Herbst <[email protected]>

[ Upstream commit eaeb9010bb4bcdc20e58254fa42f3fe730a7f908 ]

Fixes various reclocking related issues on prime systems.

---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/gpu/drm/nouveau/nouveau_debugfs.c +4 -0
@@ -160,7 +160,11 @@ nouveau_debugfs_pstate_set(struct file *
 		args.ustate = value;
 	}
 
+	ret = pm_runtime_get_sync(drm->dev);
+	if (IS_ERR_VALUE(ret) && ret != -EACCES)
+		return ret;
 	ret = nvif_mthd(ctrl, NVIF_CONTROL_PSTATE_USER, &args, sizeof(args));
+	pm_runtime_put_autosuspend(drm->dev);
 	if (ret < 0)
 		return ret;
 
author maintainer
#192 lore raw

PATCH 186/235 drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Thierry Reding <[email protected]>

[ Upstream commit b59fb482b52269977ee5de205308e5b236a03917 ]

Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the memory controller). Transparently backing DMA memory with an IOMMU prevents Nouveau from properly handling such memory accesses and causes memory access faults.

As a side-note: buffers other than those allocated in instance memory don't need to be physically contiguous from the GPU's perspective since the GPU can map them into contiguous buffers using its own MMU. Mapping these buffers through the IOMMU is unnecessary and will even lead to performance degradation because of the additional translation. One exception to this are compressible buffers which need large pages. In order to enable these large pages, multiple small pages will have to be combined into one large (I/O virtually contiguous) mapping via the IOMMU. However, that is a topic outside the scope of this fix and isn't currently supported. An implementation will want to explicitly create these large pages in the Nouveau driver, so detaching from a DMA/IOMMU mapping would still be required.

---
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c +13 -0
@@ -23,6 +23,10 @@
 #ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
 #include "priv.h"
 
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+#include <asm/dma-iommu.h>
+#endif
+
 static int
 nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
 {
@@ -105,6 +109,15 @@ nvkm_device_tegra_probe_iommu(struct nvk
 	unsigned long pgsize_bitmap;
 	int ret;
 
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+	if (dev->archdata.mapping) {
+		struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+
+		arm_iommu_detach_device(dev);
+		arm_iommu_release_mapping(mapping);
+	}
+#endif
+
 	if (!tdev->func->iommu_bit)
 		return;
 
author maintainer
#193 lore raw

PATCH 187/235 tls: Fix zerocopy_from_iter iov handling

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Boris Pismenny <[email protected]>

[ Upstream commit 4718799817c5a30ae723eda21f3a6c7d8701b1a4 ]

zerocopy_from_iter iterates over the message, but it doesn't revert the updates made by the iov iteration. This patch fixes it. Now, the iov can be used after calling zerocopy_from_iter.

Fixes 3c4d75591 ("tls: kernel TLS support")
---
 net/tls/tls_sw.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
net/tls/tls_sw.c +5 -3
@@ -286,7 +286,7 @@ static int zerocopy_from_iter(struct soc
 			      int length, int *pages_used,
 			      unsigned int *size_used,
 			      struct scatterlist *to, int to_max_pages,
-			      bool charge)
+			      bool charge, bool revert)
 {
 	struct page *pages[MAX_SKB_FRAGS];
 
@@ -337,6 +337,8 @@ static int zerocopy_from_iter(struct soc
 out:
 	*size_used = size;
 	*pages_used = num_elem;
+	if (revert)
+		iov_iter_revert(from, size);
 
 	return rc;
 }
@@ -438,7 +440,7 @@ alloc_encrypted:
 				&ctx->sg_plaintext_size,
 				ctx->sg_plaintext_data,
 				ARRAY_SIZE(ctx->sg_plaintext_data),
-				true);
+				true, false);
 			if (ret)
 				goto fallback_to_reg_send;
 
@@ -826,7 +828,7 @@ int tls_sw_recvmsg(struct sock *sk,
 				err = zerocopy_from_iter(sk, &msg->msg_iter,
 							 to_copy, &pages,
 							 &chunk, &sgin[1],
-							 MAX_SKB_FRAGS,	false);
+							 MAX_SKB_FRAGS,	false, true);
 				if (err < 0)
 					goto fallback_to_reg_recv;
 
author maintainer
#194 lore raw

PATCH 188/235 parport: sunbpp: fix error return code

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Julia Lawall <[email protected]>

[ Upstream commit faa1a47388b33623e4d504c23569188907b039a0 ]

Return an error code on failure. Change leading spaces to tab on the first if.

Problem found using Coccinelle.

---
 drivers/parport/parport_sunbpp.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/parport/parport_sunbpp.c +6 -2
@@ -286,12 +286,16 @@ static int bpp_probe(struct platform_dev
 
 	ops = kmemdup(&parport_sunbpp_ops, sizeof(struct parport_operations),
 		      GFP_KERNEL);
-        if (!ops)
+	if (!ops) {
+		err = -ENOMEM;
 		goto out_unmap;
+	}
 
 	dprintk(("register_port\n"));
-	if (!(p = parport_register_port((unsigned long)base, irq, dma, ops)))
+	if (!(p = parport_register_port((unsigned long)base, irq, dma, ops))) {
+		err = -ENOMEM;
 		goto out_free_ops;
+	}
 
 	p->size = size;
 	p->dev = &op->dev;
author maintainer
#195 lore raw

PATCH 189/235 sched/fair: Fix util_avg of new tasks for asymmetric systems

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Quentin Perret <[email protected]>

[ Upstream commit 8fe5c5a937d0f4e84221631833a2718afde52285 ]

When a new task wakes-up for the first time, its initial utilization is set to half of the spare capacity of its CPU. The current implementation of post_init_entity_util_avg() uses SCHED_CAPACITY_SCALE directly as a capacity reference. As a result, on a big.LITTLE system, a new task waking up on an idle little CPU will be given ~512 of util_avg, even if the CPU's capacity is significantly less than that.

Fix this by computing the spare capacity with arch_scale_cpu_capacity().

---
 kernel/sched/fair.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)
kernel/sched/fair.c +6 -4
@@ -735,11 +735,12 @@ static void attach_entity_cfs_rq(struct
  * To solve this problem, we also cap the util_avg of successive tasks to
  * only 1/2 of the left utilization budget:
  *
- *   util_avg_cap = (1024 - cfs_rq->avg.util_avg) / 2^n
+ *   util_avg_cap = (cpu_scale - cfs_rq->avg.util_avg) / 2^n
  *
- * where n denotes the nth task.
+ * where n denotes the nth task and cpu_scale the CPU capacity.
  *
- * For example, a simplest series from the beginning would be like:
+ * For example, for a CPU with 1024 of capacity, a simplest series from
+ * the beginning would be like:
  *
  *  task  util_avg: 512, 256, 128,  64,  32,   16,    8, ...
  * cfs_rq util_avg: 512, 768, 896, 960, 992, 1008, 1016, ...
@@ -751,7 +752,8 @@ void post_init_entity_util_avg(struct sc
 {
 	struct cfs_rq *cfs_rq = cfs_rq_of(se);
 	struct sched_avg *sa = &se->avg;
-	long cap = (long)(SCHED_CAPACITY_SCALE - cfs_rq->avg.util_avg) / 2;
+	long cpu_scale = arch_scale_cpu_capacity(NULL, cpu_of(rq_of(cfs_rq)));
+	long cap = (long)(cpu_scale - cfs_rq->avg.util_avg) / 2;
 
 	if (cap > 0) {
 		if (cfs_rq->avg.util_avg != 0) {
author maintainer
#196 lore raw

PATCH 190/235 coresight: Handle errors in finding input/output ports

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Suzuki K Poulose <[email protected]>

[ Upstream commit fe470f5f7f684ed15bc49b6183a64237547910ff ]

If we fail to find the input / output port for a LINK component while enabling a path, we should fail gracefully rather than assuming port "0".

---
 drivers/hwtracing/coresight/coresight.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/hwtracing/coresight/coresight.c +5 -2
@@ -108,7 +108,7 @@ static int coresight_find_link_inport(st
 	dev_err(&csdev->dev, "couldn't find inport, parent: %s, child: %s\n",
 		dev_name(&parent->dev), dev_name(&csdev->dev));
 
-	return 0;
+	return -ENODEV;
 }
 
 static int coresight_find_link_outport(struct coresight_device *csdev,
@@ -126,7 +126,7 @@ static int coresight_find_link_outport(s
 	dev_err(&csdev->dev, "couldn't find outport, parent: %s, child: %s\n",
 		dev_name(&csdev->dev), dev_name(&child->dev));
 
-	return 0;
+	return -ENODEV;
 }
 
 static int coresight_enable_sink(struct coresight_device *csdev, u32 mode)
@@ -179,6 +179,9 @@ static int coresight_enable_link(struct
 	else
 		refport = 0;
 
+	if (refport < 0)
+		return refport;
+
 	if (atomic_inc_return(&csdev->refcnt[refport]) == 1) {
 		if (link_ops(csdev)->enable) {
 			ret = link_ops(csdev)->enable(csdev, inport, outport);
author maintainer
#197 lore raw

PATCH 191/235 coresight: tpiu: Fix disabling timeouts

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Robin Murphy <[email protected]>

[ Upstream commit ccff2dfaceaca4517432f5c149594215fe9098cc ]

Probing the TPIU driver under UBSan triggers an out-of-bounds shift warning in coresight_timeout():

...

[    5.677530] UBSAN: Undefined behaviour in drivers/hwtracing/coresight/coresight.c:929:16
[    5.685542] shift exponent 64 is too large for 64-bit type 'long unsigned int'

...

On closer inspection things are exponentially out of whack because we're passing a bitmask where a bit number should be. Amusingly, it seems that both calls will find their expected values by sheer luck and appear to
succeed: 1 << FFCR_FON_MAN ends up at bit 64 which whilst undefined evaluates as zero in practice, while 1 << FFSR_FT_STOPPED finds bit 2 (TCPresent) which apparently is usually tied high.

Following the examples of other drivers, define separate FOO and FOO_BIT macros for masks vs. indices, and put things right.

CC Robert Walker <[email protected]>
CC Mike Leach <[email protected]>
CC Mathieu Poirier <[email protected]>
Fixes 11595db8e17f ("coresight: Fix disabling of CoreSight TPIU")
---
 drivers/hwtracing/coresight/coresight-tpiu.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/hwtracing/coresight/coresight-tpiu.c +4 -3
@@ -40,8 +40,9 @@
 
 /** register definition **/
 /* FFSR - 0x300 */
-#define FFSR_FT_STOPPED		BIT(1)
+#define FFSR_FT_STOPPED_BIT	1
 /* FFCR - 0x304 */
+#define FFCR_FON_MAN_BIT	6
 #define FFCR_FON_MAN		BIT(6)
 #define FFCR_STOP_FI		BIT(12)
 
@@ -86,9 +87,9 @@ static void tpiu_disable_hw(struct tpiu_
 	/* Generate manual flush */
 	writel_relaxed(FFCR_STOP_FI | FFCR_FON_MAN, drvdata->base + TPIU_FFCR);
 	/* Wait for flush to complete */
-	coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN, 0);
+	coresight_timeout(drvdata->base, TPIU_FFCR, FFCR_FON_MAN_BIT, 0);
 	/* Wait for formatter to stop */
-	coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED, 1);
+	coresight_timeout(drvdata->base, TPIU_FFSR, FFSR_FT_STOPPED_BIT, 1);
 
 	CS_LOCK(drvdata->base);
 }
author maintainer
#198 lore raw

PATCH 192/235 coresight: ETM: Add support for Arm Cortex-A73 and Cortex-A35

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Suzuki K Poulose <[email protected]>

[ Upstream commit 5cedd22370a0a460b663c06de1fc10b4ba3c5d0b ]

Add ETM PIDs of the Arm cortex-A CPUs to the white list of ETMs. While at it add a helper macro to make it easier to add the new entries.

---
 drivers/hwtracing/coresight/coresight-etm4x.c |   31 +++++++++++---------------
 1 file changed, 14 insertions(+), 17 deletions(-)
drivers/hwtracing/coresight/coresight-etm4x.c +14 -17
@@ -1027,7 +1027,8 @@ static int etm4_probe(struct amba_device
 	}
 
 	pm_runtime_put(&adev->dev);
-	dev_info(dev, "%s initialized\n", (char *)id->data);
+	dev_info(dev, "CPU%d: ETM v%d.%d initialized\n",
+		 drvdata->cpu, drvdata->arch >> 4, drvdata->arch & 0xf);
 
 	if (boot_enable) {
 		coresight_enable(drvdata->csdev);
@@ -1045,23 +1046,19 @@ err_arch_supported:
 	return ret;
 }
 
+#define ETM4x_AMBA_ID(pid)			\
+	{					\
+		.id	= pid,			\
+		.mask	= 0x000fffff,		\
+	}
+
 static const struct amba_id etm4_ids[] = {
-	{       /* ETM 4.0 - Cortex-A53  */
-		.id	= 0x000bb95d,
-		.mask	= 0x000fffff,
-		.data	= "ETM 4.0",
-	},
-	{       /* ETM 4.0 - Cortex-A57 */
-		.id	= 0x000bb95e,
-		.mask	= 0x000fffff,
-		.data	= "ETM 4.0",
-	},
-	{       /* ETM 4.0 - A72, Maia, HiSilicon */
-		.id = 0x000bb95a,
-		.mask = 0x000fffff,
-		.data = "ETM 4.0",
-	},
-	{ 0, 0},
+	ETM4x_AMBA_ID(0x000bb95d),		/* Cortex-A53 */
+	ETM4x_AMBA_ID(0x000bb95e),		/* Cortex-A57 */
+	ETM4x_AMBA_ID(0x000bb95a),		/* Cortex-A72 */
+	ETM4x_AMBA_ID(0x000bb959),		/* Cortex-A73 */
+	ETM4x_AMBA_ID(0x000bb9da),		/* Cortex-A35 */
+	{},
 };
 
 static struct amba_driver etm4x_driver = {
author maintainer
#199 lore raw

PATCH 193/235 f2fs: do checkpoint in kill_sb

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Jaegeuk Kim <[email protected]>

[ Upstream commit 1cb50f87e10696e8cc61fb62d0d948e11b0e6dc1 ]

When unmounting f2fs in force mode, we can get it stuck by io_schedule() by some pending IOs in meta_inode.

io_schedule+0xd/0x30
wait_on_page_bit_common+0xc6/0x130
__filemap_fdatawait_range+0xbd/0x100
filemap_fdatawait_keep_errors+0x15/0x40
sync_inodes_sb+0x1cf/0x240
sync_filesystem+0x52/0x90
generic_shutdown_super+0x1d/0x110
kill_f2fs_super+0x28/0x80 [f2fs]
deactivate_locked_super+0x35/0x60
cleanup_mnt+0x36/0x70
task_work_run+0x79/0xa0
exit_to_usermode_loop+0x62/0x70
do_syscall_64+0xdb/0xf0
entry_SYSCALL_64_after_hwframe+0x44/0xa9

0xffffffffffffffff

---
 fs/f2fs/super.c |   16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)
fs/f2fs/super.c +13 -3
@@ -3106,9 +3106,19 @@ static struct dentry *f2fs_mount(struct
 static void kill_f2fs_super(struct super_block *sb)
 {
 	if (sb->s_root) {
-		set_sbi_flag(F2FS_SB(sb), SBI_IS_CLOSE);
-		f2fs_stop_gc_thread(F2FS_SB(sb));
-		f2fs_stop_discard_thread(F2FS_SB(sb));
+		struct f2fs_sb_info *sbi = F2FS_SB(sb);
+
+		set_sbi_flag(sbi, SBI_IS_CLOSE);
+		f2fs_stop_gc_thread(sbi);
+		f2fs_stop_discard_thread(sbi);
+
+		if (is_sbi_flag_set(sbi, SBI_IS_DIRTY) ||
+				!is_set_ckpt_flags(sbi, CP_UMOUNT_FLAG)) {
+			struct cp_control cpc = {
+				.reason = CP_UMOUNT,
+			};
+			f2fs_write_checkpoint(sbi, &cpc);
+		}
 	}
 	kill_block_super(sb);
 }
author maintainer
#200 lore raw

PATCH 194/235 tools/testing/nvdimm: Fix support for emulating controller temperature

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Williams <[email protected]>

[ Upstream commit e5d772fbe7685aae0dff99f3b54158a0ec32155e ]

In addition to populating the value the payload also needs to set the "controller temperature valid" flag.

Fixes cdd77d3e1930 ("nfit, libnvdimm: deprecate the generic SMART ioctl")
---
 tools/testing/nvdimm/test/nfit.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
tools/testing/nvdimm/test/nfit.c +2 -1
@@ -1308,7 +1308,8 @@ static void smart_init(struct nfit_test
 			| ND_INTEL_SMART_ALARM_VALID
 			| ND_INTEL_SMART_USED_VALID
 			| ND_INTEL_SMART_SHUTDOWN_VALID
-			| ND_INTEL_SMART_MTEMP_VALID,
+			| ND_INTEL_SMART_MTEMP_VALID
+			| ND_INTEL_SMART_CTEMP_VALID,
 		.health = ND_INTEL_SMART_NON_CRITICAL_HEALTH,
 		.media_temperature = 23 * 16,
 		.ctrl_temperature = 25 * 16,
author maintainer
#201 lore raw

PATCH 195/235 drm/amd/display: support access ddc for mst branch

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Eric Yang <[email protected]>

[ Upstream commit 0a14544661fad1606cc96aece30b2950fd9c4c81 ]

[Why]
Megachip dockings accesses ddc line through display driver when installing FW. Previously, we would fail every transaction because link attached to mst branch did not have their ddc transaction type set.

[How]
Set ddc transaction type when mst branch is connected.

---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/gpu/drm/amd/display/dc/core/dc_link.c +4 -0
@@ -497,6 +497,10 @@ static bool detect_dp(
 			sink_caps->signal = SIGNAL_TYPE_DISPLAY_PORT_MST;
 			link->type = dc_connection_mst_branch;
 
+			dal_ddc_service_set_transaction_type(
+							link->ddc,
+							sink_caps->transaction_type);
+
 			/*
 			 * This call will initiate MST topology discovery. Which
 			 * will detect MST ports and add new DRM connector DRM
author maintainer
#202 lore raw

PATCH 196/235 ASoC: qdsp6: q6afe-dai: fix a range check in of_q6afe_parse_dai_data()

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

[ Upstream commit b8110a87b75f948d978c06e130cc68026645c4a1 ]

The main thing is that the data->priv[] array has AFE_PORT_MAX elements so the > condition should be >=. But we may as well check for negative values as well just to be safe.

Fixes 24c4cbcfac09 ("ASoC: qdsp6: q6afe: Add q6afe dai driver")
---
 sound/soc/qcom/qdsp6/q6afe-dai.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/qcom/qdsp6/q6afe-dai.c +1 -1
@@ -1180,7 +1180,7 @@ static void of_q6afe_parse_dai_data(stru
 		int id, i, num_lines;
 
 		ret = of_property_read_u32(node, "reg", &id);
-		if (ret || id > AFE_PORT_MAX) {
+		if (ret || id < 0 || id >= AFE_PORT_MAX) {
 			dev_err(dev, "valid dai id not found:%d\n", ret);
 			continue;
 		}
author maintainer
#203 lore raw

PATCH 197/235 lightnvm: pblk: assume that chunks are closed on 1.2 devices

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Hans Holmberg <[email protected]>

[ Upstream commit f6352103d2e0ad2d2066725eb19bfdfb8763239b ]

We can't know if a block is closed or not on 1.2 devices, so assume closed state to make sure that blocks are erased before writing.

Fixes 32ef9412c114 ("lightnvm: pblk: implement get log report chunk")
---
 drivers/lightnvm/pblk-init.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/lightnvm/pblk-init.c +3 -2
@@ -716,10 +716,11 @@ static int pblk_setup_line_meta_12(struc
 
 		/*
 		 * In 1.2 spec. chunk state is not persisted by the device. Thus
-		 * some of the values are reset each time pblk is instantiated.
+		 * some of the values are reset each time pblk is instantiated,
+		 * so we have to assume that the block is closed.
 		 */
 		if (lun_bb_meta[line->id] == NVM_BLK_T_FREE)
-			chunk->state =  NVM_CHK_ST_FREE;
+			chunk->state =  NVM_CHK_ST_CLOSED;
 		else
 			chunk->state = NVM_CHK_ST_OFFLINE;
 
author maintainer
#204 lore raw

PATCH 198/235 lightnvm: pblk: enable line minor version detection

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Matias Bjørling <[email protected]>

[ Upstream commit 99b8dad1b6e52721904220322a947f7b75056303 ]

When recovering a line, an extra check was added when debugging was active, such that minor version where also checked. Unfortunately, this used the ifdef NVM_DEBUG, which is not correct.

Instead use the proper DEBUG def, and now that it compiles, also fix the variable.

Fixes d0ab0b1ab991f ("lightnvm: pblk: check data lines version on recovery")
---
 drivers/lightnvm/pblk-recovery.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/lightnvm/pblk-recovery.c +3 -2
@@ -742,9 +742,10 @@ static int pblk_recov_check_line_version
 		return 1;
 	}
 
-#ifdef NVM_DEBUG
+#ifdef CONFIG_NVM_PBLK_DEBUG
 	if (header->version_minor > EMETA_VERSION_MINOR)
-		pr_info("pblk: newer line minor version found: %d\n", line_v);
+		pr_info("pblk: newer line minor version found: %d\n",
+				header->version_minor);
 #endif
 
 	return 0;
author maintainer
#205 lore raw

PATCH 199/235 staging: bcm2835-audio: Dont leak workqueue if open fails

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Tuomas Tynkkynen <[email protected]>

[ Upstream commit 678c5b119307c40f9a17152512f9c949d0ec7292 ]

Currently, if bcm2835_audio_open() fails partway, the allocated workqueue is leaked. Avoid that.

While at it, propagate the return value of bcm2835_audio_open_connection() on failure instead of returning -1.

---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c |   16 +++++++-----
 1 file changed, 10 insertions(+), 6 deletions(-)
drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c +10 -6
@@ -439,16 +439,16 @@ int bcm2835_audio_open(struct bcm2835_al
 	my_workqueue_init(alsa_stream);
 
 	ret = bcm2835_audio_open_connection(alsa_stream);
-	if (ret) {
-		ret = -1;
-		goto exit;
-	}
+	if (ret)
+		goto free_wq;
+
 	instance = alsa_stream->instance;
 	LOG_DBG(" instance (%p)\n", instance);
 
 	if (mutex_lock_interruptible(&instance->vchi_mutex)) {
 		LOG_DBG("Interrupted whilst waiting for lock on (%d)\n", instance->num_connections);
-		return -EINTR;
+		ret = -EINTR;
+		goto free_wq;
 	}
 	vchi_service_use(instance->vchi_handle[0]);
 
@@ -471,7 +471,11 @@ int bcm2835_audio_open(struct bcm2835_al
 unlock:
 	vchi_service_release(instance->vchi_handle[0]);
 	mutex_unlock(&instance->vchi_mutex);
-exit:
+
+free_wq:
+	if (ret)
+		destroy_workqueue(alsa_stream->my_wq);
+
 	return ret;
 }
 
author maintainer
#206 lore raw

PATCH 200/235 gpio: pxa: Fix potential NULL dereference

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Wei Yongjun <[email protected]>

[ Upstream commit 9506755633d0b32ef76f67c345000178e9b0dfc4 ]

platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference a bit later in the code.

This is detected by Coccinelle semantic patch.

@@
expression pdev, res, n, t, e, e1, e2;
@@

res = platform_get_resource(pdev, t, n);
+ if (!res)
+ return -EINVAL;
... when != res == NULL
e = devm_ioremap(e1, res->start, e2);

---
 drivers/gpio/gpio-pxa.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/gpio/gpio-pxa.c +2 -0
@@ -665,6 +665,8 @@ static int pxa_gpio_probe(struct platfor
 	pchip->irq0 = irq0;
 	pchip->irq1 = irq1;
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -EINVAL;
 	gpio_reg_base = devm_ioremap(&pdev->dev, res->start,
 				     resource_size(res));
 	if (!gpio_reg_base)
author maintainer
#207 lore raw

PATCH 201/235 gpiolib: Mark gpio_suffixes array with __maybe_unused

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Andy Shevchenko <[email protected]>

[ Upstream commit b23ec59926faf05b0c43680d05671c484e810ac4 ]

Since we put static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it.

Mark gpio_suffixes array with __maybe_unused to hide a compiler warning:

In file included from
drivers/gpio/gpiolib-legacy.c:6:0:
drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]

 static const char * const gpio_suffixes[] = { "gpios", "gpio" };
                           ^~~~~~~~~~~~~
In file included from drivers/gpio/gpiolib-devprop.c:17:0:
drivers/gpio/gpiolib.h:95:27: warning: ‘gpio_suffixes’ defined but not used [-Wunused-const-variable=]
 static const char * const gpio_suffixes[] = { "gpios", "gpio" };
                           ^~~~~~~~~~~~~
---
 drivers/gpio/gpiolib.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpiolib.h +1 -1
@@ -92,7 +92,7 @@ struct acpi_gpio_info {
 };
 
 /* gpio suffixes used for ACPI and device tree lookup */
-static const char * const gpio_suffixes[] = { "gpios", "gpio" };
+static __maybe_unused const char * const gpio_suffixes[] = { "gpios", "gpio" };
 
 #ifdef CONFIG_OF_GPIO
 struct gpio_desc *of_find_gpio(struct device *dev,
author maintainer
#208 lore raw

PATCH 202/235 net: gemini: Allow multiple ports to instantiate

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Linus Walleij <[email protected]>

[ Upstream commit 60cc7767b901dd1e3f70755c3d2505556ba487c2 ]

The code was not tested with two ports actually in use at the same time. (I blame this on lack of actual hardware using that feature.) Now after locating a system using both ports, add necessary fix to make both ports come up.

---
 drivers/net/ethernet/cortina/gemini.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/cortina/gemini.c +4 -1
@@ -1753,7 +1753,10 @@ static int gmac_open(struct net_device *
 	phy_start(netdev->phydev);
 
 	err = geth_resize_freeq(port);
-	if (err) {
+	/* It's fine if it's just busy, the other port has set up
+	 * the freeq in that case.
+	 */
+	if (err && (err != -EBUSY)) {
 		netdev_err(netdev, "could not resize freeq\n");
 		goto err_stop_phy;
 	}
author maintainer
#209 lore raw

PATCH 203/235 net: mvpp2: make sure we use single queue mode on PPv2.1

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Maxime Chevallier <[email protected]>

[ Upstream commit 1e27a628e3f444f53ab8099dfb31c5156e38d112 ]

The PPv2 driver defines 2 "queue_modes" :
- QDIST_SINGLE_MODE, where each port share one rx queue vector between all CPUs
- QDIST_MULTI_MODE, where each port has one rx queue vector per CPU.

Multi queue mode isn't available on PPv2.1, make sure we fallback to single mode when running on this revision.

---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +6 -0
@@ -5011,6 +5011,12 @@ static int mvpp2_probe(struct platform_d
 			(unsigned long)of_device_get_match_data(&pdev->dev);
 	}
 
+	/* multi queue mode isn't supported on PPV2.1, fallback to single
+	 * mode
+	 */
+	if (priv->hw_version == MVPP21)
+		queue_mode = MVPP2_QDIST_SINGLE_MODE;
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(base))
author maintainer
#210 lore raw

PATCH 204/235 rcutorture: Use monotonic timestamp for stall detection

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit 622be33fcbc93e9b672b99ed338369eb5e843ac3 ]

The get_seconds() call is deprecated because it overflows on 32-bit architectures. The algorithm in rcu_torture_stall() can deal with the overflow, but another problem here is that using a CLOCK_REALTIME stamp can lead to a false-positive stall warning when a settimeofday() happens concurrently.

Using ktime_get_seconds() instead avoids those issues and will never overflow. The added cast to 'unsigned long' however is necessary to make ULONG_CMP_LT() work correctly.

---
 kernel/rcu/rcutorture.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
kernel/rcu/rcutorture.c +3 -2
@@ -1446,7 +1446,7 @@ static int rcu_torture_stall(void *args)
 		VERBOSE_TOROUT_STRING("rcu_torture_stall end holdoff");
 	}
 	if (!kthread_should_stop()) {
-		stop_at = get_seconds() + stall_cpu;
+		stop_at = ktime_get_seconds() + stall_cpu;
 		/* RCU CPU stall is expected behavior in following code. */
 		rcu_read_lock();
 		if (stall_cpu_irqsoff)
@@ -1455,7 +1455,8 @@ static int rcu_torture_stall(void *args)
 			preempt_disable();
 		pr_alert("rcu_torture_stall start on CPU %d.\n",
 			 smp_processor_id());
-		while (ULONG_CMP_LT(get_seconds(), stop_at))
+		while (ULONG_CMP_LT((unsigned long)ktime_get_seconds(),
+				    stop_at))
 			continue;  /* Induce RCU CPU stall warning. */
 		if (stall_cpu_irqsoff)
 			local_irq_enable();
author maintainer
#211 lore raw

PATCH 205/235 mfd: 88pm860x-i2c: switch to i2c_lock_bus(..., I2C_LOCK_SEGMENT)

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Peter Rosin <[email protected]>

[ Upstream commit 8c8f74f327a76604a499fad8c54c15e1c0ee8051 ]

Locking the root adapter for __i2c_transfer will deadlock if the device sits behind a mux-locked I2C mux. Switch to the finer-grained i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not sit behind a mux-locked mux, the two locking variants are equivalent.

---
 drivers/mfd/88pm860x-i2c.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/mfd/88pm860x-i2c.c +4 -4
@@ -146,14 +146,14 @@ int pm860x_page_reg_write(struct i2c_cli
 	unsigned char zero;
 	int ret;
 
-	i2c_lock_adapter(i2c->adapter);
+	i2c_lock_bus(i2c->adapter, I2C_LOCK_SEGMENT);
 	read_device(i2c, 0xFA, 0, &zero);
 	read_device(i2c, 0xFB, 0, &zero);
 	read_device(i2c, 0xFF, 0, &zero);
 	ret = write_device(i2c, reg, 1, &data);
 	read_device(i2c, 0xFE, 0, &zero);
 	read_device(i2c, 0xFC, 0, &zero);
-	i2c_unlock_adapter(i2c->adapter);
+	i2c_unlock_bus(i2c->adapter, I2C_LOCK_SEGMENT);
 	return ret;
 }
 EXPORT_SYMBOL(pm860x_page_reg_write);
@@ -164,14 +164,14 @@ int pm860x_page_bulk_read(struct i2c_cli
 	unsigned char zero = 0;
 	int ret;
 
-	i2c_lock_adapter(i2c->adapter);
+	i2c_lock_bus(i2c->adapter, I2C_LOCK_SEGMENT);
 	read_device(i2c, 0xfa, 0, &zero);
 	read_device(i2c, 0xfb, 0, &zero);
 	read_device(i2c, 0xff, 0, &zero);
 	ret = read_device(i2c, reg, count, buf);
 	read_device(i2c, 0xFE, 0, &zero);
 	read_device(i2c, 0xFC, 0, &zero);
-	i2c_unlock_adapter(i2c->adapter);
+	i2c_unlock_bus(i2c->adapter, I2C_LOCK_SEGMENT);
 	return ret;
 }
 EXPORT_SYMBOL(pm860x_page_bulk_read);
author maintainer
#212 lore raw

PATCH 206/235 input: rohm_bu21023: switch to i2c_lock_bus(..., I2C_LOCK_SEGMENT)

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Peter Rosin <[email protected]>

[ Upstream commit 193c2a07cfaacb9249ab0e3d34bce32490879355 ]

Locking the root adapter for __i2c_transfer will deadlock if the device sits behind a mux-locked I2C mux. Switch to the finer-grained i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not sit behind a mux-locked mux, the two locking variants are equivalent.

---
 drivers/input/touchscreen/rohm_bu21023.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/input/touchscreen/rohm_bu21023.c +2 -2
@@ -304,7 +304,7 @@ static int rohm_i2c_burst_read(struct i2
 	msg[1].len = len;
 	msg[1].buf = buf;
 
-	i2c_lock_adapter(adap);
+	i2c_lock_bus(adap, I2C_LOCK_SEGMENT);
 
 	for (i = 0; i < 2; i++) {
 		if (__i2c_transfer(adap, &msg[i], 1) < 0) {
@@ -313,7 +313,7 @@ static int rohm_i2c_burst_read(struct i2
 		}
 	}
 
-	i2c_unlock_adapter(adap);
+	i2c_unlock_bus(adap, I2C_LOCK_SEGMENT);
 
 	return ret;
 }
author maintainer
#213 lore raw

PATCH 207/235 rcu: Fix grace-period hangs due to race with CPU offline

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: "Paul E. McKenney" <[email protected]>

[ Upstream commit 1e64b15a4b102e1cd059d4d798b7a78f93341333 ]

Without special fail-safe quiescent-state-propagation checks, grace-period hangs can result from the following scenario:

1. CPU 1 goes offline.

2. Because CPU 1 is the only CPU in the system blocking the current
grace period, the grace period ends as soon as rcu_cleanup_dying_idle_cpu()'s call to rcu_report_qs_rnp() returns.

3. At this point, the leaf rcu_node structure's ->lock is no longer
held: rcu_report_qs_rnp() has released it, as it must in order to awaken the RCU grace-period kthread.

4. At this point, that same leaf rcu_node structure's ->qsmaskinitnext
field still records CPU 1 as being online. This is absolutely necessary because the scheduler uses RCU (in this case on the wake-up path while awakening RCU's grace-period kthread), and ->qsmaskinitnext contains RCU's idea as to which CPUs are online. Therefore, invoking rcu_report_qs_rnp() after clearing CPU 1's bit from ->qsmaskinitnext would result in a lockdep-RCU splat due to RCU being used from an offline CPU.

5. RCU's grace-period kthread awakens, sees that the old grace period
has completed and that a new one is needed. It therefore starts a new grace period, but because CPU 1's leaf rcu_node structure's ->qsmaskinitnext field still shows CPU 1 as being online, this new grace period is initialized to wait for a quiescent state from the now-offline CPU 1.

6. Without the fail-safe force-quiescent-state checks, there would
be no quiescent state from the now-offline CPU 1, which would eventually result in RCU CPU stall warnings and memory exhaustion.

It would be good to get rid of the special fail-safe quiescent-state propagation checks, and thus it would be good to fix things so that the above scenario cannot happen. This commit therefore adds a new ->ofl_lock to the rcu_state structure. This lock is held by rcu_gp_init() across the applying of buffered online and offline operations to the rcu_node tree, and it is also held by rcu_cleanup_dying_idle_cpu() when buffering a new offline operation. This prevents rcu_gp_init() from acquiring the leaf rcu_node structure's lock during the interval between when rcu_cleanup_dying_idle_cpu() invokes rcu_report_qs_rnp(), which releases ->lock and the re-acquisition of that same lock. This in turn prevents the failure scenario outlined above, and will hopefully eventually allow removal of the offline-CPU checks from the force-quiescent-state code path.

---
 kernel/rcu/tree.c |    6 ++++++
 kernel/rcu/tree.h |    4 ++++
 2 files changed, 10 insertions(+)
kernel/rcu/tree.c +6 -0
@@ -102,6 +102,7 @@ struct rcu_state sname##_state = { \
 	.abbr = sabbr, \
 	.exp_mutex = __MUTEX_INITIALIZER(sname##_state.exp_mutex), \
 	.exp_wake_mutex = __MUTEX_INITIALIZER(sname##_state.exp_wake_mutex), \
+	.ofl_lock = __SPIN_LOCK_UNLOCKED(sname##_state.ofl_lock), \
 }
 
 RCU_STATE_INITIALIZER(rcu_sched, 's', call_rcu_sched);
@@ -1925,11 +1926,13 @@ static bool rcu_gp_init(struct rcu_state
 	 */
 	rcu_for_each_leaf_node(rsp, rnp) {
 		rcu_gp_slow(rsp, gp_preinit_delay);
+		spin_lock(&rsp->ofl_lock);
 		raw_spin_lock_irq_rcu_node(rnp);
 		if (rnp->qsmaskinit == rnp->qsmaskinitnext &&
 		    !rnp->wait_blkd_tasks) {
 			/* Nothing to do on this leaf rcu_node structure. */
 			raw_spin_unlock_irq_rcu_node(rnp);
+			spin_unlock(&rsp->ofl_lock);
 			continue;
 		}
 
@@ -1964,6 +1967,7 @@ static bool rcu_gp_init(struct rcu_state
 		}
 
 		raw_spin_unlock_irq_rcu_node(rnp);
+		spin_unlock(&rsp->ofl_lock);
 	}
 
 	/*
@@ -3725,9 +3729,11 @@ static void rcu_cleanup_dying_idle_cpu(i
 
 	/* Remove outgoing CPU from mask in the leaf rcu_node structure. */
 	mask = rdp->grpmask;
+	spin_lock(&rsp->ofl_lock);
 	raw_spin_lock_irqsave_rcu_node(rnp, flags); /* Enforce GP memory-order guarantee. */
 	rnp->qsmaskinitnext &= ~mask;
 	raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
+	spin_unlock(&rsp->ofl_lock);
 }
 
 /*
kernel/rcu/tree.h +4 -0
@@ -384,6 +384,10 @@ struct rcu_state {
 	const char *name;			/* Name of structure. */
 	char abbr;				/* Abbreviated name. */
 	struct list_head flavors;		/* List of RCU flavors. */
+
+	spinlock_t ofl_lock ____cacheline_internodealigned_in_smp;
+						/* Synchronize offline with */
+						/*  GP pre-initialization. */
 };
 
 /* Values for rcu_state structure's gp_flags field. */
#214 lore raw

Re: [PATCH 4.18 207/235] rcu: Fix grace-period hangs due to race with CPU offline

Quoted 1 line · Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

This should not be needed in 4.18 because of a number of crude but effective grace-period forward-progress failsafes. I have not tested it in isolation. It looks harmless enough, but all testing has been in conjunction with a large number of preceding patches.

I therefore strongly recommend against backporting this one.

Thanx, Paul

Quoted 121 lines

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

From: "Paul E. McKenney" <[email protected]>

[ Upstream commit 1e64b15a4b102e1cd059d4d798b7a78f93341333 ]

Without special fail-safe quiescent-state-propagation checks, grace-period hangs can result from the following scenario:

1. CPU 1 goes offline.

2. Because CPU 1 is the only CPU in the system blocking the current
grace period, the grace period ends as soon as rcu_cleanup_dying_idle_cpu()'s call to rcu_report_qs_rnp() returns.

3. At this point, the leaf rcu_node structure's ->lock is no longer
held: rcu_report_qs_rnp() has released it, as it must in order to awaken the RCU grace-period kthread.

4. At this point, that same leaf rcu_node structure's ->qsmaskinitnext
field still records CPU 1 as being online. This is absolutely necessary because the scheduler uses RCU (in this case on the wake-up path while awakening RCU's grace-period kthread), and ->qsmaskinitnext contains RCU's idea as to which CPUs are online. Therefore, invoking rcu_report_qs_rnp() after clearing CPU 1's bit from ->qsmaskinitnext would result in a lockdep-RCU splat due to RCU being used from an offline CPU.

5. RCU's grace-period kthread awakens, sees that the old grace period
has completed and that a new one is needed. It therefore starts a new grace period, but because CPU 1's leaf rcu_node structure's ->qsmaskinitnext field still shows CPU 1 as being online, this new grace period is initialized to wait for a quiescent state from the now-offline CPU 1.

6. Without the fail-safe force-quiescent-state checks, there would
be no quiescent state from the now-offline CPU 1, which would eventually result in RCU CPU stall warnings and memory exhaustion.

It would be good to get rid of the special fail-safe quiescent-state propagation checks, and thus it would be good to fix things so that the above scenario cannot happen. This commit therefore adds a new ->ofl_lock to the rcu_state structure. This lock is held by rcu_gp_init() across the applying of buffered online and offline operations to the rcu_node tree, and it is also held by rcu_cleanup_dying_idle_cpu() when buffering a new offline operation. This prevents rcu_gp_init() from acquiring the leaf rcu_node structure's lock during the interval between when rcu_cleanup_dying_idle_cpu() invokes rcu_report_qs_rnp(), which releases ->lock and the re-acquisition of that same lock. This in turn prevents the failure scenario outlined above, and will hopefully eventually allow removal of the offline-CPU checks from the force-quiescent-state code path.

---
 kernel/rcu/tree.c |    6 ++++++
 kernel/rcu/tree.h |    4 ++++
 2 files changed, 10 insertions(+)
kernel/rcu/tree.c +6 -0
@@ -102,6 +102,7 @@ struct rcu_state sname##_state = { \
 	.abbr = sabbr, \
 	.exp_mutex = __MUTEX_INITIALIZER(sname##_state.exp_mutex), \
 	.exp_wake_mutex = __MUTEX_INITIALIZER(sname##_state.exp_wake_mutex), \
+	.ofl_lock = __SPIN_LOCK_UNLOCKED(sname##_state.ofl_lock), \
 }
 
 RCU_STATE_INITIALIZER(rcu_sched, 's', call_rcu_sched);
@@ -1925,11 +1926,13 @@ static bool rcu_gp_init(struct rcu_state
 	 */
 	rcu_for_each_leaf_node(rsp, rnp) {
 		rcu_gp_slow(rsp, gp_preinit_delay);
+		spin_lock(&rsp->ofl_lock);
 		raw_spin_lock_irq_rcu_node(rnp);
 		if (rnp->qsmaskinit == rnp->qsmaskinitnext &&
 		    !rnp->wait_blkd_tasks) {
 			/* Nothing to do on this leaf rcu_node structure. */
 			raw_spin_unlock_irq_rcu_node(rnp);
+			spin_unlock(&rsp->ofl_lock);
 			continue;
 		}
 
@@ -1964,6 +1967,7 @@ static bool rcu_gp_init(struct rcu_state
 		}
 
 		raw_spin_unlock_irq_rcu_node(rnp);
+		spin_unlock(&rsp->ofl_lock);
 	}
 
 	/*
@@ -3725,9 +3729,11 @@ static void rcu_cleanup_dying_idle_cpu(i
 
 	/* Remove outgoing CPU from mask in the leaf rcu_node structure. */
 	mask = rdp->grpmask;
+	spin_lock(&rsp->ofl_lock);
 	raw_spin_lock_irqsave_rcu_node(rnp, flags); /* Enforce GP memory-order guarantee. */
 	rnp->qsmaskinitnext &= ~mask;
 	raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
+	spin_unlock(&rsp->ofl_lock);
 }
 
 /*
kernel/rcu/tree.h +4 -0
@@ -384,6 +384,10 @@ struct rcu_state {
 	const char *name;			/* Name of structure. */
 	char abbr;				/* Abbreviated name. */
 	struct list_head flavors;		/* List of RCU flavors. */
+
+	spinlock_t ofl_lock ____cacheline_internodealigned_in_smp;
+						/* Synchronize offline with */
+						/*  GP pre-initialization. */
 };
 
 /* Values for rcu_state structure's gp_flags field. */
author maintainer
#215 lore raw

Re: [PATCH 4.18 207/235] rcu: Fix grace-period hangs due to race with CPU offline

Quoted 9 lines · Paul E. McKenney
Quoted 1 line · Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

This should not be needed in 4.18 because of a number of crude but effective grace-period forward-progress failsafes. I have not tested it in isolation. It looks harmless enough, but all testing has been in conjunction with a large number of preceding patches.

I therefore strongly recommend against backporting this one.

Now dropped from all 3 queues, thanks for letting me know.

greg k-h

author maintainer
#216 lore raw

PATCH 208/235 drm/amdkfd: Fix kernel queue 64 bit doorbell offset calculation

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Shaoyun Liu <[email protected]>

[ Upstream commit 951df6d9cfd07f205f1905bf3b27d994612e0614 ]

The bitmap index calculation should reverse the logic used on allocation so it will clear the same bit used on allocation

---
 drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c +5 -4
@@ -188,9 +188,9 @@ void __iomem *kfd_get_kernel_doorbell(st
 	*doorbell_off = kfd->doorbell_id_offset + inx;
 
 	pr_debug("Get kernel queue doorbell\n"
-			 "     doorbell offset   == 0x%08X\n"
-			 "     kernel address    == %p\n",
-		*doorbell_off, (kfd->doorbell_kernel_ptr + inx));
+			"     doorbell offset   == 0x%08X\n"
+			"     doorbell index    == 0x%x\n",
+		*doorbell_off, inx);
 
 	return kfd->doorbell_kernel_ptr + inx;
 }
@@ -199,7 +199,8 @@ void kfd_release_kernel_doorbell(struct
 {
 	unsigned int inx;
 
-	inx = (unsigned int)(db_addr - kfd->doorbell_kernel_ptr);
+	inx = (unsigned int)(db_addr - kfd->doorbell_kernel_ptr)
+		* sizeof(u32) / kfd->device_info->doorbell_size;
 
 	mutex_lock(&kfd->doorbell_mutex);
 	__clear_bit(inx, kfd->doorbell_available_index);
author maintainer
#217 lore raw

PATCH 209/235 drm/amdkfd: Fix error codes in kfd_get_process

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Wei Lu <[email protected]>

[ Upstream commit e47cb828eb3fca3e8999a0b9aa053dda18552071 ]

Return ERR_PTR(-EINVAL) if kfd_get_process fails to find the process. This fixes kernel oopses when a child process calls KFD ioctls with a file descriptor inherited from the parent process.

---
 drivers/gpu/drm/amd/amdkfd/kfd_process.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/gpu/drm/amd/amdkfd/kfd_process.c +2 -0
@@ -244,6 +244,8 @@ struct kfd_process *kfd_get_process(cons
 		return ERR_PTR(-EINVAL);
 
 	process = find_process(thread);
+	if (!process)
+		return ERR_PTR(-EINVAL);
 
 	return process;
 }
author maintainer
#218 lore raw

PATCH 210/235 rtc: bq4802: add error handling for devm_ioremap

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Zhouyang Jia <[email protected]>

[ Upstream commit 7874b919866ba91bac253fa219d3d4c82bb944df ]

When devm_ioremap fails, the lack of error-handling code may cause unexpected results.

This patch adds error-handling code after calling devm_ioremap.

---
 drivers/rtc/rtc-bq4802.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/rtc/rtc-bq4802.c +4 -0
@@ -162,6 +162,10 @@ static int bq4802_probe(struct platform_
 	} else if (p->r->flags & IORESOURCE_MEM) {
 		p->regs = devm_ioremap(&pdev->dev, p->r->start,
 					resource_size(p->r));
+		if (!p->regs){
+			err = -ENOMEM;
+			goto out;
+		}
 		p->read = bq4802_read_mem;
 		p->write = bq4802_write_mem;
 	} else {
author maintainer
#219 lore raw

PATCH 211/235 selftests: vDSO - fix to return KSFT_SKIP when test couldnt be run

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: "Shuah Khan (Samsung OSG)" <[email protected]>

[ Upstream commit d2d49495b5c0dffee5c4da5ea12ac0da6679bd08 ]

Fix to return KSFT_SKIP when test couldn't be run because AT_SYSINFO_EHDR isn't found and gettimeofday isn't defined.

---
 tools/testing/selftests/vDSO/vdso_test.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
tools/testing/selftests/vDSO/vdso_test.c +5 -2
@@ -15,6 +15,8 @@
 #include <sys/auxv.h>
 #include <sys/time.h>
 
+#include "../kselftest.h"
+
 extern void *vdso_sym(const char *version, const char *name);
 extern void vdso_init_from_sysinfo_ehdr(uintptr_t base);
 extern void vdso_init_from_auxv(void *auxv);
@@ -37,7 +39,7 @@ int main(int argc, char **argv)
 	unsigned long sysinfo_ehdr = getauxval(AT_SYSINFO_EHDR);
 	if (!sysinfo_ehdr) {
 		printf("AT_SYSINFO_EHDR is not present!\n");
-		return 0;
+		return KSFT_SKIP;
 	}
 
 	vdso_init_from_sysinfo_ehdr(getauxval(AT_SYSINFO_EHDR));
@@ -48,7 +50,7 @@ int main(int argc, char **argv)
 
 	if (!gtod) {
 		printf("Could not find %s\n", name);
-		return 1;
+		return KSFT_SKIP;
 	}
 
 	struct timeval tv;
@@ -59,6 +61,7 @@ int main(int argc, char **argv)
 		       (long long)tv.tv_sec, (long long)tv.tv_usec);
 	} else {
 		printf("%s failed\n", name);
+		return KSFT_FAIL;
 	}
 
 	return 0;
author maintainer
#220 lore raw

PATCH 212/235 selftests/android: initialize heap_type to avoid compiling warning

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Li Zhijian <[email protected]>

[ Upstream commit cc7c673032fc7427087e74b75f732b43db38a256 ]

Initialize heap_type to ION_HEAP_TYPE_SYSTEM to avoid "used uninitialized" compiler warning. heap_type gets used after initialization, this change is to just keep the compiler happy.

root@vm-lkp-nex04-8G-7 ~/linux-v4.18-rc2/tools/testing/selftests/android# make make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. make[1]: Entering directory '/root/linux-v4.18-rc2/tools/testing/selftests/android/ion'
gcc -I. -I../../../../../drivers/staging/android/uapi/ -I../../../../../usr/include/ -Wall -O2 -g ionapp_export.c ipcsocket.c ionutils.c -o ionapp_export
ionapp_export.c: In function 'main':
ionapp_export.c:91:2: warning: 'heap_type' may be used uninitialized in this function [-Wmaybe-uninitialized]
printf("heap_type: %ld, heap_size: %ld\n", heap_type, heap_size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---
 tools/testing/selftests/android/ion/ionapp_export.c |    1 +
 1 file changed, 1 insertion(+)
tools/testing/selftests/android/ion/ionapp_export.c +1 -0
@@ -51,6 +51,7 @@ int main(int argc, char *argv[])
 
 	heap_size = 0;
 	flags = 0;
+	heap_type = ION_HEAP_TYPE_SYSTEM;
 
 	while ((opt = getopt(argc, argv, "hi:s:")) != -1) {
 		switch (opt) {
author maintainer
#221 lore raw

PATCH 213/235 ALSA: pcm: Fix snd_interval_refine first/last with open min/max

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Timo Wischer <[email protected]>

[ Upstream commit ff2d6acdf6f13d9f8fdcd890844c6d7535ac1f10 ]

Without this commit the following intervals [x y), (x y) were be replaced to (y-1 y) by snd_interval_refine_last(). This was also done if y-1 is part of the previous interval.
With this changes it will be replaced with [y-1 y) in case of y-1 is part of the previous interval. A similar behavior will be used for snd_interval_refine_first().

This commit adapts the changes for alsa-lib of commit 9bb985c ("pcm: snd_interval_refine_first/last: exclude value only if also excluded before")

---
 sound/core/pcm_lib.c |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)
sound/core/pcm_lib.c +10 -4
@@ -626,27 +626,33 @@ EXPORT_SYMBOL(snd_interval_refine);
 
 static int snd_interval_refine_first(struct snd_interval *i)
 {
+	const unsigned int last_max = i->max;
+
 	if (snd_BUG_ON(snd_interval_empty(i)))
 		return -EINVAL;
 	if (snd_interval_single(i))
 		return 0;
 	i->max = i->min;
-	i->openmax = i->openmin;
-	if (i->openmax)
+	if (i->openmin)
 		i->max++;
+	/* only exclude max value if also excluded before refine */
+	i->openmax = (i->openmax && i->max >= last_max);
 	return 1;
 }
 
 static int snd_interval_refine_last(struct snd_interval *i)
 {
+	const unsigned int last_min = i->min;
+
 	if (snd_BUG_ON(snd_interval_empty(i)))
 		return -EINVAL;
 	if (snd_interval_single(i))
 		return 0;
 	i->min = i->max;
-	i->openmin = i->openmax;
-	if (i->openmin)
+	if (i->openmax)
 		i->min--;
+	/* only exclude min value if also excluded before refine */
+	i->openmin = (i->openmin && i->min <= last_min);
 	return 1;
 }
 
author maintainer
#222 lore raw

PATCH 214/235 scsi: libfc: fixup sleeping function called from invalid context

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Hannes Reinecke <[email protected]>

[ Upstream commit fa519f701d27198a2858bb108fc18ea9d8c106a7 ]

fc_rport_login() will be calling mutex_lock() while running inside an RCU-protected section, triggering the warning 'sleeping function called from invalid context'. To fix this we can drop the rcu functions here altogether as the disc mutex protecting the list itself is already held, preventing any list manipulation.

Fixes a407c593398c ("scsi: libfc: Fixup disc_mutex handling")
---
 drivers/scsi/libfc/fc_disc.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/scsi/libfc/fc_disc.c +4 -3
@@ -294,9 +294,11 @@ static void fc_disc_done(struct fc_disc
 	 * discovery, reverify or log them in.	Otherwise, log them out.
 	 * Skip ports which were never discovered.  These are the dNS port
 	 * and ports which were created by PLOGI.
+	 *
+	 * We don't need to use the _rcu variant here as the rport list
+	 * is protected by the disc mutex which is already held on entry.
 	 */
-	rcu_read_lock();
-	list_for_each_entry_rcu(rdata, &disc->rports, peers) {
+	list_for_each_entry(rdata, &disc->rports, peers) {
 		if (!kref_get_unless_zero(&rdata->kref))
 			continue;
 		if (rdata->disc_id) {
@@ -307,7 +309,6 @@ static void fc_disc_done(struct fc_disc
 		}
 		kref_put(&rdata->kref, fc_rport_destroy);
 	}
-	rcu_read_unlock();
 	mutex_unlock(&disc->disc_mutex);
 	disc->disc_callback(lport, event);
 	mutex_lock(&disc->disc_mutex);
author maintainer
#223 lore raw

PATCH 215/235 scsi: lpfc: Fix NVME Target crash in defer rcv logic

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: James Smart <[email protected]>

[ Upstream commit 6871e8144f935a1f08e7fc6269c894861ce494aa ]

Kernel occasionally crashed with the following
ops on NVME Target:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
  IP: [<ffffffffa042ee50>] lpfc_nvmet_defer_rcv+0x50/0x70 [lpfc]

Callback routine was called for deferred rcv when it should be treated as a normal rcv.

Added code in callback routine to detect this condition and log a message, then bail.

---
 drivers/scsi/lpfc/lpfc_nvmet.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_nvmet.c +11 -1
@@ -402,6 +402,7 @@ lpfc_nvmet_ctxbuf_post(struct lpfc_hba *
 
 		/* Process FCP command */
 		if (rc == 0) {
+			ctxp->rqb_buffer = NULL;
 			atomic_inc(&tgtp->rcv_fcp_cmd_out);
 			nvmebuf->hrq->rqbp->rqb_free_buffer(phba, nvmebuf);
 			return;
@@ -1116,8 +1117,17 @@ lpfc_nvmet_defer_rcv(struct nvmet_fc_tar
 	lpfc_nvmeio_data(phba, "NVMET DEFERRCV: xri x%x sz %d CPU %02x\n",
 			 ctxp->oxid, ctxp->size, smp_processor_id());
 
+	if (!nvmebuf) {
+		lpfc_printf_log(phba, KERN_INFO, LOG_NVME_IOERR,
+				"6425 Defer rcv: no buffer xri x%x: "
+				"flg %x ste %x\n",
+				ctxp->oxid, ctxp->flag, ctxp->state);
+		return;
+	}
+
 	tgtp = phba->targetport->private;
-	atomic_inc(&tgtp->rcv_fcp_cmd_defer);
+	if (tgtp)
+		atomic_inc(&tgtp->rcv_fcp_cmd_defer);
 
 	/* Free the nvmebuf since a new buffer already replaced it */
 	nvmebuf->hrq->rqbp->rqb_free_buffer(phba, nvmebuf);
author maintainer
#224 lore raw

PATCH 216/235 scsi: lpfc: Fix panic if driver unloaded when port is offline

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: James Smart <[email protected]>

[ Upstream commit d580c6137476ab307a66e278cf7dbc666230f714 ]

System crashes when the lpfc module is unloaded after making the port offline

The nvme queue pointers were freed during port offline, but were later accessed in pci remove path.

Validate the pointers in pci remove path before accessing them.

---
 drivers/scsi/lpfc/lpfc_nvme.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/scsi/lpfc/lpfc_nvme.c +4 -1
@@ -2976,7 +2976,7 @@ lpfc_nvme_wait_for_io_drain(struct lpfc_
 	struct lpfc_sli_ring  *pring;
 	u32 i, wait_cnt = 0;
 
-	if (phba->sli_rev < LPFC_SLI_REV4)
+	if (phba->sli_rev < LPFC_SLI_REV4 || !phba->sli4_hba.nvme_wq)
 		return;
 
 	/* Cycle through all NVME rings and make sure all outstanding
@@ -2985,6 +2985,9 @@ lpfc_nvme_wait_for_io_drain(struct lpfc_
 	for (i = 0; i < phba->cfg_nvme_io_channel; i++) {
 		pring = phba->sli4_hba.nvme_wq[i]->pring;
 
+		if (!pring)
+			continue;
+
 		/* Retrieve everything on the txcmplq */
 		while (!list_empty(&pring->txcmplq)) {
 			msleep(LPFC_XRI_EXCH_BUSY_WAIT_T1);
author maintainer
#225 lore raw

PATCH 217/235 remoteproc: qcom: q6v5-pil: fix modem hang on SDM845 after axis2 clk unvote

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Sibi Sankar <[email protected]>

[ Upstream commit 7cbb540a3a68e4d4a8bef2d9451afb1635b5d2d3 ]

GCC_MSS_AXIS2 clock is used for disabling boot IMEM (a part of AP boot up). With Boot IMEM disable now a part TZ/ATF, AXIS2 clock is no longer required post AP boot up and expected to remain untouched. However if the clock is turned ON after Q6 is brought out of reset and later turned off, it results in modem hang. When Q6 attempts a power collapse the internal handshaking to check if AXIS2 is idle never goes through since it is turned off preventing the RSC from getting triggered, leaving modem in a funky state. Hence removing AXIS2 clk enable/disable from the driver.

---
 drivers/remoteproc/qcom_q6v5_pil.c |    1 -
 1 file changed, 1 deletion(-)
drivers/remoteproc/qcom_q6v5_pil.c +0 -1
@@ -1370,7 +1370,6 @@ static const struct rproc_hexagon_res sd
 	.hexagon_mba_image = "mba.mbn",
 	.proxy_clk_names = (char*[]){
 			"xo",
-			"axis2",
 			"prng",
 			NULL
 	},
author maintainer
#226 lore raw

PATCH 218/235 selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET/other clock adjustments are in progress

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: John Stultz <[email protected]>

[ Upstream commit 1416270f4a1ae83ea84156ceba19a66a8f88be1f ]

In the past we've warned when ADJ_OFFSET was in progress, usually caused by ntpd or some other time adjusting daemon running in non steady sate, which can cause the skew calculations to be incorrect.

Thus, this patch checks to see if the clock was being adjusted when we fail so that we don't cause false negatives.

Cc Thomas Gleixner <tglx at linutronix.de>
Cc Ingo Molnar <mingo at kernel.org>
Cc Miroslav Lichvar <mlichvar at redhat.com>
Cc Richard Cochran <richardcochran at gmail.com>
Cc Prarit Bhargava <prarit at redhat.com>
Cc Stephen Boyd <sboyd at kernel.org>
Cc Shuah Khan <shuah at kernel.org>
Cc linux-kselftest at vger.kernel.org
Suggested-by Miroslav Lichvar <mlichvar at redhat.com>
Signed-off-by John Stultz <john.stultz at linaro.org>
Signed-off-by Greg Kroah-Hartman <gregkh at linuxfoundation.org>

---
v2: Widened the checks to look for other clock adjustments that
could happen, as suggested by Miroslav
v3: Fixed up commit message
Signed-off-by: Sasha Levin <alexander.levin at microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

---
 tools/testing/selftests/timers/raw_skew.c |    5 +++++
 1 file changed, 5 insertions(+)
tools/testing/selftests/timers/raw_skew.c +5 -0
@@ -134,6 +134,11 @@ int main(int argv, char **argc)
 	printf(" %lld.%i(act)", ppm/1000, abs((int)(ppm%1000)));
 
 	if (llabs(eppm - ppm) > 1000) {
+		if (tx1.offset || tx2.offset ||
+		    tx1.freq != tx2.freq || tx1.tick != tx2.tick) {
+			printf("	[SKIP]\n");
+			return ksft_exit_skip("The clock was adjusted externally. Shutdown NTPd or other time sync daemons\n");
+		}
 		printf("	[FAILED]\n");
 		return ksft_exit_fail();
 	}
author maintainer
#227 lore raw

PATCH 219/235 ASoC: rt5651: Fix workqueue cancel vs irq free race on remove

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>

[ Upstream commit 8d2d7bcdc1645dc243f7735278675b083c0e506c ]

On removal we must free the IRQ *before* cancelling the jack-detect work, so that the jack-detect work cannot be rescheduled by the IRQ.

Before this commit we were cancelling the jack-detect work from the driver remove callback, while relying on devm to free the IRQ, which happens after the remove callback.

This is the wrong order. This commit uses a devm-action to register a devm callback which cancels the work, before requesting the IRQ (devm tears things down in reverse order). This also allows us to remove the now empty remove driver callback.

---
 sound/soc/codecs/rt5651.c |   22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)
sound/soc/codecs/rt5651.c +12 -10
@@ -1696,6 +1696,13 @@ static irqreturn_t rt5651_irq(int irq, v
 	return IRQ_HANDLED;
 }
 
+static void rt5651_cancel_work(void *data)
+{
+	struct rt5651_priv *rt5651 = data;
+
+	cancel_work_sync(&rt5651->jack_detect_work);
+}
+
 static int rt5651_set_jack(struct snd_soc_component *component,
 			   struct snd_soc_jack *hp_jack, void *data)
 {
@@ -2036,6 +2043,11 @@ static int rt5651_i2c_probe(struct i2c_c
 
 	INIT_WORK(&rt5651->jack_detect_work, rt5651_jack_detect_work);
 
+	/* Make sure work is stopped on probe-error / remove */
+	ret = devm_add_action_or_reset(&i2c->dev, rt5651_cancel_work, rt5651);
+	if (ret)
+		return ret;
+
 	ret = devm_snd_soc_register_component(&i2c->dev,
 				&soc_component_dev_rt5651,
 				rt5651_dai, ARRAY_SIZE(rt5651_dai));
@@ -2043,15 +2055,6 @@ static int rt5651_i2c_probe(struct i2c_c
 	return ret;
 }
 
-static int rt5651_i2c_remove(struct i2c_client *i2c)
-{
-	struct rt5651_priv *rt5651 = i2c_get_clientdata(i2c);
-
-	cancel_work_sync(&rt5651->jack_detect_work);
-
-	return 0;
-}
-
 static struct i2c_driver rt5651_i2c_driver = {
 	.driver = {
 		.name = "rt5651",
@@ -2059,7 +2062,6 @@ static struct i2c_driver rt5651_i2c_driv
 		.of_match_table = of_match_ptr(rt5651_of_match),
 	},
 	.probe = rt5651_i2c_probe,
-	.remove   = rt5651_i2c_remove,
 	.id_table = rt5651_i2c_id,
 };
 module_i2c_driver(rt5651_i2c_driver);
author maintainer
#228 lore raw

PATCH 220/235 drm/panel: type promotion bug in s6e8aa0_read_mtp_id()

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

[ Upstream commit cd0e0ca69109d025b1a1b6609f70682db62138b0 ]

The ARRAY_SIZE() macro is type size_t. If s6e8aa0_dcs_read() returns a negative error code, then "ret < ARRAY_SIZE(id)" is false because the negative error code is type promoted to a high positive value.

---
 drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c +1 -1
@@ -823,7 +823,7 @@ static void s6e8aa0_read_mtp_id(struct s
 	int ret, i;
 
 	ret = s6e8aa0_dcs_read(ctx, 0xd1, id, ARRAY_SIZE(id));
-	if (ret < ARRAY_SIZE(id) || id[0] == 0x00) {
+	if (ret < 0 || ret < ARRAY_SIZE(id) || id[0] == 0x00) {
 		dev_err(ctx->dev, "read id failed\n");
 		ctx->error = -EIO;
 		return;
author maintainer
#229 lore raw

PATCH 221/235 arm64: perf: Disable PMU while processing counter overflows

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Suzuki K Poulose <[email protected]>

[ Upstream commit 3cce50dfec4a5b0414c974190940f47dd32c6dee ]

The arm64 PMU updates the event counters and reprograms the counters in the overflow IRQ handler without disabling the PMU. This could potentially cause skews in for group counters, where the overflowed counters may potentially loose some event counts, while they are reprogrammed. To prevent this, disable the PMU while we process the counter overflows and enable it right back when we are done.

This patch also moves the PMU stop/start routines to avoid a forward declaration.

---
 arch/arm64/kernel/perf_event.c |   50 ++++++++++++++++++++++-------------------
 1 file changed, 28 insertions(+), 22 deletions(-)
arch/arm64/kernel/perf_event.c +28 -22
@@ -670,6 +670,28 @@ static void armv8pmu_disable_event(struc
 	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
 }
 
+static void armv8pmu_start(struct arm_pmu *cpu_pmu)
+{
+	unsigned long flags;
+	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
+
+	raw_spin_lock_irqsave(&events->pmu_lock, flags);
+	/* Enable all counters */
+	armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
+	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
+}
+
+static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
+{
+	unsigned long flags;
+	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
+
+	raw_spin_lock_irqsave(&events->pmu_lock, flags);
+	/* Disable all counters */
+	armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMU_PMCR_E);
+	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
+}
+
 static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
 {
 	u32 pmovsr;
@@ -694,6 +716,11 @@ static irqreturn_t armv8pmu_handle_irq(s
 	 */
 	regs = get_irq_regs();
 
+	/*
+	 * Stop the PMU while processing the counter overflows
+	 * to prevent skews in group events.
+	 */
+	armv8pmu_stop(cpu_pmu);
 	for (idx = 0; idx < cpu_pmu->num_events; ++idx) {
 		struct perf_event *event = cpuc->events[idx];
 		struct hw_perf_event *hwc;
@@ -718,6 +745,7 @@ static irqreturn_t armv8pmu_handle_irq(s
 		if (perf_event_overflow(event, &data, regs))
 			cpu_pmu->disable(event);
 	}
+	armv8pmu_start(cpu_pmu);
 
 	/*
 	 * Handle the pending perf events.
@@ -731,28 +759,6 @@ static irqreturn_t armv8pmu_handle_irq(s
 	return IRQ_HANDLED;
 }
 
-static void armv8pmu_start(struct arm_pmu *cpu_pmu)
-{
-	unsigned long flags;
-	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
-
-	raw_spin_lock_irqsave(&events->pmu_lock, flags);
-	/* Enable all counters */
-	armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
-	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
-}
-
-static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
-{
-	unsigned long flags;
-	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
-
-	raw_spin_lock_irqsave(&events->pmu_lock, flags);
-	/* Disable all counters */
-	armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMU_PMCR_E);
-	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
-}
-
 static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc,
 				  struct perf_event *event)
 {
author maintainer
#230 lore raw

PATCH 222/235 drm/amd/pp: Send khz clock values to DC for smu7/8

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Harry Wentland <[email protected]>

[ Upstream commit c3cb424a086921f6bb0449b10d998352a756d6d5 ]

The previous change wasn't covering smu 7 and 8 and therefore DC was seeing wrong clock values.

This fixes an issue where the pipes seem to hang with a 4k DP and 1080p HDMI display.

Fixes c3df50abc84b ("drm/amd/pp: Convert clock unit to KHz as defined")
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |    8 ++++----
 drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c |    6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +4 -4
@@ -4555,12 +4555,12 @@ static int smu7_get_sclks(struct pp_hwmg
 			return -EINVAL;
 		dep_sclk_table = table_info->vdd_dep_on_sclk;
 		for (i = 0; i < dep_sclk_table->count; i++)
-			clocks->clock[i] = dep_sclk_table->entries[i].clk;
+			clocks->clock[i] = dep_sclk_table->entries[i].clk * 10;
 		clocks->count = dep_sclk_table->count;
 	} else if (hwmgr->pp_table_version == PP_TABLE_V0) {
 		sclk_table = hwmgr->dyn_state.vddc_dependency_on_sclk;
 		for (i = 0; i < sclk_table->count; i++)
-			clocks->clock[i] = sclk_table->entries[i].clk;
+			clocks->clock[i] = sclk_table->entries[i].clk * 10;
 		clocks->count = sclk_table->count;
 	}
 
@@ -4592,7 +4592,7 @@ static int smu7_get_mclks(struct pp_hwmg
 			return -EINVAL;
 		dep_mclk_table = table_info->vdd_dep_on_mclk;
 		for (i = 0; i < dep_mclk_table->count; i++) {
-			clocks->clock[i] = dep_mclk_table->entries[i].clk;
+			clocks->clock[i] = dep_mclk_table->entries[i].clk * 10;
 			clocks->latency[i] = smu7_get_mem_latency(hwmgr,
 						dep_mclk_table->entries[i].clk);
 		}
@@ -4600,7 +4600,7 @@ static int smu7_get_mclks(struct pp_hwmg
 	} else if (hwmgr->pp_table_version == PP_TABLE_V0) {
 		mclk_table = hwmgr->dyn_state.vddc_dependency_on_mclk;
 		for (i = 0; i < mclk_table->count; i++)
-			clocks->clock[i] = mclk_table->entries[i].clk;
+			clocks->clock[i] = mclk_table->entries[i].clk * 10;
 		clocks->count = mclk_table->count;
 	}
 	return 0;
drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c +3 -3
@@ -1605,17 +1605,17 @@ static int smu8_get_clock_by_type(struct
 	switch (type) {
 	case amd_pp_disp_clock:
 		for (i = 0; i < clocks->count; i++)
-			clocks->clock[i] = data->sys_info.display_clock[i];
+			clocks->clock[i] = data->sys_info.display_clock[i] * 10;
 		break;
 	case amd_pp_sys_clock:
 		table = hwmgr->dyn_state.vddc_dependency_on_sclk;
 		for (i = 0; i < clocks->count; i++)
-			clocks->clock[i] = table->entries[i].clk;
+			clocks->clock[i] = table->entries[i].clk * 10;
 		break;
 	case amd_pp_mem_clock:
 		clocks->count = SMU8_NUM_NBPMEMORYCLOCK;
 		for (i = 0; i < clocks->count; i++)
-			clocks->clock[i] = data->sys_info.nbp_memory_clock[clocks->count - 1 - i];
+			clocks->clock[i] = data->sys_info.nbp_memory_clock[clocks->count - 1 - i] * 10;
 		break;
 	default:
 		return -1;
#231 lore raw

RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 11 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 2 lines

4.18-stable review patch. If anyone has any objections, please let me know.

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Thanks,

Alex

Quoted 88 lines

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

From: Harry Wentland <[email protected]>

[ Upstream commit c3cb424a086921f6bb0449b10d998352a756d6d5 ]

The previous change wasn't covering smu 7 and 8 and therefore DC was seeing wrong clock values.

This fixes an issue where the pipes seem to hang with a 4k DP and 1080p HDMI display.

Fixes c3df50abc84b ("drm/amd/pp: Convert clock unit to KHz as defined")
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |    8 ++++----
 drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c |    6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +3 -3
@@ -4555,12 +4555,12 @@ static int smu7_get_sclks(struct pp_hwmg
 			return -EINVAL;
 		dep_sclk_table = table_info->vdd_dep_on_sclk;
 		for (i = 0; i < dep_sclk_table->count; i++)
-			clocks->clock[i] = dep_sclk_table->entries[i].clk;
+			clocks->clock[i] = dep_sclk_table->entries[i].clk * 10;
 		clocks->count = dep_sclk_table->count;
 	} else if (hwmgr->pp_table_version == PP_TABLE_V0) {
 		sclk_table = hwmgr->dyn_state.vddc_dependency_on_sclk;
 		for (i = 0; i < sclk_table->count; i++)
-			clocks->clock[i] = sclk_table->entries[i].clk;
+			clocks->clock[i] = sclk_table->entries[i].clk * 10;
 		clocks->count = sclk_table->count;
 	}
 
@@ -4592,7 +4592,7 @@ static int smu7_get_mclks(struct pp_hwmg
 			return -EINVAL;
 		dep_mclk_table = table_info->vdd_dep_on_mclk;
 		for (i = 0; i < dep_mclk_table->count; i++) {
-			clocks->clock[i] = dep_mclk_table->entries[i].clk;
+			clocks->clock[i] = dep_mclk_table->entries[i].clk * 10;
 			clocks->latency[i] = smu7_get_mem_latency(hwmgr,
 						dep_mclk_table-
 >entries[i].clk);
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +1 -1
 		}
@@ -4600,7 +4600,7 @@ static int smu7_get_mclks(struct pp_hwmg
 	} else if (hwmgr->pp_table_version == PP_TABLE_V0) {
 		mclk_table = hwmgr-
 >dyn_state.vddc_dependency_on_mclk;
 		for (i = 0; i < mclk_table->count; i++)
-			clocks->clock[i] = mclk_table->entries[i].clk;
+			clocks->clock[i] = mclk_table->entries[i].clk * 10;
 		clocks->count = mclk_table->count;
 	}
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +0 -0
 	return 0;
drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c +3 -3
@@ -1605,17 +1605,17 @@ static int smu8_get_clock_by_type(struct
 	switch (type) {
 	case amd_pp_disp_clock:
 		for (i = 0; i < clocks->count; i++)
-			clocks->clock[i] = data->sys_info.display_clock[i];
+			clocks->clock[i] = data->sys_info.display_clock[i] * 10;
 		break;
 	case amd_pp_sys_clock:
 		table = hwmgr->dyn_state.vddc_dependency_on_sclk;
 		for (i = 0; i < clocks->count; i++)
-			clocks->clock[i] = table->entries[i].clk;
+			clocks->clock[i] = table->entries[i].clk * 10;
 		break;
 	case amd_pp_mem_clock:
 		clocks->count = SMU8_NUM_NBPMEMORYCLOCK;
 		for (i = 0; i < clocks->count; i++)
-			clocks->clock[i] = data-
 >sys_info.nbp_memory_clock[clocks->count - 1 - i];
+			clocks->clock[i] = data-
Quoted 1 line

sys_info.nbp_memory_clock[clocks->count - 1

+- i] * 10;

drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c +0 -0
 		break;
 	default:
 		return -1;
author maintainer
#232 lore raw

Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 11 lines · Alexander
Quoted 11 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 5 lines
Quoted 2 lines

4.18-stable review patch. If anyone has any objections, please let me know.

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.

thanks,

greg k-h

#233 lore raw

RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 24 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 12 lines · Alexander
Quoted 12 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8

Quoted 1 line
Quoted 1 line

4.18-stable review patch. If anyone has any objections, please let me

Quoted 9 lines

know.

Quoted 4 lines
Quoted 1 line

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.

There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.

Alex

Quoted 3 lines

thanks,

greg k-h

#234 lore raw

RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Hi Alex,

Yes, we have fixed this issue in drm-next.
I am trying to dig out the patches in drm-next and will sent them out.

Regards
Rex

Quoted 55 lines

-----Original Message-----
From: Deucher, Alexander
Sent: Tuesday, October 9, 2018 12:02 AM
To: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 6 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;

Sasha

Quoted 19 lines

Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 12 lines · Alexander
Quoted 12 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8

Quoted 2 lines
Quoted 2 lines

4.18-stable review patch. If anyone has any objections, please let me

Quoted 9 lines

know.

Quoted 4 lines
Quoted 1 line

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.

There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.

Alex

Quoted 3 lines

thanks,

greg k-h

author maintainer
#235 lore raw

Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

In reply to Deucher, Alexander
Quoted 30 lines · Alexander
Quoted 30 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 12 lines · Alexander
Quoted 12 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8

Quoted 1 line
Quoted 1 line

4.18-stable review patch. If anyone has any objections, please let me

know.

Quoted 4 lines
Quoted 1 line

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Quoted 7 lines
Quoted 3 lines

Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.

There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.

So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.

confused,

greg k-h

#236 lore raw

RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 49 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 1:11 PM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 6 lines · Alexander
Quoted 6 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;

Sasha

Quoted 5 lines
Quoted 5 lines

Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander wrote:

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>;

Sasha

Quoted 17 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines

Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8

4.18-stable review patch. If anyone has any objections, please let me

know.

Quoted 4 lines
Quoted 1 line

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.

Quoted 6 lines
Quoted 3 lines

There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.

So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.

Sorry, what statement about drm-next? This patch was for 4.19 and was not intended for 4.18. It was picked up by Sasha's auto select system for stable.

Alex

author maintainer
#237 lore raw

Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 49 lines · Alexander
Quoted 49 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 1:11 PM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 6 lines · Alexander
Quoted 6 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;

Sasha

Quoted 5 lines
Quoted 5 lines

Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander wrote:

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>;

Sasha

Quoted 17 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines

Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8

4.18-stable review patch. If anyone has any objections, please let me

know.

Quoted 4 lines
Quoted 1 line

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

There's no breakage in upstream. This patch addressed breakages in 4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.

So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.

Sorry, what statement about drm-next? This patch was for 4.19 and was not intended for 4.18. It was picked up by Sasha's auto select system for stable.

I thought this thread said that.

Ok, so I should just revert it?

thanks,

greg k-h

#238 lore raw

RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 72 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Tuesday, October 9, 2018 8:45 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 6 lines · Alexander
Quoted 6 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 1:11 PM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;

Sasha

Quoted 18 lines
Quoted 18 lines

Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 7 lines · Alexander
Quoted 7 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;

Sasha

Quoted 5 lines
Quoted 5 lines

Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander

Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex

<[email protected]>;

Quoted 26 lines
Quoted 25 lines

Sasha

Quoted 13 lines
Quoted 13 lines
Quoted 7 lines
Quoted 7 lines

Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8

4.18-stable review patch. If anyone has any objections, please let me

know.

Quoted 4 lines
Quoted 1 line

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Quoted 8 lines
Quoted 3 lines

Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.

There's no breakage in upstream. This patch addressed breakages in
4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.

So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.

Quoted 7 lines
Quoted 1 line

Sorry, what statement about drm-next? This patch was for 4.19 and was

not intended for 4.18. It was picked up by Sasha's auto select system for stable.

I thought this thread said that.

Ok, so I should just revert it?

Yes, please.

Thanks,

Alex

author maintainer
#239 lore raw

Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 73 lines · Alexander
Quoted 73 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Tuesday, October 9, 2018 8:45 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 6 lines · Alexander
Quoted 6 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 1:11 PM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;

Sasha

Quoted 18 lines
Quoted 18 lines

Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 7 lines · Alexander
Quoted 7 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, October 8, 2018 10:44 AM
To: Deucher, Alexander <[email protected]>
Cc: [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>;

Sasha

Quoted 5 lines
Quoted 5 lines

Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander

Quoted 8 lines · wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex

<[email protected]>;

Quoted 27 lines
Quoted 18 lines

Sasha

Quoted 17 lines
Quoted 16 lines
Quoted 7 lines
Quoted 7 lines

Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8

4.18-stable review patch. If anyone has any objections, please let me

know.

Quoted 4 lines
Quoted 1 line

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Is it reverted in "upstream" as well? If not, please get the fix in there and then I will be glad to backport it here.

Quoted 7 lines
Quoted 4 lines

There's no breakage in upstream. This patch addressed breakages in
4.19 specifically due to some other refactoring we did in the driver. I'll try and dig out the exact series of patches this addressed.

So there is no problem in 4.19-rc7? That contridicts the statement of looking in drm-next for the fixes.

Sorry, what statement about drm-next? This patch was for 4.19 and was

Quoted 8 lines
Quoted 6 lines

not intended for 4.18. It was picked up by Sasha's auto select system for stable.

I thought this thread said that.

Ok, so I should just revert it?

Yes, please.

Now reverted, thanks.

greg k-h

maintainer
#240 lore raw

Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

In reply to Deucher, Alexander
Quoted 11 lines · Alexander
Quoted 11 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 5 lines
Quoted 2 lines

4.18-stable review patch. If anyone has any objections, please let me know.

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Hi Alex,

Thank you for the report.

I'm working on improving this process, I'd be very grateful if you could answer a few questions about this:

1. Is the same breakage seen upstream? (if so, it should be reverted there as well and we can grab the revert into -stable).
2. Does the issue reported by this patch ("pipes seem to hang with a 4k DP and 1080p HDMI display") exist in the 4.18 stable tree?
3. If not, could you briefly explain why?

The algorithm I use was very confident about this patch being stable material, and when I looked at it back then (and again now) I was very confident of the same. If I can understand where I was wrong I could improve my process.

Thank you!

#241 lore raw

RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 33 lines

-----Original Message-----
From: Sasha Levin <[email protected]>
Sent: Monday, October 8, 2018 10:49 AM
To: Deucher, Alexander <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>; linux- [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 12 lines · Alexander
Quoted 12 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8

Quoted 1 line
Quoted 1 line

4.18-stable review patch. If anyone has any objections, please let me

know.

Quoted 4 lines
Quoted 1 line

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Hi Alex,

Quoted 7 lines

Thank you for the report.

I'm working on improving this process, I'd be very grateful if you could answer a few questions about this:

1. Is the same breakage seen upstream? (if so, it should be reverted there as well and we can grab the revert into -stable).

No regression in 4.19 or -next.

Quoted 2 lines

2. Does the issue reported by this patch ("pipes seem to hang with a 4k DP and 1080p HDMI display") exist in the 4.18 stable tree?

I don't think so, but I'm not 100% sure. Harry, Rex do you know if this is a general issue or was it just fall out from the changes to the interface?

Quoted 1 line

3. If not, could you briefly explain why?

We refactored the interface between the power and display components and this patch fixed up some of that fallout due to the differences in units used in each component.

Quoted 5 lines

The algorithm I use was very confident about this patch being stable material, and when I looked at it back then (and again now) I was very confident of the same. If I can understand where I was wrong I could improve my process.

There are some other dependent patches required that were not flagged in the patch itself. IIRC, they were a bit big for stable.

Alex

Acked-by Alex Deucher Acked-by
#242 lore raw

Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 41 lines · Alexander
Quoted 33 lines

-----Original Message-----
From: Sasha Levin <[email protected]>
Sent: Monday, October 8, 2018 10:49 AM
To: Deucher, Alexander <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>; linux- [email protected]; [email protected]; Wentland, Harry <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for smu7/8

Quoted 12 lines · Alexander
Quoted 12 lines

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, September 24, 2018 7:53 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; Wentland, Harry <[email protected]>; Deucher, Alexander <[email protected]>; Zhu, Rex <[email protected]>; Sasha Levin <[email protected]>
Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
smu7/8

Quoted 1 line
Quoted 1 line

4.18-stable review patch. If anyone has any objections, please let me

know.

Quoted 4 lines
Quoted 1 line

This regresses power usage on 4.18. Please revert.
https://bugzilla.kernel.org/show_bug.cgi?id=201275

Hi Alex,

Quoted 7 lines

Thank you for the report.

I'm working on improving this process, I'd be very grateful if you could answer a few questions about this:

1. Is the same breakage seen upstream? (if so, it should be reverted there as well and we can grab the revert into -stable).

Quoted 7 lines

No regression in 4.19 or -next.

Quoted 2 lines

2. Does the issue reported by this patch ("pipes seem to hang with a 4k DP and 1080p HDMI display") exist in the 4.18 stable tree?

I don't think so, but I'm not 100% sure. Harry, Rex do you know if this is a general issue or was it just fall out from the changes to the interface?

It was intended to deal with fallout to smu7/8 caused by the change to move the kHz-to-10kHz-conversion from display to powerplay. I believe that conversion initially overlooked these blocks. Rex, please correct me if I'm wrong. You probably know more about this than I do.

So yes, I agree, it was never intended to be used without the change to drop the *10 in display code, which was done with this change:

commit 23ec3d1479fd79658cd52c47618d8ddd2f32550b

Author: Rex Zhu <[email protected]>
Date:   Mon Jun 18 18:15:15 2018 +0800

drm/amd/pp: Convert clock unit to KHz as defined

Convert clock unit 10KHz to KHz as the data sturct defined. e.g.
struct pp_clock_with_latency {
uint32_t clocks_in_khz;
uint32_t latency_in_us;
};
Meanwhile revert the same conversion in display side.

I don't see this change in the 4.18.y stable tree. I probably should've caught that with the initial 4.18-stable review patch.

Harry

Quoted 14 lines
Quoted 1 line

3. If not, could you briefly explain why?

We refactored the interface between the power and display components and this patch fixed up some of that fallout due to the differences in units used in each component.

Quoted 5 lines

The algorithm I use was very confident about this patch being stable material, and when I looked at it back then (and again now) I was very confident of the same. If I can understand where I was wrong I could improve my process.

There are some other dependent patches required that were not flagged in the patch itself. IIRC, they were a bit big for stable.

Alex

author maintainer
#243 lore raw

PATCH 223/235 dmaengine: sh: rcar-dmac: avoid to write CHCR.TE to 1 if TCR is set to 0

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Yoshihiro Shimoda <[email protected]>

[ Upstream commit 538603c6026ce769eec633bb79349f5f287519c7 ]

This patch fixes an issue that unexpected retransfering happens if TCR is set to 0 before rcar_dmac_sync_tcr() writes DE bit to the CHCR register. For example, sh-sci driver can reproduce this issue like below:

In rx_timer_fn(): /* CHCR DE bit may be set to 1 */
dmaengine_tx_status()
rcar_dmac_tx_status()
rcar_dmac_chan_get_residue()
rcar_dmac_sync_tcr() /* TCR is possible to be set to 0 */

According to the description of commit 73a47bd0da66 ("dmaengine:
rcar-dmac: use TCRB instead of TCR for residue"), "this buffered data will be transferred if CHCR::DE bit was cleared". So, this patch doesn't need to check TCRB register.

Fixes 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue")
---
 drivers/dma/sh/rcar-dmac.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/dma/sh/rcar-dmac.c +3 -2
@@ -774,8 +774,9 @@ static void rcar_dmac_sync_tcr(struct rc
 	/* make sure all remaining data was flushed */
 	rcar_dmac_chcr_de_barrier(chan);
 
-	/* back DE */
-	rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
+	/* back DE if remain data exists */
+	if (rcar_dmac_chan_read(chan, RCAR_DMATCR))
+		rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
 }
 
 static void rcar_dmac_chan_halt(struct rcar_dmac_chan *chan)
author maintainer
#244 lore raw

PATCH 224/235 staging: fsl-dpaa2/eth: Fix DMA mapping direction

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Ioana Radulescu <[email protected]>

[ Upstream commit 466bcdc1fa303be175c45d054bb00effc575033a ]

We are using DMA_FROM_DEVICE when mapping RX frame buffers, but DMA_BIDIRECTIONAL for unmap. Fix the direction for DMA unmapping operation.

Fixes 87eb55e418b7 ("staging: fsl-dpaa2/eth: Fix potential endless loop")
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c +1 -1
@@ -767,7 +767,7 @@ static void free_bufs(struct dpaa2_eth_p
 	for (i = 0; i < count; i++) {
 		vaddr = dpaa2_iova_to_virt(priv->iommu_domain, buf_array[i]);
 		dma_unmap_single(dev, buf_array[i], DPAA2_ETH_RX_BUF_SIZE,
-				 DMA_BIDIRECTIONAL);
+				 DMA_FROM_DEVICE);
 		skb_free_frag(vaddr);
 	}
 }
author maintainer
#245 lore raw

PATCH 225/235 IB/nes: Fix a compiler warning

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Bart Van Assche <[email protected]>

[ Upstream commit 4c5743bc4fe3233cecc1c184a773c79c8ee45bbe ]

Avoid that the following compiler warning is reported when building with W=1:

drivers/infiniband/hw/nes/nes_hw.c:646:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]

---
 drivers/infiniband/hw/nes/nes.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/hw/nes/nes.h +1 -1
@@ -159,7 +159,7 @@ do { \
 
 #define NES_EVENT_TIMEOUT   1200000
 #else
-#define nes_debug(level, fmt, args...)
+#define nes_debug(level, fmt, args...) do {} while (0)
 #define assert(expr)          do {} while (0)
 
 #define NES_EVENT_TIMEOUT   100000
author maintainer
#246 lore raw

PATCH 226/235 block/DAC960.c: fix defined but not used build warnings

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Randy Dunlap <[email protected]>

[ Upstream commit 3993e501bf853cce85c5114a704b86b8f486790c ]

Fix build warnings in DAC960.c when CONFIG_PROC_FS is not enabled by marking the unused functions as __maybe_unused.

../drivers/block/DAC960.c:6429:12: warning: 'dac960_proc_show' defined but not used [-Wunused-function] ../drivers/block/DAC960.c:6449:12: warning: 'dac960_initial_status_proc_show' defined but not used [-Wunused-function] ../drivers/block/DAC960.c:6456:12: warning: 'dac960_current_status_proc_show' defined but not used [-Wunused-function]

---
 drivers/block/DAC960.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/block/DAC960.c +6 -3
@@ -21,6 +21,7 @@
 #define DAC960_DriverDate			"21 Aug 2007"
 
 
+#include <linux/compiler.h>
 #include <linux/module.h>
 #include <linux/types.h>
 #include <linux/miscdevice.h>
@@ -6426,7 +6427,7 @@ static bool DAC960_V2_ExecuteUserCommand
   return true;
 }
 
-static int dac960_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused dac960_proc_show(struct seq_file *m, void *v)
 {
   unsigned char *StatusMessage = "OK\n";
   int ControllerNumber;
@@ -6446,14 +6447,16 @@ static int dac960_proc_show(struct seq_f
   return 0;
 }
 
-static int dac960_initial_status_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused dac960_initial_status_proc_show(struct seq_file *m,
+							  void *v)
 {
 	DAC960_Controller_T *Controller = (DAC960_Controller_T *)m->private;
 	seq_printf(m, "%.*s", Controller->InitialStatusLength, Controller->CombinedStatusBuffer);
 	return 0;
 }
 
-static int dac960_current_status_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused dac960_current_status_proc_show(struct seq_file *m,
+							  void *v)
 {
   DAC960_Controller_T *Controller = (DAC960_Controller_T *) m->private;
   unsigned char *StatusMessage =
author maintainer
#247 lore raw

PATCH 227/235 IB/mlx5: fix uaccess beyond "count" in debugfs read/write handlers

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Jann Horn <[email protected]>

[ Upstream commit 60e6627f12a78203a093ca05b7bca15627747d81 ]

In general, accessing userspace memory beyond the length of the supplied buffer in VFS read/write handlers can lead to both kernel memory corruption (via kernel_read()/kernel_write(), which can e.g. be triggered via sys_splice()) and privilege escalation inside userspace.

In this case, the affected files are in debugfs (and should therefore only be accessible to root), and the read handlers check that *pos is zero (meaning that at least sys_splice() can't trigger kernel memory corruption). Because of the root requirement, this is not a security fix, but rather a cleanup.

For the read handlers, fix it by using simple_read_from_buffer() instead of custom logic. Add min() calls to the write handlers.

Fixes 4a2da0b8c078 ("IB/mlx5: Add debug control parameters for congestion control")
Fixes e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
---
 drivers/infiniband/hw/mlx5/cong.c |    9 +--------
 drivers/infiniband/hw/mlx5/mr.c   |   32 ++++++++------------------------
 2 files changed, 9 insertions(+), 32 deletions(-)
drivers/infiniband/hw/mlx5/cong.c +1 -8
@@ -359,9 +359,6 @@ static ssize_t get_param(struct file *fi
 	int ret;
 	char lbuf[11];
 
-	if (*pos)
-		return 0;
-
 	ret = mlx5_ib_get_cc_params(param->dev, param->port_num, offset, &var);
 	if (ret)
 		return ret;
@@ -370,11 +367,7 @@ static ssize_t get_param(struct file *fi
 	if (ret < 0)
 		return ret;
 
-	if (copy_to_user(buf, lbuf, ret))
-		return -EFAULT;
-
-	*pos += ret;
-	return ret;
+	return simple_read_from_buffer(buf, count, pos, lbuf, ret);
 }
 
 static const struct file_operations dbg_cc_fops = {
drivers/infiniband/hw/mlx5/mr.c +8 -24
@@ -271,16 +271,16 @@ static ssize_t size_write(struct file *f
 {
 	struct mlx5_cache_ent *ent = filp->private_data;
 	struct mlx5_ib_dev *dev = ent->dev;
-	char lbuf[20];
+	char lbuf[20] = {0};
 	u32 var;
 	int err;
 	int c;
 
-	if (copy_from_user(lbuf, buf, sizeof(lbuf)))
+	count = min(count, sizeof(lbuf) - 1);
+	if (copy_from_user(lbuf, buf, count))
 		return -EFAULT;
 
 	c = order2idx(dev, ent->order);
-	lbuf[sizeof(lbuf) - 1] = 0;
 
 	if (sscanf(lbuf, "%u", &var) != 1)
 		return -EINVAL;
@@ -310,19 +310,11 @@ static ssize_t size_read(struct file *fi
 	char lbuf[20];
 	int err;
 
-	if (*pos)
-		return 0;
-
 	err = snprintf(lbuf, sizeof(lbuf), "%d\n", ent->size);
 	if (err < 0)
 		return err;
 
-	if (copy_to_user(buf, lbuf, err))
-		return -EFAULT;
-
-	*pos += err;
-
-	return err;
+	return simple_read_from_buffer(buf, count, pos, lbuf, err);
 }
 
 static const struct file_operations size_fops = {
@@ -337,16 +329,16 @@ static ssize_t limit_write(struct file *
 {
 	struct mlx5_cache_ent *ent = filp->private_data;
 	struct mlx5_ib_dev *dev = ent->dev;
-	char lbuf[20];
+	char lbuf[20] = {0};
 	u32 var;
 	int err;
 	int c;
 
-	if (copy_from_user(lbuf, buf, sizeof(lbuf)))
+	count = min(count, sizeof(lbuf) - 1);
+	if (copy_from_user(lbuf, buf, count))
 		return -EFAULT;
 
 	c = order2idx(dev, ent->order);
-	lbuf[sizeof(lbuf) - 1] = 0;
 
 	if (sscanf(lbuf, "%u", &var) != 1)
 		return -EINVAL;
@@ -372,19 +364,11 @@ static ssize_t limit_read(struct file *f
 	char lbuf[20];
 	int err;
 
-	if (*pos)
-		return 0;
-
 	err = snprintf(lbuf, sizeof(lbuf), "%d\n", ent->limit);
 	if (err < 0)
 		return err;
 
-	if (copy_to_user(buf, lbuf, err))
-		return -EFAULT;
-
-	*pos += err;
-
-	return err;
+	return simple_read_from_buffer(buf, count, pos, lbuf, err);
 }
 
 static const struct file_operations limit_fops = {
author maintainer
#248 lore raw

PATCH 228/235 blk-mq: only attempt to merge bio if there is rq in sw queue

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Ming Lei <[email protected]>

[ Upstream commit b04f50ab8a74129b3041a2836c33c916be3c6667 ]

Only attempt to merge bio iff the ctx->rq_list isn't empty, because:

1) for high-performance SSD, most of times dispatch may succeed, then there may be nothing left in ctx->rq_list, so don't try to merge over sw queue if it is empty, then we can save one acquiring of ctx->lock

2) we can't expect good merge performance on per-cpu sw queue, and missing one merge on sw queue won't be a big deal since tasks can be scheduled from one CPU to another.

---
 block/blk-mq-sched.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
block/blk-mq-sched.c +2 -1
@@ -339,7 +339,8 @@ bool __blk_mq_sched_bio_merge(struct req
 		return e->type->ops.mq.bio_merge(hctx, bio);
 	}
 
-	if (hctx->flags & BLK_MQ_F_SHOULD_MERGE) {
+	if ((hctx->flags & BLK_MQ_F_SHOULD_MERGE) &&
+			!list_empty_careful(&ctx->rq_list)) {
 		/* default per sw-queue merge */
 		spin_lock(&ctx->lock);
 		ret = blk_mq_attempt_merge(q, ctx, bio);
author maintainer
#249 lore raw

PATCH 229/235 blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Ming Lei <[email protected]>

[ Upstream commit 1311326cf4755c7ffefd20f576144ecf46d9906b ]

SCSI probing may synchronously create and destroy a lot of request_queues for non-existent devices. Any synchronize_rcu() in queue creation or destroy path may introduce long latency during booting, see detailed description in comment of blk_register_queue().

This patch removes one synchronize_rcu() inside blk_cleanup_queue() for this case, commit c2856ae2f315d75(blk-mq: quiesce queue before freeing queue) needs synchronize_rcu() for implementing blk_mq_quiesce_queue(), but when queue isn't initialized, it isn't necessary to do that since only pass-through requests are involved, no original issue in scsi_execute() at all.

Without this patch and previous one, it may take more 20+ seconds for virtio-scsi to complete disk probe. With the two patches, the time becomes less than 100ms.

Fixes c2856ae2f315d75 ("blk-mq: quiesce queue before freeing queue")
Cc Omar Sandoval <[email protected]>
Cc Bart Van Assche <[email protected]>
Cc "Martin K. Petersen" <[email protected]>
Cc Christoph Hellwig <[email protected]>
---
 block/blk-core.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
block/blk-core.c +6 -2
@@ -791,9 +791,13 @@ void blk_cleanup_queue(struct request_qu
 	 * make sure all in-progress dispatch are completed because
 	 * blk_freeze_queue() can only complete all requests, and
 	 * dispatch may still be in-progress since we dispatch requests
-	 * from more than one contexts
+	 * from more than one contexts.
+	 *
+	 * No need to quiesce queue if it isn't initialized yet since
+	 * blk_freeze_queue() should be enough for cases of passthrough
+	 * request.
 	 */
-	if (q->mq_ops)
+	if (q->mq_ops && blk_queue_init_done(q))
 		blk_mq_quiesce_queue(q);
 
 	/* for synchronous bio-based driver finish in-flight integrity i/o */
author maintainer
#250 lore raw

PATCH 230/235 gpiolib: Respect error code of ->get_direction()

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Andy Shevchenko <[email protected]>

[ Upstream commit 36b312792b97933dc07abe074f50941199bd357c ]

In case we try to lock GPIO pin as IRQ when something going wrong we print a misleading message.

Correct this by checking an error code from ->get_direction() in gpiochip_lock_as_irq() and printing a corresponding message.

---
 drivers/gpio/gpiolib.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/gpio/gpiolib.c +6 -0
@@ -3257,6 +3257,12 @@ int gpiochip_lock_as_irq(struct gpio_chi
 	if (!chip->can_sleep && chip->get_direction) {
 		int dir = chip->get_direction(chip, offset);
 
+		if (dir < 0) {
+			chip_err(chip, "%s: cannot get GPIO direction\n",
+				 __func__);
+			return dir;
+		}
+
 		if (dir)
 			clear_bit(FLAG_IS_OUT, &desc->flags);
 		else
author maintainer
#251 lore raw

PATCH 231/235 pinctrl: msm: Fix msm_config_group_get() to be compliant

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Douglas Anderson <[email protected]>

[ Upstream commit 05e0c828955c1cab58dd71a04539442e5375d917 ]

If you do this on an sdm845 board:
cat /sys/kernel/debug/pinctrl/3400000.pinctrl/pinconf-groups

...it looks like nonsense. For every pin you see listed:
input bias bus hold, input bias disabled, input bias pull down, input bias pull up

That's because msm_config_group_get() isn't complying with the rules that pinconf_generic_dump_one() expects. Specifically for boolean parameters (anything with a "struct pin_config_item" where has_arg is false) the function expects that the function should return its value not through the "config" parameter but should return "0" if the value is set and "-EINVAL" if the value isn't set.

Let's fix this.

Quoted 1 line

From a quick sample of other pinctrl drivers, it appears to be

tradition to also return 1 through the config parameter for these boolean parameters when they exist. I'm not one to knock tradition, so I'll follow tradition and return 1 in these cases. While I'm at it, I'll also continue searching for four leaf clovers, kocking on wood three times, and trying not to break mirrors.

Fixes f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
---
 drivers/pinctrl/qcom/pinctrl-msm.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/pinctrl/qcom/pinctrl-msm.c +11 -3
@@ -250,22 +250,30 @@ static int msm_config_group_get(struct p
 	/* Convert register value to pinconf value */
 	switch (param) {
 	case PIN_CONFIG_BIAS_DISABLE:
-		arg = arg == MSM_NO_PULL;
+		if (arg != MSM_NO_PULL)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_PULL_DOWN:
-		arg = arg == MSM_PULL_DOWN;
+		if (arg != MSM_PULL_DOWN)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_BUS_HOLD:
 		if (pctrl->soc->pull_no_keeper)
 			return -ENOTSUPP;
 
-		arg = arg == MSM_KEEPER;
+		if (arg != MSM_KEEPER)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_PULL_UP:
 		if (pctrl->soc->pull_no_keeper)
 			arg = arg == MSM_PULL_UP_NO_KEEPER;
 		else
 			arg = arg == MSM_PULL_UP;
+		if (!arg)
+			return -EINVAL;
 		break;
 	case PIN_CONFIG_DRIVE_STRENGTH:
 		arg = msm_regval_to_drive(arg);
author maintainer
#252 lore raw

PATCH 232/235 pinctrl: qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Douglas Anderson <[email protected]>

[ Upstream commit 1cf86bc21257a330e3af51f2a4e885f1a705f6a5 ]

If you do this on an sdm845 board:
grep "" /sys/kernel/debug/pinctrl/*spmi:pmic*/pinconf-groups

...it looks like nonsense. For every pin you see listed:
input bias disabled, input bias high impedance, input bias pull down, input bias pull up, ...

That's because pmic_gpio_config_get() isn't complying with the rules that pinconf_generic_dump_one() expects. Specifically for boolean parameters (anything with a "struct pin_config_item" where has_arg is false) the function expects that the function should return its value not through the "config" parameter but should return "0" if the value is set and "-EINVAL" if the value isn't set.

Let's fix this.

Quoted 1 line

From a quick sample of other pinctrl drivers, it appears to be

tradition to also return 1 through the config parameter for these boolean parameters when they exist. I'm not one to knock tradition, so I'll follow tradition and return 1 in these cases. While I'm at it, I'll also continue searching for four leaf clovers, kocking on wood three times, and trying not to break mirrors.

NOTE: This also fixes an apparent typo for reading PIN_CONFIG_BIAS_DISABLE where the old driver was accidentally using "=" instead of "==" and thus was setting some internal state when you tried to query PIN_CONFIG_BIAS_DISABLE. Oops.

Fixes eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver")
---
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c |   32 +++++++++++++++++++++++--------
 1 file changed, 24 insertions(+), 8 deletions(-)
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c +24 -8
@@ -390,31 +390,47 @@ static int pmic_gpio_config_get(struct p
 
 	switch (param) {
 	case PIN_CONFIG_DRIVE_PUSH_PULL:
-		arg = pad->buffer_type == PMIC_GPIO_OUT_BUF_CMOS;
+		if (pad->buffer_type != PMIC_GPIO_OUT_BUF_CMOS)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_DRIVE_OPEN_DRAIN:
-		arg = pad->buffer_type == PMIC_GPIO_OUT_BUF_OPEN_DRAIN_NMOS;
+		if (pad->buffer_type != PMIC_GPIO_OUT_BUF_OPEN_DRAIN_NMOS)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_DRIVE_OPEN_SOURCE:
-		arg = pad->buffer_type == PMIC_GPIO_OUT_BUF_OPEN_DRAIN_PMOS;
+		if (pad->buffer_type != PMIC_GPIO_OUT_BUF_OPEN_DRAIN_PMOS)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_PULL_DOWN:
-		arg = pad->pullup == PMIC_GPIO_PULL_DOWN;
+		if (pad->pullup != PMIC_GPIO_PULL_DOWN)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_DISABLE:
-		arg = pad->pullup = PMIC_GPIO_PULL_DISABLE;
+		if (pad->pullup != PMIC_GPIO_PULL_DISABLE)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_PULL_UP:
-		arg = pad->pullup == PMIC_GPIO_PULL_UP_30;
+		if (pad->pullup != PMIC_GPIO_PULL_UP_30)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
-		arg = !pad->is_enabled;
+		if (pad->is_enabled)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_POWER_SOURCE:
 		arg = pad->power_source;
 		break;
 	case PIN_CONFIG_INPUT_ENABLE:
-		arg = pad->input_enabled;
+		if (!pad->input_enabled)
+			return -EINVAL;
+		arg = 1;
 		break;
 	case PIN_CONFIG_OUTPUT:
 		arg = pad->out_value;
author maintainer
#253 lore raw

PATCH 233/235 clk: tegra: bpmp: Dont crash when a clock fails to register

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Mikko Perttunen <[email protected]>

[ Upstream commit f7b3182232c82bb9769e2d5471d702bae2972d2b ]

When registering clocks, we just skip any that fail to register (leaving a NULL hole in the clock table). However, our of_xlate function still tries to dereference each entry while looking for the clock with the requested id, causing a crash if any clocks failed to register. Add a check to of_xlate to skip any NULL clocks.

---
 drivers/clk/tegra/clk-bpmp.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
drivers/clk/tegra/clk-bpmp.c +9 -3
@@ -586,9 +586,15 @@ static struct clk_hw *tegra_bpmp_clk_of_
 	unsigned int id = clkspec->args[0], i;
 	struct tegra_bpmp *bpmp = data;
 
-	for (i = 0; i < bpmp->num_clocks; i++)
-		if (bpmp->clocks[i]->id == id)
-			return &bpmp->clocks[i]->hw;
+	for (i = 0; i < bpmp->num_clocks; i++) {
+		struct tegra_bpmp_clk *clk = bpmp->clocks[i];
+
+		if (!clk)
+			continue;
+
+		if (clk->id == id)
+			return &clk->hw;
+	}
 
 	return NULL;
 }
author maintainer
#254 lore raw

PATCH 234/235 mei: bus: type promotion bug in mei_nfc_if_version()

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

commit b40b3e9358fbafff6a4ba0f4b9658f6617146f9c upstream.

We accidentally removed the check for negative returns without considering the issue of type promotion.
The "if_version_length" variable is type size_t so if __mei_cl_recv() returns a negative then "bytes_recv" is type promoted
to a high positive value and treated as success.

Fixes 582ab27a063a ("mei: bus: fix received data size check in NFC fixup")
---
 drivers/misc/mei/bus-fixup.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/misc/mei/bus-fixup.c +1 -1
@@ -267,7 +267,7 @@ static int mei_nfc_if_version(struct mei
 
 	ret = 0;
 	bytes_recv = __mei_cl_recv(cl, (u8 *)reply, if_version_length, 0);
-	if (bytes_recv < if_version_length) {
+	if (bytes_recv < 0 || bytes_recv < if_version_length) {
 		dev_err(bus->dev, "Could not read IF version\n");
 		ret = -EIO;
 		goto err;
author maintainer
#255 lore raw

PATCH 235/235 crypto: ccp - add timeout support in the SEV command

In reply to Greg Kroah-Hartman

4.18-stable review patch. If anyone has any objections, please let me know.

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

From: Brijesh Singh <[email protected]>

commit 3702a0585e64d70d5bf73bf3e943b8d6005b72c1 upstream.

Currently, the CCP driver assumes that the SEV command issued to the PSP will always return (i.e. it will never hang). But recently, firmware bugs have shown that a command can hang. Since of the SEV commands are used in probe routines, this can cause boot hangs and/or loss of virtualization capabilities.

To protect against firmware bugs, add a timeout in the SEV command execution flow. If a command does not complete within the specified timeout then return -ETIMEOUT and stop the driver from executing any further commands since the state of the SEV firmware is unknown.

Cc Tom Lendacky <[email protected]>
Cc Gary Hook <[email protected]>
Cc Herbert Xu <[email protected]>
[Brijesh: Backported to 4.18..4.19 - offset change in few hunks]
---
 drivers/crypto/ccp/psp-dev.c |   46 ++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 41 insertions(+), 5 deletions(-)
drivers/crypto/ccp/psp-dev.c +41 -5
@@ -38,6 +38,17 @@ static DEFINE_MUTEX(sev_cmd_mutex);
 static struct sev_misc_dev *misc_dev;
 static struct psp_device *psp_master;
 
+static int psp_cmd_timeout = 100;
+module_param(psp_cmd_timeout, int, 0644);
+MODULE_PARM_DESC(psp_cmd_timeout, " default timeout value, in seconds, for PSP commands");
+
+static int psp_probe_timeout = 5;
+module_param(psp_probe_timeout, int, 0644);
+MODULE_PARM_DESC(psp_probe_timeout, " default timeout value, in seconds, during PSP device probe");
+
+static bool psp_dead;
+static int psp_timeout;
+
 static struct psp_device *psp_alloc_struct(struct sp_device *sp)
 {
 	struct device *dev = sp->dev;
@@ -82,10 +93,19 @@ done:
 	return IRQ_HANDLED;
 }
 
-static void sev_wait_cmd_ioc(struct psp_device *psp, unsigned int *reg)
+static int sev_wait_cmd_ioc(struct psp_device *psp,
+			    unsigned int *reg, unsigned int timeout)
 {
-	wait_event(psp->sev_int_queue, psp->sev_int_rcvd);
+	int ret;
+
+	ret = wait_event_timeout(psp->sev_int_queue,
+			psp->sev_int_rcvd, timeout * HZ);
+	if (!ret)
+		return -ETIMEDOUT;
+
 	*reg = ioread32(psp->io_regs + PSP_CMDRESP);
+
+	return 0;
 }
 
 static int sev_cmd_buffer_len(int cmd)
@@ -133,12 +153,15 @@ static int __sev_do_cmd_locked(int cmd,
 	if (!psp)
 		return -ENODEV;
 
+	if (psp_dead)
+		return -EBUSY;
+
 	/* Get the physical address of the command buffer */
 	phys_lsb = data ? lower_32_bits(__psp_pa(data)) : 0;
 	phys_msb = data ? upper_32_bits(__psp_pa(data)) : 0;
 
-	dev_dbg(psp->dev, "sev command id %#x buffer 0x%08x%08x\n",
-		cmd, phys_msb, phys_lsb);
+	dev_dbg(psp->dev, "sev command id %#x buffer 0x%08x%08x timeout %us\n",
+		cmd, phys_msb, phys_lsb, psp_timeout);
 
 	print_hex_dump_debug("(in):  ", DUMP_PREFIX_OFFSET, 16, 2, data,
 			     sev_cmd_buffer_len(cmd), false);
@@ -154,7 +177,18 @@ static int __sev_do_cmd_locked(int cmd,
 	iowrite32(reg, psp->io_regs + PSP_CMDRESP);
 
 	/* wait for command completion */
-	sev_wait_cmd_ioc(psp, &reg);
+	ret = sev_wait_cmd_ioc(psp, &reg, psp_timeout);
+	if (ret) {
+		if (psp_ret)
+			*psp_ret = 0;
+
+		dev_err(psp->dev, "sev command %#x timed out, disabling PSP \n", cmd);
+		psp_dead = true;
+
+		return ret;
+	}
+
+	psp_timeout = psp_cmd_timeout;
 
 	if (psp_ret)
 		*psp_ret = reg & PSP_CMDRESP_ERR_MASK;
@@ -886,6 +920,8 @@ void psp_pci_init(void)
 
 	psp_master = sp->psp_data;
 
+	psp_timeout = psp_probe_timeout;
+
 	if (sev_get_api_version())
 		goto err;
 
maintainer
#256 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.18.10 release. There are 235 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Wed Sep 26 11:30:01 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions since the last release I tested.

thanks,
-- Shuah

author maintainer
#257 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.18.10 release. There are 235 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Quoted 8 lines

Responses should be made by Wed Sep 26 11:30:01 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y
and the diffstat can be found below.

-rc2 is out to resolve some reported problems:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc2.gz

#258 lore raw
Quoted 15 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.18.10 release. There are 235 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Wed Sep 26 11:30:01 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y
and the diffstat can be found below.

Review

Quoted 2 lines
(quoted diff) +0 -1
-rc2 is out to resolve some reported problems:
 	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc2.gz

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 4.18.10-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.18.y
git commit: a728cc9e2683aba1752aa9a0aacae4bbfc1066d2
git describe: v4.18.9-232-ga728cc9e2683
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.9-232-ga728cc9e2683

No regressions (compared to build v4.18.9)
------------------------------------------------------------------------

Ran 16243 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-timers-tests
* ltp-syscalls-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

Signature · 2 lines
Linaro LKFT
https://lkft.linaro.org
author maintainer
#259 lore raw
Quoted 16 lines · Dan Rue
Quoted 15 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.18.10 release. There are 235 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Wed Sep 26 11:30:01 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y
and the diffstat can be found below.

Quoted 5 lines

Review

Quoted 2 lines
(quoted diff) +0 -1
-rc2 is out to resolve some reported problems:
 	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.10-rc2.gz

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Great, thanks for testing and glad to see the problem get fixed.

greg k-h

#260 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.18.10 release. There are 235 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Wed Sep 26 11:30:01 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 137 pass: 137 fail: 0
Qemu test results:
	total: 318 pass: 317 fail: 1

Failed tests:
powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs

The failed test is the result of a crash in devicetree unittest code. It affects all branches. Nothing to worry about; fix is being worked on.

Details are available at https://kerneltests.org/builders/.

Guenter

author maintainer
#261 lore raw
Quoted 11 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.18.10 release. There are 235 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Wed Sep 26 11:30:01 UTC 2018. Anything received after that time might be too late.

Build results:

Quoted 8 lines
	total: 137 pass: 137 fail: 0
Qemu test results:
	total: 318 pass: 317 fail: 1

Failed tests:
powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs

The failed test is the result of a crash in devicetree unittest code. It affects all branches. Nothing to worry about; fix is being worked on.

Thanks for testing all of these and letting me know.

greg k-h