This is a note to let you know that I've just added the patch titled
iwlwifi: fix access to prph when transport is stopped
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iwlwifi-fix-access-to-prph-when-transport-is-stopped.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Sara Sharon <sara.sharon(a)intel.com>
Date: Mon, 20 Nov 2017 13:25:05 +0200
Subject: iwlwifi: fix access to prph when transport is stopped
From: Sara Sharon <sara.sharon(a)intel.com>
[ Upstream commit 0232d2cd7aa8e1b810fe84fb4059a0bd1eabe2ba ]
When getting HW rfkill we get stop_device being called from
two paths.
One path is the IRQ calling stop device, and updating op
mode and stack.
As a result, cfg80211 is running rfkill sync work that shuts
down all devices (second path).
In the second path, we eventually get to iwl_mvm_stop_device
which calls iwl_fw_dump_conf_clear->iwl_fw_dbg_stop_recording,
that access periphery registers.
The device may be stopped at this point from the first path,
which will result with a failure to access those registers.
Simply checking for the trans status is insufficient, since
the race will still exist, only minimized.
Instead, move the stop from iwl_fw_dump_conf_clear (which is
getting called only from stop path) to the transport stop
device function, where the access is always safe.
This has the added value, of actually stopping dbgc before
stopping device even when the stop is initiated from the
transport.
Fixes: 1efc3843a4ee ("iwlwifi: stop dbgc recording before stopping DMA")
Signed-off-by: Sara Sharon <sara.sharon(a)intel.com>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 2 --
drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 6 ++++++
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 9 +++++++++
3 files changed, 15 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.h
@@ -209,8 +209,6 @@ static inline void iwl_fw_dbg_stop_recor
static inline void iwl_fw_dump_conf_clear(struct iwl_fw_runtime *fwrt)
{
- iwl_fw_dbg_stop_recording(fwrt);
-
fwrt->dump.conf = FW_DBG_INVALID;
}
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c
@@ -49,6 +49,7 @@
*
*****************************************************************************/
#include "iwl-trans.h"
+#include "iwl-prph.h"
#include "iwl-context-info.h"
#include "internal.h"
@@ -156,6 +157,11 @@ void _iwl_trans_pcie_gen2_stop_device(st
trans_pcie->is_down = true;
+ /* Stop dbgc before stopping device */
+ iwl_write_prph(trans, DBGC_IN_SAMPLE, 0);
+ udelay(100);
+ iwl_write_prph(trans, DBGC_OUT_CTRL, 0);
+
/* tell the device to stop sending interrupts */
iwl_disable_interrupts(trans);
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -1138,6 +1138,15 @@ static void _iwl_trans_pcie_stop_device(
trans_pcie->is_down = true;
+ /* Stop dbgc before stopping device */
+ if (trans->cfg->device_family == IWL_DEVICE_FAMILY_7000) {
+ iwl_set_bits_prph(trans, MON_BUFF_SAMPLE_CTL, 0x100);
+ } else {
+ iwl_write_prph(trans, DBGC_IN_SAMPLE, 0);
+ udelay(100);
+ iwl_write_prph(trans, DBGC_OUT_CTRL, 0);
+ }
+
/* tell the device to stop sending interrupts */
iwl_disable_interrupts(trans);
Patches currently in stable-queue which might be from sara.sharon(a)intel.com are
queue-4.14/iwlwifi-fix-access-to-prph-when-transport-is-stopped.patch
This is a note to let you know that I've just added the patch titled
i2c: i2c-boardinfo: fix memory leaks on devinfo
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i2c-i2c-boardinfo-fix-memory-leaks-on-devinfo.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Colin Ian King <colin.king(a)canonical.com>
Date: Wed, 22 Nov 2017 17:52:24 +0000
Subject: i2c: i2c-boardinfo: fix memory leaks on devinfo
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 66a7c84d677e8e4a5a2ef4afdb9bd52e1399a866 ]
Currently when an error occurs devinfo is still allocated but is
unused when the error exit paths break out of the for-loop. Fix
this by kfree'ing devinfo to avoid the leak.
Detected by CoverityScan, CID#1416590 ("Resource Leak")
Fixes: 4124c4eba402 ("i2c: allow attaching IRQ resources to i2c_board_info")
Fixes: 0daaf99d8424 ("i2c: copy device properties when using i2c_register_board_info()")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Wolfram Sang <wsa(a)the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/i2c/i2c-boardinfo.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/i2c/i2c-boardinfo.c
+++ b/drivers/i2c/i2c-boardinfo.c
@@ -86,6 +86,7 @@ int i2c_register_board_info(int busnum,
property_entries_dup(info->properties);
if (IS_ERR(devinfo->board_info.properties)) {
status = PTR_ERR(devinfo->board_info.properties);
+ kfree(devinfo);
break;
}
}
@@ -98,6 +99,7 @@ int i2c_register_board_info(int busnum,
GFP_KERNEL);
if (!devinfo->board_info.resources) {
status = -ENOMEM;
+ kfree(devinfo);
break;
}
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/i2c-i2c-boardinfo-fix-memory-leaks-on-devinfo.patch
queue-4.14/usb-gadget-don-t-dereference-g-until-after-it-has-been-null-checked.patch
This is a note to let you know that I've just added the patch titled
hwmon: (pmbus) Use 64bit math for DIRECT format values
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hwmon-pmbus-use-64bit-math-for-direct-format-values.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Robert Lippert <roblip(a)gmail.com>
Date: Mon, 27 Nov 2017 15:51:55 -0800
Subject: hwmon: (pmbus) Use 64bit math for DIRECT format values
From: Robert Lippert <roblip(a)gmail.com>
[ Upstream commit bd467e4eababe4c04272c1e646f066db02734c79 ]
Power values in the 100s of watt range can easily blow past
32bit math limits when processing everything in microwatts.
Use 64bit math instead to avoid these issues on common 32bit ARM
BMC platforms.
Fixes: 442aba78728e ("hwmon: PMBus device driver")
Signed-off-by: Robert Lippert <rlippert(a)google.com>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwmon/pmbus/pmbus_core.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -21,6 +21,7 @@
#include <linux/debugfs.h>
#include <linux/kernel.h>
+#include <linux/math64.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/err.h>
@@ -499,8 +500,8 @@ static long pmbus_reg2data_linear(struct
static long pmbus_reg2data_direct(struct pmbus_data *data,
struct pmbus_sensor *sensor)
{
- long val = (s16) sensor->data;
- long m, b, R;
+ s64 b, val = (s16)sensor->data;
+ s32 m, R;
m = data->info->m[sensor->class];
b = data->info->b[sensor->class];
@@ -528,11 +529,12 @@ static long pmbus_reg2data_direct(struct
R--;
}
while (R < 0) {
- val = DIV_ROUND_CLOSEST(val, 10);
+ val = div_s64(val + 5LL, 10L); /* round closest */
R++;
}
- return (val - b) / m;
+ val = div_s64(val - b, m);
+ return clamp_val(val, LONG_MIN, LONG_MAX);
}
/*
@@ -656,7 +658,8 @@ static u16 pmbus_data2reg_linear(struct
static u16 pmbus_data2reg_direct(struct pmbus_data *data,
struct pmbus_sensor *sensor, long val)
{
- long m, b, R;
+ s64 b, val64 = val;
+ s32 m, R;
m = data->info->m[sensor->class];
b = data->info->b[sensor->class];
@@ -673,18 +676,18 @@ static u16 pmbus_data2reg_direct(struct
R -= 3; /* Adjust R and b for data in milli-units */
b *= 1000;
}
- val = val * m + b;
+ val64 = val64 * m + b;
while (R > 0) {
- val *= 10;
+ val64 *= 10;
R--;
}
while (R < 0) {
- val = DIV_ROUND_CLOSEST(val, 10);
+ val64 = div_s64(val64 + 5LL, 10L); /* round closest */
R++;
}
- return val;
+ return (u16)clamp_val(val64, S16_MIN, S16_MAX);
}
static u16 pmbus_data2reg_vid(struct pmbus_data *data,
Patches currently in stable-queue which might be from roblip(a)gmail.com are
queue-4.14/hwmon-pmbus-use-64bit-math-for-direct-format-values.patch
This is a note to let you know that I've just added the patch titled
grace: replace BUG_ON by WARN_ONCE in exit_net hook
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Vasily Averin <vvs(a)virtuozzo.com>
Date: Mon, 6 Nov 2017 16:22:48 +0300
Subject: grace: replace BUG_ON by WARN_ONCE in exit_net hook
From: Vasily Averin <vvs(a)virtuozzo.com>
[ Upstream commit b872285751c1af010e12d02bce7069e2061a58ca ]
Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs_common/grace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/nfs_common/grace.c
+++ b/fs/nfs_common/grace.c
@@ -104,7 +104,9 @@ grace_exit_net(struct net *net)
{
struct list_head *grace_list = net_generic(net, grace_net_id);
- BUG_ON(!list_empty(grace_list));
+ WARN_ONCE(!list_empty(grace_list),
+ "net %x %s: grace_list is not empty\n",
+ net->ns.inum, __func__);
}
static struct pernet_operations grace_net_ops = {
Patches currently in stable-queue which might be from vvs(a)virtuozzo.com are
queue-4.14/lockd-fix-list_add-double-add-caused-by-legacy-signal-interface.patch
queue-4.14/grace-replace-bug_on-by-warn_once-in-exit_net-hook.patch
queue-4.14/perf-core-fix-memory-leak-triggered-by-perf-namespace.patch
queue-4.14/race-of-lockd-inetaddr-notifiers-vs-nlmsvc_rqst-change.patch
This is a note to let you know that I've just added the patch titled
drm/vc4: Move IRQ enable to PM path
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-vc4-move-irq-enable-to-pm-path.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Stefan Schake <stschake(a)gmail.com>
Date: Fri, 29 Dec 2017 17:05:43 +0100
Subject: drm/vc4: Move IRQ enable to PM path
From: Stefan Schake <stschake(a)gmail.com>
[ Upstream commit ce9caf2f79a5aa170a4b6456a03db639eed9c988 ]
We were calling enable_irq on bind, where it was already enabled previously
by the IRQ helper. Additionally, dev->irq is not set correctly until after
postinstall and so was always zero here, triggering a warning in 4.15.
Fix both by moving the enable to the power management resume path, where we
know there was a previous disable invocation during suspend.
Fixes: 253696ccd613 ("drm/vc4: Account for interrupts in flight")
Signed-off-by: Stefan Schake <stschake(a)gmail.com>
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1514563543-32511-1-git-send-e…
Tested-by: Stefan Wahren <stefan.wahren(a)i2se.com>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vc4/vc4_irq.c | 3 ---
drivers/gpu/drm/vc4/vc4_v3d.c | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -208,9 +208,6 @@ vc4_irq_postinstall(struct drm_device *d
{
struct vc4_dev *vc4 = to_vc4_dev(dev);
- /* Undo the effects of a previous vc4_irq_uninstall. */
- enable_irq(dev->irq);
-
/* Enable both the render done and out of memory interrupts. */
V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS);
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -327,6 +327,9 @@ static int vc4_v3d_runtime_resume(struct
return ret;
vc4_v3d_init_hw(vc4->dev);
+
+ /* We disabled the IRQ as part of vc4_irq_uninstall in suspend. */
+ enable_irq(vc4->dev->irq);
vc4_irq_postinstall(vc4->dev);
return 0;
Patches currently in stable-queue which might be from stschake(a)gmail.com are
queue-4.14/drm-vc4-move-irq-enable-to-pm-path.patch
queue-4.14/drm-vc4-account-for-interrupts-in-flight.patch
This is a note to let you know that I've just added the patch titled
drm/vc4: Account for interrupts in flight
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-vc4-account-for-interrupts-in-flight.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Stefan Schake <stschake(a)gmail.com>
Date: Fri, 10 Nov 2017 02:05:06 +0100
Subject: drm/vc4: Account for interrupts in flight
From: Stefan Schake <stschake(a)gmail.com>
[ Upstream commit 253696ccd613fbdaa5aba1de44c461a058e0a114 ]
Synchronously disable the IRQ to make the following cancel_work_sync
invocation effective.
An interrupt in flight could enqueue further overflow mem work. As we
free the binner BO immediately following vc4_irq_uninstall this caused
a NULL pointer dereference in the work callback vc4_overflow_mem_work.
Link: https://github.com/anholt/linux/issues/114
Signed-off-by: Stefan Schake <stschake(a)gmail.com>
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1510275907-993-2-git-send-ema…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vc4/vc4_irq.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -208,6 +208,9 @@ vc4_irq_postinstall(struct drm_device *d
{
struct vc4_dev *vc4 = to_vc4_dev(dev);
+ /* Undo the effects of a previous vc4_irq_uninstall. */
+ enable_irq(dev->irq);
+
/* Enable both the render done and out of memory interrupts. */
V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS);
@@ -225,6 +228,9 @@ vc4_irq_uninstall(struct drm_device *dev
/* Clear any pending interrupts we might have left. */
V3D_WRITE(V3D_INTCTL, V3D_DRIVER_IRQS);
+ /* Finish any interrupt handler still in flight. */
+ disable_irq(dev->irq);
+
cancel_work_sync(&vc4->overflow_mem_work);
}
Patches currently in stable-queue which might be from stschake(a)gmail.com are
queue-4.14/drm-vc4-move-irq-enable-to-pm-path.patch
queue-4.14/drm-vc4-account-for-interrupts-in-flight.patch
This is a note to let you know that I've just added the patch titled
drm/rockchip: dw-mipi-dsi: fix possible un-balanced runtime PM enable
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-rockchip-dw-mipi-dsi-fix-possible-un-balanced-runtime-pm-enable.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Mirza Krak <mirza.krak(a)endian.se>
Date: Wed, 15 Nov 2017 08:24:46 +0000
Subject: drm/rockchip: dw-mipi-dsi: fix possible un-balanced runtime PM enable
From: Mirza Krak <mirza.krak(a)endian.se>
[ Upstream commit 517f56839f581618d24f2e67a35738a5c6cbaecb ]
In the case where the bind gets deferred we would end up with a
un-balanced runtime PM enable call.
Fix this by simply moving the pm_runtime_enable call to the end of
the bind function when all paths have succeeded.
Signed-off-by: Mirza Krak <mirza.krak(a)endian.se>
Signed-off-by: Sandy Huang <hjc(a)rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510734286-37434-1-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1275,8 +1275,6 @@ static int dw_mipi_dsi_bind(struct devic
goto err_pllref;
}
- pm_runtime_enable(dev);
-
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
dsi->dsi_host.dev = dev;
ret = mipi_dsi_host_register(&dsi->dsi_host);
@@ -1291,6 +1289,7 @@ static int dw_mipi_dsi_bind(struct devic
}
dev_set_drvdata(dev, dsi);
+ pm_runtime_enable(dev);
return 0;
err_mipi_dsi_host:
Patches currently in stable-queue which might be from mirza.krak(a)endian.se are
queue-4.14/drm-rockchip-dw-mipi-dsi-fix-possible-un-balanced-runtime-pm-enable.patch
This is a note to let you know that I've just added the patch titled
drm/omap: Fix error handling path in 'omap_dmm_probe()'
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sun, 24 Sep 2017 08:01:03 +0200
Subject: drm/omap: Fix error handling path in 'omap_dmm_probe()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 8677b1ac2db021ab30bb1fa34f1e56ebe0051ec3 ]
If we don't find a matching device node, we must free the memory allocated
in 'omap_dmm' a few lines above.
Fixes: 7cb0d6c17b96 ("drm/omap: fix TILER on OMAP5")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -638,7 +638,8 @@ static int omap_dmm_probe(struct platfor
match = of_match_node(dmm_of_match, dev->dev.of_node);
if (!match) {
dev_err(&dev->dev, "failed to find matching device node\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto fail;
}
omap_dmm->plat_data = match->data;
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/bnxt_en-fix-an-error-handling-path-in-bnxt_get_module_eeprom.patch
queue-4.14/drm-omap-fix-error-handling-path-in-omap_dmm_probe.patch
This is a note to let you know that I've just added the patch titled
drm/omap: displays: panel-dpi: add backlight dependency
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-omap-displays-panel-dpi-add-backlight-dependency.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 5 Oct 2017 14:06:41 +0200
Subject: drm/omap: displays: panel-dpi: add backlight dependency
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 499ec0ed5eb2f6a7fcaab2dd66ffc5993484bda9 ]
The new backlight code causes a link failure when backlight
support itself is disabled:
drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function `panel_dpi_probe_of':
panel-dpi.c:(.text+0x35c): undefined reference to `of_find_backlight_by_node'
This adds a Kconfig dependency like we have for the other OMAP
display targets.
Fixes: 39135a305a0f ("drm/omap: displays: panel-dpi: Support for handling backlight devices")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/omapdrm/displays/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/omapdrm/displays/Kconfig
+++ b/drivers/gpu/drm/omapdrm/displays/Kconfig
@@ -35,6 +35,7 @@ config DRM_OMAP_CONNECTOR_ANALOG_TV
config DRM_OMAP_PANEL_DPI
tristate "Generic DPI panel"
+ depends on BACKLIGHT_CLASS_DEVICE
help
Driver for generic DPI panels.
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/drm-omap-displays-panel-dpi-add-backlight-dependency.patch
queue-4.14/gpio-fix-kernel-stack-leak-to-userspace.patch
This is a note to let you know that I've just added the patch titled
drm/bridge: tc358767: fix timing calculations
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-bridge-tc358767-fix-timing-calculations.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Feb 1 13:45:42 CET 2018
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Date: Tue, 7 Nov 2017 19:56:22 +0300
Subject: drm/bridge: tc358767: fix timing calculations
From: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
[ Upstream commit 66d1c3b94d5d59e4325e61a78d520f92c043d645 ]
Fields in HTIM01 and HTIM02 regs should be even.
Recomended thresh_dly value is max_tu_symbol.
Remove set of VPCTRL0.VSDELAY as it is related to DSI input
interface. Currently driver supports only DPI.
Acked-by: Philipp Zabel <p.zabel(a)pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov(a)cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-5-git-send-e…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/bridge/tc358767.c | 34 ++++++++++++++++++++--------------
1 file changed, 20 insertions(+), 14 deletions(-)
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -659,6 +659,14 @@ static int tc_set_video_mode(struct tc_d
int lower_margin = mode->vsync_start - mode->vdisplay;
int vsync_len = mode->vsync_end - mode->vsync_start;
+ /*
+ * Recommended maximum number of symbols transferred in a transfer unit:
+ * DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
+ * (output active video bandwidth in bytes))
+ * Must be less than tu_size.
+ */
+ max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
+
dev_dbg(tc->dev, "set mode %dx%d\n",
mode->hdisplay, mode->vdisplay);
dev_dbg(tc->dev, "H margin %d,%d sync %d\n",
@@ -668,13 +676,18 @@ static int tc_set_video_mode(struct tc_d
dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
- /* LCD Ctl Frame Size */
- tc_write(VPCTRL0, (0x40 << 20) /* VSDELAY */ |
+ /*
+ * LCD Ctl Frame Size
+ * datasheet is not clear of vsdelay in case of DPI
+ * assume we do not need any delay when DPI is a source of
+ * sync signals
+ */
+ tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ |
OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
- tc_write(HTIM01, (left_margin << 16) | /* H back porch */
- (hsync_len << 0)); /* Hsync */
- tc_write(HTIM02, (right_margin << 16) | /* H front porch */
- (mode->hdisplay << 0)); /* width */
+ tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */
+ (ALIGN(hsync_len, 2) << 0)); /* Hsync */
+ tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) | /* H front porch */
+ (ALIGN(mode->hdisplay, 2) << 0)); /* width */
tc_write(VTIM01, (upper_margin << 16) | /* V back porch */
(vsync_len << 0)); /* Vsync */
tc_write(VTIM02, (lower_margin << 16) | /* V front porch */
@@ -693,7 +706,7 @@ static int tc_set_video_mode(struct tc_d
/* DP Main Stream Attributes */
vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
tc_write(DP0_VIDSYNCDELAY,
- (0x003e << 16) | /* thresh_dly */
+ (max_tu_symbol << 16) | /* thresh_dly */
(vid_sync_dly << 0));
tc_write(DP0_TOTALVAL, (mode->vtotal << 16) | (mode->htotal));
@@ -709,13 +722,6 @@ static int tc_set_video_mode(struct tc_d
tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW |
DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888);
- /*
- * Recommended maximum number of symbols transferred in a transfer unit:
- * DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
- * (output active video bandwidth in bytes))
- * Must be less than tu_size.
- */
- max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) |
BPC_8);
Patches currently in stable-queue which might be from andrey.gusakov(a)cogentembedded.com are
queue-4.14/drm-bridge-tc358767-fix-timing-calculations.patch
queue-4.14/drm-bridge-tc358767-fix-auxdatan-registers-access.patch
queue-4.14/drm-bridge-tc358767-filter-out-too-high-modes.patch
queue-4.14/drm-bridge-tc358767-fix-1-lane-behavior.patch
queue-4.14/drm-bridge-tc358767-fix-dp0_misc-register-set.patch
queue-4.14/drm-bridge-tc358767-do-no-fail-on-hi-res-displays.patch