--- /dev/null
+From 0a29c57b76624723b6b00c027e0e992d130ace49 Mon Sep 17 00:00:00 2001
+From: Kailang Yang <kailang@realtek.com>
+Date: Wed, 24 Apr 2019 16:34:25 +0800
+Subject: ALSA: hda/realtek - Add new Dell platform for headset mode
+
+From: Kailang Yang <kailang@realtek.com>
+
+commit 0a29c57b76624723b6b00c027e0e992d130ace49 upstream.
+
+Add two Dell platform for headset mode.
+
+[ Note: this is a further correction / addition of the previous
+ pin-based quirks for Dell machines; another entry for ALC236 with
+ the d-mic pin 0x12 and an entry for ALC295 -- tiwai ]
+
+Fixes: b26e36b7ef36 ("ALSA: hda/realtek - add two more pin configuration sets to quirk table")
+Signed-off-by: Kailang Yang <kailang@realtek.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -7172,6 +7172,10 @@ static const struct snd_hda_pin_quirk al
+ {0x21, 0x02211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
+ {0x21, 0x02211020}),
++ SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
++ {0x12, 0x40000000},
++ {0x14, 0x90170110},
++ {0x21, 0x02211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL2_MIC_NO_PRESENCE,
+ {0x14, 0x90170110},
+ {0x21, 0x02211020}),
+@@ -7446,6 +7450,9 @@ static const struct snd_hda_pin_quirk al
+ {0x17, 0x90170110},
+ {0x21, 0x04211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
++ {0x14, 0x90170110},
++ {0x21, 0x04211020}),
++ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
+ ALC295_STANDARD_PINS,
+ {0x17, 0x21014020},
+ {0x18, 0x21a19030}),
--- /dev/null
+From 3887c26c0e24d50a4d0ce20cf4726737cee1a2fd Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 30 Apr 2019 15:10:01 +0200
+Subject: ALSA: hda/realtek - Apply the fixup for ASUS Q325UAR
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 3887c26c0e24d50a4d0ce20cf4726737cee1a2fd upstream.
+
+Some ASUS models like Q325UAR with ALC295 codec requires the same
+fixup that has been applied to ALC294 codec. Just copy the entry with
+the pin matching to cover ALC295 too.
+
+BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784485
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -7451,6 +7451,10 @@ static const struct snd_hda_pin_quirk al
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x04211020}),
++ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1043, "ASUS", ALC294_FIXUP_ASUS_SPK,
++ {0x12, 0x90a60130},
++ {0x17, 0x90170110},
++ {0x21, 0x03211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
+ {0x14, 0x90170110},
+ {0x21, 0x04211020}),
--- /dev/null
+From 0700d3d117a7f110ddddbd83873e13652f69c54b Mon Sep 17 00:00:00 2001
+From: Kailang Yang <kailang@realtek.com>
+Date: Fri, 26 Apr 2019 16:13:54 +0800
+Subject: ALSA: hda/realtek - Fixed Dell AIO speaker noise
+
+From: Kailang Yang <kailang@realtek.com>
+
+commit 0700d3d117a7f110ddddbd83873e13652f69c54b upstream.
+
+Fixed Dell AIO speaker noise.
+spec->gen.auto_mute_via_amp = 1, this option was solved speaker white
+noise at boot.
+codec->power_save_node = 0, this option was solved speaker noise at
+resume back.
+
+Fixes: 9226665159f0 ("ALSA: hda/realtek - Fix Dell AIO LineOut issue")
+Signed-off-by: Kailang Yang <kailang@realtek.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -5448,6 +5448,8 @@ static void alc274_fixup_bind_dacs(struc
+ return;
+
+ spec->gen.preferred_dacs = preferred_pairs;
++ spec->gen.auto_mute_via_amp = 1;
++ codec->power_save_node = 0;
+ }
+
+ /* The DAC of NID 0x3 will introduce click/pop noise on headphones, so invalidate it */
--- /dev/null
+From 93b6604c5a669d84e45fe5129294875bf82eb1ff Mon Sep 17 00:00:00 2001
+From: Jim Broadus <jbroadus@gmail.com>
+Date: Tue, 19 Feb 2019 11:30:27 -0800
+Subject: i2c: Allow recovery of the initial IRQ by an I2C client device.
+
+From: Jim Broadus <jbroadus@gmail.com>
+
+commit 93b6604c5a669d84e45fe5129294875bf82eb1ff upstream.
+
+A previous change allowed I2C client devices to discover new IRQs upon
+reprobe by clearing the IRQ in i2c_device_remove. However, if an IRQ was
+assigned in i2c_new_device, that information is lost.
+
+For example, the touchscreen and trackpad devices on a Dell Inspiron laptop
+are I2C devices whose IRQs are defined by ACPI extended IRQ types. The
+client device structures are initialized during an ACPI walk. After
+removing the i2c_hid device, modprobe fails.
+
+This change caches the initial IRQ value in i2c_new_device and then resets
+the client device IRQ to the initial value in i2c_device_remove.
+
+Fixes: 6f108dd70d30 ("i2c: Clear client->irq in i2c_device_remove")
+Signed-off-by: Jim Broadus <jbroadus@gmail.com>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
+[wsa: this is an easy to backport fix for the regression. We will
+refactor the code to handle irq assignments better in general.]
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/i2c-core-base.c | 9 +++++----
+ include/linux/i2c.h | 1 +
+ 2 files changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/i2c/i2c-core-base.c
++++ b/drivers/i2c/i2c-core-base.c
+@@ -430,7 +430,7 @@ static int i2c_device_remove(struct devi
+ dev_pm_clear_wake_irq(&client->dev);
+ device_init_wakeup(&client->dev, false);
+
+- client->irq = 0;
++ client->irq = client->init_irq;
+
+ return status;
+ }
+@@ -741,10 +741,11 @@ i2c_new_device(struct i2c_adapter *adap,
+ client->flags = info->flags;
+ client->addr = info->addr;
+
+- client->irq = info->irq;
+- if (!client->irq)
+- client->irq = i2c_dev_irq_from_resources(info->resources,
++ client->init_irq = info->irq;
++ if (!client->init_irq)
++ client->init_irq = i2c_dev_irq_from_resources(info->resources,
+ info->num_resources);
++ client->irq = client->init_irq;
+
+ strlcpy(client->name, info->type, sizeof(client->name));
+
+--- a/include/linux/i2c.h
++++ b/include/linux/i2c.h
+@@ -333,6 +333,7 @@ struct i2c_client {
+ char name[I2C_NAME_SIZE];
+ struct i2c_adapter *adapter; /* the adapter we sit on */
+ struct device dev; /* the device structure */
++ int init_irq; /* irq set at initialization */
+ int irq; /* irq issued by device */
+ struct list_head detected;
+ #if IS_ENABLED(CONFIG_I2C_SLAVE)
--- /dev/null
+From 6f108dd70d3010c391c1e9f56f3f20d1f9e75450 Mon Sep 17 00:00:00 2001
+From: Charles Keepax <ckeepax@opensource.cirrus.com>
+Date: Fri, 19 Oct 2018 09:59:58 +0100
+Subject: i2c: Clear client->irq in i2c_device_remove
+
+From: Charles Keepax <ckeepax@opensource.cirrus.com>
+
+commit 6f108dd70d3010c391c1e9f56f3f20d1f9e75450 upstream.
+
+The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
+i2c_device_remove does not clear this. When rebinding an I2C device,
+whos IRQ provider has also been rebound this means that an IRQ mapping
+will never be created, causing the I2C device to fail to acquire its
+IRQ. Fix this issue by clearing client->irq in i2c_device_remove,
+forcing i2c_device_probe to lookup the mapping again.
+
+Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/i2c-core-base.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/i2c/i2c-core-base.c
++++ b/drivers/i2c/i2c-core-base.c
+@@ -430,6 +430,8 @@ static int i2c_device_remove(struct devi
+ dev_pm_clear_wake_irq(&client->dev);
+ device_init_wakeup(&client->dev, false);
+
++ client->irq = 0;
++
+ return status;
+ }
+
--- /dev/null
+From d386bb9042f4629bf62cdc5952ea8aab225f24a7 Mon Sep 17 00:00:00 2001
+From: Anson Huang <anson.huang@nxp.com>
+Date: Wed, 17 Apr 2019 01:59:34 +0000
+Subject: i2c: imx: correct the method of getting private data in notifier_call
+
+From: Anson Huang <anson.huang@nxp.com>
+
+commit d386bb9042f4629bf62cdc5952ea8aab225f24a7 upstream.
+
+The way of getting private imx_i2c_struct in i2c_imx_clk_notifier_call()
+is incorrect, should use clk_change_nb element to get correct address
+and avoid below kernel dump during POST_RATE_CHANGE notify by clk
+framework:
+
+Unable to handle kernel paging request at virtual address 03ef1488
+pgd = (ptrval)
+[03ef1488] *pgd=00000000
+Internal error: Oops: 5 [#1] PREEMPT SMP ARM
+Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
+Workqueue: events reduce_bus_freq_handler
+PC is at i2c_imx_set_clk+0x10/0xb8
+LR is at i2c_imx_clk_notifier_call+0x20/0x28
+pc : [<806a893c>] lr : [<806a8a04>] psr: a0080013
+sp : bf399dd8 ip : bf3432ac fp : bf7c1dc0
+r10: 00000002 r9 : 00000000 r8 : 00000000
+r7 : 03ef1480 r6 : bf399e50 r5 : ffffffff r4 : 00000000
+r3 : bf025300 r2 : bf399e50 r1 : 00b71b00 r0 : bf399be8
+Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
+Control: 10c5387d Table: 4e03004a DAC: 00000051
+Process kworker/2:1 (pid: 38, stack limit = 0x(ptrval))
+Stack: (0xbf399dd8 to 0xbf39a000)
+9dc0: 806a89e4 00000000
+9de0: ffffffff bf399e50 00000002 806a8a04 806a89e4 80142900 ffffffff 00000000
+9e00: bf34ef18 bf34ef04 00000000 ffffffff bf399e50 80142d84 00000000 bf399e6c
+9e20: bf34ef00 80f214c4 bf025300 00000002 80f08d08 bf017480 00000000 80142df0
+9e40: 00000000 80166ed8 80c27638 8045de58 bf352340 03ef1480 00b71b00 0f82e242
+9e60: bf025300 00000002 03ef1480 80f60e5c 00000001 8045edf0 00000002 8045eb08
+9e80: bf025300 00000002 03ef1480 8045ee10 03ef1480 8045eb08 bf01be40 00000002
+9ea0: 03ef1480 8045ee10 07de2900 8045eb08 bf01b780 00000002 07de2900 8045ee10
+9ec0: 80c27898 bf399ee4 bf020a80 00000002 1f78a400 8045ee10 80f60e5c 80460514
+9ee0: 80f60e5c bf01b600 bf01b480 80460460 0f82e242 bf383a80 bf383a00 80f60e5c
+9f00: 00000000 bf7c1dc0 80f60e70 80460564 80f60df0 80f60d24 80f60df0 8011e72c
+9f20: 00000000 80f60df0 80f60e6c bf7c4f00 00000000 8011e7ac bf274000 8013bd84
+9f40: bf7c1dd8 80f03d00 bf274000 bf7c1dc0 bf274014 bf7c1dd8 80f03d00 bf398000
+9f60: 00000008 8013bfb4 00000000 bf25d100 bf25d0c0 00000000 bf274000 8013bf88
+9f80: bf25d11c bf0cfebc 00000000 8014140c bf25d0c0 801412ec 00000000 00000000
+9fa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000
+9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
+9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
+[<806a893c>] (i2c_imx_set_clk) from [<806a8a04>] (i2c_imx_clk_notifier_call+0x20/0x28)
+[<806a8a04>] (i2c_imx_clk_notifier_call) from [<80142900>] (notifier_call_chain+0x44/0x84)
+[<80142900>] (notifier_call_chain) from [<80142d84>] (__srcu_notifier_call_chain+0x44/0x98)
+[<80142d84>] (__srcu_notifier_call_chain) from [<80142df0>] (srcu_notifier_call_chain+0x18/0x20)
+[<80142df0>] (srcu_notifier_call_chain) from [<8045de58>] (__clk_notify+0x78/0xa4)
+[<8045de58>] (__clk_notify) from [<8045edf0>] (__clk_recalc_rates+0x60/0xb4)
+[<8045edf0>] (__clk_recalc_rates) from [<8045ee10>] (__clk_recalc_rates+0x80/0xb4)
+Code: e92d40f8 e5903298 e59072a0 e1530001 (e5975008)
+---[ end trace fc7f5514b97b6cbb ]---
+
+Fixes: 90ad2cbe88c2 ("i2c: imx: use clk notifier for rate changes")
+Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
+Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-imx.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-imx.c
++++ b/drivers/i2c/busses/i2c-imx.c
+@@ -510,9 +510,9 @@ static int i2c_imx_clk_notifier_call(str
+ unsigned long action, void *data)
+ {
+ struct clk_notifier_data *ndata = data;
+- struct imx_i2c_struct *i2c_imx = container_of(&ndata->clk,
++ struct imx_i2c_struct *i2c_imx = container_of(nb,
+ struct imx_i2c_struct,
+- clk);
++ clk_change_nb);
+
+ if (action & POST_RATE_CHANGE)
+ i2c_imx_set_clk(i2c_imx, ndata->new_rate);
--- /dev/null
+From 72bfcee11cf89509795c56b0e40a3785ab00bbdd Mon Sep 17 00:00:00 2001
+From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
+Date: Tue, 30 Apr 2019 17:23:22 +0300
+Subject: i2c: Prevent runtime suspend of adapter when Host Notify is required
+
+From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
+
+commit 72bfcee11cf89509795c56b0e40a3785ab00bbdd upstream.
+
+Multiple users have reported their Synaptics touchpad has stopped
+working between v4.20.1 and v4.20.2 when using SMBus interface.
+
+The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow
+runtime PM without callback functions") that fixed the runtime PM for
+i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801
+for SMBus communication and testing showed they are able to get back
+working by preventing the runtime suspend of adapter.
+
+Normally when i2c-i801 SMBus adapter transmits with the client it resumes
+before operation and autosuspends after.
+
+However, if client requires SMBus Host Notify protocol, what those
+Synaptics touchpads do, then the host adapter must not go to runtime
+suspend since then it cannot process incoming SMBus Host Notify commands
+the client may send.
+
+Fix this by keeping I2C/SMBus adapter active in case client requires
+Host Notify.
+
+Reported-by: Keijo Vaara <ferdasyn@rocketmail.com>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297
+Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
+Cc: stable@vger.kernel.org # v4.20+
+Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
+Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Tested-by: Keijo Vaara <ferdasyn@rocketmail.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/i2c-core-base.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/i2c/i2c-core-base.c
++++ b/drivers/i2c/i2c-core-base.c
+@@ -327,6 +327,8 @@ static int i2c_device_probe(struct devic
+
+ if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
+ dev_dbg(dev, "Using Host Notify IRQ\n");
++ /* Keep adapter active when Host Notify is required */
++ pm_runtime_get_sync(&client->adapter->dev);
+ irq = i2c_smbus_host_notify_to_irq(client);
+ } else if (dev->of_node) {
+ irq = of_irq_get_byname(dev->of_node, "irq");
+@@ -431,6 +433,8 @@ static int i2c_device_remove(struct devi
+ device_init_wakeup(&client->dev, false);
+
+ client->irq = client->init_irq;
++ if (client->flags & I2C_CLIENT_HOST_NOTIFY)
++ pm_runtime_put(&client->adapter->dev);
+
+ return status;
+ }
--- /dev/null
+From b9bb3fdf4e870fb655064f5c3c81c1fee7fd89ce Mon Sep 17 00:00:00 2001
+From: Charles Keepax <ckeepax@opensource.cirrus.com>
+Date: Fri, 19 Oct 2018 09:59:57 +0100
+Subject: i2c: Remove unnecessary call to irq_find_mapping
+
+From: Charles Keepax <ckeepax@opensource.cirrus.com>
+
+commit b9bb3fdf4e870fb655064f5c3c81c1fee7fd89ce upstream.
+
+irq_create_mapping calls irq_find_mapping internally and will use the
+found mapping if one exists, so there is no need to manually call this
+from i2c_smbus_host_notify_to_irq.
+
+Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/i2c-core-base.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/drivers/i2c/i2c-core-base.c
++++ b/drivers/i2c/i2c-core-base.c
+@@ -306,10 +306,7 @@ static int i2c_smbus_host_notify_to_irq(
+ if (client->flags & I2C_CLIENT_TEN)
+ return -EINVAL;
+
+- irq = irq_find_mapping(adap->host_notify_domain, client->addr);
+- if (!irq)
+- irq = irq_create_mapping(adap->host_notify_domain,
+- client->addr);
++ irq = irq_create_mapping(adap->host_notify_domain, client->addr);
+
+ return irq > 0 ? irq : -ENXIO;
+ }
--- /dev/null
+From 95e0cf3caeb11e1b0398c747b5cfa12828263824 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Date: Tue, 30 Apr 2019 11:47:34 +0200
+Subject: i2c: synquacer: fix enumeration of slave devices
+
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+
+commit 95e0cf3caeb11e1b0398c747b5cfa12828263824 upstream.
+
+The I2C host driver for SynQuacer fails to populate the of_node and
+ACPI companion fields of the struct i2c_adapter it instantiates,
+resulting in enumeration of the subordinate I2C bus to fail.
+
+Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller")
+Cc: <stable@vger.kernel.org> # v4.19+
+Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-synquacer.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/i2c/busses/i2c-synquacer.c
++++ b/drivers/i2c/busses/i2c-synquacer.c
+@@ -602,6 +602,8 @@ static int synquacer_i2c_probe(struct pl
+ i2c->adapter = synquacer_i2c_ops;
+ i2c_set_adapdata(&i2c->adapter, i2c);
+ i2c->adapter.dev.parent = &pdev->dev;
++ i2c->adapter.dev.of_node = pdev->dev.of_node;
++ ACPI_COMPANION_SET(&i2c->adapter.dev, ACPI_COMPANION(&pdev->dev));
+ i2c->adapter.nr = pdev->id;
+ init_completion(&i2c->completion);
+
--- /dev/null
+From 5c9adef9789148d382d7d1307c3d6bfaf51d143d Mon Sep 17 00:00:00 2001
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Sun, 21 Apr 2019 17:58:11 +0300
+Subject: iwlwifi: fix driver operation for 5350
+
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+
+commit 5c9adef9789148d382d7d1307c3d6bfaf51d143d upstream.
+
+We introduced a bug that prevented this old device from
+working. The driver would simply not be able to complete
+the INIT flow while spewing this warning:
+
+ CSR addresses aren't configured
+ WARNING: CPU: 0 PID: 819 at drivers/net/wireless/intel/iwlwifi/pcie/drv.c:917
+ iwl_pci_probe+0x160/0x1e0 [iwlwifi]
+
+Cc: stable@vger.kernel.org # v4.18+
+Fixes: a8cbb46f831d ("iwlwifi: allow different csr flags for different device families")
+Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Fixes: c8f1b51e506d ("iwlwifi: allow different csr flags for different device families")
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/intel/iwlwifi/cfg/5000.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/cfg/5000.c
++++ b/drivers/net/wireless/intel/iwlwifi/cfg/5000.c
+@@ -1,7 +1,7 @@
+ /******************************************************************************
+ *
+ * Copyright(c) 2007 - 2014 Intel Corporation. All rights reserved.
+- * Copyright(c) 2018 Intel Corporation
++ * Copyright(c) 2018 - 2019 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License as
+@@ -140,6 +140,7 @@ const struct iwl_cfg iwl5350_agn_cfg = {
+ .ht_params = &iwl5000_ht_params,
+ .led_mode = IWL_LED_BLINK,
+ .internal_wimax_coex = true,
++ .csr = &iwl_csr_v1,
+ };
+
+ #define IWL_DEVICE_5150 \
--- /dev/null
+From 517879147493a5e1df6b89a50f708f1133fcaddb Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Mon, 15 Apr 2019 11:39:33 +0200
+Subject: mac80211: don't attempt to rename ERR_PTR() debugfs dirs
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 517879147493a5e1df6b89a50f708f1133fcaddb upstream.
+
+We need to dereference the directory to get its parent to
+be able to rename it, so it's clearly not safe to try to
+do this with ERR_PTR() pointers. Skip in this case.
+
+It seems that this is most likely what was causing the
+report by syzbot, but I'm not entirely sure as it didn't
+come with a reproducer this time.
+
+Cc: stable@vger.kernel.org
+Reported-by: syzbot+4ece1a28b8f4730547c9@syzkaller.appspotmail.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/debugfs_netdev.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/mac80211/debugfs_netdev.c
++++ b/net/mac80211/debugfs_netdev.c
+@@ -838,7 +838,7 @@ void ieee80211_debugfs_rename_netdev(str
+
+ dir = sdata->vif.debugfs_dir;
+
+- if (!dir)
++ if (IS_ERR_OR_NULL(dir))
+ return;
+
+ sprintf(buf, "netdev:%s", sdata->name);
--- /dev/null
+From b82d6c1f8f8288f744a9dcc16cd3085d535decca Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Wed, 3 Apr 2019 21:01:06 -0700
+Subject: mwifiex: Make resume actually do something useful again on SDIO cards
+
+From: Douglas Anderson <dianders@chromium.org>
+
+commit b82d6c1f8f8288f744a9dcc16cd3085d535decca upstream.
+
+The commit fc3a2fcaa1ba ("mwifiex: use atomic bitops to represent
+adapter status variables") had a fairly straightforward bug in it. It
+contained this bit of diff:
+
+ - if (!adapter->is_suspended) {
+ + if (test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) {
+
+As you can see the patch missed the "!" when converting to the atomic
+bitops. This meant that the resume hasn't done anything at all since
+that commit landed and suspend/resume for mwifiex SDIO cards has been
+totally broken.
+
+After fixing this mwifiex suspend/resume appears to work again, at
+least with the simple testing I've done.
+
+Fixes: fc3a2fcaa1ba ("mwifiex: use atomic bitops to represent adapter status variables")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Brian Norris <briannorris@chromium.org>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/marvell/mwifiex/sdio.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
++++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
+@@ -181,7 +181,7 @@ static int mwifiex_sdio_resume(struct de
+
+ adapter = card->adapter;
+
+- if (test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) {
++ if (!test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) {
+ mwifiex_dbg(adapter, WARN,
+ "device already resumed\n");
+ return 0;
+iwlwifi-fix-driver-operation-for-5350.patch
+mwifiex-make-resume-actually-do-something-useful-again-on-sdio-cards.patch
+mac80211-don-t-attempt-to-rename-err_ptr-debugfs-dirs.patch
+i2c-synquacer-fix-enumeration-of-slave-devices.patch
+i2c-imx-correct-the-method-of-getting-private-data-in-notifier_call.patch
+i2c-remove-unnecessary-call-to-irq_find_mapping.patch
+i2c-clear-client-irq-in-i2c_device_remove.patch
+i2c-allow-recovery-of-the-initial-irq-by-an-i2c-client-device.patch
+i2c-prevent-runtime-suspend-of-adapter-when-host-notify-is-required.patch
+alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch
+alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch
+alsa-hda-realtek-apply-the-fixup-for-asus-q325uar.patch
+usb-yurex-fix-protection-fault-after-device-removal.patch
+usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch
+usb-dummy-hcd-fix-failure-to-give-back-unlinked-urbs.patch
+usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch
+usb-core-fix-unterminated-string-returned-by-usb_string.patch
+usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch
--- /dev/null
+From c2b71462d294cf517a0bc6e4fd6424d7cee5596f Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 19 Apr 2019 13:52:38 -0400
+Subject: USB: core: Fix bug caused by duplicate interface PM usage counter
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit c2b71462d294cf517a0bc6e4fd6424d7cee5596f upstream.
+
+The syzkaller fuzzer reported a bug in the USB hub driver which turned
+out to be caused by a negative runtime-PM usage counter. This allowed
+a hub to be runtime suspended at a time when the driver did not expect
+it. The symptom is a WARNING issued because the hub's status URB is
+submitted while it is already active:
+
+ URB 0000000031fb463e submitted while active
+ WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363
+
+The negative runtime-PM usage count was caused by an unfortunate
+design decision made when runtime PM was first implemented for USB.
+At that time, USB class drivers were allowed to unbind from their
+interfaces without balancing the usage counter (i.e., leaving it with
+a positive count). The core code would take care of setting the
+counter back to 0 before allowing another driver to bind to the
+interface.
+
+Later on when runtime PM was implemented for the entire kernel, the
+opposite decision was made: Drivers were required to balance their
+runtime-PM get and put calls. In order to maintain backward
+compatibility, however, the USB subsystem adapted to the new
+implementation by keeping an independent usage counter for each
+interface and using it to automatically adjust the normal usage
+counter back to 0 whenever a driver was unbound.
+
+This approach involves duplicating information, but what is worse, it
+doesn't work properly in cases where a USB class driver delays
+decrementing the usage counter until after the driver's disconnect()
+routine has returned and the counter has been adjusted back to 0.
+Doing so would cause the usage counter to become negative. There's
+even a warning about this in the USB power management documentation!
+
+As it happens, this is exactly what the hub driver does. The
+kick_hub_wq() routine increments the runtime-PM usage counter, and the
+corresponding decrement is carried out by hub_event() in the context
+of the hub_wq work-queue thread. This work routine may sometimes run
+after the driver has been unbound from its interface, and when it does
+it causes the usage counter to go negative.
+
+It is not possible for hub_disconnect() to wait for a pending
+hub_event() call to finish, because hub_disconnect() is called with
+the device lock held and hub_event() acquires that lock. The only
+feasible fix is to reverse the original design decision: remove the
+duplicate interface-specific usage counter and require USB drivers to
+balance their runtime PM gets and puts. As far as I know, all
+existing drivers currently do this.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/driver-api/usb/power-management.rst | 14 +++++++++-----
+ drivers/usb/core/driver.c | 13 -------------
+ drivers/usb/storage/realtek_cr.c | 13 +++++--------
+ include/linux/usb.h | 2 --
+ 4 files changed, 14 insertions(+), 28 deletions(-)
+
+--- a/Documentation/driver-api/usb/power-management.rst
++++ b/Documentation/driver-api/usb/power-management.rst
+@@ -370,11 +370,15 @@ autosuspend the interface's device. Whe
+ then the interface is considered to be idle, and the kernel may
+ autosuspend the device.
+
+-Drivers need not be concerned about balancing changes to the usage
+-counter; the USB core will undo any remaining "get"s when a driver
+-is unbound from its interface. As a corollary, drivers must not call
+-any of the ``usb_autopm_*`` functions after their ``disconnect``
+-routine has returned.
++Drivers must be careful to balance their overall changes to the usage
++counter. Unbalanced "get"s will remain in effect when a driver is
++unbound from its interface, preventing the device from going into
++runtime suspend should the interface be bound to a driver again. On
++the other hand, drivers are allowed to achieve this balance by calling
++the ``usb_autopm_*`` functions even after their ``disconnect`` routine
++has returned -- say from within a work-queue routine -- provided they
++retain an active reference to the interface (via ``usb_get_intf`` and
++``usb_put_intf``).
+
+ Drivers using the async routines are responsible for their own
+ synchronization and mutual exclusion.
+--- a/drivers/usb/core/driver.c
++++ b/drivers/usb/core/driver.c
+@@ -473,11 +473,6 @@ static int usb_unbind_interface(struct d
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+
+- /* Undo any residual pm_autopm_get_interface_* calls */
+- for (r = atomic_read(&intf->pm_usage_cnt); r > 0; --r)
+- usb_autopm_put_interface_no_suspend(intf);
+- atomic_set(&intf->pm_usage_cnt, 0);
+-
+ if (!error)
+ usb_autosuspend_device(udev);
+
+@@ -1636,7 +1631,6 @@ void usb_autopm_put_interface(struct usb
+ int status;
+
+ usb_mark_last_busy(udev);
+- atomic_dec(&intf->pm_usage_cnt);
+ status = pm_runtime_put_sync(&intf->dev);
+ dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
+ __func__, atomic_read(&intf->dev.power.usage_count),
+@@ -1665,7 +1659,6 @@ void usb_autopm_put_interface_async(stru
+ int status;
+
+ usb_mark_last_busy(udev);
+- atomic_dec(&intf->pm_usage_cnt);
+ status = pm_runtime_put(&intf->dev);
+ dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
+ __func__, atomic_read(&intf->dev.power.usage_count),
+@@ -1687,7 +1680,6 @@ void usb_autopm_put_interface_no_suspend
+ struct usb_device *udev = interface_to_usbdev(intf);
+
+ usb_mark_last_busy(udev);
+- atomic_dec(&intf->pm_usage_cnt);
+ pm_runtime_put_noidle(&intf->dev);
+ }
+ EXPORT_SYMBOL_GPL(usb_autopm_put_interface_no_suspend);
+@@ -1718,8 +1710,6 @@ int usb_autopm_get_interface(struct usb_
+ status = pm_runtime_get_sync(&intf->dev);
+ if (status < 0)
+ pm_runtime_put_sync(&intf->dev);
+- else
+- atomic_inc(&intf->pm_usage_cnt);
+ dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
+ __func__, atomic_read(&intf->dev.power.usage_count),
+ status);
+@@ -1753,8 +1743,6 @@ int usb_autopm_get_interface_async(struc
+ status = pm_runtime_get(&intf->dev);
+ if (status < 0 && status != -EINPROGRESS)
+ pm_runtime_put_noidle(&intf->dev);
+- else
+- atomic_inc(&intf->pm_usage_cnt);
+ dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
+ __func__, atomic_read(&intf->dev.power.usage_count),
+ status);
+@@ -1778,7 +1766,6 @@ void usb_autopm_get_interface_no_resume(
+ struct usb_device *udev = interface_to_usbdev(intf);
+
+ usb_mark_last_busy(udev);
+- atomic_inc(&intf->pm_usage_cnt);
+ pm_runtime_get_noresume(&intf->dev);
+ }
+ EXPORT_SYMBOL_GPL(usb_autopm_get_interface_no_resume);
+--- a/drivers/usb/storage/realtek_cr.c
++++ b/drivers/usb/storage/realtek_cr.c
+@@ -763,18 +763,16 @@ static void rts51x_suspend_timer_fn(stru
+ break;
+ case RTS51X_STAT_IDLE:
+ case RTS51X_STAT_SS:
+- usb_stor_dbg(us, "RTS51X_STAT_SS, intf->pm_usage_cnt:%d, power.usage:%d\n",
+- atomic_read(&us->pusb_intf->pm_usage_cnt),
++ usb_stor_dbg(us, "RTS51X_STAT_SS, power.usage:%d\n",
+ atomic_read(&us->pusb_intf->dev.power.usage_count));
+
+- if (atomic_read(&us->pusb_intf->pm_usage_cnt) > 0) {
++ if (atomic_read(&us->pusb_intf->dev.power.usage_count) > 0) {
+ usb_stor_dbg(us, "Ready to enter SS state\n");
+ rts51x_set_stat(chip, RTS51X_STAT_SS);
+ /* ignore mass storage interface's children */
+ pm_suspend_ignore_children(&us->pusb_intf->dev, true);
+ usb_autopm_put_interface_async(us->pusb_intf);
+- usb_stor_dbg(us, "RTS51X_STAT_SS 01, intf->pm_usage_cnt:%d, power.usage:%d\n",
+- atomic_read(&us->pusb_intf->pm_usage_cnt),
++ usb_stor_dbg(us, "RTS51X_STAT_SS 01, power.usage:%d\n",
+ atomic_read(&us->pusb_intf->dev.power.usage_count));
+ }
+ break;
+@@ -807,11 +805,10 @@ static void rts51x_invoke_transport(stru
+ int ret;
+
+ if (working_scsi(srb)) {
+- usb_stor_dbg(us, "working scsi, intf->pm_usage_cnt:%d, power.usage:%d\n",
+- atomic_read(&us->pusb_intf->pm_usage_cnt),
++ usb_stor_dbg(us, "working scsi, power.usage:%d\n",
+ atomic_read(&us->pusb_intf->dev.power.usage_count));
+
+- if (atomic_read(&us->pusb_intf->pm_usage_cnt) <= 0) {
++ if (atomic_read(&us->pusb_intf->dev.power.usage_count) <= 0) {
+ ret = usb_autopm_get_interface(us->pusb_intf);
+ usb_stor_dbg(us, "working scsi, ret=%d\n", ret);
+ }
+--- a/include/linux/usb.h
++++ b/include/linux/usb.h
+@@ -200,7 +200,6 @@ usb_find_last_int_out_endpoint(struct us
+ * @dev: driver model's view of this device
+ * @usb_dev: if an interface is bound to the USB major, this will point
+ * to the sysfs representation for that device.
+- * @pm_usage_cnt: PM usage counter for this interface
+ * @reset_ws: Used for scheduling resets from atomic context.
+ * @resetting_device: USB core reset the device, so use alt setting 0 as
+ * current; needs bandwidth alloc after reset.
+@@ -257,7 +256,6 @@ struct usb_interface {
+
+ struct device dev; /* interface specific device info */
+ struct device *usb_dev;
+- atomic_t pm_usage_cnt; /* usage counter for autosuspend */
+ struct work_struct reset_ws; /* for resets in atomic context */
+ };
+ #define to_usb_interface(d) container_of(d, struct usb_interface, dev)
--- /dev/null
+From c01c348ecdc66085e44912c97368809612231520 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon, 15 Apr 2019 11:51:38 -0400
+Subject: USB: core: Fix unterminated string returned by usb_string()
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit c01c348ecdc66085e44912c97368809612231520 upstream.
+
+Some drivers (such as the vub300 MMC driver) expect usb_string() to
+return a properly NUL-terminated string, even when an error occurs.
+(In fact, vub300's probe routine doesn't bother to check the return
+code from usb_string().) When the driver goes on to use an
+unterminated string, it leads to kernel errors such as
+stack-out-of-bounds, as found by the syzkaller USB fuzzer.
+
+An out-of-range string index argument is not at all unlikely, given
+that some devices don't provide string descriptors and therefore list
+0 as the value for their string indexes. This patch makes
+usb_string() return a properly terminated empty string along with the
+-EINVAL error code when an out-of-range index is encountered.
+
+And since a USB string index is a single-byte value, indexes >= 256
+are just as invalid as values of 0 or below.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-by: syzbot+b75b85111c10b8d680f1@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/message.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/core/message.c
++++ b/drivers/usb/core/message.c
+@@ -820,9 +820,11 @@ int usb_string(struct usb_device *dev, i
+
+ if (dev->state == USB_STATE_SUSPENDED)
+ return -EHOSTUNREACH;
+- if (size <= 0 || !buf || !index)
++ if (size <= 0 || !buf)
+ return -EINVAL;
+ buf[0] = 0;
++ if (index <= 0 || index >= 256)
++ return -EINVAL;
+ tbuf = kmalloc(256, GFP_NOIO);
+ if (!tbuf)
+ return -ENOMEM;
--- /dev/null
+From fc834e607ae3d18e1a20bca3f9a2d7f52ea7a2be Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 18 Apr 2019 13:12:07 -0400
+Subject: USB: dummy-hcd: Fix failure to give back unlinked URBs
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit fc834e607ae3d18e1a20bca3f9a2d7f52ea7a2be upstream.
+
+The syzkaller USB fuzzer identified a failure mode in which dummy-hcd
+would never give back an unlinked URB. This causes usb_kill_urb() to
+hang, leading to WARNINGs and unkillable threads.
+
+In dummy-hcd, all URBs are given back by the dummy_timer() routine as
+it scans through the list of pending URBS. Failure to give back URBs
+can be caused by failure to start or early exit from the scanning
+loop. The code currently has two such pathways: One is triggered when
+an unsupported bus transfer speed is encountered, and the other by
+exhausting the simulated bandwidth for USB transfers during a frame.
+
+This patch removes those two paths, thereby allowing all unlinked URBs
+to be given back in a timely manner. It adds a check for the bus
+speed when the gadget first starts running, so that dummy_timer() will
+never thereafter encounter an unsupported speed. And it prevents the
+loop from exiting as soon as the total bandwidth has been used up (the
+scanning loop continues, giving back unlinked URBs as they are found,
+but not transferring any more data).
+
+Thanks to Andrey Konovalov for manually running the syzkaller fuzzer
+to help track down the source of the bug.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+d919b0f29d7b5a4994b9@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/udc/dummy_hcd.c | 19 +++++++++++++++----
+ 1 file changed, 15 insertions(+), 4 deletions(-)
+
+--- a/drivers/usb/gadget/udc/dummy_hcd.c
++++ b/drivers/usb/gadget/udc/dummy_hcd.c
+@@ -979,8 +979,18 @@ static int dummy_udc_start(struct usb_ga
+ struct dummy_hcd *dum_hcd = gadget_to_dummy_hcd(g);
+ struct dummy *dum = dum_hcd->dum;
+
+- if (driver->max_speed == USB_SPEED_UNKNOWN)
++ switch (g->speed) {
++ /* All the speeds we support */
++ case USB_SPEED_LOW:
++ case USB_SPEED_FULL:
++ case USB_SPEED_HIGH:
++ case USB_SPEED_SUPER:
++ break;
++ default:
++ dev_err(dummy_dev(dum_hcd), "Unsupported driver max speed %d\n",
++ driver->max_speed);
+ return -EINVAL;
++ }
+
+ /*
+ * SLAVE side init ... the layer above hardware, which
+@@ -1784,9 +1794,10 @@ static void dummy_timer(struct timer_lis
+ /* Bus speed is 500000 bytes/ms, so use a little less */
+ total = 490000;
+ break;
+- default:
++ default: /* Can't happen */
+ dev_err(dummy_dev(dum_hcd), "bogus device speed\n");
+- return;
++ total = 0;
++ break;
+ }
+
+ /* FIXME if HZ != 1000 this will probably misbehave ... */
+@@ -1828,7 +1839,7 @@ restart:
+
+ /* Used up this frame's bandwidth? */
+ if (total <= 0)
+- break;
++ continue;
+
+ /* find the gadget's ep for this request (if configured) */
+ address = usb_pipeendpoint (urb->pipe);
--- /dev/null
+From c409ca3be3c6ff3a1eeb303b191184e80d412862 Mon Sep 17 00:00:00 2001
+From: Malte Leip <malte@leip.net>
+Date: Sun, 14 Apr 2019 12:00:12 +0200
+Subject: usb: usbip: fix isoc packet num validation in get_pipe
+
+From: Malte Leip <malte@leip.net>
+
+commit c409ca3be3c6ff3a1eeb303b191184e80d412862 upstream.
+
+Change the validation of number_of_packets in get_pipe to compare the
+number of packets to a fixed maximum number of packets allowed, set to
+be 1024. This number was chosen due to it being used by other drivers as
+well, for example drivers/usb/host/uhci-q.c
+
+Background/reason:
+The get_pipe function in stub_rx.c validates the number of packets in
+isochronous mode and aborts with an error if that number is too large,
+in order to prevent malicious input from possibly triggering large
+memory allocations. This was previously done by checking whether
+pdu->u.cmd_submit.number_of_packets is bigger than the number of packets
+that would be needed for pdu->u.cmd_submit.transfer_buffer_length bytes
+if all except possibly the last packet had maximum length, given by
+usb_endpoint_maxp(epd) * usb_endpoint_maxp_mult(epd). This leads to an
+error if URBs with packets shorter than the maximum possible length are
+submitted, which is allowed according to
+Documentation/driver-api/usb/URB.rst and occurs for example with the
+snd-usb-audio driver.
+
+Fixes: c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input")
+Signed-off-by: Malte Leip <malte@leip.net>
+Cc: stable <stable@vger.kernel.org>
+Acked-by: Shuah Khan <skhan@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/usbip/stub_rx.c | 12 +++---------
+ drivers/usb/usbip/usbip_common.h | 7 +++++++
+ 2 files changed, 10 insertions(+), 9 deletions(-)
+
+--- a/drivers/usb/usbip/stub_rx.c
++++ b/drivers/usb/usbip/stub_rx.c
+@@ -361,16 +361,10 @@ static int get_pipe(struct stub_device *
+ }
+
+ if (usb_endpoint_xfer_isoc(epd)) {
+- /* validate packet size and number of packets */
+- unsigned int maxp, packets, bytes;
+-
+- maxp = usb_endpoint_maxp(epd);
+- maxp *= usb_endpoint_maxp_mult(epd);
+- bytes = pdu->u.cmd_submit.transfer_buffer_length;
+- packets = DIV_ROUND_UP(bytes, maxp);
+-
++ /* validate number of packets */
+ if (pdu->u.cmd_submit.number_of_packets < 0 ||
+- pdu->u.cmd_submit.number_of_packets > packets) {
++ pdu->u.cmd_submit.number_of_packets >
++ USBIP_MAX_ISO_PACKETS) {
+ dev_err(&sdev->udev->dev,
+ "CMD_SUBMIT: isoc invalid num packets %d\n",
+ pdu->u.cmd_submit.number_of_packets);
+--- a/drivers/usb/usbip/usbip_common.h
++++ b/drivers/usb/usbip/usbip_common.h
+@@ -121,6 +121,13 @@ extern struct device_attribute dev_attr_
+ #define USBIP_DIR_OUT 0x00
+ #define USBIP_DIR_IN 0x01
+
++/*
++ * Arbitrary limit for the maximum number of isochronous packets in an URB,
++ * compare for example the uhci_submit_isochronous function in
++ * drivers/usb/host/uhci-q.c
++ */
++#define USBIP_MAX_ISO_PACKETS 1024
++
+ /**
+ * struct usbip_header_basic - data pertinent to every request
+ * @command: the usbip request type
--- /dev/null
+From c114944d7d67f24e71562fcfc18d550ab787e4d4 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon, 22 Apr 2019 11:16:04 -0400
+Subject: USB: w1 ds2490: Fix bug caused by improper use of altsetting array
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit c114944d7d67f24e71562fcfc18d550ab787e4d4 upstream.
+
+The syzkaller USB fuzzer spotted a slab-out-of-bounds bug in the
+ds2490 driver. This bug is caused by improper use of the altsetting
+array in the usb_interface structure (the array's entries are not
+always stored in numerical order), combined with a naive assumption
+that all interfaces probed by the driver will have the expected number
+of altsettings.
+
+The bug can be fixed by replacing references to the possibly
+non-existent intf->altsetting[alt] entry with the guaranteed-to-exist
+intf->cur_altsetting entry.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+d65f673b847a1a96cdba@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/w1/masters/ds2490.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/w1/masters/ds2490.c
++++ b/drivers/w1/masters/ds2490.c
+@@ -1016,15 +1016,15 @@ static int ds_probe(struct usb_interface
+ /* alternative 3, 1ms interrupt (greatly speeds search), 64 byte bulk */
+ alt = 3;
+ err = usb_set_interface(dev->udev,
+- intf->altsetting[alt].desc.bInterfaceNumber, alt);
++ intf->cur_altsetting->desc.bInterfaceNumber, alt);
+ if (err) {
+ dev_err(&dev->udev->dev, "Failed to set alternative setting %d "
+ "for %d interface: err=%d.\n", alt,
+- intf->altsetting[alt].desc.bInterfaceNumber, err);
++ intf->cur_altsetting->desc.bInterfaceNumber, err);
+ goto err_out_clear;
+ }
+
+- iface_desc = &intf->altsetting[alt];
++ iface_desc = intf->cur_altsetting;
+ if (iface_desc->desc.bNumEndpoints != NUM_EP-1) {
+ pr_info("Num endpoints=%d. It is not DS9490R.\n",
+ iface_desc->desc.bNumEndpoints);
--- /dev/null
+From ef61eb43ada6c1d6b94668f0f514e4c268093ff3 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Tue, 23 Apr 2019 14:48:29 -0400
+Subject: USB: yurex: Fix protection fault after device removal
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit ef61eb43ada6c1d6b94668f0f514e4c268093ff3 upstream.
+
+The syzkaller USB fuzzer found a general-protection-fault bug in the
+yurex driver. The fault occurs when a device has been unplugged; the
+driver's interrupt-URB handler logs an error message referring to the
+device by name, after the device has been unregistered and its name
+deallocated.
+
+This problem is caused by the fact that the interrupt URB isn't
+cancelled until the driver's private data structure is released, which
+can happen long after the device is gone. The cure is to make sure
+that the interrupt URB is killed before yurex_disconnect() returns;
+this is exactly the sort of thing that usb_poison_urb() was meant for.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-and-tested-by: syzbot+2eb9121678bdb36e6d57@syzkaller.appspotmail.com
+CC: <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/misc/yurex.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/misc/yurex.c
++++ b/drivers/usb/misc/yurex.c
+@@ -314,6 +314,7 @@ static void yurex_disconnect(struct usb_
+ usb_deregister_dev(interface, &yurex_class);
+
+ /* prevent more I/O from starting */
++ usb_poison_urb(dev->urb);
+ mutex_lock(&dev->io_mutex);
+ dev->interface = NULL;
+ mutex_unlock(&dev->io_mutex);
projects / thirdparty / kernel / stable-queue.git / commitdiff
