* Patch "IB/ipoib: Replace list_del of the neigh->list with list_del_init" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon, valex,
yuval.shaia
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: Replace list_del of the neigh->list with list_del_init
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:27 +0200
Subject: IB/ipoib: Replace list_del of the neigh->list with list_del_init
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit c586071d1dc8227a7182179b8e50ee92cc43f6d2 ]
In order to resolve a situation where a few process delete
the same list element in sequence and cause panic, list_del
is replaced with list_del_init. In this case if the first
process that calls list_del releases the lock before acquiring
it again, other processes who can acquire the lock will call
list_del_init.
Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1302,7 +1302,7 @@ static void __ipoib_reap_neigh(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1466,7 +1466,7 @@ void ipoib_neigh_free(struct ipoib_neigh
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
return;
} else {
@@ -1551,7 +1551,7 @@ void ipoib_del_neighs_by_gid(struct net_
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1593,7 +1593,7 @@ static void ipoib_flush_neighs(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
}
}
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-4.9/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-4.9/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-4.9/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "hugetlbfs: initialize shared policy as part of inode allocation" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: mike.kravetz, akpm, alexander.levin, dave.hansen, dvyukov, gregkh,
hillf.zj, mhocko, penguin-kernel, torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
hugetlbfs: initialize shared policy as part of inode allocation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
hugetlbfs-initialize-shared-policy-as-part-of-inode-allocation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Mike Kravetz <mike.kravetz@oracle.com>
Date: Fri, 31 Mar 2017 15:12:01 -0700
Subject: hugetlbfs: initialize shared policy as part of inode allocation
From: Mike Kravetz <mike.kravetz@oracle.com>
[ Upstream commit 4742a35d9de745e867405b4311e1aac412f0ace1 ]
Any time after inode allocation, destroy_inode can be called. The
hugetlbfs inode contains a shared_policy structure, and
mpol_free_shared_policy is unconditionally called as part of
hugetlbfs_destroy_inode. Initialize the policy as part of inode
allocation so that any quick (error path) calls to destroy_inode will be
handed an initialized policy.
syzkaller fuzzer found this bug, that resulted in the following:
BUG: KASAN: user-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
000000131730bd7a
BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 000000131730bd7a
Write of size 4 by task syz-executor6/14086
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
__lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
__raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
_raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
alloc_inode+0x10d/0x180 fs/inode.c:216
new_inode_pseudo+0x69/0x190 fs/inode.c:889
new_inode+0x1c/0x40 fs/inode.c:918
hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
newseg+0x422/0xd30 ipc/shm.c:575
ipcget_new ipc/util.c:285 [inline]
ipcget+0x21e/0x580 ipc/util.c:639
SYSC_shmget ipc/shm.c:673 [inline]
SyS_shmget+0x158/0x230 ipc/shm.c:657
entry_SYSCALL_64_fastpath+0x1f/0xc2
Analysis provided by Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Link: http://lkml.kernel.org/r/1490477850-7944-1-git-send-email-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/hugetlbfs/inode.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -695,14 +695,11 @@ static struct inode *hugetlbfs_get_root(
inode = new_inode(sb);
if (inode) {
- struct hugetlbfs_inode_info *info;
inode->i_ino = get_next_ino();
inode->i_mode = S_IFDIR | config->mode;
inode->i_uid = config->uid;
inode->i_gid = config->gid;
inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode);
- info = HUGETLBFS_I(inode);
- mpol_shared_policy_init(&info->policy, NULL);
inode->i_op = &hugetlbfs_dir_inode_operations;
inode->i_fop = &simple_dir_operations;
/* directory inodes start off with i_nlink == 2 (for "." entry) */
@@ -733,7 +730,6 @@ static struct inode *hugetlbfs_get_inode
inode = new_inode(sb);
if (inode) {
- struct hugetlbfs_inode_info *info;
inode->i_ino = get_next_ino();
inode_init_owner(inode, dir, mode);
lockdep_set_class(&inode->i_mapping->i_mmap_rwsem,
@@ -741,15 +737,6 @@ static struct inode *hugetlbfs_get_inode
inode->i_mapping->a_ops = &hugetlbfs_aops;
inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode);
inode->i_mapping->private_data = resv_map;
- info = HUGETLBFS_I(inode);
- /*
- * The policy is initialized here even if we are creating a
- * private inode because initialization simply creates an
- * an empty rb tree and calls rwlock_init(), later when we
- * call mpol_free_shared_policy() it will just return because
- * the rb tree will still be empty.
- */
- mpol_shared_policy_init(&info->policy, NULL);
switch (mode & S_IFMT) {
default:
init_special_inode(inode, mode, dev);
@@ -937,6 +924,18 @@ static struct inode *hugetlbfs_alloc_ino
hugetlbfs_inc_free_inodes(sbinfo);
return NULL;
}
+
+ /*
+ * Any time after allocation, hugetlbfs_destroy_inode can be called
+ * for the inode. mpol_free_shared_policy is unconditionally called
+ * as part of hugetlbfs_destroy_inode. So, initialize policy here
+ * in case of a quick call to destroy.
+ *
+ * Note that the policy is initialized even if we are creating a
+ * private inode. This simplifies hugetlbfs_destroy_inode.
+ */
+ mpol_shared_policy_init(&p->policy, NULL);
+
return &p->vfs_inode;
}
Patches currently in stable-queue which might be from mike.kravetz@oracle.com are
queue-4.9/hugetlbfs-initialize-shared-policy-as-part-of-inode-allocation.patch
^ permalink raw reply
* Patch "i2c: meson: fix wrong variable usage in meson_i2c_put_data" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: hkallweit1, alexander.levin, gregkh, jbrunet, wsa; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
i2c: meson: fix wrong variable usage in meson_i2c_put_data
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
i2c-meson-fix-wrong-variable-usage-in-meson_i2c_put_data.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 7 Mar 2017 21:06:38 +0100
Subject: i2c: meson: fix wrong variable usage in meson_i2c_put_data
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit 3b0277f198ac928f323c42e180680d2f79aa980d ]
Most likely a copy & paste error.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: 30021e3707a7 ("i2c: add support for Amlogic Meson I2C controller")
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-meson.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-meson.c
+++ b/drivers/i2c/busses/i2c-meson.c
@@ -175,7 +175,7 @@ static void meson_i2c_put_data(struct me
wdata1 |= *buf++ << ((i - 4) * 8);
writel(wdata0, i2c->regs + REG_TOK_WDATA0);
- writel(wdata0, i2c->regs + REG_TOK_WDATA1);
+ writel(wdata1, i2c->regs + REG_TOK_WDATA1);
dev_dbg(i2c->dev, "%s: data %08x %08x len %d\n", __func__,
wdata0, wdata1, len);
Patches currently in stable-queue which might be from hkallweit1@gmail.com are
queue-4.9/mmc-sdio-fix-alignment-issue-in-struct-sdio_func.patch
queue-4.9/i2c-meson-fix-wrong-variable-usage-in-meson_i2c_put_data.patch
^ permalink raw reply
* Patch "hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: linux, alexander.levin, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
hwmon-gl520sm-fix-overflows-and-crash-seen-when-writing-into-limit-attributes.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Guenter Roeck <linux@roeck-us.net>
Date: Tue, 27 Dec 2016 14:15:07 -0800
Subject: hwmon: (gl520sm) Fix overflows and crash seen when writing into limit attributes
From: Guenter Roeck <linux@roeck-us.net>
[ Upstream commit 87cdfa9d60f4f40e6d71b04b10b36d9df3c89282 ]
Writes into limit attributes can overflow due to multplications and
additions with unbound input values. Writing into fan limit attributes
can result in a crash with a division by zero if very large values are
written and the fan divider is larger than 1.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/gl520sm.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
--- a/drivers/hwmon/gl520sm.c
+++ b/drivers/hwmon/gl520sm.c
@@ -208,11 +208,13 @@ static ssize_t get_cpu_vid(struct device
}
static DEVICE_ATTR(cpu0_vid, S_IRUGO, get_cpu_vid, NULL);
-#define VDD_FROM_REG(val) (((val) * 95 + 2) / 4)
-#define VDD_TO_REG(val) clamp_val((((val) * 4 + 47) / 95), 0, 255)
-
-#define IN_FROM_REG(val) ((val) * 19)
-#define IN_TO_REG(val) clamp_val((((val) + 9) / 19), 0, 255)
+#define VDD_FROM_REG(val) DIV_ROUND_CLOSEST((val) * 95, 4)
+#define VDD_CLAMP(val) clamp_val(val, 0, 255 * 95 / 4)
+#define VDD_TO_REG(val) DIV_ROUND_CLOSEST(VDD_CLAMP(val) * 4, 95)
+
+#define IN_FROM_REG(val) ((val) * 19)
+#define IN_CLAMP(val) clamp_val(val, 0, 255 * 19)
+#define IN_TO_REG(val) DIV_ROUND_CLOSEST(IN_CLAMP(val), 19)
static ssize_t get_in_input(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -349,8 +351,13 @@ static SENSOR_DEVICE_ATTR(in4_max, S_IRU
#define DIV_FROM_REG(val) (1 << (val))
#define FAN_FROM_REG(val, div) ((val) == 0 ? 0 : (480000 / ((val) << (div))))
-#define FAN_TO_REG(val, div) ((val) <= 0 ? 0 : \
- clamp_val((480000 + ((val) << ((div)-1))) / ((val) << (div)), 1, 255))
+
+#define FAN_BASE(div) (480000 >> (div))
+#define FAN_CLAMP(val, div) clamp_val(val, FAN_BASE(div) / 255, \
+ FAN_BASE(div))
+#define FAN_TO_REG(val, div) ((val) == 0 ? 0 : \
+ DIV_ROUND_CLOSEST(480000, \
+ FAN_CLAMP(val, div) << (div)))
static ssize_t get_fan_input(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -513,9 +520,9 @@ static SENSOR_DEVICE_ATTR(fan2_div, S_IR
static DEVICE_ATTR(fan1_off, S_IRUGO | S_IWUSR,
get_fan_off, set_fan_off);
-#define TEMP_FROM_REG(val) (((val) - 130) * 1000)
-#define TEMP_TO_REG(val) clamp_val(((((val) < 0 ? \
- (val) - 500 : (val) + 500) / 1000) + 130), 0, 255)
+#define TEMP_FROM_REG(val) (((val) - 130) * 1000)
+#define TEMP_CLAMP(val) clamp_val(val, -130000, 125000)
+#define TEMP_TO_REG(val) (DIV_ROUND_CLOSEST(TEMP_CLAMP(val), 1000) + 130)
static ssize_t get_temp_input(struct device *dev, struct device_attribute *attr,
char *buf)
Patches currently in stable-queue which might be from linux@roeck-us.net are
queue-4.9/hwmon-gl520sm-fix-overflows-and-crash-seen-when-writing-into-limit-attributes.patch
^ permalink raw reply
* Patch "HID: wacom: release the resources before leaving despite devm" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: benjamin.tissoires, alexander.levin, gregkh, jason.gerecke,
jkosina
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
HID: wacom: release the resources before leaving despite devm
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
hid-wacom-release-the-resources-before-leaving-despite-devm.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Fri, 20 Jan 2017 16:20:11 +0100
Subject: HID: wacom: release the resources before leaving despite devm
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
[ Upstream commit 5b779fc52020ac6f5beea31c5eafc3d25cf70dc1 ]
In the general case, the resources are properly released by devm without
needing to do anything. However, when unplugging the wireless receiver,
the kernel segfaults from time to time while calling devres_release_all().
I think in that case the resources attempt to access hid_get_drvdata(hdev)
which has been set to null while leaving wacom_remove().
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/wacom_sys.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -2433,6 +2433,8 @@ static void wacom_remove(struct hid_devi
if (hdev->bus == BUS_BLUETOOTH)
device_remove_file(&hdev->dev, &dev_attr_speed);
+ wacom_release_resources(wacom);
+
hid_set_drvdata(hdev, NULL);
}
Patches currently in stable-queue which might be from benjamin.tissoires@redhat.com are
queue-4.9/hid-wacom-release-the-resources-before-leaving-despite-devm.patch
^ permalink raw reply
* Patch "extcon: axp288: Use vbus-valid instead of -present to determine cable presence" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: hdegoede, alexander.levin, cw00.choi, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
extcon: axp288: Use vbus-valid instead of -present to determine cable presence
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
extcon-axp288-use-vbus-valid-instead-of-present-to-determine-cable-presence.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Hans de Goede <hdegoede@redhat.com>
Date: Mon, 19 Dec 2016 01:13:11 +0100
Subject: extcon: axp288: Use vbus-valid instead of -present to determine cable presence
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 5757aca10146061befd168dab37fb0db1ccd8f73 ]
The vbus-present bit in the power status register also gets set to 1
when a usb-host cable (id-pin shorted to ground) is plugged in and a 5v
boost converter is supplying 5v to the otg usb bus.
This causes a "disconnect or unknown or ID event" warning in dmesg as
well as the extcon device to report the last detected charger cable
type as being connected even though none is connected.
This commit switches to checking the vbus-valid bit instead, which is
only 1 when both vbus is present and the vbus-path is enabled in the
vbus-path control register (the vbus-path gets disabled when a usb-host
cable is detected, to avoid the pmic drawing power from the 5v boost
converter).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/extcon/extcon-axp288.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -168,7 +168,7 @@ static int axp288_handle_chrg_det_event(
return ret;
}
- vbus_attach = (pwr_stat & PS_STAT_VBUS_PRESENT);
+ vbus_attach = (pwr_stat & PS_STAT_VBUS_VALID);
if (!vbus_attach)
goto notify_otg;
Patches currently in stable-queue which might be from hdegoede@redhat.com are
queue-4.9/iio-adc-axp288-drop-bogus-axp288_adc_ts_pin_ctrl-register-modifications.patch
queue-4.9/power-supply-axp288_fuel_gauge-fix-fuel_gauge_reg_readb-return-on-error.patch
queue-4.9/extcon-axp288-use-vbus-valid-instead-of-present-to-determine-cable-presence.patch
^ permalink raw reply
* Patch "GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: dan.carpenter, alexander.levin, gregkh, rpeterso; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
gfs2-fix-reference-to-err_ptr-in-gfs2_glock_iter_next.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 14 Dec 2016 08:02:03 -0600
Subject: GFS2: Fix reference to ERR_PTR in gfs2_glock_iter_next
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit 14d37564fa3dc4e5d4c6828afcd26ac14e6796c5 ]
This patch fixes a place where function gfs2_glock_iter_next can
reference an invalid error pointer.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/gfs2/glock.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1820,16 +1820,18 @@ void gfs2_glock_exit(void)
static void gfs2_glock_iter_next(struct gfs2_glock_iter *gi)
{
- do {
- gi->gl = rhashtable_walk_next(&gi->hti);
+ while ((gi->gl = rhashtable_walk_next(&gi->hti))) {
if (IS_ERR(gi->gl)) {
if (PTR_ERR(gi->gl) == -EAGAIN)
continue;
gi->gl = NULL;
+ return;
}
- /* Skip entries for other sb and dead entries */
- } while ((gi->gl) && ((gi->sdp != gi->gl->gl_name.ln_sbd) ||
- __lockref_is_dead(&gi->gl->gl_lockref)));
+ /* Skip entries for other sb and dead entries */
+ if (gi->sdp == gi->gl->gl_name.ln_sbd &&
+ !__lockref_is_dead(&gi->gl->gl_lockref))
+ return;
+ }
}
static void *gfs2_glock_seq_start(struct seq_file *seq, loff_t *pos)
Patches currently in stable-queue which might be from dan.carpenter@oracle.com are
queue-4.9/gfs2-fix-reference-to-err_ptr-in-gfs2_glock_iter_next.patch
queue-4.9/asoc-dapm-fix-some-pointer-error-handling.patch
^ permalink raw reply
* Patch "[media] exynos-gsc: Do not swap cb/cr for semi planar formats" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: thibault.saunier, alexander.levin, gregkh, javier, mchehab,
nicolas.dufresne, s.nawrocki
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
[media] exynos-gsc: Do not swap cb/cr for semi planar formats
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
exynos-gsc-do-not-swap-cb-cr-for-semi-planar-formats.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Thibault Saunier <thibault.saunier@osg.samsung.com>
Date: Wed, 1 Feb 2017 18:05:21 -0200
Subject: [media] exynos-gsc: Do not swap cb/cr for semi planar formats
From: Thibault Saunier <thibault.saunier@osg.samsung.com>
[ Upstream commit d7f3e33df4fbdc9855fb151f4a328ec46447e3ba ]
In the case of semi planar formats cb and cr are in the same plane
in memory, meaning that will be set to 'cb' whatever the format is,
and whatever the (packed) order of those components are.
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Thibault Saunier <thibault.saunier@osg.samsung.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -849,9 +849,7 @@ int gsc_prepare_addr(struct gsc_ctx *ctx
if ((frame->fmt->pixelformat == V4L2_PIX_FMT_VYUY) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVYU) ||
- (frame->fmt->pixelformat == V4L2_PIX_FMT_NV61) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420) ||
- (frame->fmt->pixelformat == V4L2_PIX_FMT_NV21) ||
(frame->fmt->pixelformat == V4L2_PIX_FMT_YVU420M))
swap(addr->cb, addr->cr);
Patches currently in stable-queue which might be from thibault.saunier@osg.samsung.com are
queue-4.9/exynos-gsc-do-not-swap-cb-cr-for-semi-planar-formats.patch
^ permalink raw reply
* Patch "drm: mali-dp: Fix transposed horizontal/vertical flip" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: brian.starkey, Liviu.Dudau, alexander.levin, gregkh
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm: mali-dp: Fix transposed horizontal/vertical flip
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-mali-dp-fix-transposed-horizontal-vertical-flip.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Brian Starkey <brian.starkey@arm.com>
Date: Wed, 7 Dec 2016 13:20:28 +0000
Subject: drm: mali-dp: Fix transposed horizontal/vertical flip
From: Brian Starkey <brian.starkey@arm.com>
[ Upstream commit 7916efe5b57505080b3cebf5bdb228b4eda008ea ]
The horizontal and vertical flip flags were the wrong way around,
causing reflect-x to result in reflect-y being applied and vice-versa.
Fix them.
Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -184,9 +184,9 @@ static void malidp_de_plane_update(struc
if (plane->state->rotation & DRM_ROTATE_MASK)
val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) << LAYER_ROT_OFFSET;
if (plane->state->rotation & DRM_REFLECT_X)
- val |= LAYER_V_FLIP;
- if (plane->state->rotation & DRM_REFLECT_Y)
val |= LAYER_H_FLIP;
+ if (plane->state->rotation & DRM_REFLECT_Y)
+ val |= LAYER_V_FLIP;
/* set the 'enable layer' bit */
val |= LAYER_ENABLE;
Patches currently in stable-queue which might be from brian.starkey@arm.com are
queue-4.9/drm-mali-dp-fix-destination-size-handling-when-rotating.patch
queue-4.9/drm-mali-dp-fix-transposed-horizontal-vertical-flip.patch
^ permalink raw reply
* Patch "drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: hoegsberg, alexander.levin, daniel.vetter, gregkh, hoegsberg
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm_fourcc-fix-drm_format_mod_linear-define.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: "Kristian H. Kristensen" <hoegsberg@gmail.com>
Date: Tue, 13 Dec 2016 11:27:52 -0800
Subject: drm_fourcc: Fix DRM_FORMAT_MOD_LINEAR #define
From: "Kristian H. Kristensen" <hoegsberg@gmail.com>
[ Upstream commit af913418261d6d3e7a29f06cf35f04610ead667c ]
We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code()
macro to work correctly.
Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1481657272-25975-1-git-send-email-hoegsberg@google.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/uapi/drm/drm_fourcc.h | 1 +
1 file changed, 1 insertion(+)
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -154,6 +154,7 @@ extern "C" {
/* Vendor Ids: */
#define DRM_FORMAT_MOD_NONE 0
+#define DRM_FORMAT_MOD_VENDOR_NONE 0
#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01
#define DRM_FORMAT_MOD_VENDOR_AMD 0x02
#define DRM_FORMAT_MOD_VENDOR_NV 0x03
Patches currently in stable-queue which might be from hoegsberg@gmail.com are
queue-4.9/drm_fourcc-fix-drm_format_mod_linear-define.patch
^ permalink raw reply
* Patch "drm/i915/psr: disable psr2 for resolution greater than 32X20" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: vathsala.nagaraju, alexander.levin, gregkh, jim.bride,
rodrigo.vivi
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/i915/psr: disable psr2 for resolution greater than 32X20
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-psr-disable-psr2-for-resolution-greater-than-32x20.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: "Nagaraju, Vathsala" <vathsala.nagaraju@intel.com>
Date: Tue, 10 Jan 2017 12:32:26 +0530
Subject: drm/i915/psr: disable psr2 for resolution greater than 32X20
From: "Nagaraju, Vathsala" <vathsala.nagaraju@intel.com>
[ Upstream commit acf45d11050abd751dcec986ab121cb2367dcbba ]
PSR2 is restricted to work with panel resolutions upto 3200x2000,
move the check to intel_psr_match_conditions and fully block psr.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484031746-20874-1-git-send-email-vathsala.nagaraju@intel.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_psr.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -387,6 +387,13 @@ static bool intel_psr_match_conditions(s
return false;
}
+ /* PSR2 is restricted to work with panel resolutions upto 3200x2000 */
+ if (intel_crtc->config->pipe_src_w > 3200 ||
+ intel_crtc->config->pipe_src_h > 2000) {
+ dev_priv->psr.psr2_support = false;
+ return false;
+ }
+
dev_priv->psr.source_ok = true;
return true;
}
@@ -425,7 +432,6 @@ void intel_psr_enable(struct intel_dp *i
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
if (!HAS_PSR(dev)) {
DRM_DEBUG_KMS("PSR not supported on this platform\n");
@@ -452,12 +458,7 @@ void intel_psr_enable(struct intel_dp *i
hsw_psr_setup_vsc(intel_dp);
if (dev_priv->psr.psr2_support) {
- /* PSR2 is restricted to work with panel resolutions upto 3200x2000 */
- if (crtc->config->pipe_src_w > 3200 ||
- crtc->config->pipe_src_h > 2000)
- dev_priv->psr.psr2_support = false;
- else
- skl_psr_setup_su_vsc(intel_dp);
+ skl_psr_setup_su_vsc(intel_dp);
}
/*
Patches currently in stable-queue which might be from vathsala.nagaraju@intel.com are
queue-4.9/drm-i915-psr-disable-psr2-for-resolution-greater-than-32x20.patch
^ permalink raw reply
* Patch "drm: mali-dp: Fix destination size handling when rotating" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: brian.starkey, Liviu.Dudau, alexander.levin, gregkh
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm: mali-dp: Fix destination size handling when rotating
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-mali-dp-fix-destination-size-handling-when-rotating.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Brian Starkey <brian.starkey@arm.com>
Date: Wed, 7 Dec 2016 13:17:21 +0000
Subject: drm: mali-dp: Fix destination size handling when rotating
From: Brian Starkey <brian.starkey@arm.com>
[ Upstream commit edabb3c4cd2d035bc93a3d67b25a304ea6217301 ]
The destination rectangle provided by userspace in the CRTC_X/Y/W/H
properties is already expressed as the dimensions after rotation.
This means we shouldn't swap the width and height ourselves when a
90/270 degree rotation is requested, so remove the code doing the swap.
Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")
Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/arm/malidp_planes.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -150,13 +150,8 @@ static void malidp_de_plane_update(struc
/* convert src values from Q16 fixed point to integer */
src_w = plane->state->src_w >> 16;
src_h = plane->state->src_h >> 16;
- if (plane->state->rotation & MALIDP_ROTATED_MASK) {
- dest_w = plane->state->crtc_h;
- dest_h = plane->state->crtc_w;
- } else {
- dest_w = plane->state->crtc_w;
- dest_h = plane->state->crtc_h;
- }
+ dest_w = plane->state->crtc_w;
+ dest_h = plane->state->crtc_h;
malidp_hw_write(mp->hwdev, format_id, mp->layer->base);
Patches currently in stable-queue which might be from brian.starkey@arm.com are
queue-4.9/drm-mali-dp-fix-destination-size-handling-when-rotating.patch
queue-4.9/drm-mali-dp-fix-transposed-horizontal-vertical-flip.patch
^ permalink raw reply
* Patch "drm/amdkfd: fix improper return value on error" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: bianpan2016, alexander.levin, gregkh, oded.gabbay; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/amdkfd: fix improper return value on error
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-amdkfd-fix-improper-return-value-on-error.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Pan Bian <bianpan2016@163.com>
Date: Thu, 1 Dec 2016 16:10:42 +0800
Subject: drm/amdkfd: fix improper return value on error
From: Pan Bian <bianpan2016@163.com>
[ Upstream commit 8bf793883da213864efc50c274d2b38ec0ca58b2 ]
In function kfd_wait_on_events(), when the call to copy_from_user()
fails, the value of return variable ret is 0. 0 indicates success, which
is inconsistent with the execution status. This patch fixes the bug by
assigning "-EFAULT" to ret when copy_from_user() returns an unexpected
value.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c
@@ -739,8 +739,10 @@ int kfd_wait_on_events(struct kfd_proces
struct kfd_event_data event_data;
if (copy_from_user(&event_data, &events[i],
- sizeof(struct kfd_event_data)))
+ sizeof(struct kfd_event_data))) {
+ ret = -EFAULT;
goto fail;
+ }
ret = init_event_waiter(p, &event_waiters[i],
event_data.event_id, i);
Patches currently in stable-queue which might be from bianpan2016@163.com are
queue-4.9/team-fix-memory-leaks.patch
queue-4.9/drm-amdkfd-fix-improper-return-value-on-error.patch
^ permalink raw reply
* Patch "drm/i915: Fix the overlay frontbuffer tracking" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: ville.syrjala, alexander.levin, chris, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/i915: Fix the overlay frontbuffer tracking
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-fix-the-overlay-frontbuffer-tracking.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Ville Syrj�l� <ville.syrjala@linux.intel.com>
Date: Wed, 7 Dec 2016 19:28:06 +0200
Subject: drm/i915: Fix the overlay frontbuffer tracking
From: Ville Syrj�l� <ville.syrjala@linux.intel.com>
[ Upstream commit 58d09ebdb4edf5d3ab3a2aee851ab0168bc83ec6 ]
Do the overlay frontbuffer tracking properly so that it matches
the state of the overlay on/off/continue requests.
One slight problem is that intel_frontbuffer_flip_complete()
may get delayed by an arbitrarily liong time due to the fact that
the overlay code likes to bail out when a signal occurs. So the
flip may not get completed until the ioctl is restarted. But fixing
that would require bigger surgery, so I decided to ignore it for now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481131693-27993-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_overlay.c | 64 ++++++++++++++++++++++-------------
1 file changed, 41 insertions(+), 23 deletions(-)
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -272,8 +272,30 @@ static int intel_overlay_on(struct intel
return intel_overlay_do_wait_request(overlay, req, NULL);
}
+static void intel_overlay_flip_prepare(struct intel_overlay *overlay,
+ struct i915_vma *vma)
+{
+ enum pipe pipe = overlay->crtc->pipe;
+
+ WARN_ON(overlay->old_vma);
+
+ i915_gem_track_fb(overlay->vma ? overlay->vma->obj : NULL,
+ vma ? vma->obj : NULL,
+ INTEL_FRONTBUFFER_OVERLAY(pipe));
+
+ intel_frontbuffer_flip_prepare(overlay->i915,
+ INTEL_FRONTBUFFER_OVERLAY(pipe));
+
+ overlay->old_vma = overlay->vma;
+ if (vma)
+ overlay->vma = i915_vma_get(vma);
+ else
+ overlay->vma = NULL;
+}
+
/* overlay needs to be enabled in OCMD reg */
static int intel_overlay_continue(struct intel_overlay *overlay,
+ struct i915_vma *vma,
bool load_polyphase_filter)
{
struct drm_i915_private *dev_priv = overlay->i915;
@@ -308,43 +330,44 @@ static int intel_overlay_continue(struct
intel_ring_emit(ring, flip_addr);
intel_ring_advance(ring);
+ intel_overlay_flip_prepare(overlay, vma);
+
intel_overlay_submit_request(overlay, req, NULL);
return 0;
}
-static void intel_overlay_release_old_vid_tail(struct i915_gem_active *active,
- struct drm_i915_gem_request *req)
+static void intel_overlay_release_old_vma(struct intel_overlay *overlay)
{
- struct intel_overlay *overlay =
- container_of(active, typeof(*overlay), last_flip);
struct i915_vma *vma;
vma = fetch_and_zero(&overlay->old_vma);
if (WARN_ON(!vma))
return;
- i915_gem_track_fb(vma->obj, NULL,
- INTEL_FRONTBUFFER_OVERLAY(overlay->crtc->pipe));
+ intel_frontbuffer_flip_complete(overlay->i915,
+ INTEL_FRONTBUFFER_OVERLAY(overlay->crtc->pipe));
i915_gem_object_unpin_from_display_plane(vma);
i915_vma_put(vma);
}
+static void intel_overlay_release_old_vid_tail(struct i915_gem_active *active,
+ struct drm_i915_gem_request *req)
+{
+ struct intel_overlay *overlay =
+ container_of(active, typeof(*overlay), last_flip);
+
+ intel_overlay_release_old_vma(overlay);
+}
+
static void intel_overlay_off_tail(struct i915_gem_active *active,
struct drm_i915_gem_request *req)
{
struct intel_overlay *overlay =
container_of(active, typeof(*overlay), last_flip);
- struct i915_vma *vma;
-
- /* never have the overlay hw on without showing a frame */
- vma = fetch_and_zero(&overlay->vma);
- if (WARN_ON(!vma))
- return;
- i915_gem_object_unpin_from_display_plane(vma);
- i915_vma_put(vma);
+ intel_overlay_release_old_vma(overlay);
overlay->crtc->overlay = NULL;
overlay->crtc = NULL;
@@ -398,6 +421,8 @@ static int intel_overlay_off(struct inte
}
intel_ring_advance(ring);
+ intel_overlay_flip_prepare(overlay, NULL);
+
return intel_overlay_do_wait_request(overlay, req,
intel_overlay_off_tail);
}
@@ -836,18 +861,10 @@ static int intel_overlay_do_put_image(st
intel_overlay_unmap_regs(overlay, regs);
- ret = intel_overlay_continue(overlay, scale_changed);
+ ret = intel_overlay_continue(overlay, vma, scale_changed);
if (ret)
goto out_unpin;
- i915_gem_track_fb(overlay->vma ? overlay->vma->obj : NULL,
- vma->obj, INTEL_FRONTBUFFER_OVERLAY(pipe));
-
- overlay->old_vma = overlay->vma;
- overlay->vma = vma;
-
- intel_frontbuffer_flip(dev_priv, INTEL_FRONTBUFFER_OVERLAY(pipe));
-
return 0;
out_unpin:
@@ -1215,6 +1232,7 @@ int intel_overlay_put_image_ioctl(struct
mutex_unlock(&dev->struct_mutex);
drm_modeset_unlock_all(dev);
+ i915_gem_object_put(new_bo);
kfree(params);
Patches currently in stable-queue which might be from ville.syrjala@linux.intel.com are
queue-4.9/drm-i915-fix-the-overlay-frontbuffer-tracking.patch
^ permalink raw reply
* Patch "drm: bridge: add DT bindings for TI ths8135" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: bgolaszewski, alexander.levin, architt, gregkh, laurent.pinchart,
robh
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm: bridge: add DT bindings for TI ths8135
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-bridge-add-dt-bindings-for-ti-ths8135.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date: Tue, 13 Dec 2016 11:09:16 +0100
Subject: drm: bridge: add DT bindings for TI ths8135
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[ Upstream commit 2e644be30fcc08c736f66b60f4898d274d4873ab ]
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1481623759-12786-3-git-send-email-bgolaszewski@baylibre.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt | 46 ++++++++++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,46 @@
+THS8135 Video DAC
+-----------------
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+-------
+
+vga-bridge {
+ compatible = "ti,ths8135";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&lcdc_out_vga>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
Patches currently in stable-queue which might be from bgolaszewski@baylibre.com are
queue-4.9/drm-bridge-add-dt-bindings-for-ti-ths8135.patch
^ permalink raw reply
* [dpdk-announce] CFP Deadline for DPDK Summit North America
From: O'Driscoll, Tim @ 2017-10-05 8:30 UTC (permalink / raw)
To: 'announce@dpdk.org'
The original CFP deadline for our DPDK Summit North America expired yesterday. This has now been extended to Friday October 13th (note that the website currently says Wednesday 13th but that's just a typo and will be corrected). So, if you were planning to submit a proposal but didn't make the deadline yesterday, there's still time to do this.
Details of the event, including registration and CFP info, are available at: http://events.linuxfoundation.org/events/dpdk-north-america-summit.
This year, the annual OVS event is on the following two days (November 16th & 17th), in the same venue. Details of the OVS event are available at: http://events.linuxfoundation.org/events/open-vswitch-fall-event.
We've been talking to the LF and to the OVS team about taking advantage of this by having some joint sessions on OVS-DPDK, and on DPDK-accelerated vswitches in general, on the afternoon of Wednesday 15th. It would be good to get some proposals on this before the new CFP deadline at the end of next week.
^ permalink raw reply
* Patch "cpufreq: intel_pstate: Update pid_params.sample_rate_ns in pid_param_set()" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: rafael.j.wysocki, alexander.levin, gregkh, viresh.kumar
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
cpufreq: intel_pstate: Update pid_params.sample_rate_ns in pid_param_set()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
cpufreq-intel_pstate-update-pid_params.sample_rate_ns-in-pid_param_set.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Date: Sun, 12 Mar 2017 18:12:56 +0100
Subject: cpufreq: intel_pstate: Update pid_params.sample_rate_ns in pid_param_set()
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
[ Upstream commit 6e7408acd04d06c04981c0c0fb5a2462b16fae4f ]
Fix the debugfs interface for PID tuning to actually update
pid_params.sample_rate_ns on PID parameters updates, as changing
pid_params.sample_rate_ms via debugfs has no effect now.
Fixes: a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/cpufreq/intel_pstate.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -609,6 +609,7 @@ static void intel_pstate_hwp_set_online_
static int pid_param_set(void *data, u64 val)
{
*(u32 *)data = val;
+ pid_params.sample_rate_ns = pid_params.sample_rate_ms * NSEC_PER_MSEC;
intel_pstate_reset_all_pid();
return 0;
}
Patches currently in stable-queue which might be from rafael.j.wysocki@intel.com are
queue-4.9/cpufreq-intel_pstate-update-pid_params.sample_rate_ns-in-pid_param_set.patch
^ permalink raw reply
* Patch "drivers/rapidio/devices/tsi721.c: make module parameter variable name unique" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: rdunlap, akpm, alexander.levin, alexandre.bounine, fengguang.wu,
gregkh, jeremy.lefaure, mporter, torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drivers/rapidio/devices/tsi721.c: make module parameter variable name unique
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drivers-rapidio-devices-tsi721.c-make-module-parameter-variable-name-unique.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Randy Dunlap <rdunlap@infradead.org>
Date: Fri, 31 Mar 2017 15:12:10 -0700
Subject: drivers/rapidio/devices/tsi721.c: make module parameter variable name unique
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit 4785603bd05b0b029c647080937674d9991600f9 ]
kbuild test robot reported a non-static variable name collision between
a staging driver and a RapidIO driver, with a generic variable name of
'dbg_level'.
Both drivers should be changed so that they don't use this generic
public variable name. This patch fixes the RapidIO driver but does not
change the user interface (name) for the module parameter.
drivers/staging/built-in.o:(.bss+0x109d0): multiple definition of `dbg_level'
drivers/rapidio/built-in.o:(.bss+0x16c): first defined here
Link: http://lkml.kernel.org/r/ab527fc5-aa3c-4b07-5d48-eef5de703192@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/rapidio/devices/tsi721.c | 4 ++--
drivers/rapidio/devices/tsi721.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -37,8 +37,8 @@
#include "tsi721.h"
#ifdef DEBUG
-u32 dbg_level;
-module_param(dbg_level, uint, S_IWUSR | S_IRUGO);
+u32 tsi_dbg_level;
+module_param_named(dbg_level, tsi_dbg_level, uint, S_IWUSR | S_IRUGO);
MODULE_PARM_DESC(dbg_level, "Debugging output level (default 0 = none)");
#endif
--- a/drivers/rapidio/devices/tsi721.h
+++ b/drivers/rapidio/devices/tsi721.h
@@ -40,11 +40,11 @@ enum {
};
#ifdef DEBUG
-extern u32 dbg_level;
+extern u32 tsi_dbg_level;
#define tsi_debug(level, dev, fmt, arg...) \
do { \
- if (DBG_##level & dbg_level) \
+ if (DBG_##level & tsi_dbg_level) \
dev_dbg(dev, "%s: " fmt "\n", __func__, ##arg); \
} while (0)
#else
Patches currently in stable-queue which might be from rdunlap@infradead.org are
queue-4.9/drivers-rapidio-devices-tsi721.c-make-module-parameter-variable-name-unique.patch
^ permalink raw reply
* Patch "clk/axs10x: Clear init field in driver probe" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: Jose.Abreu, alexander.levin, gregkh, joabreu, mturquette,
palminha, sboyd
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
clk/axs10x: Clear init field in driver probe
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
clk-axs10x-clear-init-field-in-driver-probe.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Mon, 12 Dec 2016 11:08:55 +0000
Subject: clk/axs10x: Clear init field in driver probe
From: Jose Abreu <Jose.Abreu@synopsys.com>
[ Upstream commit 6205406cf6f282d622f31de25036e6d1ab3a2ff5 ]
Init field must be cleared in driver probe as this structure is not
dinamically allocated. If not, wrong flags can be passed to core.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Fixes: 923587aafc2c ("clk/axs10x: Add I2S PLL clock driver")
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Link: lkml.kernel.org/r/040cc9afdfa0e95ce7a01c406ff427ef7dc0c0fd.1481540717.git.joabreu@synopsys.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/axs10x/i2s_pll_clock.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/clk/axs10x/i2s_pll_clock.c
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -182,6 +182,7 @@ static int i2s_pll_clk_probe(struct plat
if (IS_ERR(pll_clk->base))
return PTR_ERR(pll_clk->base);
+ memset(&init, 0, sizeof(init));
clk_name = node->name;
init.name = clk_name;
init.ops = &i2s_pll_ops;
Patches currently in stable-queue which might be from Jose.Abreu@synopsys.com are
queue-4.9/clk-axs10x-clear-init-field-in-driver-probe.patch
^ permalink raw reply
* Re: [PATCH v6 4/8] ethdev: add GTP items to support flow API
From: Adrien Mazarguil @ 2017-10-05 8:30 UTC (permalink / raw)
To: Wu, Jingjing; +Cc: Sean Harte, Xing, Beilei, Chilikin, Andrey, dev@dpdk.org
In-Reply-To: <9BB6961774997848B5B42BEC655768F810E89F3C@SHSMSX103.ccr.corp.intel.com>
On Thu, Oct 05, 2017 at 08:06:38AM +0000, Wu, Jingjing wrote:
>
>
> > -----Original Message-----
> > From: Sean Harte [mailto:seanbh@gmail.com]
> > Sent: Tuesday, October 3, 2017 4:57 PM
> > To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Cc: Xing, Beilei <beilei.xing@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Chilikin,
> > Andrey <andrey.chilikin@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v6 4/8] ethdev: add GTP items to support flow API
> >
> > On 2 October 2017 at 13:27, Adrien Mazarguil <adrien.mazarguil@6wind.com> wrote:
> > > On Fri, Sep 29, 2017 at 10:29:55AM +0100, Sean Harte wrote:
> > >> On 29 September 2017 at 09:54, Xing, Beilei <beilei.xing@intel.com> wrote:
> > > <snip>
> > >> >> > /**
> > >> >> > + * RTE_FLOW_ITEM_TYPE_GTP.
> > >> >> > + *
> > >> >> > + * Matches a GTPv1 header.
> > >> >> > + */
> > >> >> > +struct rte_flow_item_gtp {
> > >> >> > + /**
> > >> >> > + * Version (3b), protocol type (1b), reserved (1b),
> > >> >> > + * Extension header flag (1b),
> > >> >> > + * Sequence number flag (1b),
> > >> >> > + * N-PDU number flag (1b).
> > >> >> > + */
> > >> >> > + uint8_t v_pt_rsv_flags;
> > >> >> > + uint8_t msg_type; /**< Message type. */
> > >> >> > + rte_be16_t msg_len; /**< Message length. */
> > >> >> > + rte_be32_t teid; /**< Tunnel endpoint identifier. */ };
> > >> >>
> > >> >> In future, you might add support for GTPv2 (which is used since LTE).
> > >> >> Maybe this structure should have v1 in its name to avoid confusion?
> > >> >
> > >> > I considered it before. But I think we can modify it when we support GTPv2 in future,
> > and keep concise 'GTP' currently:) since I have described it matches v1 header.
> > >> >
> > >>
> > >> You could rename v_pt_rsv_flags to version_flags to avoid some future
> > >> code changes to support GTPv2. There's still the issue that not all
> > >> GTPv2 messages have a TEID though.
> > >
> > > Although they have the same size, the header of these two protocols
> > > obviously differs. My suggestion would be to go with a separate GTPv2
> > > pattern item using its own dedicated structure instead.
> > >
> > > --
> > > Adrien Mazarguil
> > > 6WIND
> >
> > The 1st four bytes are the same (flags in first byte have different
> > meanings, but the bits indicating the version are in the same
> > location). After that, different fields in each version are optional,
> > and the headers have variable size. A single structure could be used
> > if the first field is renamed to something like "version_flags", and
> > then check that the teid field in item->mask is not set if
> > ((version_flags >> 5 == 2) && ((version_flags >> 4) & 1) == 1). If
> > there's going to be two structures, it would be good to put v1 and v2
> > in the names, in my opinion.
>
> I think the name GTP is OK for now. Due to v1 and v2 are different, why not rename them
> when the v2 supporting are introduced?
In any case I'd rather avoid renaming and modifying existing items and
structure contents once part of the API to avoid API/ABI breakage that
require deprecation notices, user applications updates and so on; rte_flow
has been created as a kind of append-only API for this reason (of course
there are exceptions, such as a bad design choice for the VLAN item I intend
to fix at some point).
I'm fine with the name "GTP" as defined now and documented as matching
GTPv1. We can add "GTPv2"-themed definitions later when some implementation
provides the ability to match this version. If you want to append the "v1"
suffix right now to be more explicit, I'm also fine with that. Your call.
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Patch "clk: sunxi-ng: fix PLL_CPUX adjusting on H3" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: megous, alexander.levin, gregkh, johns98, maxime.ripard, wens
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
clk: sunxi-ng: fix PLL_CPUX adjusting on H3
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
clk-sunxi-ng-fix-pll_cpux-adjusting-on-h3.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Ondrej Jirman <megous@megous.com>
Date: Fri, 25 Nov 2016 01:28:47 +0100
Subject: clk: sunxi-ng: fix PLL_CPUX adjusting on H3
From: Ondrej Jirman <megous@megous.com>
[ Upstream commit a43c96427e713bea94e9ef50e8be1f493afc0691 ]
When adjusting PLL_CPUX on H3, the PLL is temporarily driven
too high, and the system becomes unstable (oopses or hangs).
Add a notifier to avoid this situation by temporarily switching
to a known stable 24 MHz oscillator.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Tested-by: Lutz Sammer <johns98@gmx.net>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -803,6 +803,13 @@ static const struct sunxi_ccu_desc sun8i
.num_resets = ARRAY_SIZE(sun8i_h3_ccu_resets),
};
+static struct ccu_mux_nb sun8i_h3_cpu_nb = {
+ .common = &cpux_clk.common,
+ .cm = &cpux_clk.mux,
+ .delay_us = 1, /* > 8 clock cycles at 24 MHz */
+ .bypass_index = 1, /* index of 24 MHz oscillator */
+};
+
static void __init sun8i_h3_ccu_setup(struct device_node *node)
{
void __iomem *reg;
@@ -821,6 +828,9 @@ static void __init sun8i_h3_ccu_setup(st
writel(val | (3 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);
sunxi_ccu_probe(node, reg, &sun8i_h3_ccu_desc);
+
+ ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
+ &sun8i_h3_cpu_nb);
}
CLK_OF_DECLARE(sun8i_h3_ccu, "allwinner,sun8i-h3-ccu",
sun8i_h3_ccu_setup);
Patches currently in stable-queue which might be from megous@megous.com are
queue-4.9/clk-sunxi-ng-fix-pll_cpux-adjusting-on-h3.patch
^ permalink raw reply
* Patch "Btrfs: fix potential use-after-free for cloned bio" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: bo.li.liu, alexander.levin, diegocg, dsterba, gregkh
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
Btrfs: fix potential use-after-free for cloned bio
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
btrfs-fix-potential-use-after-free-for-cloned-bio.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Liu Bo <bo.li.liu@oracle.com>
Date: Mon, 10 Apr 2017 12:36:26 -0700
Subject: Btrfs: fix potential use-after-free for cloned bio
From: Liu Bo <bo.li.liu@oracle.com>
[ Upstream commit a967efb30b3afa3d858edd6a17f544f9e9e46eea ]
KASAN reports that there is a use-after-free case of bio in btrfs_map_bio.
If we need to submit IOs to several disks at a time, the original bio
would get cloned and mapped to the destination disk, but we really should
use the original bio instead of a cloned bio to do the sanity check
because cloned bios are likely to be freed by its endio.
Reported-by: Diego <diegocg@gmail.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/volumes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -6226,7 +6226,7 @@ int btrfs_map_bio(struct btrfs_root *roo
for (dev_nr = 0; dev_nr < total_devs; dev_nr++) {
dev = bbio->stripes[dev_nr].dev;
if (!dev || !dev->bdev ||
- (bio_op(bio) == REQ_OP_WRITE && !dev->writeable)) {
+ (bio_op(first_bio) == REQ_OP_WRITE && !dev->writeable)) {
bbio_error(bbio, first_bio, logical);
continue;
}
Patches currently in stable-queue which might be from bo.li.liu@oracle.com are
queue-4.9/btrfs-fix-potential-use-after-free-for-cloned-bio.patch
queue-4.9/btrfs-fix-segmentation-fault-when-doing-dio-read.patch
^ permalink raw reply
* Patch "Btrfs: fix segmentation fault when doing dio read" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: bo.li.liu, alexander.levin, dsterba, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
Btrfs: fix segmentation fault when doing dio read
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
btrfs-fix-segmentation-fault-when-doing-dio-read.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Liu Bo <bo.li.liu@oracle.com>
Date: Fri, 7 Apr 2017 13:11:10 -0700
Subject: Btrfs: fix segmentation fault when doing dio read
From: Liu Bo <bo.li.liu@oracle.com>
[ Upstream commit 97bf5a5589aa3a59c60aa775fc12ec0483fc5002 ]
Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
introduced this bug during iterating bio pages in dio read's endio hook,
and it could end up with segment fault of the dio reading task.
So the reason is 'if (nr_sectors--)', and it makes the code assume that
there is one more block in the same page, so page offset is increased and
the bio which is created to repair the bad block then has an incorrect
bvec.bv_offset, and a later access of the page content would throw a
segmentation fault.
This also adds ASSERT to check page offset against page size.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/inode.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8050,8 +8050,10 @@ next_block_or_try_again:
start += sectorsize;
- if (nr_sectors--) {
+ nr_sectors--;
+ if (nr_sectors) {
pgoff += sectorsize;
+ ASSERT(pgoff < PAGE_SIZE);
goto next_block_or_try_again;
}
}
@@ -8157,8 +8159,10 @@ next:
ASSERT(nr_sectors);
- if (--nr_sectors) {
+ nr_sectors--;
+ if (nr_sectors) {
pgoff += sectorsize;
+ ASSERT(pgoff < PAGE_SIZE);
goto next_block;
}
}
Patches currently in stable-queue which might be from bo.li.liu@oracle.com are
queue-4.9/btrfs-fix-potential-use-after-free-for-cloned-bio.patch
queue-4.9/btrfs-fix-segmentation-fault-when-doing-dio-read.patch
^ permalink raw reply
* Patch "bridge: netlink: register netdevice before executing changelink" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: idosch, alexander.levin, davem, gregkh, nikolay, peter
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
bridge: netlink: register netdevice before executing changelink
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
bridge-netlink-register-netdevice-before-executing-changelink.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Ido Schimmel <idosch@mellanox.com>
Date: Mon, 10 Apr 2017 14:59:28 +0300
Subject: bridge: netlink: register netdevice before executing changelink
From: Ido Schimmel <idosch@mellanox.com>
[ Upstream commit 5b8d5429daa05bebef6ffd3297df3b502cc6f184 ]
Peter reported a kernel oops when executing the following command:
$ ip link add name test type bridge vlan_default_pvid 1
[13634.939408] BUG: unable to handle kernel NULL pointer dereference at
0000000000000190
[13634.939436] IP: __vlan_add+0x73/0x5f0
[...]
[13634.939783] Call Trace:
[13634.939791] ? pcpu_next_unpop+0x3b/0x50
[13634.939801] ? pcpu_alloc+0x3d2/0x680
[13634.939810] ? br_vlan_add+0x135/0x1b0
[13634.939820] ? __br_vlan_set_default_pvid.part.28+0x204/0x2b0
[13634.939834] ? br_changelink+0x120/0x4e0
[13634.939844] ? br_dev_newlink+0x50/0x70
[13634.939854] ? rtnl_newlink+0x5f5/0x8a0
[13634.939864] ? rtnl_newlink+0x176/0x8a0
[13634.939874] ? mem_cgroup_commit_charge+0x7c/0x4e0
[13634.939886] ? rtnetlink_rcv_msg+0xe1/0x220
[13634.939896] ? lookup_fast+0x52/0x370
[13634.939905] ? rtnl_newlink+0x8a0/0x8a0
[13634.939915] ? netlink_rcv_skb+0xa1/0xc0
[13634.939925] ? rtnetlink_rcv+0x24/0x30
[13634.939934] ? netlink_unicast+0x177/0x220
[13634.939944] ? netlink_sendmsg+0x2fe/0x3b0
[13634.939954] ? _copy_from_user+0x39/0x40
[13634.939964] ? sock_sendmsg+0x30/0x40
[13634.940159] ? ___sys_sendmsg+0x29d/0x2b0
[13634.940326] ? __alloc_pages_nodemask+0xdf/0x230
[13634.940478] ? mem_cgroup_commit_charge+0x7c/0x4e0
[13634.940592] ? mem_cgroup_try_charge+0x76/0x1a0
[13634.940701] ? __handle_mm_fault+0xdb9/0x10b0
[13634.940809] ? __sys_sendmsg+0x51/0x90
[13634.940917] ? entry_SYSCALL_64_fastpath+0x1e/0xad
The problem is that the bridge's VLAN group is created after setting the
default PVID, when registering the netdevice and executing its
ndo_init().
Fix this by changing the order of both operations, so that
br_changelink() is only processed after the netdevice is registered,
when the VLAN group is already initialized.
Fixes: b6677449dff6 ("bridge: netlink: call br_changelink() during br_dev_newlink()")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reported-by: Peter V. Saveliev <peter@svinota.eu>
Tested-by: Peter V. Saveliev <peter@svinota.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bridge/br_netlink.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1098,11 +1098,14 @@ static int br_dev_newlink(struct net *sr
spin_unlock_bh(&br->lock);
}
- err = br_changelink(dev, tb, data);
+ err = register_netdevice(dev);
if (err)
return err;
- return register_netdevice(dev);
+ err = br_changelink(dev, tb, data);
+ if (err)
+ unregister_netdevice(dev);
+ return err;
}
static size_t br_get_size(const struct net_device *brdev)
Patches currently in stable-queue which might be from idosch@mellanox.com are
queue-4.9/bridge-netlink-register-netdevice-before-executing-changelink.patch
^ permalink raw reply
* Patch "ath10k: prevent sta pointer rcu violation" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: michal.kazior, alexander.levin, gregkh, kvalo; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ath10k: prevent sta pointer rcu violation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ath10k-prevent-sta-pointer-rcu-violation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Michal Kazior <michal.kazior@tieto.com>
Date: Thu, 12 Jan 2017 16:14:30 +0100
Subject: ath10k: prevent sta pointer rcu violation
From: Michal Kazior <michal.kazior@tieto.com>
[ Upstream commit 0a744d927406389e00687560d9ce3c5ab0e58db9 ]
Station pointers are RCU protected so driver must
be extra careful if it tries to store them
internally for later use outside of the RCU
section it obtained it in.
It was possible for station teardown to race with
some htt events. The possible outcome could be a
use-after-free and a crash.
Only peer-flow-control capable firmware was
affected (so hardware-wise qca99x0 and qca4019).
This could be done in sta_state() itself via
explicit synchronize_net() call but there's
already a convenient sta_pre_rcu_remove() op that
can be hooked up to avoid extra rcu stall.
The peer->sta pointer itself can't be set to
NULL/ERR_PTR because it is later used in
sta_state() for extra sanity checks.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/mac.c | 18 ++++++++++++++++++
2 files changed, 19 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -314,6 +314,7 @@ struct ath10k_peer {
struct ieee80211_vif *vif;
struct ieee80211_sta *sta;
+ bool removed;
int vdev_id;
u8 addr[ETH_ALEN];
DECLARE_BITMAP(peer_ids, ATH10K_MAX_NUM_PEER_IDS);
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3738,6 +3738,9 @@ struct ieee80211_txq *ath10k_mac_txq_loo
if (!peer)
return NULL;
+ if (peer->removed)
+ return NULL;
+
if (peer->sta)
return peer->sta->txq[tid];
else if (peer->vif)
@@ -7422,6 +7425,20 @@ ath10k_mac_op_switch_vif_chanctx(struct
return 0;
}
+static void ath10k_mac_op_sta_pre_rcu_remove(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct ath10k *ar;
+ struct ath10k_peer *peer;
+
+ ar = hw->priv;
+
+ list_for_each_entry(peer, &ar->peers, list)
+ if (peer->sta == sta)
+ peer->removed = true;
+}
+
static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_mac_op_tx,
.wake_tx_queue = ath10k_mac_op_wake_tx_queue,
@@ -7462,6 +7479,7 @@ static const struct ieee80211_ops ath10k
.assign_vif_chanctx = ath10k_mac_op_assign_vif_chanctx,
.unassign_vif_chanctx = ath10k_mac_op_unassign_vif_chanctx,
.switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
+ .sta_pre_rcu_remove = ath10k_mac_op_sta_pre_rcu_remove,
CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
Patches currently in stable-queue which might be from michal.kazior@tieto.com are
queue-4.9/ath10k-prevent-sta-pointer-rcu-violation.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.