--- /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
+@@ -1738,7 +1738,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
+@@ -2177,6 +2177,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,
+@@ -2196,6 +2207,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
+@@ -310,8 +310,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 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
+@@ -333,7 +333,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:
+@@ -345,11 +347,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;
+@@ -3122,7 +3119,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
+@@ -569,7 +569,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;
+ }
+@@ -583,7 +583,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)
+ {
+@@ -629,7 +645,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)
+@@ -639,7 +655,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
+@@ -1456,6 +1456,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
+@@ -544,16 +544,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 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
+@@ -337,8 +337,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;
+ }
+@@ -1763,7 +1762,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) {
+@@ -1789,7 +1787,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
+@@ -2768,15 +2765,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;
+@@ -2923,8 +2915,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
+@@ -693,7 +693,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
+@@ -1591,8 +1591,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
+@@ -578,7 +578,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
+@@ -279,8 +279,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
+@@ -394,8 +392,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 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
+@@ -693,9 +693,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
+@@ -90,6 +90,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;
+
+@@ -133,7 +134,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;
+@@ -141,15 +142,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);
+@@ -175,7 +179,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
+@@ -63,6 +63,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;
+@@ -70,6 +71,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;
+ };
+
+ /**
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
+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
+pci-aspm-clear-the-correct-bits-when-enabling-l1-substates.patch
+pci-endpoint-fix-for-concurrent-memory-allocation-in-ob-address-region.patch
+keys-reaching-the-keys-quotas-correctly.patch
+irqchip-versatile-fpga-apply-clear-mask-earlier.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
+@@ -1373,7 +1373,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
+@@ -839,8 +839,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
+@@ -1675,7 +1675,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 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
+@@ -850,6 +850,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;
+@@ -2281,6 +2286,7 @@ void composite_suspend(struct usb_gadget
+
+ cdev->suspended = 1;
+
++ usb_gadget_set_selfpowered(gadget);
+ usb_gadget_vbus_draw(gadget, 2);
+ }
+
+@@ -2309,6 +2315,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
+@@ -1037,6 +1037,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
+@@ -1057,6 +1057,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
