--- /dev/null
+From 333f31436d3db19f4286f8862a00ea1d8d8420a1 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 29 Aug 2019 09:52:02 +0200
+Subject: ALSA: hda - Fix potential endless loop at applying quirks
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 333f31436d3db19f4286f8862a00ea1d8d8420a1 upstream.
+
+Since the chained quirks via chained_before flag is applied before the
+depth check, it may lead to the endless recursive calls, when the
+chain were set up incorrectly. Fix it by moving the depth check at
+the beginning of the loop.
+
+Fixes: 1f57825077dc ("ALSA: hda - Add chained_before flag to the fixup entry")
+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/hda_auto_parser.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/hda/hda_auto_parser.c
++++ b/sound/pci/hda/hda_auto_parser.c
+@@ -824,6 +824,8 @@ static void apply_fixup(struct hda_codec
+ while (id >= 0) {
+ const struct hda_fixup *fix = codec->fixup_list + id;
+
++ if (++depth > 10)
++ break;
+ if (fix->chained_before)
+ apply_fixup(codec, fix->chain_id, action, depth + 1);
+
+@@ -863,8 +865,6 @@ static void apply_fixup(struct hda_codec
+ }
+ if (!fix->chained || fix->chained_before)
+ break;
+- if (++depth > 10)
+- break;
+ id = fix->chain_id;
+ }
+ }
--- /dev/null
+From d33cd42d86671bed870827aa399aeb9f1da74119 Mon Sep 17 00:00:00 2001
+From: Sam Bazley <sambazley@fastmail.com>
+Date: Sun, 1 Sep 2019 03:31:30 +0100
+Subject: ALSA: hda/realtek - Add quirk for HP Pavilion 15
+
+From: Sam Bazley <sambazley@fastmail.com>
+
+commit d33cd42d86671bed870827aa399aeb9f1da74119 upstream.
+
+HP Pavilion 15 (AMD Ryzen-based model) with 103c:84e7 needs the same
+quirk like HP Envy/Spectre x360 for enabling the mute LED over Mic3 pin.
+
+[ rearranged in the SSID number order by tiwai ]
+
+Signed-off-by: Sam Bazley <sambazley@fastmail.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 | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -6981,6 +6981,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x103c, 0x82c0, "HP G3 mini premium", ALC221_FIXUP_HP_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x103c, 0x83b9, "HP Spectre x360", ALC269_FIXUP_HP_MUTE_LED_MIC3),
+ SND_PCI_QUIRK(0x103c, 0x8497, "HP Envy x360", ALC269_FIXUP_HP_MUTE_LED_MIC3),
++ SND_PCI_QUIRK(0x103c, 0x84e7, "HP Pavilion 15", ALC269_FIXUP_HP_MUTE_LED_MIC3),
+ SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC),
+ SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC282_FIXUP_ASUS_TX300),
+ SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
--- /dev/null
+From 60083f9e94b2f28047d71ed778adf89357c1a8fb Mon Sep 17 00:00:00 2001
+From: Jian-Hong Pan <jian-hong@endlessm.com>
+Date: Mon, 2 Sep 2019 18:00:56 +0800
+Subject: ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL
+
+From: Jian-Hong Pan <jian-hong@endlessm.com>
+
+commit 60083f9e94b2f28047d71ed778adf89357c1a8fb upstream.
+
+Original pin node values of ASUS UX431FL with ALC294:
+
+0x12 0xb7a60140
+0x13 0x40000000
+0x14 0x90170110
+0x15 0x411111f0
+0x16 0x411111f0
+0x17 0x90170111
+0x18 0x411111f0
+0x19 0x411111f0
+0x1a 0x411111f0
+0x1b 0x411111f0
+0x1d 0x4066852d
+0x1e 0x411111f0
+0x1f 0x411111f0
+0x21 0x04211020
+
+1. Has duplicated internal speakers (0x14 & 0x17) which makes the output
+ route become confused. So, the output volume cannot be changed by
+ setting.
+2. Misses the headset mic pin node.
+
+This patch disables the confusing speaker (NID 0x14) and enables the
+headset mic (NID 0x19).
+
+Link: https://lore.kernel.org/r/20190902100054.6941-1-jian-hong@endlessm.com
+Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.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 | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -5799,6 +5799,7 @@ enum {
+ ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
+ ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
+ ALC299_FIXUP_PREDATOR_SPK,
++ ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC,
+ };
+
+ static const struct hda_fixup alc269_fixups[] = {
+@@ -6839,6 +6840,16 @@ static const struct hda_fixup alc269_fix
+ { }
+ }
+ },
++ [ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC] = {
++ .type = HDA_FIXUP_PINS,
++ .v.pins = (const struct hda_pintbl[]) {
++ { 0x14, 0x411111f0 }, /* disable confusing internal speaker */
++ { 0x19, 0x04a11150 }, /* use as headset mic, without its own jack detect */
++ { }
++ },
++ .chained = true,
++ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
++ },
+ };
+
+ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
+@@ -6998,6 +7009,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", ALC269VB_FIXUP_ASUS_ZENBOOK),
+ SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
+ SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
++ SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL", ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
+ SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC),
+ SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
--- /dev/null
+From 89781d0806c2c4f29072d3f00cb2dd4274aabc3d Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 30 Aug 2019 12:03:38 +0200
+Subject: ALSA: hda/realtek - Fix overridden device-specific initialization
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 89781d0806c2c4f29072d3f00cb2dd4274aabc3d upstream.
+
+The recent change to shuffle the codec initialization procedure for
+Realtek via commit 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on
+later") caused the silent output on some machines. This change was
+supposed to be safe, but it isn't actually; some devices have quirk
+setups to override the EAPD via COEF or BTL in the additional verb
+table, which is applied at the beginning of snd_hda_gen_init(). And
+this EAPD setup is again overridden in alc_auto_init_amp().
+
+For recovering from the regression, tell snd_hda_gen_init() not to
+apply the verbs there by a new flag, then apply the verbs in
+alc_init().
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204727
+Fixes: 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later")
+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/hda_generic.c | 3 ++-
+ sound/pci/hda/hda_generic.h | 1 +
+ sound/pci/hda/patch_realtek.c | 2 ++
+ 3 files changed, 5 insertions(+), 1 deletion(-)
+
+--- a/sound/pci/hda/hda_generic.c
++++ b/sound/pci/hda/hda_generic.c
+@@ -6009,7 +6009,8 @@ int snd_hda_gen_init(struct hda_codec *c
+ if (spec->init_hook)
+ spec->init_hook(codec);
+
+- snd_hda_apply_verbs(codec);
++ if (!spec->skip_verbs)
++ snd_hda_apply_verbs(codec);
+
+ init_multi_out(codec);
+ init_extra_out(codec);
+--- a/sound/pci/hda/hda_generic.h
++++ b/sound/pci/hda/hda_generic.h
+@@ -243,6 +243,7 @@ struct hda_gen_spec {
+ unsigned int indep_hp_enabled:1; /* independent HP enabled */
+ unsigned int have_aamix_ctl:1;
+ unsigned int hp_mic_jack_modes:1;
++ unsigned int skip_verbs:1; /* don't apply verbs at snd_hda_gen_init() */
+
+ /* additional mute flags (only effective with auto_mute_via_amp=1) */
+ u64 mute_bits;
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -837,9 +837,11 @@ static int alc_init(struct hda_codec *co
+ if (spec->init_hook)
+ spec->init_hook(codec);
+
++ spec->gen.skip_verbs = 1; /* applied in below */
+ snd_hda_gen_init(codec);
+ alc_fix_pll(codec);
+ alc_auto_init_amp(codec, spec->init_amp);
++ snd_hda_apply_verbs(codec); /* apply verbs here after own init */
+
+ snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_INIT);
+
--- /dev/null
+From 2a36c16efab254dd6017efeb35ad88ecc96f2328 Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Wed, 4 Sep 2019 13:53:27 +0800
+Subject: ALSA: hda/realtek - Fix the problem of two front mics on a ThinkCentre
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit 2a36c16efab254dd6017efeb35ad88ecc96f2328 upstream.
+
+This ThinkCentre machine has a new realtek codec alc222, it is not
+in the support list, we add it in the realtek.c then this machine
+can apply FIXUPs for the realtek codec.
+
+And this machine has two front mics which can't be handled
+by PA so far, it uses the pin 0x18 and 0x19 as the front mics, as
+a result the existing FIXUP ALC294_FIXUP_LENOVO_MIC_LOCATION doesn't
+work on this machine. Fortunately another FIXUP
+ALC283_FIXUP_HEADSET_MIC also can change the location for one of the
+two mics on this machine.
+
+Link: https://lore.kernel.org/r/20190904055327.9883-1-hui.wang@canonical.com
+Signed-off-by: Hui Wang <hui.wang@canonical.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
+@@ -7087,6 +7087,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x17aa, 0x312a, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
+ SND_PCI_QUIRK(0x17aa, 0x312f, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
+ SND_PCI_QUIRK(0x17aa, 0x313c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
++ SND_PCI_QUIRK(0x17aa, 0x3151, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC),
+ SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
+ SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC),
+ SND_PCI_QUIRK(0x17aa, 0x3978, "Lenovo B50-70", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
+@@ -8961,6 +8962,7 @@ static int patch_alc680(struct hda_codec
+ static const struct hda_device_id snd_hda_id_realtek[] = {
+ HDA_CODEC_ENTRY(0x10ec0215, "ALC215", patch_alc269),
+ HDA_CODEC_ENTRY(0x10ec0221, "ALC221", patch_alc269),
++ HDA_CODEC_ENTRY(0x10ec0222, "ALC222", patch_alc269),
+ HDA_CODEC_ENTRY(0x10ec0225, "ALC225", patch_alc269),
+ HDA_CODEC_ENTRY(0x10ec0231, "ALC231", patch_alc269),
+ HDA_CODEC_ENTRY(0x10ec0233, "ALC233", patch_alc269),
--- /dev/null
+From 55f7e5c364dce20e691fda329fb2a6cc3cbb63b6 Mon Sep 17 00:00:00 2001
+From: Ben Skeggs <bskeggs@redhat.com>
+Date: Mon, 2 Sep 2019 16:33:22 +1000
+Subject: drm/nouveau/sec2/gp102: add missing MODULE_FIRMWAREs
+
+From: Ben Skeggs <bskeggs@redhat.com>
+
+commit 55f7e5c364dce20e691fda329fb2a6cc3cbb63b6 upstream.
+
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Cc: stable@vger.kernel.org [v5.2+]
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gp102.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gp102.c
++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gp102.c
+@@ -190,6 +190,9 @@ MODULE_FIRMWARE("nvidia/gp102/nvdec/scru
+ MODULE_FIRMWARE("nvidia/gp102/sec2/desc.bin");
+ MODULE_FIRMWARE("nvidia/gp102/sec2/image.bin");
+ MODULE_FIRMWARE("nvidia/gp102/sec2/sig.bin");
++MODULE_FIRMWARE("nvidia/gp102/sec2/desc-1.bin");
++MODULE_FIRMWARE("nvidia/gp102/sec2/image-1.bin");
++MODULE_FIRMWARE("nvidia/gp102/sec2/sig-1.bin");
+ MODULE_FIRMWARE("nvidia/gp104/acr/bl.bin");
+ MODULE_FIRMWARE("nvidia/gp104/acr/unload_bl.bin");
+ MODULE_FIRMWARE("nvidia/gp104/acr/ucode_load.bin");
+@@ -210,6 +213,9 @@ MODULE_FIRMWARE("nvidia/gp104/nvdec/scru
+ MODULE_FIRMWARE("nvidia/gp104/sec2/desc.bin");
+ MODULE_FIRMWARE("nvidia/gp104/sec2/image.bin");
+ MODULE_FIRMWARE("nvidia/gp104/sec2/sig.bin");
++MODULE_FIRMWARE("nvidia/gp104/sec2/desc-1.bin");
++MODULE_FIRMWARE("nvidia/gp104/sec2/image-1.bin");
++MODULE_FIRMWARE("nvidia/gp104/sec2/sig-1.bin");
+ MODULE_FIRMWARE("nvidia/gp106/acr/bl.bin");
+ MODULE_FIRMWARE("nvidia/gp106/acr/unload_bl.bin");
+ MODULE_FIRMWARE("nvidia/gp106/acr/ucode_load.bin");
+@@ -230,6 +236,9 @@ MODULE_FIRMWARE("nvidia/gp106/nvdec/scru
+ MODULE_FIRMWARE("nvidia/gp106/sec2/desc.bin");
+ MODULE_FIRMWARE("nvidia/gp106/sec2/image.bin");
+ MODULE_FIRMWARE("nvidia/gp106/sec2/sig.bin");
++MODULE_FIRMWARE("nvidia/gp106/sec2/desc-1.bin");
++MODULE_FIRMWARE("nvidia/gp106/sec2/image-1.bin");
++MODULE_FIRMWARE("nvidia/gp106/sec2/sig-1.bin");
+ MODULE_FIRMWARE("nvidia/gp107/acr/bl.bin");
+ MODULE_FIRMWARE("nvidia/gp107/acr/unload_bl.bin");
+ MODULE_FIRMWARE("nvidia/gp107/acr/ucode_load.bin");
+@@ -250,3 +259,6 @@ MODULE_FIRMWARE("nvidia/gp107/nvdec/scru
+ MODULE_FIRMWARE("nvidia/gp107/sec2/desc.bin");
+ MODULE_FIRMWARE("nvidia/gp107/sec2/image.bin");
+ MODULE_FIRMWARE("nvidia/gp107/sec2/sig.bin");
++MODULE_FIRMWARE("nvidia/gp107/sec2/desc-1.bin");
++MODULE_FIRMWARE("nvidia/gp107/sec2/image-1.bin");
++MODULE_FIRMWARE("nvidia/gp107/sec2/sig-1.bin");
--- /dev/null
+From 08b0c891605acf727e43e3e03a25857d3e789b61 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 15 Aug 2019 11:30:50 +0300
+Subject: drm/vmwgfx: Fix double free in vmw_recv_msg()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 08b0c891605acf727e43e3e03a25857d3e789b61 upstream.
+
+We recently added a kfree() after the end of the loop:
+
+ if (retries == RETRIES) {
+ kfree(reply);
+ return -EINVAL;
+ }
+
+There are two problems. First the test is wrong and because retries
+equals RETRIES if we succeed on the last iteration through the loop.
+Second if we fail on the last iteration through the loop then the kfree
+is a double free.
+
+When you're reading this code, please note the break statement at the
+end of the while loop. This patch changes the loop so that if it's not
+successful then "reply" is NULL and we can test for that afterward.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 6b7c3b86f0b6 ("drm/vmwgfx: fix memory leak when too many retries have occurred")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+@@ -353,7 +353,7 @@ static int vmw_recv_msg(struct rpc_chann
+ !!(HIGH_WORD(ecx) & MESSAGE_STATUS_HB));
+ if ((HIGH_WORD(ebx) & MESSAGE_STATUS_SUCCESS) == 0) {
+ kfree(reply);
+-
++ reply = NULL;
+ if ((HIGH_WORD(ebx) & MESSAGE_STATUS_CPT) != 0) {
+ /* A checkpoint occurred. Retry. */
+ continue;
+@@ -377,7 +377,7 @@ static int vmw_recv_msg(struct rpc_chann
+
+ if ((HIGH_WORD(ecx) & MESSAGE_STATUS_SUCCESS) == 0) {
+ kfree(reply);
+-
++ reply = NULL;
+ if ((HIGH_WORD(ecx) & MESSAGE_STATUS_CPT) != 0) {
+ /* A checkpoint occurred. Retry. */
+ continue;
+@@ -389,10 +389,8 @@ static int vmw_recv_msg(struct rpc_chann
+ break;
+ }
+
+- if (retries == RETRIES) {
+- kfree(reply);
++ if (!reply)
+ return -EINVAL;
+- }
+
+ *msg_len = reply_len;
+ *msg = reply;
--- /dev/null
+From bc624a06f0c5190bc37fec7d22cd82b43a579698 Mon Sep 17 00:00:00 2001
+From: David Jander <david@protonic.nl>
+Date: Tue, 27 Aug 2019 06:46:28 +0000
+Subject: gpio: pca953x: correct type of reg_direction
+
+From: David Jander <david@protonic.nl>
+
+commit bc624a06f0c5190bc37fec7d22cd82b43a579698 upstream.
+
+The type of reg_direction needs to match the type of the regmap, which
+is u8.
+
+Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache")
+Cc: Cc: <stable@vger.kernel.org>
+Signed-off-by: David Jander <david@protonic.nl>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpio-pca953x.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpio/gpio-pca953x.c
++++ b/drivers/gpio/gpio-pca953x.c
+@@ -604,7 +604,7 @@ static void pca953x_irq_bus_sync_unlock(
+ u8 new_irqs;
+ int level, i;
+ u8 invert_irq_mask[MAX_BANK];
+- int reg_direction[MAX_BANK];
++ u8 reg_direction[MAX_BANK];
+
+ regmap_bulk_read(chip->regmap, chip->regs->direction, reg_direction,
+ NBANK(chip));
+@@ -679,7 +679,7 @@ static bool pca953x_irq_pending(struct p
+ bool pending_seen = false;
+ bool trigger_seen = false;
+ u8 trigger[MAX_BANK];
+- int reg_direction[MAX_BANK];
++ u8 reg_direction[MAX_BANK];
+ int ret, i;
+
+ if (chip->driver_data & PCA_PCAL) {
+@@ -768,7 +768,7 @@ static int pca953x_irq_setup(struct pca9
+ {
+ struct i2c_client *client = chip->client;
+ struct irq_chip *irq_chip = &chip->irq_chip;
+- int reg_direction[MAX_BANK];
++ u8 reg_direction[MAX_BANK];
+ int ret, i;
+
+ if (!client->irq)
--- /dev/null
+From 438b6c20e6161a1a7542490baa093c86732f77d6 Mon Sep 17 00:00:00 2001
+From: David Jander <david@protonic.nl>
+Date: Tue, 27 Aug 2019 06:46:29 +0000
+Subject: gpio: pca953x: use pca953x_read_regs instead of regmap_bulk_read
+
+From: David Jander <david@protonic.nl>
+
+commit 438b6c20e6161a1a7542490baa093c86732f77d6 upstream.
+
+The register number needs to be translated for chips with more than 8
+ports. This patch fixes a bug causing all chips with more than 8 GPIO pins
+to not work correctly.
+
+Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache")
+Cc: Cc: <stable@vger.kernel.org>
+Signed-off-by: David Jander <david@protonic.nl>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpio/gpio-pca953x.c | 9 +++------
+ 1 file changed, 3 insertions(+), 6 deletions(-)
+
+--- a/drivers/gpio/gpio-pca953x.c
++++ b/drivers/gpio/gpio-pca953x.c
+@@ -606,8 +606,7 @@ static void pca953x_irq_bus_sync_unlock(
+ u8 invert_irq_mask[MAX_BANK];
+ u8 reg_direction[MAX_BANK];
+
+- regmap_bulk_read(chip->regmap, chip->regs->direction, reg_direction,
+- NBANK(chip));
++ pca953x_read_regs(chip, chip->regs->direction, reg_direction);
+
+ if (chip->driver_data & PCA_PCAL) {
+ /* Enable latch on interrupt-enabled inputs */
+@@ -710,8 +709,7 @@ static bool pca953x_irq_pending(struct p
+ return false;
+
+ /* Remove output pins from the equation */
+- regmap_bulk_read(chip->regmap, chip->regs->direction, reg_direction,
+- NBANK(chip));
++ pca953x_read_regs(chip, chip->regs->direction, reg_direction);
+ for (i = 0; i < NBANK(chip); i++)
+ cur_stat[i] &= reg_direction[i];
+
+@@ -789,8 +787,7 @@ static int pca953x_irq_setup(struct pca9
+ * interrupt. We have to rely on the previous read for
+ * this purpose.
+ */
+- regmap_bulk_read(chip->regmap, chip->regs->direction, reg_direction,
+- NBANK(chip));
++ pca953x_read_regs(chip, chip->regs->direction, reg_direction);
+ for (i = 0; i < NBANK(chip); i++)
+ chip->irq_stat[i] &= reg_direction[i];
+ mutex_init(&chip->irq_lock);
--- /dev/null
+From b9ee5e04fd77898208c51b1395fa0b5e8536f9b6 Mon Sep 17 00:00:00 2001
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+Date: Thu, 8 Aug 2019 12:48:26 +0000
+Subject: powerpc/64e: Drop stale call to smp_processor_id() which hangs SMP startup
+
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+
+commit b9ee5e04fd77898208c51b1395fa0b5e8536f9b6 upstream.
+
+Commit ebb9d30a6a74 ("powerpc/mm: any thread in one core can be the
+first to setup TLB1") removed the need to know the cpu_id in
+early_init_this_mmu(), but the call to smp_processor_id() which was
+marked __maybe_used remained.
+
+Since commit ed1cd6deb013 ("powerpc: Activate CONFIG_THREAD_INFO_IN_TASK")
+thread_info cannot be reached before MMU is properly set up.
+
+Drop this stale call to smp_processor_id() which makes SMP hang when
+CONFIG_PREEMPT is set.
+
+Fixes: ebb9d30a6a74 ("powerpc/mm: any thread in one core can be the first to setup TLB1")
+Fixes: ed1cd6deb013 ("powerpc: Activate CONFIG_THREAD_INFO_IN_TASK")
+Cc: stable@vger.kernel.org # v5.1+
+Reported-by: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/bef479514f4c08329fa649f67735df8918bc0976.1565268248.git.christophe.leroy@c-s.fr
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/mm/nohash/tlb.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/powerpc/mm/nohash/tlb.c
++++ b/arch/powerpc/mm/nohash/tlb.c
+@@ -630,7 +630,6 @@ static void early_init_this_mmu(void)
+ #ifdef CONFIG_PPC_FSL_BOOK3E
+ if (mmu_has_feature(MMU_FTR_TYPE_FSL_E)) {
+ unsigned int num_cams;
+- int __maybe_unused cpu = smp_processor_id();
+ bool map = true;
+
+ /* use a quarter of the TLBCAM for bolted linear map */
--- /dev/null
+From 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 Mon Sep 17 00:00:00 2001
+From: Gustavo Romero <gromero@linux.ibm.com>
+Date: Wed, 4 Sep 2019 00:55:27 -0400
+Subject: powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction
+
+From: Gustavo Romero <gromero@linux.ibm.com>
+
+commit 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 upstream.
+
+When we take an FP unavailable exception in a transaction we have to
+account for the hardware FP TM checkpointed registers being
+incorrect. In this case for this process we know the current and
+checkpointed FP registers must be the same (since FP wasn't used
+inside the transaction) hence in the thread_struct we copy the current
+FP registers to the checkpointed ones.
+
+This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr
+to determine if FP was on when in userspace. thread->ckpt_regs.msr
+represents the state of the MSR when exiting userspace. This is setup
+by check_if_tm_restore_required().
+
+Unfortunatley there is an optimisation in giveup_all() which returns
+early if tsk->thread.regs->msr (via local variable `usermsr`) has
+FP=VEC=VSX=SPE=0. This optimisation means that
+check_if_tm_restore_required() is not called and hence
+thread->ckpt_regs.msr is not updated and will contain an old value.
+
+This can happen if due to load_fp=255 we start a userspace process
+with MSR FP=1 and then we are context switched out. In this case
+thread->ckpt_regs.msr will contain FP=1. If that same process is then
+context switched in and load_fp overflows, MSR will have FP=0. If that
+process now enters a transaction and does an FP instruction, the FP
+unavailable will not update thread->ckpt_regs.msr (the bug) and MSR
+FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread()
+will then not perform the required memcpy and the checkpointed FP regs
+in the thread struct will contain the wrong values.
+
+The code path for this happening is:
+
+ Userspace: Kernel
+ Start userspace
+ with MSR FP/VEC/VSX/SPE=0 TM=1
+ < -----
+ ...
+ tbegin
+ bne
+ fp instruction
+ FP unavailable
+ ---- >
+ fp_unavailable_tm()
+ tm_reclaim_current()
+ tm_reclaim_thread()
+ giveup_all()
+ return early since FP/VMX/VSX=0
+ /* ckpt MSR not updated (Incorrect) */
+ tm_reclaim()
+ /* thread_struct ckpt FP regs contain junk (OK) */
+ /* Sees ckpt MSR FP=1 (Incorrect) */
+ no memcpy() performed
+ /* thread_struct ckpt FP regs not fixed (Incorrect) */
+ tm_recheckpoint()
+ /* Put junk in hardware checkpoint FP regs */
+ ....
+ < -----
+ Return to userspace
+ with MSR TM=1 FP=1
+ with junk in the FP TM checkpoint
+ TM rollback
+ reads FP junk
+
+This is a data integrity problem for the current process as the FP
+registers are corrupted. It's also a security problem as the FP
+registers from one process may be leaked to another.
+
+This patch moves up check_if_tm_restore_required() in giveup_all() to
+ensure thread->ckpt_regs.msr is updated correctly.
+
+A simple testcase to replicate this will be posted to
+tools/testing/selftests/powerpc/tm/tm-poison.c
+
+Similarly for VMX.
+
+This fixes CVE-2019-15030.
+
+Fixes: f48e91e87e67 ("powerpc/tm: Fix FP and VMX register corruption")
+Cc: stable@vger.kernel.org # 4.12+
+Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com>
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/process.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/kernel/process.c
++++ b/arch/powerpc/kernel/process.c
+@@ -497,13 +497,14 @@ void giveup_all(struct task_struct *tsk)
+ if (!tsk->thread.regs)
+ return;
+
++ check_if_tm_restore_required(tsk);
++
+ usermsr = tsk->thread.regs->msr;
+
+ if ((usermsr & msr_all_available) == 0)
+ return;
+
+ msr_check_and_set(msr_all_available);
+- check_if_tm_restore_required(tsk);
+
+ WARN_ON((usermsr & MSR_VSX) && !((usermsr & MSR_FP) && (usermsr & MSR_VEC)));
+
--- /dev/null
+From a8318c13e79badb92bc6640704a64cc022a6eb97 Mon Sep 17 00:00:00 2001
+From: Gustavo Romero <gromero@linux.ibm.com>
+Date: Wed, 4 Sep 2019 00:55:28 -0400
+Subject: powerpc/tm: Fix restoring FP/VMX facility incorrectly on interrupts
+
+From: Gustavo Romero <gromero@linux.ibm.com>
+
+commit a8318c13e79badb92bc6640704a64cc022a6eb97 upstream.
+
+When in userspace and MSR FP=0 the hardware FP state is unrelated to
+the current process. This is extended for transactions where if tbegin
+is run with FP=0, the hardware checkpoint FP state will also be
+unrelated to the current process. Due to this, we need to ensure this
+hardware checkpoint is updated with the correct state before we enable
+FP for this process.
+
+Unfortunately we get this wrong when returning to a process from a
+hardware interrupt. A process that starts a transaction with FP=0 can
+take an interrupt. When the kernel returns back to that process, we
+change to FP=1 but with hardware checkpoint FP state not updated. If
+this transaction is then rolled back, the FP registers now contain the
+wrong state.
+
+The process looks like this:
+ Userspace: Kernel
+
+ Start userspace
+ with MSR FP=0 TM=1
+ < -----
+ ...
+ tbegin
+ bne
+ Hardware interrupt
+ ---- >
+ <do_IRQ...>
+ ....
+ ret_from_except
+ restore_math()
+ /* sees FP=0 */
+ restore_fp()
+ tm_active_with_fp()
+ /* sees FP=1 (Incorrect) */
+ load_fp_state()
+ FP = 0 -> 1
+ < -----
+ Return to userspace
+ with MSR TM=1 FP=1
+ with junk in the FP TM checkpoint
+ TM rollback
+ reads FP junk
+
+When returning from the hardware exception, tm_active_with_fp() is
+incorrectly making restore_fp() call load_fp_state() which is setting
+FP=1.
+
+The fix is to remove tm_active_with_fp().
+
+tm_active_with_fp() is attempting to handle the case where FP state
+has been changed inside a transaction. In this case the checkpointed
+and transactional FP state is different and hence we must restore the
+FP state (ie. we can't do lazy FP restore inside a transaction that's
+used FP). It's safe to remove tm_active_with_fp() as this case is
+handled by restore_tm_state(). restore_tm_state() detects if FP has
+been using inside a transaction and will set load_fp and call
+restore_math() to ensure the FP state (checkpoint and transaction) is
+restored.
+
+This is a data integrity problem for the current process as the FP
+registers are corrupted. It's also a security problem as the FP
+registers from one process may be leaked to another.
+
+Similarly for VMX.
+
+A simple testcase to replicate this will be posted to
+tools/testing/selftests/powerpc/tm/tm-poison.c
+
+This fixes CVE-2019-15031.
+
+Fixes: a7771176b439 ("powerpc: Don't enable FP/Altivec if not checkpointed")
+Cc: stable@vger.kernel.org # 4.15+
+Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190904045529.23002-2-gromero@linux.vnet.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/process.c | 18 ++----------------
+ 1 file changed, 2 insertions(+), 16 deletions(-)
+
+--- a/arch/powerpc/kernel/process.c
++++ b/arch/powerpc/kernel/process.c
+@@ -101,21 +101,8 @@ static void check_if_tm_restore_required
+ }
+ }
+
+-static bool tm_active_with_fp(struct task_struct *tsk)
+-{
+- return MSR_TM_ACTIVE(tsk->thread.regs->msr) &&
+- (tsk->thread.ckpt_regs.msr & MSR_FP);
+-}
+-
+-static bool tm_active_with_altivec(struct task_struct *tsk)
+-{
+- return MSR_TM_ACTIVE(tsk->thread.regs->msr) &&
+- (tsk->thread.ckpt_regs.msr & MSR_VEC);
+-}
+ #else
+ static inline void check_if_tm_restore_required(struct task_struct *tsk) { }
+-static inline bool tm_active_with_fp(struct task_struct *tsk) { return false; }
+-static inline bool tm_active_with_altivec(struct task_struct *tsk) { return false; }
+ #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
+
+ bool strict_msr_control;
+@@ -252,7 +239,7 @@ EXPORT_SYMBOL(enable_kernel_fp);
+
+ static int restore_fp(struct task_struct *tsk)
+ {
+- if (tsk->thread.load_fp || tm_active_with_fp(tsk)) {
++ if (tsk->thread.load_fp) {
+ load_fp_state(¤t->thread.fp_state);
+ current->thread.load_fp++;
+ return 1;
+@@ -334,8 +321,7 @@ EXPORT_SYMBOL_GPL(flush_altivec_to_threa
+
+ static int restore_altivec(struct task_struct *tsk)
+ {
+- if (cpu_has_feature(CPU_FTR_ALTIVEC) &&
+- (tsk->thread.load_vec || tm_active_with_altivec(tsk))) {
++ if (cpu_has_feature(CPU_FTR_ALTIVEC) && (tsk->thread.load_vec)) {
+ load_vr_state(&tsk->thread.vr_state);
+ tsk->thread.used_vr = 1;
+ tsk->thread.load_vec++;
--- /dev/null
+From 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 Mon Sep 17 00:00:00 2001
+From: Liangyan <liangyan.peng@linux.alibaba.com>
+Date: Mon, 26 Aug 2019 20:16:33 +0800
+Subject: sched/fair: Don't assign runtime for throttled cfs_rq
+
+From: Liangyan <liangyan.peng@linux.alibaba.com>
+
+commit 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 upstream.
+
+do_sched_cfs_period_timer() will refill cfs_b runtime and call
+distribute_cfs_runtime to unthrottle cfs_rq, sometimes cfs_b->runtime
+will allocate all quota to one cfs_rq incorrectly, then other cfs_rqs
+attached to this cfs_b can't get runtime and will be throttled.
+
+We find that one throttled cfs_rq has non-negative
+cfs_rq->runtime_remaining and cause an unexpetced cast from s64 to u64
+in snippet:
+
+ distribute_cfs_runtime() {
+ runtime = -cfs_rq->runtime_remaining + 1;
+ }
+
+The runtime here will change to a large number and consume all
+cfs_b->runtime in this cfs_b period.
+
+According to Ben Segall, the throttled cfs_rq can have
+account_cfs_rq_runtime called on it because it is throttled before
+idle_balance, and the idle_balance calls update_rq_clock to add time
+that is accounted to the task.
+
+This commit prevents cfs_rq to be assgined new runtime if it has been
+throttled until that distribute_cfs_runtime is called.
+
+Signed-off-by: Liangyan <liangyan.peng@linux.alibaba.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
+Reviewed-by: Ben Segall <bsegall@google.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: shanpeic@linux.alibaba.com
+Cc: stable@vger.kernel.org
+Cc: xlpang@linux.alibaba.com
+Fixes: d3d9dc330236 ("sched: Throttle entities exceeding their allowed bandwidth")
+Link: https://lkml.kernel.org/r/20190826121633.6538-1-liangyan.peng@linux.alibaba.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/sched/fair.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/kernel/sched/fair.c
++++ b/kernel/sched/fair.c
+@@ -4449,6 +4449,8 @@ static void __account_cfs_rq_runtime(str
+ if (likely(cfs_rq->runtime_remaining > 0))
+ return;
+
++ if (cfs_rq->throttled)
++ return;
+ /*
+ * if we're unable to extend our runtime we resched so that the active
+ * hierarchy can be throttled
+@@ -4652,6 +4654,9 @@ static u64 distribute_cfs_runtime(struct
+ if (!cfs_rq_throttled(cfs_rq))
+ goto next;
+
++ /* By the above check, this should never be true */
++ SCHED_WARN_ON(cfs_rq->runtime_remaining > 0);
++
+ runtime = -cfs_rq->runtime_remaining + 1;
+ if (runtime > remaining)
+ runtime = remaining;
--- /dev/null
+From 264b563b8675771834419057cbe076c1a41fb666 Mon Sep 17 00:00:00 2001
+From: Tiwei Bie <tiwei.bie@intel.com>
+Date: Wed, 28 Aug 2019 13:37:00 +0800
+Subject: vhost/test: fix build for vhost test - again
+
+From: Tiwei Bie <tiwei.bie@intel.com>
+
+commit 264b563b8675771834419057cbe076c1a41fb666 upstream.
+
+Since vhost_exceeds_weight() was introduced, callers need to specify
+the packet weight and byte weight in vhost_dev_init(). Note that, the
+packet weight isn't counted in this patch to keep the original behavior
+unchanged.
+
+Fixes: e82b9b0727ff ("vhost: introduce vhost_exceeds_weight()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/vhost/test.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/drivers/vhost/test.c
++++ b/drivers/vhost/test.c
+@@ -22,6 +22,12 @@
+ * Using this limit prevents one virtqueue from starving others. */
+ #define VHOST_TEST_WEIGHT 0x80000
+
++/* Max number of packets transferred before requeueing the job.
++ * Using this limit prevents one virtqueue from starving others with
++ * pkts.
++ */
++#define VHOST_TEST_PKT_WEIGHT 256
++
+ enum {
+ VHOST_TEST_VQ = 0,
+ VHOST_TEST_VQ_MAX = 1,
+@@ -80,10 +86,8 @@ static void handle_vq(struct vhost_test
+ }
+ vhost_add_used_and_signal(&n->dev, vq, head, 0);
+ total_len += len;
+- if (unlikely(total_len >= VHOST_TEST_WEIGHT)) {
+- vhost_poll_queue(&vq->poll);
++ if (unlikely(vhost_exceeds_weight(vq, 0, total_len)))
+ break;
+- }
+ }
+
+ mutex_unlock(&vq->mutex);
+@@ -115,7 +119,8 @@ static int vhost_test_open(struct inode
+ dev = &n->dev;
+ vqs[VHOST_TEST_VQ] = &n->vqs[VHOST_TEST_VQ];
+ n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
+- vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV);
++ vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV,
++ VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT);
+
+ f->private_data = n;
+
--- /dev/null
+From 93d2c4de8d8129b97ee1e1a222aedb0719d2fcd9 Mon Sep 17 00:00:00 2001
+From: Tiwei Bie <tiwei.bie@intel.com>
+Date: Wed, 28 Aug 2019 13:36:59 +0800
+Subject: vhost/test: fix build for vhost test
+
+From: Tiwei Bie <tiwei.bie@intel.com>
+
+commit 93d2c4de8d8129b97ee1e1a222aedb0719d2fcd9 upstream.
+
+Since below commit, callers need to specify the iov_limit in
+vhost_dev_init() explicitly.
+
+Fixes: b46a0bf78ad7 ("vhost: fix OOB in get_rx_bufs()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/vhost/test.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/vhost/test.c
++++ b/drivers/vhost/test.c
+@@ -115,7 +115,7 @@ static int vhost_test_open(struct inode
+ dev = &n->dev;
+ vqs[VHOST_TEST_VQ] = &n->vqs[VHOST_TEST_VQ];
+ n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
+- vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX);
++ vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV);
+
+ f->private_data = n;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
