--- /dev/null
+From 56aeb07c914a616ab84357d34f8414a69b140cdf Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Thu, 4 Jan 2018 17:53:12 +0100
+Subject: ARM: dts: kirkwood: fix pin-muxing of MPP7 on OpenBlocks A7
+
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+commit 56aeb07c914a616ab84357d34f8414a69b140cdf upstream.
+
+MPP7 is currently muxed as "gpio", but this function doesn't exist for
+MPP7, only "gpo" is available. This causes the following error:
+
+kirkwood-pinctrl f1010000.pin-controller: unsupported function gpio on pin mpp7
+pinctrl core: failed to register map default (6): invalid type given
+kirkwood-pinctrl f1010000.pin-controller: error claiming hogs: -22
+kirkwood-pinctrl f1010000.pin-controller: could not claim hogs: -22
+kirkwood-pinctrl f1010000.pin-controller: unable to register pinctrl driver
+kirkwood-pinctrl: probe of f1010000.pin-controller failed with error -22
+
+So the pinctrl driver is not probed, all device drivers (including the
+UART driver) do a -EPROBE_DEFER, and therefore the system doesn't
+really boot (well, it boots, but with no UART, and no devices that
+require pin-muxing).
+
+Back when the Device Tree file for this board was introduced, the
+definition was already wrong. The pinctrl driver also always described
+as "gpo" this function for MPP7. However, between Linux 4.10 and 4.11,
+a hog pin failing to be muxed was turned from a simple warning to a
+hard error that caused the entire pinctrl driver probe to bail
+out. This is probably the result of commit 6118714275f0a ("pinctrl:
+core: Fix pinctrl_register_and_init() with pinctrl_enable()").
+
+This commit fixes the Device Tree to use the proper "gpo" function for
+MPP7, which fixes the boot of OpenBlocks A7, which was broken since
+Linux 4.11.
+
+Fixes: f24b56cbcd9d ("ARM: kirkwood: add support for OpenBlocks A7 platform")
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/kirkwood-openblocks_a7.dts | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
++++ b/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
+@@ -53,7 +53,8 @@
+ };
+
+ pinctrl: pin-controller@10000 {
+- pinctrl-0 = <&pmx_dip_switches &pmx_gpio_header>;
++ pinctrl-0 = <&pmx_dip_switches &pmx_gpio_header
++ &pmx_gpio_header_gpo>;
+ pinctrl-names = "default";
+
+ pmx_uart0: pmx-uart0 {
+@@ -85,11 +86,16 @@
+ * ground.
+ */
+ pmx_gpio_header: pmx-gpio-header {
+- marvell,pins = "mpp17", "mpp7", "mpp29", "mpp28",
++ marvell,pins = "mpp17", "mpp29", "mpp28",
+ "mpp35", "mpp34", "mpp40";
+ marvell,function = "gpio";
+ };
+
++ pmx_gpio_header_gpo: pxm-gpio-header-gpo {
++ marvell,pins = "mpp7";
++ marvell,function = "gpo";
++ };
++
+ pmx_gpio_init: pmx-init {
+ marvell,pins = "mpp38";
+ marvell,function = "gpio";
--- /dev/null
+From c13e7f313da33d1488355440f1a10feb1897480a Mon Sep 17 00:00:00 2001
+From: Maxime Ripard <maxime.ripard@free-electrons.com>
+Date: Fri, 19 Jan 2018 14:32:08 +0100
+Subject: ARM: sunxi_defconfig: Enable CMA
+
+From: Maxime Ripard <maxime.ripard@free-electrons.com>
+
+commit c13e7f313da33d1488355440f1a10feb1897480a upstream.
+
+The DRM driver most notably, but also out of tree drivers (for now) like
+the VPU or GPU drivers, are quite big consumers of large, contiguous memory
+buffers. However, the sunxi_defconfig doesn't enable CMA in order to
+mitigate that, which makes them almost unusable.
+
+Enable it to make sure it somewhat works.
+
+Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/configs/sunxi_defconfig | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm/configs/sunxi_defconfig
++++ b/arch/arm/configs/sunxi_defconfig
+@@ -11,6 +11,7 @@ CONFIG_SMP=y
+ CONFIG_NR_CPUS=8
+ CONFIG_AEABI=y
+ CONFIG_HIGHMEM=y
++CONFIG_CMA=y
+ CONFIG_ARM_APPENDED_DTB=y
+ CONFIG_ARM_ATAG_DTB_COMPAT=y
+ CONFIG_CPU_FREQ=y
+@@ -35,6 +36,7 @@ CONFIG_CAN_SUN4I=y
+ # CONFIG_WIRELESS is not set
+ CONFIG_DEVTMPFS=y
+ CONFIG_DEVTMPFS_MOUNT=y
++CONFIG_DMA_CMA=y
+ CONFIG_BLK_DEV_SD=y
+ CONFIG_ATA=y
+ CONFIG_AHCI_SUNXI=y
--- /dev/null
+From d8a243af1a68395e07ac85384a2740d4134c67f4 Mon Sep 17 00:00:00 2001
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+Date: Mon, 15 Jan 2018 16:31:19 +0100
+Subject: can: peak: fix potential bug in packet fragmentation
+
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+
+commit d8a243af1a68395e07ac85384a2740d4134c67f4 upstream.
+
+In some rare conditions when running one PEAK USB-FD interface over
+a non high-speed USB controller, one useless USB fragment might be sent.
+This patch fixes the way a USB command is fragmented when its length is
+greater than 64 bytes and when the underlying USB controller is not a
+high-speed one.
+
+Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 21 +++++++++++----------
+ 1 file changed, 11 insertions(+), 10 deletions(-)
+
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+@@ -184,7 +184,7 @@ static int pcan_usb_fd_send_cmd(struct p
+ void *cmd_head = pcan_usb_fd_cmd_buffer(dev);
+ int err = 0;
+ u8 *packet_ptr;
+- int i, n = 1, packet_len;
++ int packet_len;
+ ptrdiff_t cmd_len;
+
+ /* usb device unregistered? */
+@@ -201,17 +201,13 @@ static int pcan_usb_fd_send_cmd(struct p
+ }
+
+ packet_ptr = cmd_head;
++ packet_len = cmd_len;
+
+ /* firmware is not able to re-assemble 512 bytes buffer in full-speed */
+- if ((dev->udev->speed != USB_SPEED_HIGH) &&
+- (cmd_len > PCAN_UFD_LOSPD_PKT_SIZE)) {
+- packet_len = PCAN_UFD_LOSPD_PKT_SIZE;
+- n += cmd_len / packet_len;
+- } else {
+- packet_len = cmd_len;
+- }
++ if (unlikely(dev->udev->speed != USB_SPEED_HIGH))
++ packet_len = min(packet_len, PCAN_UFD_LOSPD_PKT_SIZE);
+
+- for (i = 0; i < n; i++) {
++ do {
+ err = usb_bulk_msg(dev->udev,
+ usb_sndbulkpipe(dev->udev,
+ PCAN_USBPRO_EP_CMDOUT),
+@@ -224,7 +220,12 @@ static int pcan_usb_fd_send_cmd(struct p
+ }
+
+ packet_ptr += packet_len;
+- }
++ cmd_len -= packet_len;
++
++ if (cmd_len < PCAN_UFD_LOSPD_PKT_SIZE)
++ packet_len = cmd_len;
++
++ } while (packet_len > 0);
+
+ return err;
+ }
--- /dev/null
+From bc68d0a43560e950850fc69b58f0f8254b28f6d6 Mon Sep 17 00:00:00 2001
+From: Joe Thornber <thornber@redhat.com>
+Date: Wed, 20 Dec 2017 09:56:06 +0000
+Subject: dm btree: fix serious bug in btree_split_beneath()
+
+From: Joe Thornber <thornber@redhat.com>
+
+commit bc68d0a43560e950850fc69b58f0f8254b28f6d6 upstream.
+
+When inserting a new key/value pair into a btree we walk down the spine of
+btree nodes performing the following 2 operations:
+
+ i) space for a new entry
+ ii) adjusting the first key entry if the new key is lower than any in the node.
+
+If the _root_ node is full, the function btree_split_beneath() allocates 2 new
+nodes, and redistibutes the root nodes entries between them. The root node is
+left with 2 entries corresponding to the 2 new nodes.
+
+btree_split_beneath() then adjusts the spine to point to one of the two new
+children. This means the first key is never adjusted if the new key was lower,
+ie. operation (ii) gets missed out. This can result in the new key being
+'lost' for a period; until another low valued key is inserted that will uncover
+it.
+
+This is a serious bug, and quite hard to make trigger in normal use. A
+reproducing test case ("thin create devices-in-reverse-order") is
+available as part of the thin-provision-tools project:
+ https://github.com/jthornber/thin-provisioning-tools/blob/master/functional-tests/device-mapper/dm-tests.scm#L593
+
+Fix the issue by changing btree_split_beneath() so it no longer adjusts
+the spine. Instead it unlocks both the new nodes, and lets the main
+loop in btree_insert_raw() relock the appropriate one and make any
+neccessary adjustments.
+
+Reported-by: Monty Pavel <monty_pavel@sina.com>
+Signed-off-by: Joe Thornber <thornber@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/persistent-data/dm-btree.c | 19 ++-----------------
+ 1 file changed, 2 insertions(+), 17 deletions(-)
+
+--- a/drivers/md/persistent-data/dm-btree.c
++++ b/drivers/md/persistent-data/dm-btree.c
+@@ -678,23 +678,8 @@ static int btree_split_beneath(struct sh
+ pn->keys[1] = rn->keys[0];
+ memcpy_disk(value_ptr(pn, 1), &val, sizeof(__le64));
+
+- /*
+- * rejig the spine. This is ugly, since it knows too
+- * much about the spine
+- */
+- if (s->nodes[0] != new_parent) {
+- unlock_block(s->info, s->nodes[0]);
+- s->nodes[0] = new_parent;
+- }
+- if (key < le64_to_cpu(rn->keys[0])) {
+- unlock_block(s->info, right);
+- s->nodes[1] = left;
+- } else {
+- unlock_block(s->info, left);
+- s->nodes[1] = right;
+- }
+- s->count = 2;
+-
++ unlock_block(s->info, left);
++ unlock_block(s->info, right);
+ return 0;
+ }
+
--- /dev/null
+From 490ae017f54e55bde382d45ea24bddfb6d1a0aaf Mon Sep 17 00:00:00 2001
+From: Dennis Yang <dennisyang@qnap.com>
+Date: Tue, 12 Dec 2017 18:21:40 +0800
+Subject: dm thin metadata: THIN_MAX_CONCURRENT_LOCKS should be 6
+
+From: Dennis Yang <dennisyang@qnap.com>
+
+commit 490ae017f54e55bde382d45ea24bddfb6d1a0aaf upstream.
+
+For btree removal, there is a corner case that a single thread
+could takes 6 locks which is more than THIN_MAX_CONCURRENT_LOCKS(5)
+and leads to deadlock.
+
+A btree removal might eventually call
+rebalance_children()->rebalance3() to rebalance entries of three
+neighbor child nodes when shadow_spine has already acquired two
+write locks. In rebalance3(), it tries to shadow and acquire the
+write locks of all three child nodes. However, shadowing a child
+node requires acquiring a read lock of the original child node and
+a write lock of the new block. Although the read lock will be
+released after block shadowing, shadowing the third child node
+in rebalance3() could still take the sixth lock.
+(2 write locks for shadow_spine +
+ 2 write locks for the first two child nodes's shadow +
+ 1 write lock for the last child node's shadow +
+ 1 read lock for the last child node)
+
+Signed-off-by: Dennis Yang <dennisyang@qnap.com>
+Acked-by: Joe Thornber <thornber@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-thin-metadata.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-thin-metadata.c
++++ b/drivers/md/dm-thin-metadata.c
+@@ -81,10 +81,14 @@
+ #define SECTOR_TO_BLOCK_SHIFT 3
+
+ /*
++ * For btree insert:
+ * 3 for btree insert +
+ * 2 for btree lookup used within space map
++ * For btree remove:
++ * 2 for shadow spine +
++ * 4 for rebalance 3 child node
+ */
+-#define THIN_MAX_CONCURRENT_LOCKS 5
++#define THIN_MAX_CONCURRENT_LOCKS 6
+
+ /* This should be plenty */
+ #define SPACE_MAP_ROOT_SIZE 128
--- /dev/null
+From 906bf7daa0618d0ef39f4872ca42218c29a3631f Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 8 Jan 2018 17:20:18 -0800
+Subject: Input: 88pm860x-ts - fix child-node lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 906bf7daa0618d0ef39f4872ca42218c29a3631f upstream.
+
+Fix child node-lookup during probe, which ended up searching the whole
+device tree depth-first starting at parent rather than just matching on
+its children.
+
+To make things worse, the parent node was prematurely freed, while the
+child node was leaked.
+
+Fixes: 2e57d56747e6 ("mfd: 88pm860x: Device tree support")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/touchscreen/88pm860x-ts.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+--- a/drivers/input/touchscreen/88pm860x-ts.c
++++ b/drivers/input/touchscreen/88pm860x-ts.c
+@@ -126,7 +126,7 @@ static int pm860x_touch_dt_init(struct p
+ int data, n, ret;
+ if (!np)
+ return -ENODEV;
+- np = of_find_node_by_name(np, "touch");
++ np = of_get_child_by_name(np, "touch");
+ if (!np) {
+ dev_err(&pdev->dev, "Can't find touch node\n");
+ return -EINVAL;
+@@ -144,13 +144,13 @@ static int pm860x_touch_dt_init(struct p
+ if (data) {
+ ret = pm860x_reg_write(i2c, PM8607_GPADC_MISC1, data);
+ if (ret < 0)
+- return -EINVAL;
++ goto err_put_node;
+ }
+ /* set tsi prebias time */
+ if (!of_property_read_u32(np, "marvell,88pm860x-tsi-prebias", &data)) {
+ ret = pm860x_reg_write(i2c, PM8607_TSI_PREBIAS, data);
+ if (ret < 0)
+- return -EINVAL;
++ goto err_put_node;
+ }
+ /* set prebias & prechg time of pen detect */
+ data = 0;
+@@ -161,10 +161,18 @@ static int pm860x_touch_dt_init(struct p
+ if (data) {
+ ret = pm860x_reg_write(i2c, PM8607_PD_PREBIAS, data);
+ if (ret < 0)
+- return -EINVAL;
++ goto err_put_node;
+ }
+ of_property_read_u32(np, "marvell,88pm860x-resistor-X", res_x);
++
++ of_node_put(np);
++
+ return 0;
++
++err_put_node:
++ of_node_put(np);
++
++ return -EINVAL;
+ }
+ #else
+ #define pm860x_touch_dt_init(x, y, z) (-1)
--- /dev/null
+From 4d94e776bd29670f01befa27e12df784fa05fa2e Mon Sep 17 00:00:00 2001
+From: Nir Perry <nirperry@gmail.com>
+Date: Thu, 11 Jan 2018 23:43:26 -0800
+Subject: Input: ALPS - fix multi-touch decoding on SS4 plus touchpads
+
+From: Nir Perry <nirperry@gmail.com>
+
+commit 4d94e776bd29670f01befa27e12df784fa05fa2e upstream.
+
+The fix for handling two-finger scroll (i4a646580f793 - "Input: ALPS -
+fix two-finger scroll breakage in right side on ALPS touchpad")
+introduced a minor "typo" that broke decoding of multi-touch events are
+decoded on some ALPS touchpads. For example, tapping with three-fingers
+can no longer be used to emulate middle-mouse-button (the kernel doesn't
+recognize this as the proper event, and doesn't report it correctly to
+userspace). This affects touchpads that use SS4 "plus" protocol
+variant, like those found on Dell E7270 & E7470 laptops (tested on
+E7270).
+
+First, probably the code in alps_decode_ss4_v2() for case
+SS4_PACKET_ID_MULTI used inconsistent indices to "f->mt[]". You can see
+0 & 1 are used for the "if" part but 2 & 3 are used for the "else" part.
+
+Second, in the previous patch, new macros were introduced to decode X
+coordinates specific to the SS4 "plus" variant, but the macro to
+define the maximum X value wasn't changed accordingly. The macros to
+decode X values for "plus" variant are effectively shifted right by 1
+bit, but the max wasn't shifted too. This causes the driver to
+incorrectly handle "no data" cases, which also interfered with how
+multi-touch was handled.
+
+Fixes: 4a646580f793 ("Input: ALPS - fix two-finger scroll breakage...")
+Signed-off-by: Nir Perry <nirperry@gmail.com>
+Reviewed-by: Masaki Ota <masaki.ota@jp.alps.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/alps.c | 23 +++++++++++++----------
+ drivers/input/mouse/alps.h | 10 ++++++----
+ 2 files changed, 19 insertions(+), 14 deletions(-)
+
+--- a/drivers/input/mouse/alps.c
++++ b/drivers/input/mouse/alps.c
+@@ -1247,29 +1247,32 @@ static int alps_decode_ss4_v2(struct alp
+ case SS4_PACKET_ID_MULTI:
+ if (priv->flags & ALPS_BUTTONPAD) {
+ if (IS_SS4PLUS_DEV(priv->dev_id)) {
+- f->mt[0].x = SS4_PLUS_BTL_MF_X_V2(p, 0);
+- f->mt[1].x = SS4_PLUS_BTL_MF_X_V2(p, 1);
++ f->mt[2].x = SS4_PLUS_BTL_MF_X_V2(p, 0);
++ f->mt[3].x = SS4_PLUS_BTL_MF_X_V2(p, 1);
++ no_data_x = SS4_PLUS_MFPACKET_NO_AX_BL;
+ } else {
+ f->mt[2].x = SS4_BTL_MF_X_V2(p, 0);
+ f->mt[3].x = SS4_BTL_MF_X_V2(p, 1);
++ no_data_x = SS4_MFPACKET_NO_AX_BL;
+ }
++ no_data_y = SS4_MFPACKET_NO_AY_BL;
+
+ f->mt[2].y = SS4_BTL_MF_Y_V2(p, 0);
+ f->mt[3].y = SS4_BTL_MF_Y_V2(p, 1);
+- no_data_x = SS4_MFPACKET_NO_AX_BL;
+- no_data_y = SS4_MFPACKET_NO_AY_BL;
+ } else {
+ if (IS_SS4PLUS_DEV(priv->dev_id)) {
+- f->mt[0].x = SS4_PLUS_STD_MF_X_V2(p, 0);
+- f->mt[1].x = SS4_PLUS_STD_MF_X_V2(p, 1);
++ f->mt[2].x = SS4_PLUS_STD_MF_X_V2(p, 0);
++ f->mt[3].x = SS4_PLUS_STD_MF_X_V2(p, 1);
++ no_data_x = SS4_PLUS_MFPACKET_NO_AX;
+ } else {
+- f->mt[0].x = SS4_STD_MF_X_V2(p, 0);
+- f->mt[1].x = SS4_STD_MF_X_V2(p, 1);
++ f->mt[2].x = SS4_STD_MF_X_V2(p, 0);
++ f->mt[3].x = SS4_STD_MF_X_V2(p, 1);
++ no_data_x = SS4_MFPACKET_NO_AX;
+ }
++ no_data_y = SS4_MFPACKET_NO_AY;
++
+ f->mt[2].y = SS4_STD_MF_Y_V2(p, 0);
+ f->mt[3].y = SS4_STD_MF_Y_V2(p, 1);
+- no_data_x = SS4_MFPACKET_NO_AX;
+- no_data_y = SS4_MFPACKET_NO_AY;
+ }
+
+ f->first_mp = 0;
+--- a/drivers/input/mouse/alps.h
++++ b/drivers/input/mouse/alps.h
+@@ -120,10 +120,12 @@ enum SS4_PACKET_ID {
+ #define SS4_IS_5F_DETECTED(_b) ((_b[2] & 0x10) == 0x10)
+
+
+-#define SS4_MFPACKET_NO_AX 8160 /* X-Coordinate value */
+-#define SS4_MFPACKET_NO_AY 4080 /* Y-Coordinate value */
+-#define SS4_MFPACKET_NO_AX_BL 8176 /* Buttonless X-Coordinate value */
+-#define SS4_MFPACKET_NO_AY_BL 4088 /* Buttonless Y-Coordinate value */
++#define SS4_MFPACKET_NO_AX 8160 /* X-Coordinate value */
++#define SS4_MFPACKET_NO_AY 4080 /* Y-Coordinate value */
++#define SS4_MFPACKET_NO_AX_BL 8176 /* Buttonless X-Coord value */
++#define SS4_MFPACKET_NO_AY_BL 4088 /* Buttonless Y-Coord value */
++#define SS4_PLUS_MFPACKET_NO_AX 4080 /* SS4 PLUS, X */
++#define SS4_PLUS_MFPACKET_NO_AX_BL 4088 /* Buttonless SS4 PLUS, X */
+
+ /*
+ * enum V7_PACKET_ID - defines the packet type for V7
--- /dev/null
+From 5b189201993ab03001a398de731045bfea90c689 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 8 Jan 2018 17:15:06 -0800
+Subject: Input: twl4030-vibra - fix sibling-node lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 5b189201993ab03001a398de731045bfea90c689 upstream.
+
+A helper purported to look up a child node based on its name was using
+the wrong of-helper and ended up prematurely freeing the parent of-node
+while searching the whole device tree depth-first starting at the parent
+node.
+
+Fixes: 64b9e4d803b1 ("input: twl4030-vibra: Support for DT booted kernel")
+Fixes: e661d0a04462 ("Input: twl4030-vibra - fix ERROR: Bad of_node_put() warning")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/misc/twl4030-vibra.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/input/misc/twl4030-vibra.c
++++ b/drivers/input/misc/twl4030-vibra.c
+@@ -178,12 +178,14 @@ static SIMPLE_DEV_PM_OPS(twl4030_vibra_p
+ twl4030_vibra_suspend, twl4030_vibra_resume);
+
+ static bool twl4030_vibra_check_coexist(struct twl4030_vibra_data *pdata,
+- struct device_node *node)
++ struct device_node *parent)
+ {
++ struct device_node *node;
++
+ if (pdata && pdata->coexist)
+ return true;
+
+- node = of_find_node_by_name(node, "codec");
++ node = of_get_child_by_name(parent, "codec");
+ if (node) {
+ of_node_put(node);
+ return true;
--- /dev/null
+From dcaf12a8b0bbdbfcfa2be8dff2c4948d9844b4ad Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 8 Jan 2018 17:17:48 -0800
+Subject: Input: twl6040-vibra - fix child-node lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+commit dcaf12a8b0bbdbfcfa2be8dff2c4948d9844b4ad upstream.
+
+Fix child-node lookup during probe, which ended up searching the whole
+device tree depth-first starting at parent rather than just matching on
+its children.
+
+Later sanity checks on node properties (which would likely be missing)
+should prevent this from causing much trouble however, especially as the
+original premature free of the parent node has already been fixed
+separately (but that "fix" was apparently never backported to stable).
+
+Fixes: e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support")
+Fixes: c52c545ead97 ("Input: twl6040-vibra - fix DT node memory management")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Tested-by: H. Nikolaus Schaller <hns@goldelico.com> (on Pyra OMAP5 hardware)
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/misc/twl6040-vibra.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/input/misc/twl6040-vibra.c
++++ b/drivers/input/misc/twl6040-vibra.c
+@@ -248,8 +248,7 @@ static int twl6040_vibra_probe(struct pl
+ int vddvibr_uV = 0;
+ int error;
+
+- of_node_get(twl6040_core_dev->of_node);
+- twl6040_core_node = of_find_node_by_name(twl6040_core_dev->of_node,
++ twl6040_core_node = of_get_child_by_name(twl6040_core_dev->of_node,
+ "vibra");
+ if (!twl6040_core_node) {
+ dev_err(&pdev->dev, "parent of node is missing?\n");
--- /dev/null
+From db5ff909798ef0099004ad50a0ff5fde92426fd1 Mon Sep 17 00:00:00 2001
+From: Xinyu Lin <xinyu0123@gmail.com>
+Date: Sun, 17 Dec 2017 20:13:39 +0800
+Subject: libata: apply MAX_SEC_1024 to all LITEON EP1 series devices
+
+From: Xinyu Lin <xinyu0123@gmail.com>
+
+commit db5ff909798ef0099004ad50a0ff5fde92426fd1 upstream.
+
+LITEON EP1 has the same timeout issues as CX1 series devices.
+
+Revert max_sectors to the value of 1024.
+
+Fixes: e0edc8c54646 ("libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices")
+Signed-off-by: Xinyu Lin <xinyu0123@gmail.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4322,6 +4322,7 @@ static const struct ata_blacklist_entry
+ * https://bugzilla.kernel.org/show_bug.cgi?id=121671
+ */
+ { "LITEON CX1-JB*-HP", NULL, ATA_HORKAGE_MAX_SEC_1024 },
++ { "LITEON EP1-*", NULL, ATA_HORKAGE_MAX_SEC_1024 },
+
+ /* Devices we expect to fail diagnostics */
+
--- /dev/null
+From b7563e2796f8b23c98afcfea7363194227fa089d Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 12 Jan 2018 11:12:05 +0100
+Subject: phy: work around 'phys' references to usb-nop-xceiv devices
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit b7563e2796f8b23c98afcfea7363194227fa089d upstream.
+
+Stefan Wahren reports a problem with a warning fix that was merged
+for v4.15: we had lots of device nodes with a 'phys' property pointing
+to a device node that is not compliant with the binding documented in
+Documentation/devicetree/bindings/phy/phy-bindings.txt
+
+This generally works because USB HCD drivers that support both the generic
+phy subsystem and the older usb-phy subsystem ignore most errors from
+phy_get() and related calls and then use the usb-phy driver instead.
+
+However, it turns out that making the usb-nop-xceiv device compatible with
+the generic-phy binding changes the phy_get() return code from -EINVAL to
+-EPROBE_DEFER, and the dwc2 usb controller driver for bcm2835 now returns
+-EPROBE_DEFER from its probe function rather than ignoring the failure,
+breaking all USB support on raspberry-pi when CONFIG_GENERIC_PHY is
+enabled. The same code is used in the dwc3 driver and the usb_add_hcd()
+function, so a reasonable assumption would be that many other platforms
+are affected as well.
+
+I have reviewed all the related patches and concluded that "usb-nop-xceiv"
+is the only USB phy that is affected by the change, and since it is by far
+the most commonly referenced phy, all the other USB phy drivers appear
+to be used in ways that are are either safe in DT (they don't use the
+'phys' property), or in the driver (they already ignore -EPROBE_DEFER
+from generic-phy when usb-phy is available).
+
+To work around the problem, this adds a special case to _of_phy_get()
+so we ignore any PHY node that is compatible with "usb-nop-xceiv",
+as we know that this can never load no matter how much we defer. In the
+future, we might implement a generic-phy driver for "usb-nop-xceiv"
+and then remove this workaround.
+
+Since we generally want older kernels to also want to work with the
+fixed devicetree files, it would be good to backport the patch into
+stable kernels as well (3.13+ are possibly affected), even though they
+don't contain any of the patches that may have caused regressions.
+
+Fixes: 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
+Fixes: c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
+Fixes: 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
+Fixes: f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
+Fixes: d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
+Fixes: 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
+Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
+Link: https://patchwork.kernel.org/patch/10158145/
+Cc: Felipe Balbi <balbi@kernel.org>
+Cc: Eric Anholt <eric@anholt.net>
+Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
+Acked-by: Rob Herring <robh@kernel.org>
+Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
+Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/phy/phy-core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/phy/phy-core.c
++++ b/drivers/phy/phy-core.c
+@@ -395,6 +395,10 @@ static struct phy *_of_phy_get(struct de
+ if (ret)
+ return ERR_PTR(-ENODEV);
+
++ /* This phy type handled by the usb-phy subsystem for now */
++ if (of_device_is_compatible(args.np, "usb-nop-xceiv"))
++ return ERR_PTR(-ENODEV);
++
+ mutex_lock(&phy_provider_mutex);
+ phy_provider = of_phy_provider_lookup(args.np);
+ if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
--- /dev/null
+From 8bb2ee192e482c5d500df9f2b1b26a560bd3026f Mon Sep 17 00:00:00 2001
+From: Alexey Dobriyan <adobriyan@gmail.com>
+Date: Thu, 18 Jan 2018 16:34:05 -0800
+Subject: proc: fix coredump vs read /proc/*/stat race
+
+From: Alexey Dobriyan <adobriyan@gmail.com>
+
+commit 8bb2ee192e482c5d500df9f2b1b26a560bd3026f upstream.
+
+do_task_stat() accesses IP and SP of a task without bumping reference
+count of a stack (which became an entity with independent lifetime at
+some point).
+
+Steps to reproduce:
+
+ #include <stdio.h>
+ #include <sys/types.h>
+ #include <sys/stat.h>
+ #include <fcntl.h>
+ #include <sys/time.h>
+ #include <sys/resource.h>
+ #include <unistd.h>
+ #include <sys/wait.h>
+
+ int main(void)
+ {
+ setrlimit(RLIMIT_CORE, &(struct rlimit){});
+
+ while (1) {
+ char buf[64];
+ char buf2[4096];
+ pid_t pid;
+ int fd;
+
+ pid = fork();
+ if (pid == 0) {
+ *(volatile int *)0 = 0;
+ }
+
+ snprintf(buf, sizeof(buf), "/proc/%u/stat", pid);
+ fd = open(buf, O_RDONLY);
+ read(fd, buf2, sizeof(buf2));
+ close(fd);
+
+ waitpid(pid, NULL, 0);
+ }
+ return 0;
+ }
+
+ BUG: unable to handle kernel paging request at 0000000000003fd8
+ IP: do_task_stat+0x8b4/0xaf0
+ PGD 800000003d73e067 P4D 800000003d73e067 PUD 3d558067 PMD 0
+ Oops: 0000 [#1] PREEMPT SMP PTI
+ CPU: 0 PID: 1417 Comm: a.out Not tainted 4.15.0-rc8-dirty #2
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc27 04/01/2014
+ RIP: 0010:do_task_stat+0x8b4/0xaf0
+ Call Trace:
+ proc_single_show+0x43/0x70
+ seq_read+0xe6/0x3b0
+ __vfs_read+0x1e/0x120
+ vfs_read+0x84/0x110
+ SyS_read+0x3d/0xa0
+ entry_SYSCALL_64_fastpath+0x13/0x6c
+ RIP: 0033:0x7f4d7928cba0
+ RSP: 002b:00007ffddb245158 EFLAGS: 00000246
+ Code: 03 b7 a0 01 00 00 4c 8b 4c 24 70 4c 8b 44 24 78 4c 89 74 24 18 e9 91 f9 ff ff f6 45 4d 02 0f 84 fd f7 ff ff 48 8b 45 40 48 89 ef <48> 8b 80 d8 3f 00 00 48 89 44 24 20 e8 9b 97 eb ff 48 89 44 24
+ RIP: do_task_stat+0x8b4/0xaf0 RSP: ffffc90000607cc8
+ CR2: 0000000000003fd8
+
+John Ogness said: for my tests I added an else case to verify that the
+race is hit and correctly mitigated.
+
+Link: http://lkml.kernel.org/r/20180116175054.GA11513@avx2
+Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
+Reported-by: "Kohli, Gaurav" <gkohli@codeaurora.org>
+Tested-by: John Ogness <john.ogness@linutronix.de>
+Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
+Cc: Ingo Molnar <mingo@elte.hu>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/proc/array.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/fs/proc/array.c
++++ b/fs/proc/array.c
+@@ -423,8 +423,11 @@ static int do_task_stat(struct seq_file
+ * safe because the task has stopped executing permanently.
+ */
+ if (permitted && (task->flags & PF_DUMPCORE)) {
+- eip = KSTK_EIP(task);
+- esp = KSTK_ESP(task);
++ if (try_get_task_stack(task)) {
++ eip = KSTK_EIP(task);
++ esp = KSTK_ESP(task);
++ put_task_stack(task);
++ }
+ }
+ }
+
--- /dev/null
+From 883d50f56d263f70fd73c0d96b09eb36c34e9305 Mon Sep 17 00:00:00 2001
+From: Xi Kangjie <imxikangjie@gmail.com>
+Date: Thu, 18 Jan 2018 16:34:00 -0800
+Subject: scripts/gdb/linux/tasks.py: fix get_thread_info
+
+From: Xi Kangjie <imxikangjie@gmail.com>
+
+commit 883d50f56d263f70fd73c0d96b09eb36c34e9305 upstream.
+
+Since kernel 4.9, the thread_info has been moved into task_struct, no
+longer locates at the bottom of kernel stack.
+
+See commits c65eacbe290b ("sched/core: Allow putting thread_info into
+task_struct") and 15f4eae70d36 ("x86: Move thread_info into
+task_struct").
+
+Before fix:
+ (gdb) set $current = $lx_current()
+ (gdb) p $lx_thread_info($current)
+ $1 = {flags = 1470918301}
+ (gdb) p $current.thread_info
+ $2 = {flags = 2147483648}
+
+After fix:
+ (gdb) p $lx_thread_info($current)
+ $1 = {flags = 2147483648}
+ (gdb) p $current.thread_info
+ $2 = {flags = 2147483648}
+
+Link: http://lkml.kernel.org/r/20180118210159.17223-1-imxikangjie@gmail.com
+Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct")
+Signed-off-by: Xi Kangjie <imxikangjie@gmail.com>
+Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
+Acked-by: Kieran Bingham <kbingham@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ scripts/gdb/linux/tasks.py | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/scripts/gdb/linux/tasks.py
++++ b/scripts/gdb/linux/tasks.py
+@@ -96,6 +96,8 @@ def get_thread_info(task):
+ thread_info_addr = task.address + ia64_task_size
+ thread_info = thread_info_addr.cast(thread_info_ptr_type)
+ else:
++ if task.type.fields()[0].type == thread_info_type.get_type():
++ return task['thread_info']
+ thread_info = task['stack'].cast(thread_info_ptr_type)
+ return thread_info.dereference()
+
pipe-avoid-round_pipe_size-nr_pages-overflow-on-32-bit.patch
x86-apic-vector-fix-off-by-one-in-error-path.patch
perf-tools-fix-build-with-arch-x86_64.patch
+input-alps-fix-multi-touch-decoding-on-ss4-plus-touchpads.patch
+input-88pm860x-ts-fix-child-node-lookup.patch
+input-twl6040-vibra-fix-child-node-lookup.patch
+input-twl4030-vibra-fix-sibling-node-lookup.patch
+tracing-fix-converting-enum-s-from-the-map-in-trace_event_eval_update.patch
+phy-work-around-phys-references-to-usb-nop-xceiv-devices.patch
+arm-sunxi_defconfig-enable-cma.patch
+arm-dts-kirkwood-fix-pin-muxing-of-mpp7-on-openblocks-a7.patch
+can-peak-fix-potential-bug-in-packet-fragmentation.patch
+scripts-gdb-linux-tasks.py-fix-get_thread_info.patch
+proc-fix-coredump-vs-read-proc-stat-race.patch
+libata-apply-max_sec_1024-to-all-liteon-ep1-series-devices.patch
+workqueue-avoid-hard-lockups-in-show_workqueue_state.patch
+dm-btree-fix-serious-bug-in-btree_split_beneath.patch
+dm-thin-metadata-thin_max_concurrent_locks-should-be-6.patch
--- /dev/null
+From 1ebe1eaf2f02784921759992ae1fde1a9bec8fd0 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Thu, 18 Jan 2018 15:53:10 -0500
+Subject: tracing: Fix converting enum's from the map in trace_event_eval_update()
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 1ebe1eaf2f02784921759992ae1fde1a9bec8fd0 upstream.
+
+Since enums do not get converted by the TRACE_EVENT macro into their values,
+the event format displaces the enum name and not the value. This breaks
+tools like perf and trace-cmd that need to interpret the raw binary data. To
+solve this, an enum map was created to convert these enums into their actual
+numbers on boot up. This is done by TRACE_EVENTS() adding a
+TRACE_DEFINE_ENUM() macro.
+
+Some enums were not being converted. This was caused by an optization that
+had a bug in it.
+
+All calls get checked against this enum map to see if it should be converted
+or not, and it compares the call's system to the system that the enum map
+was created under. If they match, then they call is processed.
+
+To cut down on the number of iterations needed to find the maps with a
+matching system, since calls and maps are grouped by system, when a match is
+made, the index into the map array is saved, so that the next call, if it
+belongs to the same system as the previous call, could start right at that
+array index and not have to scan all the previous arrays.
+
+The problem was, the saved index was used as the variable to know if this is
+a call in a new system or not. If the index was zero, it was assumed that
+the call is in a new system and would keep incrementing the saved index
+until it found a matching system. The issue arises when the first matching
+system was at index zero. The next map, if it belonged to the same system,
+would then think it was the first match and increment the index to one. If
+the next call belong to the same system, it would begin its search of the
+maps off by one, and miss the first enum that should be converted. This left
+a single enum not converted properly.
+
+Also add a comment to describe exactly what that index was for. It took me a
+bit too long to figure out what I was thinking when debugging this issue.
+
+Link: http://lkml.kernel.org/r/717BE572-2070-4C1E-9902-9F2E0FEDA4F8@oracle.com
+
+Fixes: 0c564a538aa93 ("tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values")
+Reported-by: Chuck Lever <chuck.lever@oracle.com>
+Teste-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_events.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_events.c
++++ b/kernel/trace/trace_events.c
+@@ -2200,6 +2200,7 @@ void trace_event_enum_update(struct trac
+ {
+ struct trace_event_call *call, *p;
+ const char *last_system = NULL;
++ bool first = false;
+ int last_i;
+ int i;
+
+@@ -2207,15 +2208,28 @@ void trace_event_enum_update(struct trac
+ list_for_each_entry_safe(call, p, &ftrace_events, list) {
+ /* events are usually grouped together with systems */
+ if (!last_system || call->class->system != last_system) {
++ first = true;
+ last_i = 0;
+ last_system = call->class->system;
+ }
+
++ /*
++ * Since calls are grouped by systems, the likelyhood that the
++ * next call in the iteration belongs to the same system as the
++ * previous call is high. As an optimization, we skip seaching
++ * for a map[] that matches the call's system if the last call
++ * was from the same system. That's what last_i is for. If the
++ * call has the same system as the previous call, then last_i
++ * will be the index of the first map[] that has a matching
++ * system.
++ */
+ for (i = last_i; i < len; i++) {
+ if (call->class->system == map[i]->system) {
+ /* Save the first system if need be */
+- if (!last_i)
++ if (first) {
+ last_i = i;
++ first = false;
++ }
+ update_event_printk(call, map[i]);
+ }
+ }
--- /dev/null
+From 62635ea8c18f0f62df4cc58379e4f1d33afd5801 Mon Sep 17 00:00:00 2001
+From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
+Date: Thu, 11 Jan 2018 09:53:35 +0900
+Subject: workqueue: avoid hard lockups in show_workqueue_state()
+
+From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
+
+commit 62635ea8c18f0f62df4cc58379e4f1d33afd5801 upstream.
+
+show_workqueue_state() can print out a lot of messages while being in
+atomic context, e.g. sysrq-t -> show_workqueue_state(). If the console
+device is slow it may end up triggering NMI hard lockup watchdog.
+
+Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/workqueue.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/kernel/workqueue.c
++++ b/kernel/workqueue.c
+@@ -48,6 +48,7 @@
+ #include <linux/nodemask.h>
+ #include <linux/moduleparam.h>
+ #include <linux/uaccess.h>
++#include <linux/nmi.h>
+
+ #include "workqueue_internal.h"
+
+@@ -4424,6 +4425,12 @@ void show_workqueue_state(void)
+ if (pwq->nr_active || !list_empty(&pwq->delayed_works))
+ show_pwq(pwq);
+ spin_unlock_irqrestore(&pwq->pool->lock, flags);
++ /*
++ * We could be printing a lot from atomic context, e.g.
++ * sysrq-t -> show_workqueue_state(). Avoid triggering
++ * hard lockup.
++ */
++ touch_nmi_watchdog();
+ }
+ }
+
+@@ -4451,6 +4458,12 @@ void show_workqueue_state(void)
+ pr_cont("\n");
+ next_pool:
+ spin_unlock_irqrestore(&pool->lock, flags);
++ /*
++ * We could be printing a lot from atomic context, e.g.
++ * sysrq-t -> show_workqueue_state(). Avoid triggering
++ * hard lockup.
++ */
++ touch_nmi_watchdog();
+ }
+
+ rcu_read_unlock_sched();
projects / thirdparty / kernel / stable-queue.git / commitdiff
