--- /dev/null
+From c366b3dbbab14b28d044b94eb9ce77c23482ea35 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 23 Dec 2019 23:18:16 +0100
+Subject: ALSA: hda - Apply sync-write workaround to old Intel platforms, too
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit c366b3dbbab14b28d044b94eb9ce77c23482ea35 upstream.
+
+Klaus Ethgen reported occasional high CPU usages in his system that
+seem caused by HD-audio driver. The perf output revealed that it's
+in the unsolicited event handling in the workqueue, and the problem
+seems triggered by some communication stall between the controller and
+the codec at the runtime or system resume.
+
+Actually a similar phenomenon was seen in the past for other Intel
+platforms, and we already applied the workaround to enforce sync-write
+for CORB/RIRB verbs for Skylake and newer chipsets (commit
+2756d9143aa5 "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel
+chips"). Fortunately, the same workaround is applicable to the old
+chipset, and the experiment showed the positive effect.
+
+Based on the experiment result, this patch enables the sync-write
+workaround for all Intel chipsets. The only reason I hesitated to
+apply this workaround was about the possibly slightly higher CPU usage.
+But if the lack of sync causes a much severer problem even for quite
+old chip, we should think this would be necessary for all Intel chips.
+
+Reported-by: Klaus Ethgen <Klaus@ethgen.ch>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191223171833.GA17053@chua
+Link: https://lore.kernel.org/r/20191223221816.32572-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/hda_intel.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -280,12 +280,13 @@ enum {
+
+ /* quirks for old Intel chipsets */
+ #define AZX_DCAPS_INTEL_ICH \
+- (AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE)
++ (AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE |\
++ AZX_DCAPS_SYNC_WRITE)
+
+ /* quirks for Intel PCH */
+ #define AZX_DCAPS_INTEL_PCH_BASE \
+ (AZX_DCAPS_NO_ALIGN_BUFSIZE | AZX_DCAPS_COUNT_LPIB_DELAY |\
+- AZX_DCAPS_SNOOP_TYPE(SCH))
++ AZX_DCAPS_SNOOP_TYPE(SCH) | AZX_DCAPS_SYNC_WRITE)
+
+ /* PCH up to IVB; no runtime PM; bind with i915 gfx */
+ #define AZX_DCAPS_INTEL_PCH_NOPM \
+@@ -300,13 +301,13 @@ enum {
+ #define AZX_DCAPS_INTEL_HASWELL \
+ (/*AZX_DCAPS_ALIGN_BUFSIZE |*/ AZX_DCAPS_COUNT_LPIB_DELAY |\
+ AZX_DCAPS_PM_RUNTIME | AZX_DCAPS_I915_COMPONENT |\
+- AZX_DCAPS_SNOOP_TYPE(SCH))
++ AZX_DCAPS_SNOOP_TYPE(SCH) | AZX_DCAPS_SYNC_WRITE)
+
+ /* Broadwell HDMI can't use position buffer reliably, force to use LPIB */
+ #define AZX_DCAPS_INTEL_BROADWELL \
+ (/*AZX_DCAPS_ALIGN_BUFSIZE |*/ AZX_DCAPS_POSFIX_LPIB |\
+ AZX_DCAPS_PM_RUNTIME | AZX_DCAPS_I915_COMPONENT |\
+- AZX_DCAPS_SNOOP_TYPE(SCH))
++ AZX_DCAPS_SNOOP_TYPE(SCH) | AZX_DCAPS_SYNC_WRITE)
+
+ #define AZX_DCAPS_INTEL_BAYTRAIL \
+ (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_I915_COMPONENT)
--- /dev/null
+From 66c5d718e5a6f80153b5e8d6ad8ba8e9c3320839 Mon Sep 17 00:00:00 2001
+From: Kailang Yang <kailang@realtek.com>
+Date: Mon, 9 Dec 2019 15:56:15 +0800
+Subject: ALSA: hda/realtek - Add headset Mic no shutup for ALC283
+
+From: Kailang Yang <kailang@realtek.com>
+
+commit 66c5d718e5a6f80153b5e8d6ad8ba8e9c3320839 upstream.
+
+Chrome machine had humming noise from external speaker plugin at
+codec D3 state.
+
+Signed-off-by: Kailang Yang <kailang@realtek.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/2692449396954c6c968f5b75e2660358@realtek.com
+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
+@@ -501,6 +501,7 @@ static void alc_shutup_pins(struct hda_c
+ struct alc_spec *spec = codec->spec;
+
+ switch (codec->core.vendor_id) {
++ case 0x10ec0283:
+ case 0x10ec0286:
+ case 0x10ec0288:
+ case 0x10ec0298:
--- /dev/null
+From 0aec96f5897ac16ad9945f531b4bef9a2edd2ebd Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 18 Dec 2019 20:26:06 +0100
+Subject: ALSA: ice1724: Fix sleep-in-atomic in Infrasonic Quartet support code
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 0aec96f5897ac16ad9945f531b4bef9a2edd2ebd upstream.
+
+Jia-Ju Bai reported a possible sleep-in-atomic scenario in the ice1724
+driver with Infrasonic Quartet support code: namely, ice->set_rate
+callback gets called inside ice->reg_lock spinlock, while the callback
+in quartet.c holds ice->gpio_mutex.
+
+This patch fixes the invalid call: it simply moves the calls of
+ice->set_rate and ice->set_mclk callbacks outside the spinlock.
+
+Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/5d43135e-73b9-a46a-2155-9e91d0dcdf83@gmail.com
+Link: https://lore.kernel.org/r/20191218192606.12866-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/ice1712/ice1724.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/sound/pci/ice1712/ice1724.c
++++ b/sound/pci/ice1712/ice1724.c
+@@ -647,6 +647,7 @@ static int snd_vt1724_set_pro_rate(struc
+ unsigned long flags;
+ unsigned char mclk_change;
+ unsigned int i, old_rate;
++ bool call_set_rate = false;
+
+ if (rate > ice->hw_rates->list[ice->hw_rates->count - 1])
+ return -EINVAL;
+@@ -670,7 +671,7 @@ static int snd_vt1724_set_pro_rate(struc
+ * setting clock rate for internal clock mode */
+ old_rate = ice->get_rate(ice);
+ if (force || (old_rate != rate))
+- ice->set_rate(ice, rate);
++ call_set_rate = true;
+ else if (rate == ice->cur_rate) {
+ spin_unlock_irqrestore(&ice->reg_lock, flags);
+ return 0;
+@@ -678,12 +679,14 @@ static int snd_vt1724_set_pro_rate(struc
+ }
+
+ ice->cur_rate = rate;
++ spin_unlock_irqrestore(&ice->reg_lock, flags);
++
++ if (call_set_rate)
++ ice->set_rate(ice, rate);
+
+ /* setting master clock */
+ mclk_change = ice->set_mclk(ice, rate);
+
+- spin_unlock_irqrestore(&ice->reg_lock, flags);
+-
+ if (mclk_change && ice->gpio.i2s_mclk_changed)
+ ice->gpio.i2s_mclk_changed(ice);
+ if (ice->gpio.set_pro_rate)
--- /dev/null
+From 0141254b0a74b37aa7eb13d42a56adba84d51c73 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 20 Dec 2019 10:31:34 +0100
+Subject: ALSA: usb-audio: fix set_format altsetting sanity check
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 0141254b0a74b37aa7eb13d42a56adba84d51c73 upstream.
+
+Make sure to check the return value of usb_altnum_to_altsetting() to
+avoid dereferencing a NULL pointer when the requested alternate settings
+is missing.
+
+The format altsetting number may come from a quirk table and there does
+not seem to be any other validation of it (the corresponding index is
+checked however).
+
+Fixes: b099b9693d23 ("ALSA: usb-audio: Avoid superfluous usb_set_interface() calls")
+Cc: stable <stable@vger.kernel.org> # 4.18
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://lore.kernel.org/r/20191220093134.1248-1-johan@kernel.org
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/pcm.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/usb/pcm.c
++++ b/sound/usb/pcm.c
+@@ -506,9 +506,9 @@ static int set_format(struct snd_usb_sub
+ if (WARN_ON(!iface))
+ return -EINVAL;
+ alts = usb_altnum_to_altsetting(iface, fmt->altsetting);
+- altsd = get_iface_desc(alts);
+- if (WARN_ON(altsd->bAlternateSetting != fmt->altsetting))
++ if (WARN_ON(!alts))
+ return -EINVAL;
++ altsd = get_iface_desc(alts);
+
+ if (fmt == subs->cur_audiofmt)
+ return 0;
--- /dev/null
+From 92adc96f8eecd9522a907c197cc3d62e405539fe Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Wed, 18 Dec 2019 21:26:50 +0800
+Subject: ALSA: usb-audio: set the interface format after resume on Dell WD19
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit 92adc96f8eecd9522a907c197cc3d62e405539fe upstream.
+
+Recently we found the headset-mic on the Dell Dock WD19 doesn't work
+anymore after s3 (s2i or deep), this problem could be workarounded by
+closing (pcm_close) the app and then reopening (pcm_open) the app, so
+this bug is not easy to be detected by users.
+
+When problem happens, retire_capture_urb() could still be called
+periodically, but the size of captured data is always 0, it could be
+a firmware bug on the dock. Anyway I found after resuming, the
+snd_usb_pcm_prepare() will be called, and if we forcibly run
+set_format() to set the interface and its endpoint, the capture
+size will be normal again. This problem and workaound also apply to
+playback.
+
+To fix it in the kernel, add a quirk to let set_format() run
+forcibly once after resume.
+
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191218132650.6303-1-hui.wang@canonical.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/card.h | 1 +
+ sound/usb/pcm.c | 21 +++++++++++++++++++--
+ sound/usb/quirks-table.h | 3 ++-
+ sound/usb/quirks.c | 11 +++++++++++
+ sound/usb/usbaudio.h | 3 ++-
+ 5 files changed, 35 insertions(+), 4 deletions(-)
+
+--- a/sound/usb/card.h
++++ b/sound/usb/card.h
+@@ -145,6 +145,7 @@ struct snd_usb_substream {
+ struct snd_usb_endpoint *sync_endpoint;
+ unsigned long flags;
+ bool need_setup_ep; /* (re)configure EP at prepare? */
++ bool need_setup_fmt; /* (re)configure fmt after resume? */
+ unsigned int speed; /* USB_SPEED_XXX */
+
+ u64 formats; /* format bitmasks (all or'ed) */
+--- a/sound/usb/pcm.c
++++ b/sound/usb/pcm.c
+@@ -510,11 +510,11 @@ static int set_format(struct snd_usb_sub
+ return -EINVAL;
+ altsd = get_iface_desc(alts);
+
+- if (fmt == subs->cur_audiofmt)
++ if (fmt == subs->cur_audiofmt && !subs->need_setup_fmt)
+ return 0;
+
+ /* close the old interface */
+- if (subs->interface >= 0 && subs->interface != fmt->iface) {
++ if (subs->interface >= 0 && (subs->interface != fmt->iface || subs->need_setup_fmt)) {
+ if (!subs->stream->chip->keep_iface) {
+ err = usb_set_interface(subs->dev, subs->interface, 0);
+ if (err < 0) {
+@@ -528,6 +528,9 @@ static int set_format(struct snd_usb_sub
+ subs->altset_idx = 0;
+ }
+
++ if (subs->need_setup_fmt)
++ subs->need_setup_fmt = false;
++
+ /* set interface */
+ if (iface->cur_altsetting != alts) {
+ err = snd_usb_select_mode_quirk(subs, fmt);
+@@ -1735,6 +1738,13 @@ static int snd_usb_substream_playback_tr
+ subs->data_endpoint->retire_data_urb = retire_playback_urb;
+ subs->running = 0;
+ return 0;
++ case SNDRV_PCM_TRIGGER_SUSPEND:
++ if (subs->stream->chip->setup_fmt_after_resume_quirk) {
++ stop_endpoints(subs, true);
++ subs->need_setup_fmt = true;
++ return 0;
++ }
++ break;
+ }
+
+ return -EINVAL;
+@@ -1767,6 +1777,13 @@ static int snd_usb_substream_capture_tri
+ subs->data_endpoint->retire_data_urb = retire_capture_urb;
+ subs->running = 1;
+ return 0;
++ case SNDRV_PCM_TRIGGER_SUSPEND:
++ if (subs->stream->chip->setup_fmt_after_resume_quirk) {
++ stop_endpoints(subs, true);
++ subs->need_setup_fmt = true;
++ return 0;
++ }
++ break;
+ }
+
+ return -EINVAL;
+--- a/sound/usb/quirks-table.h
++++ b/sound/usb/quirks-table.h
+@@ -3466,7 +3466,8 @@ AU0828_DEVICE(0x2040, 0x7270, "Hauppauge
+ .vendor_name = "Dell",
+ .product_name = "WD19 Dock",
+ .profile_name = "Dell-WD15-Dock",
+- .ifnum = QUIRK_NO_INTERFACE
++ .ifnum = QUIRK_ANY_INTERFACE,
++ .type = QUIRK_SETUP_FMT_AFTER_RESUME
+ }
+ },
+ /* MOTU Microbook II */
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -508,6 +508,16 @@ static int create_standard_mixer_quirk(s
+ return snd_usb_create_mixer(chip, quirk->ifnum, 0);
+ }
+
++
++static int setup_fmt_after_resume_quirk(struct snd_usb_audio *chip,
++ struct usb_interface *iface,
++ struct usb_driver *driver,
++ const struct snd_usb_audio_quirk *quirk)
++{
++ chip->setup_fmt_after_resume_quirk = 1;
++ return 1; /* Continue with creating streams and mixer */
++}
++
+ /*
+ * audio-interface quirks
+ *
+@@ -546,6 +556,7 @@ int snd_usb_create_quirk(struct snd_usb_
+ [QUIRK_AUDIO_EDIROL_UAXX] = create_uaxx_quirk,
+ [QUIRK_AUDIO_ALIGN_TRANSFER] = create_align_transfer_quirk,
+ [QUIRK_AUDIO_STANDARD_MIXER] = create_standard_mixer_quirk,
++ [QUIRK_SETUP_FMT_AFTER_RESUME] = setup_fmt_after_resume_quirk,
+ };
+
+ if (quirk->type < QUIRK_TYPE_COUNT) {
+--- a/sound/usb/usbaudio.h
++++ b/sound/usb/usbaudio.h
+@@ -33,7 +33,7 @@ struct snd_usb_audio {
+ wait_queue_head_t shutdown_wait;
+ unsigned int txfr_quirk:1; /* Subframe boundaries on transfers */
+ unsigned int tx_length_quirk:1; /* Put length specifier in transfers */
+-
++ unsigned int setup_fmt_after_resume_quirk:1; /* setup the format to interface after resume */
+ int num_interfaces;
+ int num_suspended_intf;
+ int sample_rate_read_error;
+@@ -98,6 +98,7 @@ enum quirk_type {
+ QUIRK_AUDIO_EDIROL_UAXX,
+ QUIRK_AUDIO_ALIGN_TRANSFER,
+ QUIRK_AUDIO_STANDARD_MIXER,
++ QUIRK_SETUP_FMT_AFTER_RESUME,
+
+ QUIRK_TYPE_COUNT
+ };
--- /dev/null
+From 1da87c9f67c98d552679974dbfc1f0f65b6a0a53 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Tue, 17 Dec 2019 09:49:52 -0500
+Subject: drm/amdgpu/smu: add metrics table lock for arcturus (v2)
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 1da87c9f67c98d552679974dbfc1f0f65b6a0a53 upstream.
+
+To protect access to the metrics table.
+
+v2: unlock on error
+
+Bug: https://gitlab.freedesktop.org/drm/amd/issues/900
+Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
+Reviewed-by: Evan Quan <evan.quan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
++++ b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
+@@ -910,18 +910,21 @@ static int arcturus_get_metrics_table(st
+ struct smu_table_context *smu_table= &smu->smu_table;
+ int ret = 0;
+
++ mutex_lock(&smu->metrics_lock);
+ if (!smu_table->metrics_time ||
+ time_after(jiffies, smu_table->metrics_time + HZ / 1000)) {
+ ret = smu_update_table(smu, SMU_TABLE_SMU_METRICS, 0,
+ (void *)smu_table->metrics_table, false);
+ if (ret) {
+ pr_info("Failed to export SMU metrics table!\n");
++ mutex_unlock(&smu->metrics_lock);
+ return ret;
+ }
+ smu_table->metrics_time = jiffies;
+ }
+
+ memcpy(metrics_table, smu_table->metrics_table, sizeof(SmuMetrics_t));
++ mutex_unlock(&smu->metrics_lock);
+
+ return ret;
+ }
--- /dev/null
+From e0e384c398d4638e54b6d2098f0ceaafdab870ee Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Tue, 17 Dec 2019 09:50:42 -0500
+Subject: drm/amdgpu/smu: add metrics table lock for navi (v2)
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit e0e384c398d4638e54b6d2098f0ceaafdab870ee upstream.
+
+To protect access to the metrics table.
+
+v2: unlock on error
+
+Bug: https://gitlab.freedesktop.org/drm/amd/issues/900
+Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
+Reviewed-by: Evan Quan <evan.quan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
++++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+@@ -547,17 +547,20 @@ static int navi10_get_metrics_table(stru
+ struct smu_table_context *smu_table= &smu->smu_table;
+ int ret = 0;
+
++ mutex_lock(&smu->metrics_lock);
+ if (!smu_table->metrics_time || time_after(jiffies, smu_table->metrics_time + msecs_to_jiffies(100))) {
+ ret = smu_update_table(smu, SMU_TABLE_SMU_METRICS, 0,
+ (void *)smu_table->metrics_table, false);
+ if (ret) {
+ pr_info("Failed to export SMU metrics table!\n");
++ mutex_unlock(&smu->metrics_lock);
+ return ret;
+ }
+ smu_table->metrics_time = jiffies;
+ }
+
+ memcpy(metrics_table, smu_table->metrics_table, sizeof(SmuMetrics_t));
++ mutex_unlock(&smu->metrics_lock);
+
+ return ret;
+ }
--- /dev/null
+From 1c455101c6d10c99b310d6bcf613244c97854012 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Tue, 17 Dec 2019 09:51:40 -0500
+Subject: drm/amdgpu/smu: add metrics table lock for vega20 (v2)
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 1c455101c6d10c99b310d6bcf613244c97854012 upstream.
+
+To protect access to the metrics table.
+
+v2: unlock on error
+
+Bug: https://gitlab.freedesktop.org/drm/amd/issues/900
+Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
+Reviewed-by: Evan Quan <evan.quan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
++++ b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
+@@ -1691,17 +1691,20 @@ static int vega20_get_metrics_table(stru
+ struct smu_table_context *smu_table= &smu->smu_table;
+ int ret = 0;
+
++ mutex_lock(&smu->metrics_lock);
+ if (!smu_table->metrics_time || time_after(jiffies, smu_table->metrics_time + HZ / 1000)) {
+ ret = smu_update_table(smu, SMU_TABLE_SMU_METRICS, 0,
+ (void *)smu_table->metrics_table, false);
+ if (ret) {
+ pr_info("Failed to export SMU metrics table!\n");
++ mutex_unlock(&smu->metrics_lock);
+ return ret;
+ }
+ smu_table->metrics_time = jiffies;
+ }
+
+ memcpy(metrics_table, smu_table->metrics_table, sizeof(SmuMetrics_t));
++ mutex_unlock(&smu->metrics_lock);
+
+ return ret;
+ }
--- /dev/null
+From 073d5eef9e043c2b7e3ef12bc6c879b1d248e831 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Tue, 17 Dec 2019 09:35:01 -0500
+Subject: drm/amdgpu/smu: add metrics table lock
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 073d5eef9e043c2b7e3ef12bc6c879b1d248e831 upstream.
+
+This table is used for lots of things, add it's own lock.
+
+Bug: https://gitlab.freedesktop.org/drm/amd/issues/900
+Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
+Reviewed-by: Evan Quan <evan.quan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 1 +
+ drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
++++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
+@@ -844,6 +844,7 @@ static int smu_sw_init(void *handle)
+ smu->smu_baco.platform_support = false;
+
+ mutex_init(&smu->sensor_lock);
++ mutex_init(&smu->metrics_lock);
+
+ smu->watermarks_bitmap = 0;
+ smu->power_profile_mode = PP_SMC_POWER_PROFILE_BOOTUP_DEFAULT;
+--- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
++++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
+@@ -345,6 +345,7 @@ struct smu_context
+ const struct pptable_funcs *ppt_funcs;
+ struct mutex mutex;
+ struct mutex sensor_lock;
++ struct mutex metrics_lock;
+ uint64_t pool_size;
+
+ struct smu_table_context smu_table;
--- /dev/null
+From 57177d214ee0816c4436c23d6c933ccb32c571f1 Mon Sep 17 00:00:00 2001
+From: Stefan Mavrodiev <stefan@olimex.com>
+Date: Tue, 17 Dec 2019 14:46:32 +0200
+Subject: drm/sun4i: hdmi: Remove duplicate cleanup calls
+
+From: Stefan Mavrodiev <stefan@olimex.com>
+
+commit 57177d214ee0816c4436c23d6c933ccb32c571f1 upstream.
+
+When the HDMI unbinds drm_connector_cleanup() and drm_encoder_cleanup()
+are called. This also happens when the connector and the encoder are
+destroyed. This double call triggers a NULL pointer exception.
+
+The patch fixes this by removing the cleanup calls in the unbind
+function.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
+Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://patchwork.freedesktop.org/patch/msgid/20191217124632.20820-1-stefan@olimex.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
++++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+@@ -683,8 +683,6 @@ static void sun4i_hdmi_unbind(struct dev
+ struct sun4i_hdmi *hdmi = dev_get_drvdata(dev);
+
+ cec_unregister_adapter(hdmi->cec_adap);
+- drm_connector_cleanup(&hdmi->connector);
+- drm_encoder_cleanup(&hdmi->encoder);
+ i2c_del_adapter(hdmi->i2c);
+ i2c_put_adapter(hdmi->ddc_i2c);
+ clk_disable_unprepare(hdmi->mod_clk);
--- /dev/null
+From 95c29d46ab2a517e4c26d0a07300edca6768db17 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Sat, 7 Dec 2019 23:48:09 +0100
+Subject: media: cec: avoid decrementing transmit_queue_sz if it is 0
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 95c29d46ab2a517e4c26d0a07300edca6768db17 upstream.
+
+WARN if transmit_queue_sz is 0 but do not decrement it.
+The CEC adapter will become unresponsive if it goes below
+0 since then it thinks there are 4 billion messages in the
+queue.
+
+Obviously this should not happen, but a driver bug could
+cause this.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Cc: <stable@vger.kernel.org> # for v4.12 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/cec/cec-adap.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/cec/cec-adap.c
++++ b/drivers/media/cec/cec-adap.c
+@@ -378,7 +378,8 @@ static void cec_data_cancel(struct cec_d
+ } else {
+ list_del_init(&data->list);
+ if (!(data->msg.tx_status & CEC_TX_STATUS_OK))
+- data->adap->transmit_queue_sz--;
++ if (!WARN_ON(!data->adap->transmit_queue_sz))
++ data->adap->transmit_queue_sz--;
+ }
+
+ if (data->msg.tx_status & CEC_TX_STATUS_OK) {
+@@ -430,6 +431,14 @@ static void cec_flush(struct cec_adapter
+ * need to do anything special in that case.
+ */
+ }
++ /*
++ * If something went wrong and this counter isn't what it should
++ * be, then this will reset it back to 0. Warn if it is not 0,
++ * since it indicates a bug, either in this framework or in a
++ * CEC driver.
++ */
++ if (WARN_ON(adap->transmit_queue_sz))
++ adap->transmit_queue_sz = 0;
+ }
+
+ /*
+@@ -520,7 +529,8 @@ int cec_thread_func(void *_adap)
+ data = list_first_entry(&adap->transmit_queue,
+ struct cec_data, list);
+ list_del_init(&data->list);
+- adap->transmit_queue_sz--;
++ if (!WARN_ON(!data->adap->transmit_queue_sz))
++ adap->transmit_queue_sz--;
+
+ /* Make this the current transmitting message */
+ adap->transmitting = data;
--- /dev/null
+From cec935ce69fc386f13959578deb40963ebbb85c3 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Wed, 4 Dec 2019 08:52:08 +0100
+Subject: media: cec: CEC 2.0-only bcast messages were ignored
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit cec935ce69fc386f13959578deb40963ebbb85c3 upstream.
+
+Some messages are allowed to be a broadcast message in CEC 2.0
+only, and should be ignored by CEC 1.4 devices.
+
+Unfortunately, the check was wrong, causing such messages to be
+marked as invalid under CEC 2.0.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Cc: <stable@vger.kernel.org> # for v4.10 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/cec/cec-adap.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/media/cec/cec-adap.c
++++ b/drivers/media/cec/cec-adap.c
+@@ -1083,11 +1083,11 @@ void cec_received_msg_ts(struct cec_adap
+ valid_la = false;
+ else if (!cec_msg_is_broadcast(msg) && !(dir_fl & DIRECTED))
+ valid_la = false;
+- else if (cec_msg_is_broadcast(msg) && !(dir_fl & BCAST1_4))
++ else if (cec_msg_is_broadcast(msg) && !(dir_fl & BCAST))
+ valid_la = false;
+ else if (cec_msg_is_broadcast(msg) &&
+- adap->log_addrs.cec_version >= CEC_OP_CEC_VERSION_2_0 &&
+- !(dir_fl & BCAST2_0))
++ adap->log_addrs.cec_version < CEC_OP_CEC_VERSION_2_0 &&
++ !(dir_fl & BCAST1_4))
+ valid_la = false;
+ }
+ if (valid_la && min_len) {
--- /dev/null
+From ac479b51f3f4aaa852b5d3f00ecfb9290230cf64 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Wed, 11 Dec 2019 12:47:57 +0100
+Subject: media: cec: check 'transmit_in_progress', not 'transmitting'
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit ac479b51f3f4aaa852b5d3f00ecfb9290230cf64 upstream.
+
+Currently wait_event_interruptible_timeout is called in cec_thread_func()
+when adap->transmitting is set. But if the adapter is unconfigured
+while transmitting, then adap->transmitting is set to NULL. But the
+hardware is still actually transmitting the message, and that's
+indicated by adap->transmit_in_progress and we should wait until that
+is finished or times out before transmitting new messages.
+
+As the original commit says: adap->transmitting is the userspace view,
+adap->transmit_in_progress reflects the hardware state.
+
+However, if adap->transmitting is NULL and adap->transmit_in_progress
+is true, then wait_event_interruptible is called (no timeout), which
+can get stuck indefinitely if the CEC driver is flaky and never marks
+the transmit-in-progress as 'done'.
+
+So test against transmit_in_progress when deciding whether to use
+the timeout variant or not, instead of testing against adap->transmitting.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Fixes: 32804fcb612b ("media: cec: keep track of outstanding transmits")
+Cc: <stable@vger.kernel.org> # for v4.19 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/cec/cec-adap.c | 20 ++++++++++++--------
+ 1 file changed, 12 insertions(+), 8 deletions(-)
+
+--- a/drivers/media/cec/cec-adap.c
++++ b/drivers/media/cec/cec-adap.c
+@@ -463,7 +463,7 @@ int cec_thread_func(void *_adap)
+ bool timeout = false;
+ u8 attempts;
+
+- if (adap->transmitting) {
++ if (adap->transmit_in_progress) {
+ int err;
+
+ /*
+@@ -498,7 +498,7 @@ int cec_thread_func(void *_adap)
+ goto unlock;
+ }
+
+- if (adap->transmitting && timeout) {
++ if (adap->transmit_in_progress && timeout) {
+ /*
+ * If we timeout, then log that. Normally this does
+ * not happen and it is an indication of a faulty CEC
+@@ -507,14 +507,18 @@ int cec_thread_func(void *_adap)
+ * so much traffic on the bus that the adapter was
+ * unable to transmit for CEC_XFER_TIMEOUT_MS (2.1s).
+ */
+- pr_warn("cec-%s: message %*ph timed out\n", adap->name,
+- adap->transmitting->msg.len,
+- adap->transmitting->msg.msg);
++ if (adap->transmitting) {
++ pr_warn("cec-%s: message %*ph timed out\n", adap->name,
++ adap->transmitting->msg.len,
++ adap->transmitting->msg.msg);
++ /* Just give up on this. */
++ cec_data_cancel(adap->transmitting,
++ CEC_TX_STATUS_TIMEOUT);
++ } else {
++ pr_warn("cec-%s: transmit timed out\n", adap->name);
++ }
+ adap->transmit_in_progress = false;
+ adap->tx_timeouts++;
+- /* Just give up on this. */
+- cec_data_cancel(adap->transmitting,
+- CEC_TX_STATUS_TIMEOUT);
+ goto unlock;
+ }
+
--- /dev/null
+From e5a52a1d15c79bb48a430fb263852263ec1d3f11 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Sat, 7 Dec 2019 23:43:23 +0100
+Subject: media: pulse8-cec: fix lost cec_transmit_attempt_done() call
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit e5a52a1d15c79bb48a430fb263852263ec1d3f11 upstream.
+
+The periodic PING command could interfere with the result of
+a CEC transmit, causing a lost cec_transmit_attempt_done()
+call.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Cc: <stable@vger.kernel.org> # for v4.10 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/usb/pulse8-cec/pulse8-cec.c | 17 +++++++++++++----
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+--- a/drivers/media/usb/pulse8-cec/pulse8-cec.c
++++ b/drivers/media/usb/pulse8-cec/pulse8-cec.c
+@@ -116,6 +116,7 @@ struct pulse8 {
+ unsigned int vers;
+ struct completion cmd_done;
+ struct work_struct work;
++ u8 work_result;
+ struct delayed_work ping_eeprom_work;
+ struct cec_msg rx_msg;
+ u8 data[DATA_SIZE];
+@@ -137,8 +138,10 @@ static void pulse8_irq_work_handler(stru
+ {
+ struct pulse8 *pulse8 =
+ container_of(work, struct pulse8, work);
++ u8 result = pulse8->work_result;
+
+- switch (pulse8->data[0] & 0x3f) {
++ pulse8->work_result = 0;
++ switch (result & 0x3f) {
+ case MSGCODE_FRAME_DATA:
+ cec_received_msg(pulse8->adap, &pulse8->rx_msg);
+ break;
+@@ -172,12 +175,12 @@ static irqreturn_t pulse8_interrupt(stru
+ pulse8->escape = false;
+ } else if (data == MSGEND) {
+ struct cec_msg *msg = &pulse8->rx_msg;
++ u8 msgcode = pulse8->buf[0];
+
+ if (debug)
+ dev_info(pulse8->dev, "received: %*ph\n",
+ pulse8->idx, pulse8->buf);
+- pulse8->data[0] = pulse8->buf[0];
+- switch (pulse8->buf[0] & 0x3f) {
++ switch (msgcode & 0x3f) {
+ case MSGCODE_FRAME_START:
+ msg->len = 1;
+ msg->msg[0] = pulse8->buf[1];
+@@ -186,14 +189,20 @@ static irqreturn_t pulse8_interrupt(stru
+ if (msg->len == CEC_MAX_MSG_SIZE)
+ break;
+ msg->msg[msg->len++] = pulse8->buf[1];
+- if (pulse8->buf[0] & MSGCODE_FRAME_EOM)
++ if (msgcode & MSGCODE_FRAME_EOM) {
++ WARN_ON(pulse8->work_result);
++ pulse8->work_result = msgcode;
+ schedule_work(&pulse8->work);
++ break;
++ }
+ break;
+ case MSGCODE_TRANSMIT_SUCCEEDED:
+ case MSGCODE_TRANSMIT_FAILED_LINE:
+ case MSGCODE_TRANSMIT_FAILED_ACK:
+ case MSGCODE_TRANSMIT_FAILED_TIMEOUT_DATA:
+ case MSGCODE_TRANSMIT_FAILED_TIMEOUT_LINE:
++ WARN_ON(pulse8->work_result);
++ pulse8->work_result = msgcode;
+ schedule_work(&pulse8->work);
+ break;
+ case MSGCODE_HIGH_ERROR:
--- /dev/null
+From bbcc5672b0063b0e9d65dc8787a4f09c3b5bb5cc Mon Sep 17 00:00:00 2001
+From: Paul Burton <paulburton@kernel.org>
+Date: Wed, 1 Jan 2020 20:50:38 -0800
+Subject: MIPS: Avoid VDSO ABI breakage due to global register variable
+
+From: Paul Burton <paulburton@kernel.org>
+
+commit bbcc5672b0063b0e9d65dc8787a4f09c3b5bb5cc upstream.
+
+Declaring __current_thread_info as a global register variable has the
+effect of preventing GCC from saving & restoring its value in cases
+where the ABI would typically do so.
+
+To quote GCC documentation:
+
+> If the register is a call-saved register, call ABI is affected: the
+> register will not be restored in function epilogue sequences after the
+> variable has been assigned. Therefore, functions cannot safely return
+> to callers that assume standard ABI.
+
+When our position independent VDSO is built for the n32 or n64 ABIs all
+functions it exposes should be preserving the value of $gp/$28 for their
+caller, but in the presence of the __current_thread_info global register
+variable GCC stops doing so & simply clobbers $gp/$28 when calculating
+the address of the GOT.
+
+In cases where the VDSO returns success this problem will typically be
+masked by the caller in libc returning & restoring $gp/$28 itself, but
+that is by no means guaranteed. In cases where the VDSO returns an error
+libc will typically contain a fallback path which will now fail
+(typically with a bad memory access) if it attempts anything which
+relies upon the value of $gp/$28 - eg. accessing anything via the GOT.
+
+One fix for this would be to move the declaration of
+__current_thread_info inside the current_thread_info() function,
+demoting it from global register variable to local register variable &
+avoiding inadvertently creating a non-standard calling ABI for the VDSO.
+Unfortunately this causes issues for clang, which doesn't support local
+register variables as pointed out by commit fe92da0f355e ("MIPS: Changed
+current_thread_info() to an equivalent supported by both clang and GCC")
+which introduced the global register variable before we had a VDSO to
+worry about.
+
+Instead, fix this by continuing to use the global register variable for
+the kernel proper but declare __current_thread_info as a simple extern
+variable when building the VDSO. It should never be referenced, and will
+cause a link error if it is. This resolves the calling convention issue
+for the VDSO without having any impact upon the build of the kernel
+itself for either clang or gcc.
+
+Signed-off-by: Paul Burton <paulburton@kernel.org>
+Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
+Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
+Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
+Tested-by: Jason A. Donenfeld <Jason@zx2c4.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Christian Brauner <christian.brauner@canonical.com>
+Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
+Cc: <stable@vger.kernel.org> # v4.4+
+Cc: linux-mips@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/include/asm/thread_info.h | 20 +++++++++++++++++++-
+ 1 file changed, 19 insertions(+), 1 deletion(-)
+
+--- a/arch/mips/include/asm/thread_info.h
++++ b/arch/mips/include/asm/thread_info.h
+@@ -49,8 +49,26 @@ struct thread_info {
+ .addr_limit = KERNEL_DS, \
+ }
+
+-/* How to get the thread information struct from C. */
++/*
++ * A pointer to the struct thread_info for the currently executing thread is
++ * held in register $28/$gp.
++ *
++ * We declare __current_thread_info as a global register variable rather than a
++ * local register variable within current_thread_info() because clang doesn't
++ * support explicit local register variables.
++ *
++ * When building the VDSO we take care not to declare the global register
++ * variable because this causes GCC to not preserve the value of $28/$gp in
++ * functions that change its value (which is common in the PIC VDSO when
++ * accessing the GOT). Since the VDSO shouldn't be accessing
++ * __current_thread_info anyway we declare it extern in order to cause a link
++ * failure if it's referenced.
++ */
++#ifdef __VDSO__
++extern struct thread_info *__current_thread_info;
++#else
+ register struct thread_info *__current_thread_info __asm__("$28");
++#endif
+
+ static inline struct thread_info *current_thread_info(void)
+ {
--- /dev/null
+From f8fffebdea752a25757b906f3dffecf1a59a6194 Mon Sep 17 00:00:00 2001
+From: Paul Burton <paulburton@kernel.org>
+Date: Thu, 5 Dec 2019 10:23:18 -0800
+Subject: MIPS: BPF: Disable MIPS32 eBPF JIT
+
+From: Paul Burton <paulburton@kernel.org>
+
+commit f8fffebdea752a25757b906f3dffecf1a59a6194 upstream.
+
+Commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32
+architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has
+previously only been availailable for MIPS64. It was my understanding at
+the time that the BPF test suite was passing & JITing a comparable
+number of tests to our cBPF JIT [1], but it turns out that was not the
+case.
+
+The eBPF JIT has a number of problems on MIPS32:
+
+- Most notably various code paths still result in emission of MIPS64
+ instructions which will cause reserved instruction exceptions & kernel
+ panics when run on MIPS32 CPUs.
+
+- The eBPF JIT doesn't account for differences between the O32 ABI used
+ by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably
+ arguments beyond the first 4 are passed on the stack in O32, and this
+ is entirely unhandled when JITing a BPF_CALL instruction. Stack space
+ must be reserved for arguments even if they all fit in registers, and
+ the callee is free to assume that stack space has been reserved for
+ its use - with the eBPF JIT this is not the case, so calling any
+ function can result in clobbering values on the stack & unpredictable
+ behaviour. Function arguments in eBPF are always 64-bit values which
+ is also entirely unhandled - the JIT still uses a single (32-bit)
+ register per argument. As a result all function arguments are always
+ passed incorrectly when JITing a BPF_CALL instruction, leading to
+ kernel crashes or strange behavior.
+
+- The JIT attempts to bail our on use of ALU64 instructions or 64-bit
+ memory access instructions. The code doing this at the start of
+ build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW,
+ when it should really be checking BPF_SIZE() & only doing so when
+ BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false
+ positives that cause more bailouts than intended, and that in turns
+ hides some of the problems described above.
+
+- The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF
+ instructions that the MIPS32 eBPF JIT bails out on, leading to most
+ cBPF programs not being JITed at all.
+
+Until these problems are resolved, revert the enabling of the eBPF JIT
+on MIPS32 done by commit 716850ab104d ("MIPS: eBPF: Initial eBPF support
+for MIPS32 architecture.").
+
+Note that this does not undo the changes made to the eBPF JIT by that
+commit, since they are a useful starting point to providing MIPS32
+support - they're just not nearly complete.
+
+[1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/
+
+Signed-off-by: Paul Burton <paulburton@kernel.org>
+Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.")
+Cc: Daniel Borkmann <daniel@iogearbox.net>
+Cc: Hassan Naveed <hnaveed@wavecomp.com>
+Cc: Tony Ambardar <itugrok@yahoo.com>
+Cc: bpf@vger.kernel.org
+Cc: netdev@vger.kernel.org
+Cc: <stable@vger.kernel.org> # v5.2+
+Cc: linux-mips@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/mips/Kconfig
++++ b/arch/mips/Kconfig
+@@ -46,7 +46,7 @@ config MIPS
+ select HAVE_ARCH_TRACEHOOK
+ select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES
+ select HAVE_ASM_MODVERSIONS
+- select HAVE_EBPF_JIT if (!CPU_MICROMIPS)
++ select HAVE_EBPF_JIT if (64BIT && !CPU_MICROMIPS)
+ select HAVE_CONTEXT_TRACKING
+ select HAVE_COPY_THREAD_TLS
+ select HAVE_C_RECORDMCOUNT
--- /dev/null
+From f596cf0d8062cb5d0a4513a8b3afca318c13be10 Mon Sep 17 00:00:00 2001
+From: Alexander Lobakin <alobakin@dlink.ru>
+Date: Fri, 6 Dec 2019 11:07:41 +0300
+Subject: MIPS: BPF: eBPF JIT: check for MIPS ISA compliance in Kconfig
+
+From: Alexander Lobakin <alobakin@dlink.ru>
+
+commit f596cf0d8062cb5d0a4513a8b3afca318c13be10 upstream.
+
+It is completely wrong to check for compile-time MIPS ISA revision in
+the body of bpf_int_jit_compile() as it may lead to get MIPS JIT fully
+omitted by the CC while the rest system will think that the JIT is
+actually present and works [1].
+We can check if the selected CPU really supports MIPS eBPF JIT at
+configure time and avoid such situations when kernel can be built
+without both JIT and interpreter, but with CONFIG_BPF_SYSCALL=y.
+
+[1] https://lore.kernel.org/linux-mips/09d713a59665d745e21d021deeaebe0a@dlink.ru/
+
+Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.")
+Cc: <stable@vger.kernel.org> # v5.2+
+Signed-off-by: Alexander Lobakin <alobakin@dlink.ru>
+Signed-off-by: Paul Burton <paulburton@kernel.org>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: James Hogan <jhogan@kernel.org>
+Cc: Hassan Naveed <hnaveed@wavecomp.com>
+Cc: Alexei Starovoitov <ast@kernel.org>
+Cc: Daniel Borkmann <daniel@iogearbox.net>
+Cc: Martin KaFai Lau <kafai@fb.com>
+Cc: Song Liu <songliubraving@fb.com>
+Cc: Yonghong Song <yhs@fb.com>
+Cc: Andrii Nakryiko <andriin@fb.com>
+Cc: linux-mips@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Cc: netdev@vger.kernel.org
+Cc: bpf@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/Kconfig | 2 +-
+ arch/mips/net/ebpf_jit.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/mips/Kconfig
++++ b/arch/mips/Kconfig
+@@ -46,7 +46,7 @@ config MIPS
+ select HAVE_ARCH_TRACEHOOK
+ select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES
+ select HAVE_ASM_MODVERSIONS
+- select HAVE_EBPF_JIT if (64BIT && !CPU_MICROMIPS)
++ select HAVE_EBPF_JIT if 64BIT && !CPU_MICROMIPS && TARGET_ISA_REV >= 2
+ select HAVE_CONTEXT_TRACKING
+ select HAVE_COPY_THREAD_TLS
+ select HAVE_C_RECORDMCOUNT
+--- a/arch/mips/net/ebpf_jit.c
++++ b/arch/mips/net/ebpf_jit.c
+@@ -1803,7 +1803,7 @@ struct bpf_prog *bpf_int_jit_compile(str
+ unsigned int image_size;
+ u8 *image_ptr;
+
+- if (!prog->jit_requested || MIPS_ISA_REV < 2)
++ if (!prog->jit_requested)
+ return prog;
+
+ tmp = bpf_jit_blind_constants(prog);
netfilter-nft_tproxy-fix-port-selector-on-big-endian.patch
block-add-bio_truncate-to-fix-guard_bio_eod.patch
mm-drop-mmap_sem-before-calling-balance_dirty_pages-.patch
+alsa-ice1724-fix-sleep-in-atomic-in-infrasonic-quartet-support-code.patch
+alsa-usb-audio-fix-set_format-altsetting-sanity-check.patch
+alsa-usb-audio-set-the-interface-format-after-resume-on-dell-wd19.patch
+alsa-hda-apply-sync-write-workaround-to-old-intel-platforms-too.patch
+alsa-hda-realtek-add-headset-mic-no-shutup-for-alc283.patch
+drm-sun4i-hdmi-remove-duplicate-cleanup-calls.patch
+drm-amdgpu-smu-add-metrics-table-lock.patch
+drm-amdgpu-smu-add-metrics-table-lock-for-arcturus-v2.patch
+drm-amdgpu-smu-add-metrics-table-lock-for-navi-v2.patch
+drm-amdgpu-smu-add-metrics-table-lock-for-vega20-v2.patch
+mips-bpf-disable-mips32-ebpf-jit.patch
+mips-bpf-ebpf-jit-check-for-mips-isa-compliance-in-kconfig.patch
+mips-avoid-vdso-abi-breakage-due-to-global-register-variable.patch
+media-pulse8-cec-fix-lost-cec_transmit_attempt_done-call.patch
+media-cec-cec-2.0-only-bcast-messages-were-ignored.patch
+media-cec-avoid-decrementing-transmit_queue_sz-if-it-is-0.patch
+media-cec-check-transmit_in_progress-not-transmitting.patch