--- /dev/null
+From ecb9c790999fd6c5af0f44783bd0217f0b89ec2b Mon Sep 17 00:00:00 2001
+From: Jan Engelhardt <jengelh@inai.de>
+Date: Thu, 5 Mar 2020 13:24:25 +0100
+Subject: acpi/x86: ignore unspecified bit positions in the ACPI global lock field
+
+From: Jan Engelhardt <jengelh@inai.de>
+
+commit ecb9c790999fd6c5af0f44783bd0217f0b89ec2b upstream.
+
+The value in "new" is constructed from "old" such that all bits defined
+as reserved by the ACPI spec[1] are left untouched. But if those bits
+do not happen to be all zero, "new < 3" will not evaluate to true.
+
+The firmware of the laptop(s) Medion MD63490 / Akoya P15648 comes with
+garbage inside the "FACS" ACPI table. The starting value is
+old=0x4944454d, therefore new=0x4944454e, which is >= 3. Mask off
+the reserved bits.
+
+[1] https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206553
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Jan Engelhardt <jengelh@inai.de>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/acpi/boot.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/acpi/boot.c
++++ b/arch/x86/kernel/acpi/boot.c
+@@ -1752,7 +1752,7 @@ int __acpi_acquire_global_lock(unsigned
+ new = (((old & ~0x3) + 2) + ((old >> 1) & 0x1));
+ val = cmpxchg(lock, old, new);
+ } while (unlikely (val != old));
+- return (new < 3) ? -1 : 0;
++ return ((new & 0x3) < 3) ? -1 : 0;
+ }
+
+ int __acpi_release_global_lock(unsigned int *lock)
--- /dev/null
+From f128090491c3f5aacef91a863f8c52abf869c436 Mon Sep 17 00:00:00 2001
+From: Thomas Hebb <tommyhebb@gmail.com>
+Date: Mon, 30 Mar 2020 12:09:37 -0400
+Subject: ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256
+
+From: Thomas Hebb <tommyhebb@gmail.com>
+
+commit f128090491c3f5aacef91a863f8c52abf869c436 upstream.
+
+This codec (among others) has a hidden set of audio routes, apparently
+designed to allow PC Beep output without a mixer widget on the output
+path, which are controlled by an undocumented Realtek vendor register.
+The default configuration of these routes means that certain inputs
+aren't accessible, necessitating driver control of the register.
+However, Realtek has provided no documentation of the register, instead
+opting to fix issues by providing magic numbers, most of which have been
+at least somewhat erroneous. These magic numbers then get copied by
+others into model-specific fixups, leading to a fragmented and buggy set
+of configurations.
+
+To get out of this situation, I've reverse engineered the register by
+flipping bits and observing how the codec's behavior changes. This
+commit documents my findings. It does not change any code.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
+Link: https://lore.kernel.org/r/bd69dfdeaf40ff31c4b7b797c829bb320031739c.1585584498.git.tommyhebb@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/sound/hd-audio/index.rst | 1
+ Documentation/sound/hd-audio/realtek-pc-beep.rst | 129 +++++++++++++++++++++++
+ 2 files changed, 130 insertions(+)
+
+--- a/Documentation/sound/hd-audio/index.rst
++++ b/Documentation/sound/hd-audio/index.rst
+@@ -8,3 +8,4 @@ HD-Audio
+ models
+ controls
+ dp-mst
++ realtek-pc-beep
+--- /dev/null
++++ b/Documentation/sound/hd-audio/realtek-pc-beep.rst
+@@ -0,0 +1,129 @@
++===============================
++Realtek PC Beep Hidden Register
++===============================
++
++This file documents the "PC Beep Hidden Register", which is present in certain
++Realtek HDA codecs and controls a muxer and pair of passthrough mixers that can
++route audio between pins but aren't themselves exposed as HDA widgets. As far
++as I can tell, these hidden routes are designed to allow flexible PC Beep output
++for codecs that don't have mixer widgets in their output paths. Why it's easier
++to hide a mixer behind an undocumented vendor register than to just expose it
++as a widget, I have no idea.
++
++Register Description
++====================
++
++The register is accessed via processing coefficient 0x36 on NID 20h. Bits not
++identified below have no discernible effect on my machine, a Dell XPS 13 9350::
++
++ MSB LSB
++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
++ | |h|S|L| | B |R| | Known bits
++ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
++ |0|0|1|1| 0x7 |0|0x0|1| 0x7 | Reset value
++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
++
++1Ah input select (B): 2 bits
++ When zero, expose the PC Beep line (from the internal beep generator, when
++ enabled with the Set Beep Generation verb on NID 01h, or else from the
++ external PCBEEP pin) on the 1Ah pin node. When nonzero, expose the headphone
++ jack (or possibly Line In on some machines) input instead. If PC Beep is
++ selected, the 1Ah boost control has no effect.
++
++Amplify 1Ah loopback, left (L): 1 bit
++ Amplify the left channel of 1Ah before mixing it into outputs as specified
++ by h and S bits. Does not affect the level of 1Ah exposed to other widgets.
++
++Amplify 1Ah loopback, right (R): 1 bit
++ Amplify the right channel of 1Ah before mixing it into outputs as specified
++ by h and S bits. Does not affect the level of 1Ah exposed to other widgets.
++
++Loopback 1Ah to 21h [active low] (h): 1 bit
++ When zero, mix 1Ah (possibly with amplification, depending on L and R bits)
++ into 21h (headphone jack on my machine). Mixed signal respects the mute
++ setting on 21h.
++
++Loopback 1Ah to 14h (S): 1 bit
++ When one, mix 1Ah (possibly with amplification, depending on L and R bits)
++ into 14h (internal speaker on my machine). Mixed signal **ignores** the mute
++ setting on 14h and is present whenever 14h is configured as an output.
++
++Path diagrams
++=============
++
++1Ah input selection (DIV is the PC Beep divider set on NID 01h)::
++
++ <Beep generator> <PCBEEP pin> <Headphone jack>
++ | | |
++ +--DIV--+--!DIV--+ {1Ah boost control}
++ | |
++ +--(b == 0)--+--(b != 0)--+
++ |
++ >1Ah (Beep/Headphone Mic/Line In)<
++
++Loopback of 1Ah to 21h/14h::
++
++ <1Ah (Beep/Headphone Mic/Line In)>
++ |
++ {amplify if L/R}
++ |
++ +-----!h-----+-----S-----+
++ | |
++ {21h mute control} |
++ | |
++ >21h (Headphone)< >14h (Internal Speaker)<
++
++Background
++==========
++
++All Realtek HDA codecs have a vendor-defined widget with node ID 20h which
++provides access to a bank of registers that control various codec functions.
++Registers are read and written via the standard HDA processing coefficient
++verbs (Set/Get Coefficient Index, Set/Get Processing Coefficient). The node is
++named "Realtek Vendor Registers" in public datasheets' verb listings and,
++apart from that, is entirely undocumented.
++
++This particular register, exposed at coefficient 0x36 and named in commits from
++Realtek, is of note: unlike most registers, which seem to control detailed
++amplifier parameters not in scope of the HDA specification, it controls audio
++routing which could just as easily have been defined using standard HDA mixer
++and selector widgets.
++
++Specifically, it selects between two sources for the input pin widget with Node
++ID (NID) 1Ah: the widget's signal can come either from an audio jack (on my
++laptop, a Dell XPS 13 9350, it's the headphone jack, but comments in Realtek
++commits indicate that it might be a Line In on some machines) or from the PC
++Beep line (which is itself multiplexed between the codec's internal beep
++generator and external PCBEEP pin, depending on if the beep generator is
++enabled via verbs on NID 01h). Additionally, it can mix (with optional
++amplification) that signal onto the 21h and/or 14h output pins.
++
++The register's reset value is 0x3717, corresponding to PC Beep on 1Ah that is
++then amplified and mixed into both the headphones and the speakers. Not only
++does this violate the HDA specification, which says that "[a vendor defined
++beep input pin] connection may be maintained *only* while the Link reset
++(**RST#**) is asserted", it means that we cannot ignore the register if we care
++about the input that 1Ah would otherwise expose or if the PCBEEP trace is
++poorly shielded and picks up chassis noise (both of which are the case on my
++machine).
++
++Unfortunately, there are lots of ways to get this register configuration wrong.
++Linux, it seems, has gone through most of them. For one, the register resets
++after S3 suspend: judging by existing code, this isn't the case for all vendor
++registers, and it's led to some fixes that improve behavior on cold boot but
++don't last after suspend. Other fixes have successfully switched the 1Ah input
++away from PC Beep but have failed to disable both loopback paths. On my
++machine, this means that the headphone input is amplified and looped back to
++the headphone output, which uses the exact same pins! As you might expect, this
++causes terrible headphone noise, the character of which is controlled by the
++1Ah boost control. (If you've seen instructions online to fix XPS 13 headphone
++noise by changing "Headphone Mic Boost" in ALSA, now you know why.)
++
++The information here has been obtained through black-box reverse engineering of
++the ALC256 codec's behavior and is not guaranteed to be correct. It likely
++also applies for the ALC255, ALC257, ALC235, and ALC236, since those codecs
++seem to be close relatives of the ALC256. (They all share one initialization
++function.) Additionally, other codecs like the ALC225 and ALC285 also have this
++register, judging by existing fixups in ``patch_realtek.c``, but specific
++data (e.g. node IDs, bit positions, pin mappings) for those codecs may differ
++from what I've described here.
--- /dev/null
+From 3c6fd1f07ed03a04debbb9a9d782205f1ef5e2ab Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 8 Apr 2020 16:04:49 +0200
+Subject: ALSA: hda: Add driver blacklist
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 3c6fd1f07ed03a04debbb9a9d782205f1ef5e2ab upstream.
+
+The recent AMD platform exposes an HD-audio bus but without any actual
+codecs, which is internally tied with a USB-audio device, supposedly.
+It results in "no codecs" error of HD-audio bus driver, and it's
+nothing but a waste of resources.
+
+This patch introduces a static blacklist table for skipping such a
+known bogus PCI SSID entry. As of writing this patch, the known SSIDs
+are:
+* 1043:874f - ASUS ROG Zenith II / Strix
+* 1462:cb59 - MSI TRX40 Creator
+* 1462:cb60 - MSI TRX40
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206543
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200408140449.22319-2-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 | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -2219,6 +2219,17 @@ static const struct hdac_io_ops pci_hda_
+ .dma_free_pages = dma_free_pages,
+ };
+
++/* Blacklist for skipping the whole probe:
++ * some HD-audio PCI entries are exposed without any codecs, and such devices
++ * should be ignored from the beginning.
++ */
++static const struct snd_pci_quirk driver_blacklist[] = {
++ SND_PCI_QUIRK(0x1043, 0x874f, "ASUS ROG Zenith II / Strix", 0),
++ SND_PCI_QUIRK(0x1462, 0xcb59, "MSI TRX40 Creator", 0),
++ SND_PCI_QUIRK(0x1462, 0xcb60, "MSI TRX40", 0),
++ {}
++};
++
+ static const struct hda_controller_ops pci_hda_ops = {
+ .disable_msi_reset_irq = disable_msi_reset_irq,
+ .substream_alloc_pages = substream_alloc_pages,
+@@ -2238,6 +2249,11 @@ static int azx_probe(struct pci_dev *pci
+ bool schedule_probe;
+ int err;
+
++ if (snd_pci_quirk_lookup(pci, driver_blacklist)) {
++ dev_info(&pci->dev, "Skipping the blacklisted device\n");
++ return -ENODEV;
++ }
++
+ if (dev >= SNDRV_CARDS)
+ return -ENODEV;
+ if (!enable[dev]) {
--- /dev/null
+From 0ad3f0b384d58f3bd1f4fb87d0af5b8f6866f41a Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 7 Apr 2020 10:44:01 +0200
+Subject: ALSA: hda: Fix potential access overflow in beep helper
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 0ad3f0b384d58f3bd1f4fb87d0af5b8f6866f41a upstream.
+
+The beep control helper function blindly stores the values in two
+stereo channels no matter whether the actual control is mono or
+stereo. This is practically harmless, but it annoys the recently
+introduced sanity check, resulting in an error when the checker is
+enabled.
+
+This patch corrects the behavior to store only on the defined array
+member.
+
+Fixes: 0401e8548eac ("ALSA: hda - Move beep helper functions to hda_beep.c")
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207139
+Reviewed-by: Jaroslav Kysela <perex@perex.cz>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200407084402.25589-2-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/hda_beep.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/sound/pci/hda/hda_beep.c
++++ b/sound/pci/hda/hda_beep.c
+@@ -297,8 +297,12 @@ int snd_hda_mixer_amp_switch_get_beep(st
+ {
+ struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+ struct hda_beep *beep = codec->beep;
++ int chs = get_amp_channels(kcontrol);
++
+ if (beep && (!beep->enabled || !ctl_has_mute(kcontrol))) {
+- ucontrol->value.integer.value[0] =
++ if (chs & 1)
++ ucontrol->value.integer.value[0] = beep->enabled;
++ if (chs & 2)
+ ucontrol->value.integer.value[1] = beep->enabled;
+ return 0;
+ }
--- /dev/null
+From 1d3aa4a5516d2e4933fe3cca11d3349ef63bc547 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 8 Apr 2020 15:56:45 +0200
+Subject: ALSA: hda/realtek - Add quirk for MSI GL63
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 1d3aa4a5516d2e4933fe3cca11d3349ef63bc547 upstream.
+
+MSI GL63 laptop requires the similar quirk like other MSI models,
+ALC1220_FIXUP_CLEVO_P950. The board BIOS doesn't provide a PCI SSID
+for the device, hence we need to take the codec SSID (1462:1275)
+instead.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207157
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200408135645.21896-1-tiwai@suse.de
+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
+@@ -2441,6 +2441,7 @@ static const struct snd_pci_quirk alc882
+ SND_PCI_QUIRK(0x1458, 0xa0b8, "Gigabyte AZ370-Gaming", ALC1220_FIXUP_GB_DUAL_CODECS),
+ SND_PCI_QUIRK(0x1458, 0xa0cd, "Gigabyte X570 Aorus Master", ALC1220_FIXUP_CLEVO_P950),
+ SND_PCI_QUIRK(0x1462, 0x1228, "MSI-GP63", ALC1220_FIXUP_CLEVO_P950),
++ SND_PCI_QUIRK(0x1462, 0x1275, "MSI-GL63", ALC1220_FIXUP_CLEVO_P950),
+ SND_PCI_QUIRK(0x1462, 0x1276, "MSI-GL73", ALC1220_FIXUP_CLEVO_P950),
+ SND_PCI_QUIRK(0x1462, 0x1293, "MSI-GP65", ALC1220_FIXUP_CLEVO_P950),
+ SND_PCI_QUIRK(0x1462, 0x7350, "MSI-7350", ALC889_FIXUP_CD),
--- /dev/null
+From f36938aa7440f46a0a365f1cfde5f5985af2bef3 Mon Sep 17 00:00:00 2001
+From: Thomas Hebb <tommyhebb@gmail.com>
+Date: Mon, 30 Mar 2020 12:09:39 -0400
+Subject: ALSA: hda/realtek - Remove now-unnecessary XPS 13 headphone noise fixups
+
+From: Thomas Hebb <tommyhebb@gmail.com>
+
+commit f36938aa7440f46a0a365f1cfde5f5985af2bef3 upstream.
+
+patch_realtek.c has historically failed to properly configure the PC
+Beep Hidden Register for the ALC256 codec (among others). Depending on
+your kernel version, symptoms of this misconfiguration can range from
+chassis noise, picked up by a poorly-shielded PCBEEP trace, getting
+amplified and played on your internal speaker and/or headphones to loud
+feedback, which responds to the "Headphone Mic Boost" ALSA control,
+getting played through your headphones. For details of the problem, see
+the patch in this series titled "ALSA: hda/realtek - Set principled PC
+Beep configuration for ALC256", which fixes the configuration.
+
+These symptoms have been most noticed on the Dell XPS 13 9350 and 9360,
+popular laptops that use the ALC256. As a result, several model-specific
+fixups have been introduced to try and fix the problem, the most
+egregious of which locks the "Headphone Mic Boost" control as a hack to
+minimize noise from a feedback loop that shouldn't have been there in
+the first place.
+
+Now that the underlying issue has been fixed, remove all these fixups.
+Remaining fixups needed by the XPS 13 are all picked up by existing pin
+quirks.
+
+This change should, for the XPS 13 9350/9360
+
+ - Significantly increase volume and audio quality on headphones
+ - Eliminate headphone popping on suspend/resume
+ - Allow "Headphone Mic Boost" to be set again, making the headphone
+ jack fully usable as a microphone jack too.
+
+Fixes: 8c69729b4439 ("ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3")
+Fixes: 423cd785619a ("ALSA: hda - Fix headphone noise on Dell XPS 13 9360")
+Fixes: e4c9fd10eb21 ("ALSA: hda - Apply headphone noise quirk for another Dell XPS 13 variant")
+Fixes: 1099f48457d0 ("ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360")
+Cc: stable@vger.kernel.org
+Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
+Link: https://lore.kernel.org/r/b649a00edfde150cf6eebbb4390e15e0c2deb39a.1585584498.git.tommyhebb@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/sound/hd-audio/models.rst | 2 -
+ sound/pci/hda/patch_realtek.c | 34 --------------------------------
+ 2 files changed, 36 deletions(-)
+
+--- a/Documentation/sound/hd-audio/models.rst
++++ b/Documentation/sound/hd-audio/models.rst
+@@ -216,8 +216,6 @@ alc298-dell-aio
+ ALC298 fixups on Dell AIO machines
+ alc275-dell-xps
+ ALC275 fixups on Dell XPS models
+-alc256-dell-xps13
+- ALC256 fixups on Dell XPS13
+ lenovo-spk-noise
+ Workaround for speaker noise on Lenovo machines
+ lenovo-hotkey
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -5272,17 +5272,6 @@ static void alc271_hp_gate_mic_jack(stru
+ }
+ }
+
+-static void alc256_fixup_dell_xps_13_headphone_noise2(struct hda_codec *codec,
+- const struct hda_fixup *fix,
+- int action)
+-{
+- if (action != HDA_FIXUP_ACT_PRE_PROBE)
+- return;
+-
+- snd_hda_codec_amp_stereo(codec, 0x1a, HDA_INPUT, 0, HDA_AMP_VOLMASK, 1);
+- snd_hda_override_wcaps(codec, 0x1a, get_wcaps(codec, 0x1a) & ~AC_WCAP_IN_AMP);
+-}
+-
+ static void alc269_fixup_limit_int_mic_boost(struct hda_codec *codec,
+ const struct hda_fixup *fix,
+ int action)
+@@ -5674,8 +5663,6 @@ enum {
+ ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
+ ALC298_FIXUP_DELL_AIO_MIC_NO_PRESENCE,
+ ALC275_FIXUP_DELL_XPS,
+- ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE,
+- ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2,
+ ALC293_FIXUP_LENOVO_SPK_NOISE,
+ ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY,
+ ALC255_FIXUP_DELL_SPK_NOISE,
+@@ -6387,23 +6374,6 @@ static const struct hda_fixup alc269_fix
+ {}
+ }
+ },
+- [ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE] = {
+- .type = HDA_FIXUP_VERBS,
+- .v.verbs = (const struct hda_verb[]) {
+- /* Disable pass-through path for FRONT 14h */
+- {0x20, AC_VERB_SET_COEF_INDEX, 0x36},
+- {0x20, AC_VERB_SET_PROC_COEF, 0x1737},
+- {}
+- },
+- .chained = true,
+- .chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE
+- },
+- [ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2] = {
+- .type = HDA_FIXUP_FUNC,
+- .v.func = alc256_fixup_dell_xps_13_headphone_noise2,
+- .chained = true,
+- .chain_id = ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE
+- },
+ [ALC293_FIXUP_LENOVO_SPK_NOISE] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_disable_aamix,
+@@ -6871,17 +6841,14 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x1028, 0x06de, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
+ SND_PCI_QUIRK(0x1028, 0x06df, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
+ SND_PCI_QUIRK(0x1028, 0x06e0, "Dell", ALC293_FIXUP_DISABLE_AAMIX_MULTIJACK),
+- SND_PCI_QUIRK(0x1028, 0x0704, "Dell XPS 13 9350", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2),
+ SND_PCI_QUIRK(0x1028, 0x0706, "Dell Inspiron 7559", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
+ SND_PCI_QUIRK(0x1028, 0x0725, "Dell Inspiron 3162", ALC255_FIXUP_DELL_SPK_NOISE),
+ SND_PCI_QUIRK(0x1028, 0x0738, "Dell Precision 5820", ALC269_FIXUP_NO_SHUTUP),
+- SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2),
+ SND_PCI_QUIRK(0x1028, 0x075c, "Dell XPS 27 7760", ALC298_FIXUP_SPK_VOLUME),
+ SND_PCI_QUIRK(0x1028, 0x075d, "Dell AIO", ALC298_FIXUP_SPK_VOLUME),
+ SND_PCI_QUIRK(0x1028, 0x07b0, "Dell Precision 7520", ALC295_FIXUP_DISABLE_DAC3),
+ SND_PCI_QUIRK(0x1028, 0x0798, "Dell Inspiron 17 7000 Gaming", ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
+ SND_PCI_QUIRK(0x1028, 0x080c, "Dell WYSE", ALC225_FIXUP_DELL_WYSE_MIC_NO_PRESENCE),
+- SND_PCI_QUIRK(0x1028, 0x082a, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE2),
+ SND_PCI_QUIRK(0x1028, 0x084b, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),
+ SND_PCI_QUIRK(0x1028, 0x084e, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),
+ SND_PCI_QUIRK(0x1028, 0x0871, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
+@@ -7232,7 +7199,6 @@ static const struct hda_model_fixup alc2
+ {.id = ALC298_FIXUP_DELL1_MIC_NO_PRESENCE, .name = "alc298-dell1"},
+ {.id = ALC298_FIXUP_DELL_AIO_MIC_NO_PRESENCE, .name = "alc298-dell-aio"},
+ {.id = ALC275_FIXUP_DELL_XPS, .name = "alc275-dell-xps"},
+- {.id = ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE, .name = "alc256-dell-xps13"},
+ {.id = ALC293_FIXUP_LENOVO_SPK_NOISE, .name = "lenovo-spk-noise"},
+ {.id = ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY, .name = "lenovo-hotkey"},
+ {.id = ALC255_FIXUP_DELL_SPK_NOISE, .name = "dell-spk-noise"},
--- /dev/null
+From c44737449468a0bdc50e09ec75e530f208391561 Mon Sep 17 00:00:00 2001
+From: Thomas Hebb <tommyhebb@gmail.com>
+Date: Mon, 30 Mar 2020 12:09:38 -0400
+Subject: ALSA: hda/realtek - Set principled PC Beep configuration for ALC256
+
+From: Thomas Hebb <tommyhebb@gmail.com>
+
+commit c44737449468a0bdc50e09ec75e530f208391561 upstream.
+
+The Realtek PC Beep Hidden Register[1] is currently set by
+patch_realtek.c in two different places:
+
+In alc_fill_eapd_coef(), it's set to the value 0x5757, corresponding to
+non-beep input on 1Ah and no 1Ah loopback to either headphones or
+speakers. (Although, curiously, the loopback amp is still enabled.) This
+write was added fairly recently by commit e3743f431143 ("ALSA:
+hda/realtek - Dell headphone has noise on unmute for ALC236") and is a
+safe default. However, it happens in the wrong place:
+alc_fill_eapd_coef() runs on module load and cold boot but not on S3
+resume, meaning the register loses its value after suspend.
+
+Conversely, in alc256_init(), the register is updated to unset bit 13
+(disable speaker loopback) and set bit 5 (set non-beep input on 1Ah).
+Although this write does run on S3 resume, it's not quite enough to fix
+up the register's default value of 0x3717. What's missing is a set of
+bit 14 to disable headphone loopback. Without that, we end up with a
+feedback loop where the headphone jack is being driven by amplified
+samples of itself[2].
+
+This change eliminates the update in alc256_init() and replaces it with
+the 0x5757 write from alc_fill_eapd_coef(). Kailang says that 0x5757 is
+supposed to be the codec's default value, so using it will make
+debugging easier for Realtek.
+
+Affects the ALC255, ALC256, ALC257, ALC235, and ALC236 codecs.
+
+[1] Newly documented in Documentation/sound/hd-audio/realtek-pc-beep.rst
+
+[2] Setting the "Headphone Mic Boost" control from userspace changes
+this feedback loop and has been a widely-shared workaround for headphone
+noise on laptops like the Dell XPS 13 9350. This commit eliminates the
+feedback loop and makes the workaround unnecessary.
+
+Fixes: e1e8c1fdce8b ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236")
+Cc: stable@vger.kernel.org
+Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
+Link: https://lore.kernel.org/r/bf22b417d1f2474b12011c2a39ed6cf8b06d3bf5.1585584498.git.tommyhebb@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_realtek.c | 15 +++++++++------
+ 1 file changed, 9 insertions(+), 6 deletions(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -379,7 +379,9 @@ static void alc_fill_eapd_coef(struct hd
+ case 0x10ec0215:
+ case 0x10ec0233:
+ case 0x10ec0235:
++ case 0x10ec0236:
+ case 0x10ec0255:
++ case 0x10ec0256:
+ case 0x10ec0257:
+ case 0x10ec0282:
+ case 0x10ec0283:
+@@ -391,11 +393,6 @@ static void alc_fill_eapd_coef(struct hd
+ case 0x10ec0300:
+ alc_update_coef_idx(codec, 0x10, 1<<9, 0);
+ break;
+- case 0x10ec0236:
+- case 0x10ec0256:
+- alc_write_coef_idx(codec, 0x36, 0x5757);
+- alc_update_coef_idx(codec, 0x10, 1<<9, 0);
+- break;
+ case 0x10ec0275:
+ alc_update_coef_idx(codec, 0xe, 0, 1<<0);
+ break;
+@@ -3249,7 +3246,13 @@ static void alc256_init(struct hda_codec
+ alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */
+ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 1 << 15); /* Clear bit */
+ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 0 << 15);
+- alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/
++ /*
++ * Expose headphone mic (or possibly Line In on some machines) instead
++ * of PC Beep on 1Ah, and disable 1Ah loopback for all outputs. See
++ * Documentation/sound/hd-audio/realtek-pc-beep.rst for details of
++ * this register.
++ */
++ alc_write_coef_idx(codec, 0x36, 0x5757);
+ }
+
+ static void alc256_shutup(struct hda_codec *codec)
--- /dev/null
+From c47914c00be346bc5b48c48de7b0da5c2d1a296c Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 7 Apr 2020 10:44:02 +0200
+Subject: ALSA: ice1724: Fix invalid access for enumerated ctl items
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit c47914c00be346bc5b48c48de7b0da5c2d1a296c upstream.
+
+The access to Analog Capture Source control value implemented in
+prodigy_hifi.c is wrong, as caught by the recently introduced sanity
+check; it should be accessing value.enumerated.item[] instead of
+value.integer.value[]. This patch corrects the wrong access pattern.
+
+Fixes: 6b8d6e5518e2 ("[ALSA] ICE1724: Added support for Audiotrak Prodigy 7.1 HiFi & HD2, Hercules Fortissimo IV")
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207139
+Reviewed-by: Jaroslav Kysela <perex@perex.cz>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200407084402.25589-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/ice1712/prodigy_hifi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/ice1712/prodigy_hifi.c
++++ b/sound/pci/ice1712/prodigy_hifi.c
+@@ -550,7 +550,7 @@ static int wm_adc_mux_enum_get(struct sn
+ struct snd_ice1712 *ice = snd_kcontrol_chip(kcontrol);
+
+ mutex_lock(&ice->gpio_mutex);
+- ucontrol->value.integer.value[0] = wm_get(ice, WM_ADC_MUX) & 0x1f;
++ ucontrol->value.enumerated.item[0] = wm_get(ice, WM_ADC_MUX) & 0x1f;
+ mutex_unlock(&ice->gpio_mutex);
+ return 0;
+ }
+@@ -564,7 +564,7 @@ static int wm_adc_mux_enum_put(struct sn
+
+ mutex_lock(&ice->gpio_mutex);
+ oval = wm_get(ice, WM_ADC_MUX);
+- nval = (oval & 0xe0) | ucontrol->value.integer.value[0];
++ nval = (oval & 0xe0) | ucontrol->value.enumerated.item[0];
+ if (nval != oval) {
+ wm_put(ice, WM_ADC_MUX, nval);
+ change = 1;
--- /dev/null
+From ae769d3556644888c964635179ef192995f40793 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 3 Apr 2020 09:25:15 +0200
+Subject: ALSA: pcm: oss: Fix regression by buffer overflow fix
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit ae769d3556644888c964635179ef192995f40793 upstream.
+
+The recent fix for the OOB access in PCM OSS plugins (commit
+f2ecf903ef06: "ALSA: pcm: oss: Avoid plugin buffer overflow") caused a
+regression on OSS applications. The patch introduced the size check
+in client and slave size calculations to limit to each plugin's buffer
+size, but I overlooked that some code paths call those without
+allocating the buffer but just for estimation.
+
+This patch fixes the bug by skipping the size check for those code
+paths while keeping checking in the actual transfer calls.
+
+Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
+Tested-and-reported-by: Jari Ruusu <jari.ruusu@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200403072515.25539-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/oss/pcm_plugin.c | 32 ++++++++++++++++++++++++--------
+ 1 file changed, 24 insertions(+), 8 deletions(-)
+
+--- a/sound/core/oss/pcm_plugin.c
++++ b/sound/core/oss/pcm_plugin.c
+@@ -196,7 +196,9 @@ int snd_pcm_plugin_free(struct snd_pcm_p
+ return 0;
+ }
+
+-snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t drv_frames)
++static snd_pcm_sframes_t plug_client_size(struct snd_pcm_substream *plug,
++ snd_pcm_uframes_t drv_frames,
++ bool check_size)
+ {
+ struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next;
+ int stream;
+@@ -209,7 +211,7 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
+ if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ plugin = snd_pcm_plug_last(plug);
+ while (plugin && drv_frames > 0) {
+- if (drv_frames > plugin->buf_frames)
++ if (check_size && drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
+ plugin_prev = plugin->prev;
+ if (plugin->src_frames)
+@@ -222,7 +224,7 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
+ plugin_next = plugin->next;
+ if (plugin->dst_frames)
+ drv_frames = plugin->dst_frames(plugin, drv_frames);
+- if (drv_frames > plugin->buf_frames)
++ if (check_size && drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
+ plugin = plugin_next;
+ }
+@@ -231,7 +233,9 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
+ return drv_frames;
+ }
+
+-snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t clt_frames)
++static snd_pcm_sframes_t plug_slave_size(struct snd_pcm_substream *plug,
++ snd_pcm_uframes_t clt_frames,
++ bool check_size)
+ {
+ struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next;
+ snd_pcm_sframes_t frames;
+@@ -252,14 +256,14 @@ snd_pcm_sframes_t snd_pcm_plug_slave_siz
+ if (frames < 0)
+ return frames;
+ }
+- if (frames > plugin->buf_frames)
++ if (check_size && frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
+ plugin = plugin_next;
+ }
+ } else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
+ plugin = snd_pcm_plug_last(plug);
+ while (plugin) {
+- if (frames > plugin->buf_frames)
++ if (check_size && frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
+ plugin_prev = plugin->prev;
+ if (plugin->src_frames) {
+@@ -274,6 +278,18 @@ snd_pcm_sframes_t snd_pcm_plug_slave_siz
+ return frames;
+ }
+
++snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug,
++ snd_pcm_uframes_t drv_frames)
++{
++ return plug_client_size(plug, drv_frames, false);
++}
++
++snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug,
++ snd_pcm_uframes_t clt_frames)
++{
++ return plug_slave_size(plug, clt_frames, false);
++}
++
+ static int snd_pcm_plug_formats(const struct snd_mask *mask,
+ snd_pcm_format_t format)
+ {
+@@ -630,7 +646,7 @@ snd_pcm_sframes_t snd_pcm_plug_write_tra
+ src_channels = dst_channels;
+ plugin = next;
+ }
+- return snd_pcm_plug_client_size(plug, frames);
++ return plug_client_size(plug, frames, true);
+ }
+
+ snd_pcm_sframes_t snd_pcm_plug_read_transfer(struct snd_pcm_substream *plug, struct snd_pcm_plugin_channel *dst_channels_final, snd_pcm_uframes_t size)
+@@ -640,7 +656,7 @@ snd_pcm_sframes_t snd_pcm_plug_read_tran
+ snd_pcm_sframes_t frames = size;
+ int err;
+
+- frames = snd_pcm_plug_slave_size(plug, frames);
++ frames = plug_slave_size(plug, frames, true);
+ if (frames < 0)
+ return frames;
+
--- /dev/null
+From 2a48218f8e23d47bd3e23cfdfb8aa9066f7dc3e6 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 8 Apr 2020 16:04:48 +0200
+Subject: ALSA: usb-audio: Add mixer workaround for TRX40 and co
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 2a48218f8e23d47bd3e23cfdfb8aa9066f7dc3e6 upstream.
+
+Some recent boards (supposedly with a new AMD platform) contain the
+USB audio class 2 device that is often tied with HD-audio. The device
+exposes an Input Gain Pad control (id=19, control=12) but this node
+doesn't behave correctly, returning an error for each inquiry of
+GET_MIN and GET_MAX that should have been mandatory.
+
+As a workaround, simply ignore this node by adding a usbmix_name_map
+table entry. The currently known devices are:
+* 0414:a002 - Gigabyte TRX40 Aorus Pro WiFi
+* 0b05:1916 - ASUS ROG Zenith II
+* 0b05:1917 - ASUS ROG Strix
+* 0db0:0d64 - MSI TRX40 Creator
+* 0db0:543d - MSI TRX40
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206543
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200408140449.22319-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/mixer_maps.c | 28 ++++++++++++++++++++++++++++
+ 1 file changed, 28 insertions(+)
+
+--- a/sound/usb/mixer_maps.c
++++ b/sound/usb/mixer_maps.c
+@@ -363,6 +363,14 @@ static const struct usbmix_name_map dell
+ { 0 }
+ };
+
++/* Some mobos shipped with a dummy HD-audio show the invalid GET_MIN/GET_MAX
++ * response for Input Gain Pad (id=19, control=12). Skip it.
++ */
++static const struct usbmix_name_map asus_rog_map[] = {
++ { 19, NULL, 12 }, /* FU, Input Gain Pad */
++ {}
++};
++
+ /*
+ * Control map entries
+ */
+@@ -482,6 +490,26 @@ static struct usbmix_ctl_map usbmix_ctl_
+ .id = USB_ID(0x05a7, 0x1020),
+ .map = bose_companion5_map,
+ },
++ { /* Gigabyte TRX40 Aorus Pro WiFi */
++ .id = USB_ID(0x0414, 0xa002),
++ .map = asus_rog_map,
++ },
++ { /* ASUS ROG Zenith II */
++ .id = USB_ID(0x0b05, 0x1916),
++ .map = asus_rog_map,
++ },
++ { /* ASUS ROG Strix */
++ .id = USB_ID(0x0b05, 0x1917),
++ .map = asus_rog_map,
++ },
++ { /* MSI TRX40 Creator */
++ .id = USB_ID(0x0db0, 0x0d64),
++ .map = asus_rog_map,
++ },
++ { /* MSI TRX40 */
++ .id = USB_ID(0x0db0, 0x543d),
++ .map = asus_rog_map,
++ },
+ { 0 } /* terminator */
+ };
+
--- /dev/null
+From 968ae2caad0782db5dbbabb560d3cdefd2945d38 Mon Sep 17 00:00:00 2001
+From: Remi Pommarel <repk@triplefau.lt>
+Date: Sat, 29 Feb 2020 17:13:47 +0100
+Subject: ath9k: Handle txpower changes even when TPC is disabled
+
+From: Remi Pommarel <repk@triplefau.lt>
+
+commit 968ae2caad0782db5dbbabb560d3cdefd2945d38 upstream.
+
+When TPC is disabled IEEE80211_CONF_CHANGE_POWER event can be handled to
+reconfigure HW's maximum txpower.
+
+This fixes 0dBm txpower setting when user attaches to an interface for
+the first time with the following scenario:
+
+ieee80211_do_open()
+ ath9k_add_interface()
+ ath9k_set_txpower() /* Set TX power with not yet initialized
+ sc->hw->conf.power_level */
+
+ ieee80211_hw_config() /* Iniatilize sc->hw->conf.power_level and
+ raise IEEE80211_CONF_CHANGE_POWER */
+
+ ath9k_config() /* IEEE80211_CONF_CHANGE_POWER is ignored */
+
+This issue can be reproduced with the following:
+
+ $ modprobe -r ath9k
+ $ modprobe ath9k
+ $ wpa_supplicant -i wlan0 -c /tmp/wpa.conf &
+ $ iw dev /* Here TX power is either 0 or 3 depending on RF chain */
+ $ killall wpa_supplicant
+ $ iw dev /* TX power goes back to calibrated value and subsequent
+ calls will be fine */
+
+Fixes: 283dd11994cde ("ath9k: add per-vif TX power capability")
+Cc: stable@vger.kernel.org
+Signed-off-by: Remi Pommarel <repk@triplefau.lt>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/ath/ath9k/main.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/wireless/ath/ath9k/main.c
++++ b/drivers/net/wireless/ath/ath9k/main.c
+@@ -1457,6 +1457,9 @@ static int ath9k_config(struct ieee80211
+ ath_chanctx_set_channel(sc, ctx, &hw->conf.chandef);
+ }
+
++ if (changed & IEEE80211_CONF_CHANGE_POWER)
++ ath9k_set_txpower(sc, NULL);
++
+ mutex_unlock(&sc->mutex);
+ ath9k_ps_restore(sc);
+
--- /dev/null
+From 6a214a28132f19ace3d835a6d8f6422ec80ad200 Mon Sep 17 00:00:00 2001
+From: Sungbo Eo <mans0n@gorani.run>
+Date: Sat, 21 Mar 2020 22:38:42 +0900
+Subject: irqchip/versatile-fpga: Apply clear-mask earlier
+
+From: Sungbo Eo <mans0n@gorani.run>
+
+commit 6a214a28132f19ace3d835a6d8f6422ec80ad200 upstream.
+
+Clear its own IRQs before the parent IRQ get enabled, so that the
+remaining IRQs do not accidentally interrupt the parent IRQ controller.
+
+This patch also fixes a reboot bug on OX820 SoC, where the remaining
+rps-timer IRQ raises a GIC interrupt that is left pending. After that,
+the rps-timer IRQ is cleared during driver initialization, and there's
+no IRQ left in rps-irq when local_irq_enable() is called, which evokes
+an error message "unexpected IRQ trap".
+
+Fixes: bdd272cbb97a ("irqchip: versatile FPGA: support cascaded interrupts from DT")
+Signed-off-by: Sungbo Eo <mans0n@gorani.run>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200321133842.2408823-1-mans0n@gorani.run
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/irqchip/irq-versatile-fpga.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/irqchip/irq-versatile-fpga.c
++++ b/drivers/irqchip/irq-versatile-fpga.c
+@@ -212,6 +212,9 @@ int __init fpga_irq_of_init(struct devic
+ if (of_property_read_u32(node, "valid-mask", &valid_mask))
+ valid_mask = 0;
+
++ writel(clear_mask, base + IRQ_ENABLE_CLEAR);
++ writel(clear_mask, base + FIQ_ENABLE_CLEAR);
++
+ /* Some chips are cascaded from a parent IRQ */
+ parent_irq = irq_of_parse_and_map(node, 0);
+ if (!parent_irq) {
+@@ -221,9 +224,6 @@ int __init fpga_irq_of_init(struct devic
+
+ fpga_irq_init(base, node->name, 0, parent_irq, valid_mask, node);
+
+- writel(clear_mask, base + IRQ_ENABLE_CLEAR);
+- writel(clear_mask, base + FIQ_ENABLE_CLEAR);
+-
+ /*
+ * On Versatile AB/PB, some secondary interrupts have a direct
+ * pass-thru to the primary controller for IRQs 20 and 22-31 which need
--- /dev/null
+From 2e356101e72ab1361821b3af024d64877d9a798d Mon Sep 17 00:00:00 2001
+From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
+Date: Fri, 28 Feb 2020 12:41:51 +0800
+Subject: KEYS: reaching the keys quotas correctly
+
+From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
+
+commit 2e356101e72ab1361821b3af024d64877d9a798d upstream.
+
+Currently, when we add a new user key, the calltrace as below:
+
+add_key()
+ key_create_or_update()
+ key_alloc()
+ __key_instantiate_and_link
+ generic_key_instantiate
+ key_payload_reserve
+ ......
+
+Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
+we can reach max bytes/keys in key_alloc, but we forget to remove this
+limit when we reserver space for payload in key_payload_reserve. So we
+can only reach max keys but not max bytes when having delta between plen
+and type->def_datalen. Remove this limit when instantiating the key, so we
+can keep consistent with key_alloc.
+
+Also, fix the similar problem in keyctl_chown_key().
+
+Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
+Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
+Cc: stable@vger.kernel.org # 5.0.x
+Cc: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
+Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Reviewed-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/keys/key.c | 2 +-
+ security/keys/keyctl.c | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/security/keys/key.c
++++ b/security/keys/key.c
+@@ -383,7 +383,7 @@ int key_payload_reserve(struct key *key,
+ spin_lock(&key->user->lock);
+
+ if (delta > 0 &&
+- (key->user->qnbytes + delta >= maxbytes ||
++ (key->user->qnbytes + delta > maxbytes ||
+ key->user->qnbytes + delta < key->user->qnbytes)) {
+ ret = -EDQUOT;
+ }
+--- a/security/keys/keyctl.c
++++ b/security/keys/keyctl.c
+@@ -882,8 +882,8 @@ long keyctl_chown_key(key_serial_t id, u
+ key_quota_root_maxbytes : key_quota_maxbytes;
+
+ spin_lock(&newowner->lock);
+- if (newowner->qnkeys + 1 >= maxkeys ||
+- newowner->qnbytes + key->quotalen >= maxbytes ||
++ if (newowner->qnkeys + 1 > maxkeys ||
++ newowner->qnbytes + key->quotalen > maxbytes ||
+ newowner->qnbytes + key->quotalen <
+ newowner->qnbytes)
+ goto quota_overrun;
--- /dev/null
+From 1db56284b9da9056093681f28db48a09a243274b Mon Sep 17 00:00:00 2001
+From: Benoit Parrot <bparrot@ti.com>
+Date: Mon, 2 Mar 2020 14:56:52 +0100
+Subject: media: ti-vpe: cal: fix disable_irqs to only the intended target
+
+From: Benoit Parrot <bparrot@ti.com>
+
+commit 1db56284b9da9056093681f28db48a09a243274b upstream.
+
+disable_irqs() was mistakenly disabling all interrupts when called.
+This cause all port stream to stop even if only stopping one of them.
+
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Benoit Parrot <bparrot@ti.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/platform/ti-vpe/cal.c | 16 ++++++++--------
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+--- a/drivers/media/platform/ti-vpe/cal.c
++++ b/drivers/media/platform/ti-vpe/cal.c
+@@ -541,16 +541,16 @@ static void enable_irqs(struct cal_ctx *
+
+ static void disable_irqs(struct cal_ctx *ctx)
+ {
++ u32 val;
++
+ /* Disable IRQ_WDMA_END 0/1 */
+- reg_write_field(ctx->dev,
+- CAL_HL_IRQENABLE_CLR(2),
+- CAL_HL_IRQ_CLEAR,
+- CAL_HL_IRQ_MASK(ctx->csi2_port));
++ val = 0;
++ set_field(&val, CAL_HL_IRQ_CLEAR, CAL_HL_IRQ_MASK(ctx->csi2_port));
++ reg_write(ctx->dev, CAL_HL_IRQENABLE_CLR(2), val);
+ /* Disable IRQ_WDMA_START 0/1 */
+- reg_write_field(ctx->dev,
+- CAL_HL_IRQENABLE_CLR(3),
+- CAL_HL_IRQ_CLEAR,
+- CAL_HL_IRQ_MASK(ctx->csi2_port));
++ val = 0;
++ set_field(&val, CAL_HL_IRQ_CLEAR, CAL_HL_IRQ_MASK(ctx->csi2_port));
++ reg_write(ctx->dev, CAL_HL_IRQENABLE_CLR(3), val);
+ /* Todo: Add VC_IRQ and CSI2_COMPLEXIO_IRQ handling */
+ reg_write(ctx->dev, CAL_CSI2_VC_IRQENABLE(1), 0);
+ }
--- /dev/null
+From 792a402c2840054533ef56279c212ef6da87d811 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Tue, 22 Jan 2019 14:18:42 -0600
+Subject: MIPS: OCTEON: irq: Fix potential NULL pointer dereference
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 792a402c2840054533ef56279c212ef6da87d811 upstream.
+
+There is a potential NULL pointer dereference in case kzalloc()
+fails and returns NULL.
+
+Fix this by adding a NULL check on *cd*
+
+This bug was detected with the help of Coccinelle.
+
+Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/cavium-octeon/octeon-irq.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/mips/cavium-octeon/octeon-irq.c
++++ b/arch/mips/cavium-octeon/octeon-irq.c
+@@ -2199,6 +2199,9 @@ static int octeon_irq_cib_map(struct irq
+ }
+
+ cd = kzalloc(sizeof(*cd), GFP_KERNEL);
++ if (!cd)
++ return -ENOMEM;
++
+ cd->host_data = host_data;
+ cd->bit = hw;
+
--- /dev/null
+From d191aaffe3687d1e73e644c185f5f0550ec242b5 Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhc@lemote.com>
+Date: Wed, 25 Mar 2020 11:44:54 +0800
+Subject: MIPS/tlbex: Fix LDDIR usage in setup_pw() for Loongson-3
+
+From: Huacai Chen <chenhc@lemote.com>
+
+commit d191aaffe3687d1e73e644c185f5f0550ec242b5 upstream.
+
+LDDIR/LDPTE is Loongson-3's acceleration for Page Table Walking. If BD
+(Base Directory, the 4th page directory) is not enabled, then GDOffset
+is biased by BadVAddr[63:62]. So, if GDOffset (aka. BadVAddr[47:36] for
+Loongson-3) is big enough, "0b11(BadVAddr[63:62])|BadVAddr[47:36]|...."
+can far beyond pg_swapper_dir. This means the pg_swapper_dir may NOT be
+accessed by LDDIR correctly, so fix it by set PWDirExt in CP0_PWCtl.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Pei Huang <huangpei@loongson.cn>
+Signed-off-by: Huacai Chen <chenhc@lemote.com>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/mm/tlbex.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/mips/mm/tlbex.c
++++ b/arch/mips/mm/tlbex.c
+@@ -1479,6 +1479,7 @@ static void build_r4000_tlb_refill_handl
+
+ static void setup_pw(void)
+ {
++ unsigned int pwctl;
+ unsigned long pgd_i, pgd_w;
+ #ifndef __PAGETABLE_PMD_FOLDED
+ unsigned long pmd_i, pmd_w;
+@@ -1505,6 +1506,7 @@ static void setup_pw(void)
+
+ pte_i = ilog2(_PAGE_GLOBAL);
+ pte_w = 0;
++ pwctl = 1 << 30; /* Set PWDirExt */
+
+ #ifndef __PAGETABLE_PMD_FOLDED
+ write_c0_pwfield(pgd_i << 24 | pmd_i << 12 | pt_i << 6 | pte_i);
+@@ -1515,8 +1517,9 @@ static void setup_pw(void)
+ #endif
+
+ #ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT
+- write_c0_pwctl(1 << 6 | psn);
++ pwctl |= (1 << 6 | psn);
+ #endif
++ write_c0_pwctl(pwctl);
+ write_c0_kpgd((long)swapper_pg_dir);
+ kscratch_used_mask |= (1 << 7); /* KScratch6 is used for KPGD */
+ }
--- /dev/null
+From 8c5c660529209a0e324c1c1a35ce3f83d67a2aa5 Mon Sep 17 00:00:00 2001
+From: James Smart <jsmart2021@gmail.com>
+Date: Fri, 3 Apr 2020 07:33:20 -0700
+Subject: nvme-fc: Revert "add module to ops template to allow module references"
+
+From: James Smart <jsmart2021@gmail.com>
+
+commit 8c5c660529209a0e324c1c1a35ce3f83d67a2aa5 upstream.
+
+The original patch was to resolve the lldd being able to be unloaded
+while being used to talk to the boot device of the system. However, the
+end result of the original patch is that any driver unload while a nvme
+controller is live via the lldd is now being prohibited. Given the module
+reference, the module teardown routine can't be called, thus there's no
+way, other than manual actions to terminate the controllers.
+
+Fixes: 863fbae929c7 ("nvme_fc: add module to ops template to allow module references")
+Cc: <stable@vger.kernel.org> # v5.4+
+Signed-off-by: James Smart <jsmart2021@gmail.com>
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/nvme/host/fc.c | 14 ++------------
+ drivers/nvme/target/fcloop.c | 1 -
+ drivers/scsi/lpfc/lpfc_nvme.c | 2 --
+ drivers/scsi/qla2xxx/qla_nvme.c | 1 -
+ include/linux/nvme-fc-driver.h | 4 ----
+ 5 files changed, 2 insertions(+), 20 deletions(-)
+
+--- a/drivers/nvme/host/fc.c
++++ b/drivers/nvme/host/fc.c
+@@ -342,8 +342,7 @@ nvme_fc_register_localport(struct nvme_f
+ !template->ls_req || !template->fcp_io ||
+ !template->ls_abort || !template->fcp_abort ||
+ !template->max_hw_queues || !template->max_sgl_segments ||
+- !template->max_dif_sgl_segments || !template->dma_boundary ||
+- !template->module) {
++ !template->max_dif_sgl_segments || !template->dma_boundary) {
+ ret = -EINVAL;
+ goto out_reghost_failed;
+ }
+@@ -1987,7 +1986,6 @@ nvme_fc_ctrl_free(struct kref *ref)
+ {
+ struct nvme_fc_ctrl *ctrl =
+ container_of(ref, struct nvme_fc_ctrl, ref);
+- struct nvme_fc_lport *lport = ctrl->lport;
+ unsigned long flags;
+
+ if (ctrl->ctrl.tagset) {
+@@ -2013,7 +2011,6 @@ nvme_fc_ctrl_free(struct kref *ref)
+ if (ctrl->ctrl.opts)
+ nvmf_free_options(ctrl->ctrl.opts);
+ kfree(ctrl);
+- module_put(lport->ops->module);
+ }
+
+ static void
+@@ -3055,15 +3052,10 @@ nvme_fc_init_ctrl(struct device *dev, st
+ goto out_fail;
+ }
+
+- if (!try_module_get(lport->ops->module)) {
+- ret = -EUNATCH;
+- goto out_free_ctrl;
+- }
+-
+ idx = ida_simple_get(&nvme_fc_ctrl_cnt, 0, 0, GFP_KERNEL);
+ if (idx < 0) {
+ ret = -ENOSPC;
+- goto out_mod_put;
++ goto out_free_ctrl;
+ }
+
+ ctrl->ctrl.opts = opts;
+@@ -3205,8 +3197,6 @@ out_free_queues:
+ out_free_ida:
+ put_device(ctrl->dev);
+ ida_simple_remove(&nvme_fc_ctrl_cnt, ctrl->cnum);
+-out_mod_put:
+- module_put(lport->ops->module);
+ out_free_ctrl:
+ kfree(ctrl);
+ out_fail:
+--- a/drivers/nvme/target/fcloop.c
++++ b/drivers/nvme/target/fcloop.c
+@@ -825,7 +825,6 @@ fcloop_targetport_delete(struct nvmet_fc
+ #define FCLOOP_DMABOUND_4G 0xFFFFFFFF
+
+ static struct nvme_fc_port_template fctemplate = {
+- .module = THIS_MODULE,
+ .localport_delete = fcloop_localport_delete,
+ .remoteport_delete = fcloop_remoteport_delete,
+ .create_queue = fcloop_create_queue,
+--- a/drivers/scsi/lpfc/lpfc_nvme.c
++++ b/drivers/scsi/lpfc/lpfc_nvme.c
+@@ -1903,8 +1903,6 @@ lpfc_nvme_fcp_abort(struct nvme_fc_local
+
+ /* Declare and initialization an instance of the FC NVME template. */
+ static struct nvme_fc_port_template lpfc_nvme_template = {
+- .module = THIS_MODULE,
+-
+ /* initiator-based functions */
+ .localport_delete = lpfc_nvme_localport_delete,
+ .remoteport_delete = lpfc_nvme_remoteport_delete,
+--- a/drivers/scsi/qla2xxx/qla_nvme.c
++++ b/drivers/scsi/qla2xxx/qla_nvme.c
+@@ -560,7 +560,6 @@ static void qla_nvme_remoteport_delete(s
+ }
+
+ static struct nvme_fc_port_template qla_nvme_fc_transport = {
+- .module = THIS_MODULE,
+ .localport_delete = qla_nvme_localport_delete,
+ .remoteport_delete = qla_nvme_remoteport_delete,
+ .create_queue = qla_nvme_alloc_queue,
+--- a/include/linux/nvme-fc-driver.h
++++ b/include/linux/nvme-fc-driver.h
+@@ -282,8 +282,6 @@ struct nvme_fc_remote_port {
+ *
+ * Host/Initiator Transport Entrypoints/Parameters:
+ *
+- * @module: The LLDD module using the interface
+- *
+ * @localport_delete: The LLDD initiates deletion of a localport via
+ * nvme_fc_deregister_localport(). However, the teardown is
+ * asynchronous. This routine is called upon the completion of the
+@@ -397,8 +395,6 @@ struct nvme_fc_remote_port {
+ * Value is Mandatory. Allowed to be zero.
+ */
+ struct nvme_fc_port_template {
+- struct module *module;
+-
+ /* initiator-based functions */
+ void (*localport_delete)(struct nvme_fc_local_port *);
+ void (*remoteport_delete)(struct nvme_fc_remote_port *);
--- /dev/null
+From c26aa572027d438de9cc311aaebcbe972f698c24 Mon Sep 17 00:00:00 2001
+From: James Smart <jsmart2021@gmail.com>
+Date: Tue, 3 Sep 2019 14:20:37 -0700
+Subject: nvme: Treat discovery subsystems as unique subsystems
+
+From: James Smart <jsmart2021@gmail.com>
+
+commit c26aa572027d438de9cc311aaebcbe972f698c24 upstream.
+
+Current code matches subnqn and collapses all controllers to the
+same subnqn to a single subsystem structure. This is good for
+recognizing multiple controllers for the same subsystem. But with
+the well-known discovery subnqn, the subsystems aren't truly the
+same subsystem. As such, subsystem specific rules, such as no
+overlap of controller id, do not apply. With today's behavior, the
+check for overlap of controller id can fail, preventing the new
+discovery controller from being created.
+
+When searching for like subsystem nqn, exclude the discovery nqn
+from matching. This will result in each discovery controller being
+attached to a unique subsystem structure.
+
+Signed-off-by: James Smart <jsmart2021@gmail.com>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
+Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/nvme/host/core.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/nvme/host/core.c
++++ b/drivers/nvme/host/core.c
+@@ -2200,6 +2200,17 @@ static struct nvme_subsystem *__nvme_fin
+
+ lockdep_assert_held(&nvme_subsystems_lock);
+
++ /*
++ * Fail matches for discovery subsystems. This results
++ * in each discovery controller bound to a unique subsystem.
++ * This avoids issues with validating controller values
++ * that can only be true when there is a single unique subsystem.
++ * There may be multiple and completely independent entities
++ * that provide discovery controllers.
++ */
++ if (!strcmp(subsysnqn, NVME_DISC_SUBSYS_NAME))
++ return NULL;
++
+ list_for_each_entry(subsys, &nvme_subsystems, entry) {
+ if (strcmp(subsys->subnqn, subsysnqn))
+ continue;
--- /dev/null
+From b88bf6c3b6ff77948c153cac4e564642b0b90632 Mon Sep 17 00:00:00 2001
+From: Sean V Kelley <sean.v.kelley@linux.intel.com>
+Date: Thu, 20 Feb 2020 11:29:29 -0800
+Subject: PCI: Add boot interrupt quirk mechanism for Xeon chipsets
+
+From: Sean V Kelley <sean.v.kelley@linux.intel.com>
+
+commit b88bf6c3b6ff77948c153cac4e564642b0b90632 upstream.
+
+The following was observed by Kar Hin Ong with RT patchset:
+
+ Backtrace:
+ irq 19: nobody cared (try booting with the "irqpoll" option)
+ CPU: 0 PID: 3329 Comm: irq/34-nipalk Tainted:4.14.87-rt49 #1
+ Hardware name: National Instruments NI PXIe-8880/NI PXIe-8880,
+ BIOS 2.1.5f1 01/09/2020
+ Call Trace:
+ <IRQ>
+ ? dump_stack+0x46/0x5e
+ ? __report_bad_irq+0x2e/0xb0
+ ? note_interrupt+0x242/0x290
+ ? nNIKAL100_memoryRead16+0x8/0x10 [nikal]
+ ? handle_irq_event_percpu+0x55/0x70
+ ? handle_irq_event+0x4f/0x80
+ ? handle_fasteoi_irq+0x81/0x180
+ ? handle_irq+0x1c/0x30
+ ? do_IRQ+0x41/0xd0
+ ? common_interrupt+0x84/0x84
+ </IRQ>
+ ...
+ handlers:
+ [<ffffffffb3297200>] irq_default_primary_handler threaded
+ [<ffffffffb3669180>] usb_hcd_irq
+ Disabling IRQ #19
+
+The problem being that this device is triggering boot interrupts
+due to threaded interrupt handling and masking of the IO-APIC. These
+boot interrupts are then forwarded on to the legacy PCH's PIRQ lines
+where there is no handler present for the device.
+
+Whenever a PCI device fires interrupt (INTx) to Pin 20 of IOAPIC 2
+(GSI 44), the kernel receives two interrupts:
+
+ 1. Interrupt from Pin 20 of IOAPIC 2 -> Expected
+ 2. Interrupt from Pin 19 of IOAPIC 1 -> UNEXPECTED
+
+Quirks for disabling boot interrupts (preferred) or rerouting the
+handler exist but do not address these Xeon chipsets' mechanism:
+https://lore.kernel.org/lkml/12131949181903-git-send-email-sassmann@suse.de/
+
+Add a new mechanism via PCI CFG for those chipsets supporting CIPINTRC
+register's dis_intx_rout2ich bit.
+
+Link: https://lore.kernel.org/r/20200220192930.64820-2-sean.v.kelley@linux.intel.com
+Reported-by: Kar Hin Ong <kar.hin.ong@ni.com>
+Tested-by: Kar Hin Ong <kar.hin.ong@ni.com>
+Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/quirks.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++-----
+ 1 file changed, 73 insertions(+), 7 deletions(-)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -1947,26 +1947,92 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_I
+ /*
+ * IO-APIC1 on 6300ESB generates boot interrupts, see Intel order no
+ * 300641-004US, section 5.7.3.
++ *
++ * Core IO on Xeon E5 1600/2600/4600, see Intel order no 326509-003.
++ * Core IO on Xeon E5 v2, see Intel order no 329188-003.
++ * Core IO on Xeon E7 v2, see Intel order no 329595-002.
++ * Core IO on Xeon E5 v3, see Intel order no 330784-003.
++ * Core IO on Xeon E7 v3, see Intel order no 332315-001US.
++ * Core IO on Xeon E5 v4, see Intel order no 333810-002US.
++ * Core IO on Xeon E7 v4, see Intel order no 332315-001US.
++ * Core IO on Xeon D-1500, see Intel order no 332051-001.
++ * Core IO on Xeon Scalable, see Intel order no 610950.
+ */
+-#define INTEL_6300_IOAPIC_ABAR 0x40
++#define INTEL_6300_IOAPIC_ABAR 0x40 /* Bus 0, Dev 29, Func 5 */
+ #define INTEL_6300_DISABLE_BOOT_IRQ (1<<14)
+
++#define INTEL_CIPINTRC_CFG_OFFSET 0x14C /* Bus 0, Dev 5, Func 0 */
++#define INTEL_CIPINTRC_DIS_INTX_ICH (1<<25)
++
+ static void quirk_disable_intel_boot_interrupt(struct pci_dev *dev)
+ {
+ u16 pci_config_word;
++ u32 pci_config_dword;
+
+ if (noioapicquirk)
+ return;
+
+- pci_read_config_word(dev, INTEL_6300_IOAPIC_ABAR, &pci_config_word);
+- pci_config_word |= INTEL_6300_DISABLE_BOOT_IRQ;
+- pci_write_config_word(dev, INTEL_6300_IOAPIC_ABAR, pci_config_word);
+-
++ switch (dev->device) {
++ case PCI_DEVICE_ID_INTEL_ESB_10:
++ pci_read_config_word(dev, INTEL_6300_IOAPIC_ABAR,
++ &pci_config_word);
++ pci_config_word |= INTEL_6300_DISABLE_BOOT_IRQ;
++ pci_write_config_word(dev, INTEL_6300_IOAPIC_ABAR,
++ pci_config_word);
++ break;
++ case 0x3c28: /* Xeon E5 1600/2600/4600 */
++ case 0x0e28: /* Xeon E5/E7 V2 */
++ case 0x2f28: /* Xeon E5/E7 V3,V4 */
++ case 0x6f28: /* Xeon D-1500 */
++ case 0x2034: /* Xeon Scalable Family */
++ pci_read_config_dword(dev, INTEL_CIPINTRC_CFG_OFFSET,
++ &pci_config_dword);
++ pci_config_dword |= INTEL_CIPINTRC_DIS_INTX_ICH;
++ pci_write_config_dword(dev, INTEL_CIPINTRC_CFG_OFFSET,
++ pci_config_dword);
++ break;
++ default:
++ return;
++ }
+ pci_info(dev, "disabled boot interrupts on device [%04x:%04x]\n",
+ dev->vendor, dev->device);
+ }
+-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10, quirk_disable_intel_boot_interrupt);
+-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10, quirk_disable_intel_boot_interrupt);
++/*
++ * Device 29 Func 5 Device IDs of IO-APIC
++ * containing ABAR—APIC1 Alternate Base Address Register
++ */
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10,
++ quirk_disable_intel_boot_interrupt);
++
++/*
++ * Device 5 Func 0 Device IDs of Core IO modules/hubs
++ * containing Coherent Interface Protocol Interrupt Control
++ *
++ * Device IDs obtained from volume 2 datasheets of commented
++ * families above.
++ */
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3c28,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0e28,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2f28,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x6f28,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2034,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x3c28,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x0e28,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x2f28,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x6f28,
++ quirk_disable_intel_boot_interrupt);
++DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x2034,
++ quirk_disable_intel_boot_interrupt);
+
+ /* Disable boot interrupts on HT-1000 */
+ #define BC_HT1000_FEATURE_REG 0x64
--- /dev/null
+From 58a3862a10a317a81097ab0c78aecebabb1704f5 Mon Sep 17 00:00:00 2001
+From: Yicong Yang <yangyicong@hisilicon.com>
+Date: Fri, 13 Mar 2020 17:53:47 +0800
+Subject: PCI/ASPM: Clear the correct bits when enabling L1 substates
+
+From: Yicong Yang <yangyicong@hisilicon.com>
+
+commit 58a3862a10a317a81097ab0c78aecebabb1704f5 upstream.
+
+In pcie_config_aspm_l1ss(), we cleared the wrong bits when enabling ASPM L1
+Substates. Instead of the L1.x enable bits (PCI_L1SS_CTL1_L1SS_MASK, 0xf), we
+cleared the Link Activation Interrupt Enable bit (PCI_L1SS_CAP_L1_PM_SS,
+0x10).
+
+Clear the L1.x enable bits before writing the new L1.x configuration.
+
+[bhelgaas: changelog]
+Fixes: aeda9adebab8 ("PCI/ASPM: Configure L1 substate settings")
+Link: https://lore.kernel.org/r/1584093227-1292-1-git-send-email-yangyicong@hisilicon.com
+Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+CC: stable@vger.kernel.org # v4.11+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/pcie/aspm.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/pcie/aspm.c
++++ b/drivers/pci/pcie/aspm.c
+@@ -747,9 +747,9 @@ static void pcie_config_aspm_l1ss(struct
+
+ /* Enable what we need to enable */
+ pci_clear_and_set_dword(parent, up_cap_ptr + PCI_L1SS_CTL1,
+- PCI_L1SS_CAP_L1_PM_SS, val);
++ PCI_L1SS_CTL1_L1SS_MASK, val);
+ pci_clear_and_set_dword(child, dw_cap_ptr + PCI_L1SS_CTL1,
+- PCI_L1SS_CAP_L1_PM_SS, val);
++ PCI_L1SS_CTL1_L1SS_MASK, val);
+ }
+
+ static void pcie_config_aspm_dev(struct pci_dev *pdev, u32 val)
--- /dev/null
+From 04e046ca57ebed3943422dee10eec9e73aec081e Mon Sep 17 00:00:00 2001
+From: Kishon Vijay Abraham I <kishon@ti.com>
+Date: Mon, 24 Feb 2020 15:23:36 +0530
+Subject: PCI: endpoint: Fix for concurrent memory allocation in OB address region
+
+From: Kishon Vijay Abraham I <kishon@ti.com>
+
+commit 04e046ca57ebed3943422dee10eec9e73aec081e upstream.
+
+pci-epc-mem uses a bitmap to manage the Endpoint outbound (OB) address
+region. This address region will be shared by multiple endpoint
+functions (in the case of multi function endpoint) and it has to be
+protected from concurrent access to avoid updating an inconsistent state.
+
+Use a mutex to protect bitmap updates to prevent the memory
+allocation API from returning incorrect addresses.
+
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Cc: stable@vger.kernel.org # v4.14+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/endpoint/pci-epc-mem.c | 10 ++++++++--
+ include/linux/pci-epc.h | 3 +++
+ 2 files changed, 11 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/endpoint/pci-epc-mem.c
++++ b/drivers/pci/endpoint/pci-epc-mem.c
+@@ -79,6 +79,7 @@ int __pci_epc_mem_init(struct pci_epc *e
+ mem->page_size = page_size;
+ mem->pages = pages;
+ mem->size = size;
++ mutex_init(&mem->lock);
+
+ epc->mem = mem;
+
+@@ -122,7 +123,7 @@ void __iomem *pci_epc_mem_alloc_addr(str
+ phys_addr_t *phys_addr, size_t size)
+ {
+ int pageno;
+- void __iomem *virt_addr;
++ void __iomem *virt_addr = NULL;
+ struct pci_epc_mem *mem = epc->mem;
+ unsigned int page_shift = ilog2(mem->page_size);
+ int order;
+@@ -130,15 +131,18 @@ void __iomem *pci_epc_mem_alloc_addr(str
+ size = ALIGN(size, mem->page_size);
+ order = pci_epc_mem_get_order(mem, size);
+
++ mutex_lock(&mem->lock);
+ pageno = bitmap_find_free_region(mem->bitmap, mem->pages, order);
+ if (pageno < 0)
+- return NULL;
++ goto ret;
+
+ *phys_addr = mem->phys_base + (pageno << page_shift);
+ virt_addr = ioremap(*phys_addr, size);
+ if (!virt_addr)
+ bitmap_release_region(mem->bitmap, pageno, order);
+
++ret:
++ mutex_unlock(&mem->lock);
+ return virt_addr;
+ }
+ EXPORT_SYMBOL_GPL(pci_epc_mem_alloc_addr);
+@@ -164,7 +168,9 @@ void pci_epc_mem_free_addr(struct pci_ep
+ pageno = (phys_addr - mem->phys_base) >> page_shift;
+ size = ALIGN(size, mem->page_size);
+ order = pci_epc_mem_get_order(mem, size);
++ mutex_lock(&mem->lock);
+ bitmap_release_region(mem->bitmap, pageno, order);
++ mutex_unlock(&mem->lock);
+ }
+ EXPORT_SYMBOL_GPL(pci_epc_mem_free_addr);
+
+--- a/include/linux/pci-epc.h
++++ b/include/linux/pci-epc.h
+@@ -69,6 +69,7 @@ struct pci_epc_ops {
+ * @bitmap: bitmap to manage the PCI address space
+ * @pages: number of bits representing the address region
+ * @page_size: size of each page
++ * @lock: mutex to protect bitmap
+ */
+ struct pci_epc_mem {
+ phys_addr_t phys_base;
+@@ -76,6 +77,8 @@ struct pci_epc_mem {
+ unsigned long *bitmap;
+ size_t page_size;
+ int pages;
++ /* mutex to protect against concurrent access for memory allocation*/
++ struct mutex lock;
+ };
+
+ /**
--- /dev/null
+From 3e487d2e4aa466decd226353755c9d423e8fbacc Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Wed, 18 Mar 2020 12:33:12 +0100
+Subject: PCI: pciehp: Fix indefinite wait on sysfs requests
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 3e487d2e4aa466decd226353755c9d423e8fbacc upstream.
+
+David Hoyer reports that powering pciehp slots up or down via sysfs may
+hang: The call to wait_event() in pciehp_sysfs_enable_slot() and
+_disable_slot() does not return because ctrl->ist_running remains true.
+
+This flag, which was introduced by commit 157c1062fcd8 ("PCI: pciehp: Avoid
+returning prematurely from sysfs requests"), signifies that the IRQ thread
+pciehp_ist() is running. It is set to true at the top of pciehp_ist() and
+reset to false at the end. However there are two additional return
+statements in pciehp_ist() before which the commit neglected to reset the
+flag to false and wake up waiters for the flag.
+
+That omission opens up the following race when powering up the slot:
+
+* pciehp_ist() runs because a PCI_EXP_SLTSTA_PDC event was requested
+ by pciehp_sysfs_enable_slot()
+
+* pciehp_ist() turns on slot power via the following call stack:
+ pciehp_handle_presence_or_link_change() -> pciehp_enable_slot() ->
+ __pciehp_enable_slot() -> board_added() -> pciehp_power_on_slot()
+
+* after slot power is turned on, the link comes up, resulting in a
+ PCI_EXP_SLTSTA_DLLSC event
+
+* the IRQ handler pciehp_isr() stores the event in ctrl->pending_events
+ and returns IRQ_WAKE_THREAD
+
+* the IRQ thread is already woken (it's bringing up the slot), but the
+ genirq code remembers to re-run the IRQ thread after it has finished
+ (such that it can deal with the new event) by setting IRQTF_RUNTHREAD
+ via __handle_irq_event_percpu() -> __irq_wake_thread()
+
+* the IRQ thread removes PCI_EXP_SLTSTA_DLLSC from ctrl->pending_events
+ via board_added() -> pciehp_check_link_status() in order to deal with
+ presence and link flaps per commit 6c35a1ac3da6 ("PCI: pciehp:
+ Tolerate initially unstable link")
+
+* after pciehp_ist() has successfully brought up the slot, it resets
+ ctrl->ist_running to false and wakes up the sysfs requester
+
+* the genirq code re-runs pciehp_ist(), which sets ctrl->ist_running
+ to true but then returns with IRQ_NONE because ctrl->pending_events
+ is empty
+
+* pciehp_sysfs_enable_slot() is finally woken but notices that
+ ctrl->ist_running is true, hence continues waiting
+
+The only way to get the hung task going again is to trigger a hotplug
+event which brings down the slot, e.g. by yanking out the card.
+
+The same race exists when powering down the slot because remove_board()
+likewise clears link or presence changes in ctrl->pending_events per commit
+3943af9d01e9 ("PCI: pciehp: Ignore Link State Changes after powering off a
+slot") and thereby may cause a re-run of pciehp_ist() which returns with
+IRQ_NONE without resetting ctrl->ist_running to false.
+
+Fix by adding a goto label before the teardown steps at the end of
+pciehp_ist() and jumping to that label from the two return statements which
+currently neglect to reset the ctrl->ist_running flag.
+
+Fixes: 157c1062fcd8 ("PCI: pciehp: Avoid returning prematurely from sysfs requests")
+Link: https://lore.kernel.org/r/cca1effa488065cb055120aa01b65719094bdcb5.1584530321.git.lukas@wunner.de
+Reported-by: David Hoyer <David.Hoyer@netapp.com>
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Cc: stable@vger.kernel.org # v4.19+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pci/hotplug/pciehp_hpc.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/pci/hotplug/pciehp_hpc.c
++++ b/drivers/pci/hotplug/pciehp_hpc.c
+@@ -627,17 +627,15 @@ static irqreturn_t pciehp_ist(int irq, v
+ if (atomic_fetch_and(~RERUN_ISR, &ctrl->pending_events) & RERUN_ISR) {
+ ret = pciehp_isr(irq, dev_id);
+ enable_irq(irq);
+- if (ret != IRQ_WAKE_THREAD) {
+- pci_config_pm_runtime_put(pdev);
+- return ret;
+- }
++ if (ret != IRQ_WAKE_THREAD)
++ goto out;
+ }
+
+ synchronize_hardirq(irq);
+ events = atomic_xchg(&ctrl->pending_events, 0);
+ if (!events) {
+- pci_config_pm_runtime_put(pdev);
+- return IRQ_NONE;
++ ret = IRQ_NONE;
++ goto out;
+ }
+
+ /* Check Attention Button Pressed */
+@@ -666,10 +664,12 @@ static irqreturn_t pciehp_ist(int irq, v
+ pciehp_handle_presence_or_link_change(slot, events);
+ up_read(&ctrl->reset_lock);
+
++ ret = IRQ_HANDLED;
++out:
+ pci_config_pm_runtime_put(pdev);
+ ctrl->ist_running = false;
+ wake_up(&ctrl->requester);
+- return IRQ_HANDLED;
++ return ret;
+ }
+
+ static int pciehp_poll(void *data)
--- /dev/null
+From 6c871b7314dde9ab64f20de8f5aa3d01be4518e8 Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Tue, 25 Feb 2020 11:11:20 +0300
+Subject: pstore: pstore_ftrace_seq_next should increase position index
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit 6c871b7314dde9ab64f20de8f5aa3d01be4518e8 upstream.
+
+In Aug 2018 NeilBrown noticed
+commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface")
+"Some ->next functions do not increment *pos when they return NULL...
+Note that such ->next functions are buggy and should be fixed.
+A simple demonstration is
+
+ dd if=/proc/swaps bs=1000 skip=1
+
+Choose any block size larger than the size of /proc/swaps. This will
+always show the whole last line of /proc/swaps"
+
+/proc/swaps output was fixed recently, however there are lot of other
+affected files, and one of them is related to pstore subsystem.
+
+If .next function does not change position index, following .show function
+will repeat output related to current position index.
+
+There are at least 2 related problems:
+- read after lseek beyond end of file, described above by NeilBrown
+ "dd if=<AFFECTED_FILE> bs=1000 skip=1" will generate whole last list
+- read after lseek on in middle of last line will output expected rest of
+ last line but then repeat whole last line once again.
+
+If .show() function generates multy-line output (like
+pstore_ftrace_seq_show() does ?) following bash script cycles endlessly
+
+ $ q=;while read -r r;do echo "$((++q)) $r";done < AFFECTED_FILE
+
+Unfortunately I'm not familiar enough to pstore subsystem and was unable
+to find affected pstore-related file on my test node.
+
+If .next function does not change position index, following .show function
+will repeat output related to current position index.
+
+Cc: stable@vger.kernel.org
+Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code ...")
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206283
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Link: https://lore.kernel.org/r/4e49830d-4c88-0171-ee24-1ee540028dad@virtuozzo.com
+[kees: with robustness tweak from Joel Fernandes <joelaf@google.com>]
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/pstore/inode.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/fs/pstore/inode.c
++++ b/fs/pstore/inode.c
+@@ -99,11 +99,11 @@ static void *pstore_ftrace_seq_next(stru
+ struct pstore_private *ps = s->private;
+ struct pstore_ftrace_seq_data *data = v;
+
++ (*pos)++;
+ data->off += REC_SIZE;
+ if (data->off + REC_SIZE > ps->total_size)
+ return NULL;
+
+- (*pos)++;
+ return data;
+ }
+
+@@ -113,6 +113,9 @@ static int pstore_ftrace_seq_show(struct
+ struct pstore_ftrace_seq_data *data = v;
+ struct pstore_ftrace_record *rec;
+
++ if (!data)
++ return 0;
++
+ rec = (struct pstore_ftrace_record *)(ps->record->buf + data->off);
+
+ seq_printf(s, "CPU:%d ts:%llu %08lx %08lx %pf <- %pF\n",
asoc-dapm-connect-virtual-mux-with-default-value.patch
asoc-dpcm-allow-start-or-stop-during-pause-for-backend.patch
asoc-topology-use-name_prefix-for-new-kcontrol.patch
+usb-gadget-f_fs-fix-use-after-free-issue-as-part-of-queue-failure.patch
+usb-gadget-composite-inform-controller-driver-of-self-powered.patch
+alsa-usb-audio-add-mixer-workaround-for-trx40-and-co.patch
+alsa-hda-add-driver-blacklist.patch
+alsa-hda-fix-potential-access-overflow-in-beep-helper.patch
+alsa-ice1724-fix-invalid-access-for-enumerated-ctl-items.patch
+alsa-pcm-oss-fix-regression-by-buffer-overflow-fix.patch
+alsa-doc-document-pc-beep-hidden-register-on-realtek-alc256.patch
+alsa-hda-realtek-set-principled-pc-beep-configuration-for-alc256.patch
+alsa-hda-realtek-remove-now-unnecessary-xps-13-headphone-noise-fixups.patch
+alsa-hda-realtek-add-quirk-for-msi-gl63.patch
+media-ti-vpe-cal-fix-disable_irqs-to-only-the-intended-target.patch
+acpi-x86-ignore-unspecified-bit-positions-in-the-acpi-global-lock-field.patch
+thermal-devfreq_cooling-inline-all-stubs-for-config_devfreq_thermal-n.patch
+nvme-fc-revert-add-module-to-ops-template-to-allow-module-references.patch
+nvme-treat-discovery-subsystems-as-unique-subsystems.patch
+pci-pciehp-fix-indefinite-wait-on-sysfs-requests.patch
+pci-aspm-clear-the-correct-bits-when-enabling-l1-substates.patch
+pci-add-boot-interrupt-quirk-mechanism-for-xeon-chipsets.patch
+pci-endpoint-fix-for-concurrent-memory-allocation-in-ob-address-region.patch
+tpm-don-t-make-log-failures-fatal.patch
+tpm-tpm1_bios_measurements_next-should-increase-position-index.patch
+tpm-tpm2_bios_measurements_next-should-increase-position-index.patch
+keys-reaching-the-keys-quotas-correctly.patch
+irqchip-versatile-fpga-apply-clear-mask-earlier.patch
+pstore-pstore_ftrace_seq_next-should-increase-position-index.patch
+mips-tlbex-fix-lddir-usage-in-setup_pw-for-loongson-3.patch
+mips-octeon-irq-fix-potential-null-pointer-dereference.patch
+ath9k-handle-txpower-changes-even-when-tpc-is-disabled.patch
+signal-extend-exec_id-to-64bits.patch
+x86-entry-32-add-missing-asm_clac-to-general_protection-entry.patch
--- /dev/null
+From d1e7fd6462ca9fc76650fbe6ca800e35b24267da Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Mon, 30 Mar 2020 19:01:04 -0500
+Subject: signal: Extend exec_id to 64bits
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit d1e7fd6462ca9fc76650fbe6ca800e35b24267da upstream.
+
+Replace the 32bit exec_id with a 64bit exec_id to make it impossible
+to wrap the exec_id counter. With care an attacker can cause exec_id
+wrap and send arbitrary signals to a newly exec'd parent. This
+bypasses the signal sending checks if the parent changes their
+credentials during exec.
+
+The severity of this problem can been seen that in my limited testing
+of a 32bit exec_id it can take as little as 19s to exec 65536 times.
+Which means that it can take as little as 14 days to wrap a 32bit
+exec_id. Adam Zabrocki has succeeded wrapping the self_exe_id in 7
+days. Even my slower timing is in the uptime of a typical server.
+Which means self_exec_id is simply a speed bump today, and if exec
+gets noticably faster self_exec_id won't even be a speed bump.
+
+Extending self_exec_id to 64bits introduces a problem on 32bit
+architectures where reading self_exec_id is no longer atomic and can
+take two read instructions. Which means that is is possible to hit
+a window where the read value of exec_id does not match the written
+value. So with very lucky timing after this change this still
+remains expoiltable.
+
+I have updated the update of exec_id on exec to use WRITE_ONCE
+and the read of exec_id in do_notify_parent to use READ_ONCE
+to make it clear that there is no locking between these two
+locations.
+
+Link: https://lore.kernel.org/kernel-hardening/20200324215049.GA3710@pi3.com.pl
+Fixes: 2.3.23pre2
+Cc: stable@vger.kernel.org
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/exec.c | 2 +-
+ include/linux/sched.h | 4 ++--
+ kernel/signal.c | 2 +-
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -1378,7 +1378,7 @@ void setup_new_exec(struct linux_binprm
+
+ /* An exec changes our domain. We are no longer part of the thread
+ group */
+- current->self_exec_id++;
++ WRITE_ONCE(current->self_exec_id, current->self_exec_id + 1);
+ flush_signal_handlers(current, 0);
+ }
+ EXPORT_SYMBOL(setup_new_exec);
+--- a/include/linux/sched.h
++++ b/include/linux/sched.h
+@@ -887,8 +887,8 @@ struct task_struct {
+ struct seccomp seccomp;
+
+ /* Thread group tracking: */
+- u32 parent_exec_id;
+- u32 self_exec_id;
++ u64 parent_exec_id;
++ u64 self_exec_id;
+
+ /* Protection against (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed, mempolicy: */
+ spinlock_t alloc_lock;
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -1837,7 +1837,7 @@ bool do_notify_parent(struct task_struct
+ * This is only possible if parent == real_parent.
+ * Check if it has changed security domain.
+ */
+- if (tsk->parent_exec_id != tsk->parent->self_exec_id)
++ if (tsk->parent_exec_id != READ_ONCE(tsk->parent->self_exec_id))
+ sig = SIGCHLD;
+ }
+
--- /dev/null
+From 3f5b9959041e0db6dacbea80bb833bff5900999f Mon Sep 17 00:00:00 2001
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Date: Fri, 3 Apr 2020 22:51:33 +0200
+Subject: thermal: devfreq_cooling: inline all stubs for CONFIG_DEVFREQ_THERMAL=n
+
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+commit 3f5b9959041e0db6dacbea80bb833bff5900999f upstream.
+
+When CONFIG_DEVFREQ_THERMAL is disabled all functions except
+of_devfreq_cooling_register_power() were already inlined. Also inline
+the last function to avoid compile errors when multiple drivers call
+of_devfreq_cooling_register_power() when CONFIG_DEVFREQ_THERMAL is not
+set. Compilation failed with the following message:
+ multiple definition of `of_devfreq_cooling_register_power'
+(which then lists all usages of of_devfreq_cooling_register_power())
+
+Thomas Zimmermann reported this problem [0] on a kernel config with
+CONFIG_DRM_LIMA={m,y}, CONFIG_DRM_PANFROST={m,y} and
+CONFIG_DEVFREQ_THERMAL=n after both, the lima and panfrost drivers
+gained devfreq cooling support.
+
+[0] https://www.spinics.net/lists/dri-devel/msg252825.html
+
+Fixes: a76caf55e5b356 ("thermal: Add devfreq cooling")
+Cc: stable@vger.kernel.org
+Reported-by: Thomas Zimmermann <tzimmermann@suse.de>
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/20200403205133.1101808-1-martin.blumenstingl@googlemail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/devfreq_cooling.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/devfreq_cooling.h
++++ b/include/linux/devfreq_cooling.h
+@@ -75,7 +75,7 @@ void devfreq_cooling_unregister(struct t
+
+ #else /* !CONFIG_DEVFREQ_THERMAL */
+
+-struct thermal_cooling_device *
++static inline struct thermal_cooling_device *
+ of_devfreq_cooling_register_power(struct device_node *np, struct devfreq *df,
+ struct devfreq_cooling_power *dfc_power)
+ {
--- /dev/null
+From 805fa88e0780b7ce1cc9b649dd91a0a7164c6eb4 Mon Sep 17 00:00:00 2001
+From: Matthew Garrett <matthewgarrett@google.com>
+Date: Thu, 2 Jan 2020 13:55:18 -0800
+Subject: tpm: Don't make log failures fatal
+
+From: Matthew Garrett <matthewgarrett@google.com>
+
+commit 805fa88e0780b7ce1cc9b649dd91a0a7164c6eb4 upstream.
+
+If a TPM is in disabled state, it's reasonable for it to have an empty
+log. Bailing out of probe in this case means that the PPI interface
+isn't available, so there's no way to then enable the TPM from the OS.
+In general it seems reasonable to ignore log errors - they shouldn't
+interfere with any other TPM functionality.
+
+Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
+Cc: stable@vger.kernel.org # 4.19.x
+Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
+Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/tpm/eventlog/common.c | 12 ++++--------
+ drivers/char/tpm/tpm-chip.c | 4 +---
+ drivers/char/tpm/tpm.h | 2 +-
+ 3 files changed, 6 insertions(+), 12 deletions(-)
+
+--- a/drivers/char/tpm/eventlog/common.c
++++ b/drivers/char/tpm/eventlog/common.c
+@@ -104,11 +104,8 @@ static int tpm_read_log(struct tpm_chip
+ *
+ * If an event log is found then the securityfs files are setup to
+ * export it to userspace, otherwise nothing is done.
+- *
+- * Returns -ENODEV if the firmware has no event log or securityfs is not
+- * supported.
+ */
+-int tpm_bios_log_setup(struct tpm_chip *chip)
++void tpm_bios_log_setup(struct tpm_chip *chip)
+ {
+ const char *name = dev_name(&chip->dev);
+ unsigned int cnt;
+@@ -117,7 +114,7 @@ int tpm_bios_log_setup(struct tpm_chip *
+
+ rc = tpm_read_log(chip);
+ if (rc < 0)
+- return rc;
++ return;
+ log_version = rc;
+
+ cnt = 0;
+@@ -163,13 +160,12 @@ int tpm_bios_log_setup(struct tpm_chip *
+ cnt++;
+ }
+
+- return 0;
++ return;
+
+ err:
+- rc = PTR_ERR(chip->bios_dir[cnt]);
+ chip->bios_dir[cnt] = NULL;
+ tpm_bios_log_teardown(chip);
+- return rc;
++ return;
+ }
+
+ void tpm_bios_log_teardown(struct tpm_chip *chip)
+--- a/drivers/char/tpm/tpm-chip.c
++++ b/drivers/char/tpm/tpm-chip.c
+@@ -463,9 +463,7 @@ int tpm_chip_register(struct tpm_chip *c
+
+ tpm_sysfs_add_device(chip);
+
+- rc = tpm_bios_log_setup(chip);
+- if (rc != 0 && rc != -ENODEV)
+- return rc;
++ tpm_bios_log_setup(chip);
+
+ tpm_add_ppi(chip);
+
+--- a/drivers/char/tpm/tpm.h
++++ b/drivers/char/tpm/tpm.h
+@@ -602,6 +602,6 @@ int tpm2_prepare_space(struct tpm_chip *
+ int tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space,
+ u32 cc, u8 *buf, size_t *bufsiz);
+
+-int tpm_bios_log_setup(struct tpm_chip *chip);
++void tpm_bios_log_setup(struct tpm_chip *chip);
+ void tpm_bios_log_teardown(struct tpm_chip *chip);
+ #endif
--- /dev/null
+From d7a47b96ed1102551eb7325f97937e276fb91045 Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Tue, 25 Feb 2020 09:26:08 +0300
+Subject: tpm: tpm1_bios_measurements_next should increase position index
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit d7a47b96ed1102551eb7325f97937e276fb91045 upstream.
+
+If .next function does not change position index,
+following .show function will repeat output related
+to current position index.
+
+In case of /sys/kernel/security/tpm0/ascii_bios_measurements
+and binary_bios_measurements:
+1) read after lseek beyound end of file generates whole last line.
+2) read after lseek to middle of last line generates
+expected end of last line and unexpected whole last line once again.
+
+Cc: stable@vger.kernel.org # 4.19.x
+Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code ...")
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206283
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/tpm/eventlog/tpm1.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/char/tpm/eventlog/tpm1.c
++++ b/drivers/char/tpm/eventlog/tpm1.c
+@@ -129,6 +129,7 @@ static void *tpm1_bios_measurements_next
+ u32 converted_event_size;
+ u32 converted_event_type;
+
++ (*pos)++;
+ converted_event_size = do_endian_conversion(event->event_size);
+
+ v += sizeof(struct tcpa_event) + converted_event_size;
+@@ -146,7 +147,6 @@ static void *tpm1_bios_measurements_next
+ ((v + sizeof(struct tcpa_event) + converted_event_size) >= limit))
+ return NULL;
+
+- (*pos)++;
+ return v;
+ }
+
--- /dev/null
+From f9bf8adb55cd5a357b247a16aafddf8c97b276e0 Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Tue, 25 Feb 2020 09:26:22 +0300
+Subject: tpm: tpm2_bios_measurements_next should increase position index
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit f9bf8adb55cd5a357b247a16aafddf8c97b276e0 upstream.
+
+If .next function does not change position index,
+following .show function will repeat output related
+to current position index.
+
+For /sys/kernel/security/tpm0/binary_bios_measurements:
+1) read after lseek beyound end of file generates whole last line.
+2) read after lseek to middle of last line generates
+expected end of last line and unexpected whole last line once again.
+
+Cc: stable@vger.kernel.org # 4.19.x
+Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code ...")
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206283
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/tpm/eventlog/tpm2.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/char/tpm/eventlog/tpm2.c
++++ b/drivers/char/tpm/eventlog/tpm2.c
+@@ -143,6 +143,7 @@ static void *tpm2_bios_measurements_next
+ size_t event_size;
+ void *marker;
+
++ (*pos)++;
+ event_header = log->bios_event_log;
+
+ if (v == SEQ_START_TOKEN) {
+@@ -167,7 +168,6 @@ static void *tpm2_bios_measurements_next
+ if (((v + event_size) >= limit) || (event_size == 0))
+ return NULL;
+
+- (*pos)++;
+ return v;
+ }
+
--- /dev/null
+From 5e5caf4fa8d3039140b4548b6ab23dd17fce9b2c Mon Sep 17 00:00:00 2001
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Date: Mon, 3 Feb 2020 18:05:32 -0800
+Subject: usb: gadget: composite: Inform controller driver of self-powered
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+commit 5e5caf4fa8d3039140b4548b6ab23dd17fce9b2c upstream.
+
+Different configuration/condition may draw different power. Inform the
+controller driver of the change so it can respond properly (e.g.
+GET_STATUS request). This fixes an issue with setting MaxPower from
+configfs. The composite driver doesn't check this value when setting
+self-powered.
+
+Cc: stable@vger.kernel.org
+Fixes: 88af8bbe4ef7 ("usb: gadget: the start of the configfs interface")
+Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/composite.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/usb/gadget/composite.c
++++ b/drivers/usb/gadget/composite.c
+@@ -847,6 +847,11 @@ static int set_config(struct usb_composi
+ else
+ power = min(power, 900U);
+ done:
++ if (power <= USB_SELF_POWER_VBUS_MAX_DRAW)
++ usb_gadget_set_selfpowered(gadget);
++ else
++ usb_gadget_clear_selfpowered(gadget);
++
+ usb_gadget_vbus_draw(gadget, power);
+ if (result >= 0 && cdev->delayed_status)
+ result = USB_GADGET_DELAYED_STATUS;
+@@ -2265,6 +2270,7 @@ void composite_suspend(struct usb_gadget
+
+ cdev->suspended = 1;
+
++ usb_gadget_set_selfpowered(gadget);
+ usb_gadget_vbus_draw(gadget, 2);
+ }
+
+@@ -2293,6 +2299,9 @@ void composite_resume(struct usb_gadget
+ else
+ maxpower = min(maxpower, 900U);
+
++ if (maxpower > USB_SELF_POWER_VBUS_MAX_DRAW)
++ usb_gadget_clear_selfpowered(gadget);
++
+ usb_gadget_vbus_draw(gadget, maxpower);
+ }
+
--- /dev/null
+From f63ec55ff904b2f2e126884fcad93175f16ab4bb Mon Sep 17 00:00:00 2001
+From: Sriharsha Allenki <sallenki@codeaurora.org>
+Date: Thu, 26 Mar 2020 17:26:20 +0530
+Subject: usb: gadget: f_fs: Fix use after free issue as part of queue failure
+
+From: Sriharsha Allenki <sallenki@codeaurora.org>
+
+commit f63ec55ff904b2f2e126884fcad93175f16ab4bb upstream.
+
+In AIO case, the request is freed up if ep_queue fails.
+However, io_data->req still has the reference to this freed
+request. In the case of this failure if there is aio_cancel
+call on this io_data it will lead to an invalid dequeue
+operation and a potential use after free issue.
+Fix this by setting the io_data->req to NULL when the request
+is freed as part of queue failure.
+
+Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
+Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
+CC: stable <stable@vger.kernel.org>
+Reviewed-by: Peter Chen <peter.chen@nxp.com>
+Link: https://lore.kernel.org/r/20200326115620.12571-1-sallenki@codeaurora.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/function/f_fs.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/gadget/function/f_fs.c
++++ b/drivers/usb/gadget/function/f_fs.c
+@@ -1036,6 +1036,7 @@ static ssize_t ffs_epfile_io(struct file
+
+ ret = usb_ep_queue(ep->ep, req, GFP_ATOMIC);
+ if (unlikely(ret)) {
++ io_data->req = NULL;
+ usb_ep_free_request(ep->ep, req);
+ goto error_lock;
+ }
--- /dev/null
+From 3d51507f29f2153a658df4a0674ec5b592b62085 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 25 Feb 2020 22:36:37 +0100
+Subject: x86/entry/32: Add missing ASM_CLAC to general_protection entry
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 3d51507f29f2153a658df4a0674ec5b592b62085 upstream.
+
+All exception entry points must have ASM_CLAC right at the
+beginning. The general_protection entry is missing one.
+
+Fixes: e59d1b0a2419 ("x86-32, smap: Add STAC/CLAC instructions to 32-bit kernel entry")
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
+Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
+Reviewed-by: Andy Lutomirski <luto@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20200225220216.219537887@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/entry/entry_32.S | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/entry/entry_32.S
++++ b/arch/x86/entry/entry_32.S
+@@ -1489,6 +1489,7 @@ ENTRY(int3)
+ END(int3)
+
+ ENTRY(general_protection)
++ ASM_CLAC
+ pushl $do_general_protection
+ jmp common_exception
+ END(general_protection)
projects / thirdparty / kernel / stable-queue.git / commitdiff
