]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.14-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 13 May 2018 09:17:07 +0000 (11:17 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 13 May 2018 09:17:07 +0000 (11:17 +0200)
added patches:
nvme-add-quirk-to-force-medium-priority-for-sq-creation.patch
thermal-exynos-propagate-error-value-from-tmu_read.patch
thermal-exynos-reading-temperature-makes-sense-only-when-tmu-is-turned-on.patch

queue-4.14/nvme-add-quirk-to-force-medium-priority-for-sq-creation.patch [new file with mode: 0644]
queue-4.14/series
queue-4.14/thermal-exynos-propagate-error-value-from-tmu_read.patch [new file with mode: 0644]
queue-4.14/thermal-exynos-reading-temperature-makes-sense-only-when-tmu-is-turned-on.patch [new file with mode: 0644]

diff --git a/queue-4.14/nvme-add-quirk-to-force-medium-priority-for-sq-creation.patch b/queue-4.14/nvme-add-quirk-to-force-medium-priority-for-sq-creation.patch
new file mode 100644 (file)
index 0000000..cc9c7e7
--- /dev/null
@@ -0,0 +1,73 @@
+From 9abd68ef454c824bfd18629033367b4382b5f390 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Tue, 8 May 2018 10:25:15 -0600
+Subject: nvme: add quirk to force medium priority for SQ creation
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit 9abd68ef454c824bfd18629033367b4382b5f390 upstream.
+
+Some P3100 drives have a bug where they think WRRU (weighted round robin)
+is always enabled, even though the host doesn't set it. Since they think
+it's enabled, they also look at the submission queue creation priority. We
+used to set that to MEDIUM by default, but that was removed in commit
+81c1cd98351b. This causes various issues on that drive. Add a quirk to
+still set MEDIUM priority for that controller.
+
+Fixes: 81c1cd98351b ("nvme/pci: Don't set reserved SQ create flags")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Keith Busch <keith.busch@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/nvme/host/nvme.h |    5 +++++
+ drivers/nvme/host/pci.c  |   12 +++++++++++-
+ 2 files changed, 16 insertions(+), 1 deletion(-)
+
+--- a/drivers/nvme/host/nvme.h
++++ b/drivers/nvme/host/nvme.h
+@@ -80,6 +80,11 @@ enum nvme_quirks {
+        * Supports the LighNVM command set if indicated in vs[1].
+        */
+       NVME_QUIRK_LIGHTNVM                     = (1 << 6),
++
++      /*
++       * Set MEDIUM priority on SQ creation
++       */
++      NVME_QUIRK_MEDIUM_PRIO_SQ               = (1 << 7),
+ };
+ /*
+--- a/drivers/nvme/host/pci.c
++++ b/drivers/nvme/host/pci.c
+@@ -947,10 +947,19 @@ static int adapter_alloc_cq(struct nvme_
+ static int adapter_alloc_sq(struct nvme_dev *dev, u16 qid,
+                                               struct nvme_queue *nvmeq)
+ {
++      struct nvme_ctrl *ctrl = &dev->ctrl;
+       struct nvme_command c;
+       int flags = NVME_QUEUE_PHYS_CONTIG;
+       /*
++       * Some drives have a bug that auto-enables WRRU if MEDIUM isn't
++       * set. Since URGENT priority is zeroes, it makes all queues
++       * URGENT.
++       */
++      if (ctrl->quirks & NVME_QUIRK_MEDIUM_PRIO_SQ)
++              flags |= NVME_SQ_PRIO_MEDIUM;
++
++      /*
+        * Note: we (ab)use the fact the the prp fields survive if no data
+        * is attached to the request.
+        */
+@@ -2523,7 +2532,8 @@ static const struct pci_device_id nvme_i
+               .driver_data = NVME_QUIRK_STRIPE_SIZE |
+                               NVME_QUIRK_DEALLOCATE_ZEROES, },
+       { PCI_VDEVICE(INTEL, 0xf1a5),   /* Intel 600P/P3100 */
+-              .driver_data = NVME_QUIRK_NO_DEEPEST_PS },
++              .driver_data = NVME_QUIRK_NO_DEEPEST_PS |
++                              NVME_QUIRK_MEDIUM_PRIO_SQ },
+       { PCI_VDEVICE(INTEL, 0x5845),   /* Qemu emulated controller */
+               .driver_data = NVME_QUIRK_IDENTIFY_CNS, },
+       { PCI_DEVICE(0x1c58, 0x0003),   /* HGST adapter */
index 0aba8a44b908f0554c7470702551c533f451cbe1..f617023fb0c23469aa7f02ca0227fbca2fcdfa1a 100644 (file)
@@ -47,3 +47,6 @@ cpufreq-schedutil-avoid-using-invalid-next_freq.patch
 revert-bluetooth-btusb-fix-quirk-for-atheros-1525-qca6174.patch
 bluetooth-btusb-add-dell-xps-13-9360-to-btusb_needs_reset_resume_table.patch
 bluetooth-btusb-only-check-needs_reset_resume-dmi-table-for-qca-rome-chipsets.patch
+thermal-exynos-reading-temperature-makes-sense-only-when-tmu-is-turned-on.patch
+thermal-exynos-propagate-error-value-from-tmu_read.patch
+nvme-add-quirk-to-force-medium-priority-for-sq-creation.patch
diff --git a/queue-4.14/thermal-exynos-propagate-error-value-from-tmu_read.patch b/queue-4.14/thermal-exynos-propagate-error-value-from-tmu_read.patch
new file mode 100644 (file)
index 0000000..9b7c8d0
--- /dev/null
@@ -0,0 +1,53 @@
+From c8da6cdef57b459ac0fd5d9d348f8460a575ae90 Mon Sep 17 00:00:00 2001
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+Date: Mon, 16 Apr 2018 12:11:53 +0200
+Subject: thermal: exynos: Propagate error value from tmu_read()
+
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+
+commit c8da6cdef57b459ac0fd5d9d348f8460a575ae90 upstream.
+
+tmu_read() in case of Exynos4210 might return error for out of bound
+values. Current code ignores such value, what leads to reporting critical
+temperature value. Add proper error code propagation to exynos_get_temp()
+function.
+
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+CC: stable@vger.kernel.org # v4.6+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/thermal/samsung/exynos_tmu.c |    9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/thermal/samsung/exynos_tmu.c
++++ b/drivers/thermal/samsung/exynos_tmu.c
+@@ -892,6 +892,7 @@ static void exynos7_tmu_control(struct p
+ static int exynos_get_temp(void *p, int *temp)
+ {
+       struct exynos_tmu_data *data = p;
++      int value, ret = 0;
+       if (!data || !data->tmu_read || !data->enabled)
+               return -EINVAL;
+@@ -899,12 +900,16 @@ static int exynos_get_temp(void *p, int
+       mutex_lock(&data->lock);
+       clk_enable(data->clk);
+-      *temp = code_to_temp(data, data->tmu_read(data)) * MCELSIUS;
++      value = data->tmu_read(data);
++      if (value < 0)
++              ret = value;
++      else
++              *temp = code_to_temp(data, value) * MCELSIUS;
+       clk_disable(data->clk);
+       mutex_unlock(&data->lock);
+-      return 0;
++      return ret;
+ }
+ #ifdef CONFIG_THERMAL_EMULATION
diff --git a/queue-4.14/thermal-exynos-reading-temperature-makes-sense-only-when-tmu-is-turned-on.patch b/queue-4.14/thermal-exynos-reading-temperature-makes-sense-only-when-tmu-is-turned-on.patch
new file mode 100644 (file)
index 0000000..d2c9485
--- /dev/null
@@ -0,0 +1,63 @@
+From 88fc6f73fddf64eb507b04f7b2bd01d7291db514 Mon Sep 17 00:00:00 2001
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+Date: Mon, 16 Apr 2018 12:11:52 +0200
+Subject: thermal: exynos: Reading temperature makes sense only when TMU is turned on
+
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+
+commit 88fc6f73fddf64eb507b04f7b2bd01d7291db514 upstream.
+
+When thermal sensor is not yet enabled, reading temperature might return
+random value. This might even result in stopping system booting when such
+temperature is higher than the critical value. Fix this by checking if TMU
+has been actually enabled before reading the temperature.
+
+This change fixes booting of Exynos4210-based board with TMU enabled (for
+example Samsung Trats board), which was broken since v4.4 kernel release.
+
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Fixes: 9e4249b40340 ("thermal: exynos: Fix first temperature read after registering sensor")
+CC: stable@vger.kernel.org # v4.6+
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/thermal/samsung/exynos_tmu.c |    5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/thermal/samsung/exynos_tmu.c
++++ b/drivers/thermal/samsung/exynos_tmu.c
+@@ -185,6 +185,7 @@
+  * @regulator: pointer to the TMU regulator structure.
+  * @reg_conf: pointer to structure to register with core thermal.
+  * @ntrip: number of supported trip points.
++ * @enabled: current status of TMU device
+  * @tmu_initialize: SoC specific TMU initialization method
+  * @tmu_control: SoC specific TMU control method
+  * @tmu_read: SoC specific TMU temperature read method
+@@ -205,6 +206,7 @@ struct exynos_tmu_data {
+       struct regulator *regulator;
+       struct thermal_zone_device *tzd;
+       unsigned int ntrip;
++      bool enabled;
+       int (*tmu_initialize)(struct platform_device *pdev);
+       void (*tmu_control)(struct platform_device *pdev, bool on);
+@@ -398,6 +400,7 @@ static void exynos_tmu_control(struct pl
+       mutex_lock(&data->lock);
+       clk_enable(data->clk);
+       data->tmu_control(pdev, on);
++      data->enabled = on;
+       clk_disable(data->clk);
+       mutex_unlock(&data->lock);
+ }
+@@ -890,7 +893,7 @@ static int exynos_get_temp(void *p, int
+ {
+       struct exynos_tmu_data *data = p;
+-      if (!data || !data->tmu_read)
++      if (!data || !data->tmu_read || !data->enabled)
+               return -EINVAL;
+       mutex_lock(&data->lock);