--- /dev/null
+From a523ef731ac6674dc07574f31bf44cc5bfa14e4d Mon Sep 17 00:00:00 2001
+From: Lukasz Majczak <lma@semihalf.com>
+Date: Thu, 15 Apr 2021 14:43:47 +0200
+Subject: ASoC: Intel: kbl_da7219_max98927: Fix kabylake_ssp_fixup function
+
+From: Lukasz Majczak <lma@semihalf.com>
+
+commit a523ef731ac6674dc07574f31bf44cc5bfa14e4d upstream.
+
+kabylake_ssp_fixup function uses snd_soc_dpcm to identify the
+codecs DAIs. The HW parameters are changed based on the codec DAI of the
+stream. The earlier approach to get snd_soc_dpcm was using container_of()
+macro on snd_pcm_hw_params.
+
+The structures have been modified over time and snd_soc_dpcm does not have
+snd_pcm_hw_params as a reference but as a copy. This causes the current
+driver to crash when used.
+
+This patch changes the way snd_soc_dpcm is extracted. snd_soc_pcm_runtime
+holds 2 dpcm instances (one for playback and one for capture). 2 codecs
+on the SSP are dmic (capture) and speakers (playback). Based on the
+stream direction, snd_soc_dpcm is extracted from snd_soc_pcm_runtime.
+
+Tested for all use cases of the driver.
+Based on similar fix in kbl_rt5663_rt5514_max98927.c
+from Harsha Priya <harshapriya.n@intel.com> and
+Vamshi Krishna Gopal <vamshi.krishna.gopal@intel.com>
+
+Cc: <stable@vger.kernel.org> # 5.4+
+Signed-off-by: Lukasz Majczak <lma@semihalf.com>
+Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Link: https://lore.kernel.org/r/20210415124347.475432-1-lma@semihalf.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/intel/boards/kbl_da7219_max98927.c | 38 +++++++++++++++++++++------
+ 1 file changed, 30 insertions(+), 8 deletions(-)
+
+--- a/sound/soc/intel/boards/kbl_da7219_max98927.c
++++ b/sound/soc/intel/boards/kbl_da7219_max98927.c
+@@ -282,12 +282,34 @@ static int kabylake_ssp_fixup(struct snd
+ struct snd_interval *chan = hw_param_interval(params,
+ SNDRV_PCM_HW_PARAM_CHANNELS);
+ struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
+- struct snd_soc_dpcm *dpcm = container_of(
+- params, struct snd_soc_dpcm, hw_params);
+- struct snd_soc_dai_link *fe_dai_link = dpcm->fe->dai_link;
+- struct snd_soc_dai_link *be_dai_link = dpcm->be->dai_link;
++ struct snd_soc_dpcm *dpcm, *rtd_dpcm = NULL;
+
+ /*
++ * The following loop will be called only for playback stream
++ * In this platform, there is only one playback device on every SSP
++ */
++ for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_PLAYBACK, dpcm) {
++ rtd_dpcm = dpcm;
++ break;
++ }
++
++ /*
++ * This following loop will be called only for capture stream
++ * In this platform, there is only one capture device on every SSP
++ */
++ for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_CAPTURE, dpcm) {
++ rtd_dpcm = dpcm;
++ break;
++ }
++
++ if (!rtd_dpcm)
++ return -EINVAL;
++
++ /*
++ * The above 2 loops are mutually exclusive based on the stream direction,
++ * thus rtd_dpcm variable will never be overwritten
++ */
++ /*
+ * Topology for kblda7219m98373 & kblmax98373 supports only S24_LE,
+ * where as kblda7219m98927 & kblmax98927 supports S16_LE by default.
+ * Skipping the port wise FE and BE configuration for kblda7219m98373 &
+@@ -309,9 +331,9 @@ static int kabylake_ssp_fixup(struct snd
+ /*
+ * The ADSP will convert the FE rate to 48k, stereo, 24 bit
+ */
+- if (!strcmp(fe_dai_link->name, "Kbl Audio Port") ||
+- !strcmp(fe_dai_link->name, "Kbl Audio Headset Playback") ||
+- !strcmp(fe_dai_link->name, "Kbl Audio Capture Port")) {
++ if (!strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Port") ||
++ !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Headset Playback") ||
++ !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Capture Port")) {
+ rate->min = rate->max = 48000;
+ chan->min = chan->max = 2;
+ snd_mask_none(fmt);
+@@ -322,7 +344,7 @@ static int kabylake_ssp_fixup(struct snd
+ * The speaker on the SSP0 supports S16_LE and not S24_LE.
+ * thus changing the mask here
+ */
+- if (!strcmp(be_dai_link->name, "SSP0-Codec"))
++ if (!strcmp(rtd_dpcm->be->dai_link->name, "SSP0-Codec"))
+ snd_mask_set_format(fmt, SNDRV_PCM_FORMAT_S16_LE);
+
+ return 0;
--- /dev/null
+From d58970da324732686529655c21791cef0ee547c4 Mon Sep 17 00:00:00 2001
+From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Date: Fri, 12 Mar 2021 12:02:30 -0600
+Subject: ASoC: samsung: tm2_wm5110: check of of_parse return value
+
+From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+
+commit d58970da324732686529655c21791cef0ee547c4 upstream.
+
+cppcheck warning:
+
+sound/soc/samsung/tm2_wm5110.c:605:6: style: Variable 'ret' is
+reassigned a value before the old one has been
+used. [redundantAssignment]
+ ret = devm_snd_soc_register_component(dev, &tm2_component,
+ ^
+sound/soc/samsung/tm2_wm5110.c:554:7: note: ret is assigned
+ ret = of_parse_phandle_with_args(dev->of_node, "i2s-controller",
+ ^
+sound/soc/samsung/tm2_wm5110.c:605:6: note: ret is overwritten
+ ret = devm_snd_soc_register_component(dev, &tm2_component,
+ ^
+
+The args is a stack variable, so it could have junk (uninitialized)
+therefore args.np could have a non-NULL and random value even though
+property was missing. Later could trigger invalid pointer dereference.
+
+There's no need to check for args.np because args.np won't be
+initialized on errors.
+
+Fixes: 8d1513cef51a ("ASoC: samsung: Add support for HDMI audio on TM2 board")
+Cc: <stable@vger.kernel.org>
+Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
+Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Link: https://lore.kernel.org/r/20210312180231.2741-2-pierre-louis.bossart@linux.intel.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/samsung/tm2_wm5110.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/soc/samsung/tm2_wm5110.c
++++ b/sound/soc/samsung/tm2_wm5110.c
+@@ -553,7 +553,7 @@ static int tm2_probe(struct platform_dev
+
+ ret = of_parse_phandle_with_args(dev->of_node, "i2s-controller",
+ cells_name, i, &args);
+- if (!args.np) {
++ if (ret) {
+ dev_err(dev, "i2s-controller property parse error: %d\n", i);
+ ret = -EINVAL;
+ goto dai_node_put;
--- /dev/null
+From 29654ed8384e9dbaf4cfba689dbcb664a6ab4bb7 Mon Sep 17 00:00:00 2001
+From: Annaliese McDermond <nh6z@nh6z.net>
+Date: Wed, 31 Mar 2021 18:21:45 +0000
+Subject: ASoC: tlv320aic32x4: Increase maximum register in regmap
+
+From: Annaliese McDermond <nh6z@nh6z.net>
+
+commit 29654ed8384e9dbaf4cfba689dbcb664a6ab4bb7 upstream.
+
+AIC32X4_REFPOWERUP was added as a register, but the maximum register value
+in the regmap and regmap range was not correspondingly increased. This
+caused an error when this register was attempted to be written.
+
+Fixes: ec96690de82c ("ASoC: tlv320aic32x4: Enable fast charge")
+Cc: stable@vger.kernel.org
+Signed-off-by: Annaliese McDermond <nh6z@nh6z.net>
+Link: https://lore.kernel.org/r/0101017889851cab-ce60cfdb-d88c-43d8-bbd2-7fbf34a0c912-000000@us-west-2.amazonses.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/codecs/tlv320aic32x4.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/codecs/tlv320aic32x4.c
++++ b/sound/soc/codecs/tlv320aic32x4.c
+@@ -577,12 +577,12 @@ static const struct regmap_range_cfg aic
+ .window_start = 0,
+ .window_len = 128,
+ .range_min = 0,
+- .range_max = AIC32X4_RMICPGAVOL,
++ .range_max = AIC32X4_REFPOWERUP,
+ },
+ };
+
+ const struct regmap_config aic32x4_regmap_config = {
+- .max_register = AIC32X4_RMICPGAVOL,
++ .max_register = AIC32X4_REFPOWERUP,
+ .ranges = aic32x4_regmap_pages,
+ .num_ranges = ARRAY_SIZE(aic32x4_regmap_pages),
+ };
--- /dev/null
+From 1ca1156cfd69530e6b7cb99943baf90c8bd871a5 Mon Sep 17 00:00:00 2001
+From: Annaliese McDermond <nh6z@nh6z.net>
+Date: Wed, 31 Mar 2021 18:21:38 +0000
+Subject: ASoC: tlv320aic32x4: Register clocks before registering component
+
+From: Annaliese McDermond <nh6z@nh6z.net>
+
+commit 1ca1156cfd69530e6b7cb99943baf90c8bd871a5 upstream.
+
+Clock registration must be performed before the component is
+registered. aic32x4_component_probe attempts to get all the
+clocks right off the bat. If the component is registered before
+the clocks there is a race condition where the clocks may not
+be registered by the time aic32x4_componet_probe actually runs.
+
+Fixes: d1c859d314d8 ("ASoC: codec: tlv3204: Increased maximum supported channels")
+Cc: stable@vger.kernel.org
+Signed-off-by: Annaliese McDermond <nh6z@nh6z.net>
+Link: https://lore.kernel.org/r/0101017889850206-dcac4cce-8cc8-4a21-80e9-4e4bef44b981-000000@us-west-2.amazonses.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/codecs/tlv320aic32x4.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/sound/soc/codecs/tlv320aic32x4.c
++++ b/sound/soc/codecs/tlv320aic32x4.c
+@@ -1243,6 +1243,10 @@ int aic32x4_probe(struct device *dev, st
+ if (ret)
+ goto err_disable_regulators;
+
++ ret = aic32x4_register_clocks(dev, aic32x4->mclk_name);
++ if (ret)
++ goto err_disable_regulators;
++
+ ret = devm_snd_soc_register_component(dev,
+ &soc_component_dev_aic32x4, &aic32x4_dai, 1);
+ if (ret) {
+@@ -1250,10 +1254,6 @@ int aic32x4_probe(struct device *dev, st
+ goto err_disable_regulators;
+ }
+
+- ret = aic32x4_register_clocks(dev, aic32x4->mclk_name);
+- if (ret)
+- goto err_disable_regulators;
+-
+ return 0;
+
+ err_disable_regulators:
--- /dev/null
+From ceaf2966ab082bbc4d26516f97b3ca8a676e2af8 Mon Sep 17 00:00:00 2001
+From: Xiao Ni <xni@redhat.com>
+Date: Sun, 25 Apr 2021 17:22:57 +0800
+Subject: async_xor: increase src_offs when dropping destination page
+
+From: Xiao Ni <xni@redhat.com>
+
+commit ceaf2966ab082bbc4d26516f97b3ca8a676e2af8 upstream.
+
+Now we support sharing one page if PAGE_SIZE is not equal stripe size. To
+support this, it needs to support calculating xor value with different
+offsets for each r5dev. One offset array is used to record those offsets.
+
+In RMW mode, parity page is used as a source page. It sets
+ASYNC_TX_XOR_DROP_DST before calculating xor value in ops_run_prexor5.
+So it needs to add src_list and src_offs at the same time. Now it only
+needs src_list. So the xor value which is calculated is wrong. It can
+cause data corruption problem.
+
+I can reproduce this problem 100% on a POWER8 machine. The steps are:
+
+ mdadm -CR /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --size=3G
+ mkfs.xfs /dev/md0
+ mount /dev/md0 /mnt/test
+ mount: /mnt/test: mount(2) system call failed: Structure needs cleaning.
+
+Fixes: 29bcff787a25 ("md/raid5: add new xor function to support different page offset")
+Cc: stable@vger.kernel.org # v5.10+
+Signed-off-by: Xiao Ni <xni@redhat.com>
+Signed-off-by: Song Liu <song@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/async_tx/async_xor.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/crypto/async_tx/async_xor.c
++++ b/crypto/async_tx/async_xor.c
+@@ -233,6 +233,7 @@ async_xor_offs(struct page *dest, unsign
+ if (submit->flags & ASYNC_TX_XOR_DROP_DST) {
+ src_cnt--;
+ src_list++;
++ src_offs++;
+ }
+
+ /* wait for any prerequisite operations */
--- /dev/null
+From f626ca682912fab55dff15469ce893ae16b65c7e Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Wed, 10 Mar 2021 13:03:09 +0100
+Subject: FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit f626ca682912fab55dff15469ce893ae16b65c7e upstream.
+
+Recent versions of the PCI Express specification have deprecated support
+for I/O transactions and actually some PCIe host bridges, such as Power
+Systems Host Bridge 4 (PHB4), do not implement them.
+
+For those systems the PCI BARs that request a mapping in the I/O space
+have the length recorded in the corresponding PCI resource set to zero,
+which makes it unassigned:
+
+# lspci -s 0031:02:04.0 -v
+0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02)
+ Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA)
+ Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8
+ Memory at 620c080020000 (32-bit, non-prefetchable) [size=128]
+ I/O ports at <unassigned> [disabled]
+ Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K]
+ Capabilities: [50] Power Management version 2
+ Kernel driver in use: defxx
+ Kernel modules: defxx
+
+#
+
+Regardless the driver goes ahead and requests it (here observed with a
+Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry:
+
+# cat /proc/ioports
+00000000-ffffffffffffffff : 0031:02:04.0
+#
+
+Furthermore, the system gets confused as the driver actually continues
+and pokes at those locations, causing a flood of messages being output
+to the system console by the underlying system firmware, like:
+
+defxx: v1.11 2014/07/01 Lawrence V. Stefani and others
+defxx 0031:02:04.0: enabling device (0140 -> 0142)
+LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000
+IPMI: dropping non severe PEL event
+LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
+IPMI: dropping non severe PEL event
+LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
+IPMI: dropping non severe PEL event
+
+and so on and so on (possibly intermixed actually, as there's no locking
+between the kernel and the firmware in console port access with this
+particular system, but cleaned up above for clarity), and once some 10k
+of such pairs of the latter two messages have been produced an interace
+eventually shows up in a useless state:
+
+0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00
+
+This was not expected to happen as resource handling was added to the
+driver a while ago, because it was not known at that time that a PCI
+system would be possible that cannot assign port I/O resources, and
+oddly enough `request_region' does not fail, which would have caught it.
+
+Correct the problem then by checking for the length of zero for the CSR
+resource and bail out gracefully refusing to register an interface if
+that turns out to be the case, producing messages like:
+
+defxx: v1.11 2014/07/01 Lawrence V. Stefani and others
+0031:02:04.0: Cannot use I/O, no address set, aborting
+0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y"
+
+Keep the original check for the EISA MMIO resource as implemented,
+because in that case the length is hardwired to 0x400 as a consequence
+of how the compare/mask address decoding works in the ESIC chip and it
+is only the base address that is set to zero if MMIO has been disabled
+for the adapter in EISA configuration, which in turn could be a valid
+bus address in a legacy-free system implementing PCI, especially for
+port I/O.
+
+Where the EISA MMIO resource has been disabled for the adapter in EISA
+configuration this arrangement keeps producing messages like:
+
+eisa 00:05: EISA: slot 5: DEC3002 detected
+defxx: v1.11 2014/07/01 Lawrence V. Stefani and others
+00:05: Cannot use MMIO, no address set, aborting
+00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n"
+00:05: Or run ECU and set adapter's MMIO location
+
+with the last two lines now swapped for easier handling in the driver.
+
+There is no need to check for and catch the case of a port I/O resource
+not having been assigned for EISA as the adapter uses the slot-specific
+I/O space, which gets assigned by how EISA has been specified and maps
+directly to the particular slot an option card has been placed in. And
+the EISA variant of the adapter has additional registers that are only
+accessible via the port I/O space anyway.
+
+While at it factor out the error message calls into helpers and fix an
+argument order bug with the `pr_err' call now in `dfx_register_res_err'.
+
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management")
+Cc: stable@vger.kernel.org # v3.19+
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/fddi/defxx.c | 47 ++++++++++++++++++++++++++++++-----------------
+ 1 file changed, 30 insertions(+), 17 deletions(-)
+
+--- a/drivers/net/fddi/defxx.c
++++ b/drivers/net/fddi/defxx.c
+@@ -495,6 +495,25 @@ static const struct net_device_ops dfx_n
+ .ndo_set_mac_address = dfx_ctl_set_mac_address,
+ };
+
++static void dfx_register_res_alloc_err(const char *print_name, bool mmio,
++ bool eisa)
++{
++ pr_err("%s: Cannot use %s, no address set, aborting\n",
++ print_name, mmio ? "MMIO" : "I/O");
++ pr_err("%s: Recompile driver with \"CONFIG_DEFXX_MMIO=%c\"\n",
++ print_name, mmio ? 'n' : 'y');
++ if (eisa && mmio)
++ pr_err("%s: Or run ECU and set adapter's MMIO location\n",
++ print_name);
++}
++
++static void dfx_register_res_err(const char *print_name, bool mmio,
++ unsigned long start, unsigned long len)
++{
++ pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, aborting\n",
++ print_name, mmio ? "MMIO" : "I/O", len, start);
++}
++
+ /*
+ * ================
+ * = dfx_register =
+@@ -568,15 +587,12 @@ static int dfx_register(struct device *b
+ dev_set_drvdata(bdev, dev);
+
+ dfx_get_bars(bdev, bar_start, bar_len);
+- if (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0) {
+- pr_err("%s: Cannot use MMIO, no address set, aborting\n",
+- print_name);
+- pr_err("%s: Run ECU and set adapter's MMIO location\n",
+- print_name);
+- pr_err("%s: Or recompile driver with \"CONFIG_DEFXX_MMIO=n\""
+- "\n", print_name);
++ if (bar_len[0] == 0 ||
++ (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0)) {
++ dfx_register_res_alloc_err(print_name, dfx_use_mmio,
++ dfx_bus_eisa);
+ err = -ENXIO;
+- goto err_out;
++ goto err_out_disable;
+ }
+
+ if (dfx_use_mmio)
+@@ -585,18 +601,16 @@ static int dfx_register(struct device *b
+ else
+ region = request_region(bar_start[0], bar_len[0], print_name);
+ if (!region) {
+- pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, "
+- "aborting\n", dfx_use_mmio ? "MMIO" : "I/O", print_name,
+- (long)bar_len[0], (long)bar_start[0]);
++ dfx_register_res_err(print_name, dfx_use_mmio,
++ bar_start[0], bar_len[0]);
+ err = -EBUSY;
+ goto err_out_disable;
+ }
+ if (bar_start[1] != 0) {
+ region = request_region(bar_start[1], bar_len[1], print_name);
+ if (!region) {
+- pr_err("%s: Cannot reserve I/O resource "
+- "0x%lx @ 0x%lx, aborting\n", print_name,
+- (long)bar_len[1], (long)bar_start[1]);
++ dfx_register_res_err(print_name, 0,
++ bar_start[1], bar_len[1]);
+ err = -EBUSY;
+ goto err_out_csr_region;
+ }
+@@ -604,9 +618,8 @@ static int dfx_register(struct device *b
+ if (bar_start[2] != 0) {
+ region = request_region(bar_start[2], bar_len[2], print_name);
+ if (!region) {
+- pr_err("%s: Cannot reserve I/O resource "
+- "0x%lx @ 0x%lx, aborting\n", print_name,
+- (long)bar_len[2], (long)bar_start[2]);
++ dfx_register_res_err(print_name, 0,
++ bar_start[2], bar_len[2]);
+ err = -EBUSY;
+ goto err_out_bh_region;
+ }
--- /dev/null
+From 4e102429f3dc62dce546f6107e34a4284634196d Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Sun, 21 Mar 2021 18:29:56 +0000
+Subject: iio:accel:adis16201: Fix wrong axis assignment that prevents loading
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 4e102429f3dc62dce546f6107e34a4284634196d upstream.
+
+Whilst running some basic tests as part of writing up the dt-bindings for
+this driver (to follow), it became clear it doesn't actually load
+currently.
+
+iio iio:device1: tried to double register : in_incli_x_index
+adis16201 spi0.0: Failed to create buffer sysfs interfaces
+adis16201: probe of spi0.0 failed with error -16
+
+Looks like a cut and paste / update bug. Fixes tag obviously not accurate
+but we don't want to bother carry thing back to before the driver moved
+out of staging.
+
+Fixes: 591298e54cea ("Staging: iio: accel: adis16201: Move adis16201 driver out of staging")
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Cc: <Stable@vger.kernel.org>
+Cc: Himanshu Jha <himanshujha199640@gmail.com>
+Cc: Nuno Sá <nuno.sa@analog.com>
+Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
+Link: https://lore.kernel.org/r/20210321182956.844652-1-jic23@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/accel/adis16201.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/accel/adis16201.c
++++ b/drivers/iio/accel/adis16201.c
+@@ -215,7 +215,7 @@ static const struct iio_chan_spec adis16
+ ADIS_AUX_ADC_CHAN(ADIS16201_AUX_ADC_REG, ADIS16201_SCAN_AUX_ADC, 0, 12),
+ ADIS_INCLI_CHAN(X, ADIS16201_XINCL_OUT_REG, ADIS16201_SCAN_INCLI_X,
+ BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14),
+- ADIS_INCLI_CHAN(X, ADIS16201_YINCL_OUT_REG, ADIS16201_SCAN_INCLI_Y,
++ ADIS_INCLI_CHAN(Y, ADIS16201_YINCL_OUT_REG, ADIS16201_SCAN_INCLI_Y,
+ BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14),
+ IIO_CHAN_SOFT_TIMESTAMP(7)
+ };
--- /dev/null
+From 6baee4bd63f5fdf1716f88e95c21a683e94fe30d Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Thu, 1 Apr 2021 18:17:57 +0100
+Subject: iio:adc:ad7476: Fix remove handling
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit 6baee4bd63f5fdf1716f88e95c21a683e94fe30d upstream.
+
+This driver was in an odd half way state between devm based cleanup
+and manual cleanup (most of which was missing).
+I would guess something went wrong with a rebase or similar.
+Anyhow, this basically finishes the job as a precursor to improving
+the regulator handling.
+
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Fixes: 4bb2b8f94ace3 ("iio: adc: ad7476: implement devm_add_action_or_reset")
+Cc: Michael Hennerich <michael.hennerich@analog.com>
+Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210401171759.318140-2-jic23@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/ad7476.c | 18 ++++--------------
+ 1 file changed, 4 insertions(+), 14 deletions(-)
+
+--- a/drivers/iio/adc/ad7476.c
++++ b/drivers/iio/adc/ad7476.c
+@@ -316,25 +316,15 @@ static int ad7476_probe(struct spi_devic
+ spi_message_init(&st->msg);
+ spi_message_add_tail(&st->xfer, &st->msg);
+
+- ret = iio_triggered_buffer_setup(indio_dev, NULL,
+- &ad7476_trigger_handler, NULL);
++ ret = devm_iio_triggered_buffer_setup(&spi->dev, indio_dev, NULL,
++ &ad7476_trigger_handler, NULL);
+ if (ret)
+- goto error_disable_reg;
++ return ret;
+
+ if (st->chip_info->reset)
+ st->chip_info->reset(st);
+
+- ret = iio_device_register(indio_dev);
+- if (ret)
+- goto error_ring_unregister;
+- return 0;
+-
+-error_ring_unregister:
+- iio_triggered_buffer_cleanup(indio_dev);
+-error_disable_reg:
+- regulator_disable(st->reg);
+-
+- return ret;
++ return devm_iio_device_register(&spi->dev, indio_dev);
+ }
+
+ static const struct spi_device_id ad7476_id[] = {
--- /dev/null
+From e09fe9135399807b8397798a53160e055dc6c29f Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Mon, 5 Apr 2021 13:44:41 +0200
+Subject: iio: inv_mpu6050: Fully validate gyro and accel scale writes
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit e09fe9135399807b8397798a53160e055dc6c29f upstream.
+
+When setting the gyro or accelerometer scale the inv_mpu6050 driver ignores
+the integer part of the value. As a result e.g. all of 0.13309, 1.13309,
+12345.13309, ... are accepted as a valid gyro scale and 0.13309 is the
+scale that gets set in all those cases.
+
+Make sure to check that the integer part of the scale value is 0 and reject
+it otherwise.
+
+Fixes: 09a642b78523 ("Invensense MPU6050 Device Driver.")
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
+Link: https://lore.kernel.org/r/20210405114441.24167-1-lars@metafoo.de
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 20 ++++++++++++++------
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
++++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
+@@ -723,12 +723,16 @@ inv_mpu6050_read_raw(struct iio_dev *ind
+ }
+ }
+
+-static int inv_mpu6050_write_gyro_scale(struct inv_mpu6050_state *st, int val)
++static int inv_mpu6050_write_gyro_scale(struct inv_mpu6050_state *st, int val,
++ int val2)
+ {
+ int result, i;
+
++ if (val != 0)
++ return -EINVAL;
++
+ for (i = 0; i < ARRAY_SIZE(gyro_scale_6050); ++i) {
+- if (gyro_scale_6050[i] == val) {
++ if (gyro_scale_6050[i] == val2) {
+ result = inv_mpu6050_set_gyro_fsr(st, i);
+ if (result)
+ return result;
+@@ -759,13 +763,17 @@ static int inv_write_raw_get_fmt(struct
+ return -EINVAL;
+ }
+
+-static int inv_mpu6050_write_accel_scale(struct inv_mpu6050_state *st, int val)
++static int inv_mpu6050_write_accel_scale(struct inv_mpu6050_state *st, int val,
++ int val2)
+ {
+ int result, i;
+ u8 d;
+
++ if (val != 0)
++ return -EINVAL;
++
+ for (i = 0; i < ARRAY_SIZE(accel_scale); ++i) {
+- if (accel_scale[i] == val) {
++ if (accel_scale[i] == val2) {
+ d = (i << INV_MPU6050_ACCL_CONFIG_FSR_SHIFT);
+ result = regmap_write(st->map, st->reg->accl_config, d);
+ if (result)
+@@ -806,10 +814,10 @@ static int inv_mpu6050_write_raw(struct
+ case IIO_CHAN_INFO_SCALE:
+ switch (chan->type) {
+ case IIO_ANGL_VEL:
+- result = inv_mpu6050_write_gyro_scale(st, val2);
++ result = inv_mpu6050_write_gyro_scale(st, val, val2);
+ break;
+ case IIO_ACCEL:
+- result = inv_mpu6050_write_accel_scale(st, val2);
++ result = inv_mpu6050_write_accel_scale(st, val, val2);
+ break;
+ default:
+ result = -EINVAL;
--- /dev/null
+From 6f0078ae704d94b1a93e5f3d0a44cf3d8090fa91 Mon Sep 17 00:00:00 2001
+From: Gwendal Grignou <gwendal@chromium.org>
+Date: Fri, 26 Mar 2021 11:46:02 -0700
+Subject: iio: sx9310: Fix access to variable DT array
+
+From: Gwendal Grignou <gwendal@chromium.org>
+
+commit 6f0078ae704d94b1a93e5f3d0a44cf3d8090fa91 upstream.
+
+With the current code, we want to read 4 entries from DT array
+"semtech,combined-sensors". If there are less, we silently fail as
+of_property_read_u32_array() returns -EOVERFLOW.
+
+First count the number of entries and if between 1 and 4, collect the
+content of the array.
+
+Fixes: 5b19ca2c78a0 ("iio: sx9310: Set various settings from DT")
+Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Link: https://lore.kernel.org/r/20210326184603.251683-2-gwendal@chromium.org
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/proximity/sx9310.c | 40 ++++++++++++++++++++++++++++------------
+ 1 file changed, 28 insertions(+), 12 deletions(-)
+
+--- a/drivers/iio/proximity/sx9310.c
++++ b/drivers/iio/proximity/sx9310.c
+@@ -1221,17 +1221,17 @@ static int sx9310_init_compensation(stru
+ }
+
+ static const struct sx9310_reg_default *
+-sx9310_get_default_reg(struct sx9310_data *data, int i,
++sx9310_get_default_reg(struct sx9310_data *data, int idx,
+ struct sx9310_reg_default *reg_def)
+ {
+- int ret;
+ const struct device_node *np = data->client->dev.of_node;
+- u32 combined[SX9310_NUM_CHANNELS] = { 4, 4, 4, 4 };
++ u32 combined[SX9310_NUM_CHANNELS];
++ u32 start = 0, raw = 0, pos = 0;
+ unsigned long comb_mask = 0;
++ int ret, i, count;
+ const char *res;
+- u32 start = 0, raw = 0, pos = 0;
+
+- memcpy(reg_def, &sx9310_default_regs[i], sizeof(*reg_def));
++ memcpy(reg_def, &sx9310_default_regs[idx], sizeof(*reg_def));
+ if (!np)
+ return reg_def;
+
+@@ -1242,15 +1242,31 @@ sx9310_get_default_reg(struct sx9310_dat
+ reg_def->def |= SX9310_REG_PROX_CTRL2_SHIELDEN_GROUND;
+ }
+
+- reg_def->def &= ~SX9310_REG_PROX_CTRL2_COMBMODE_MASK;
+- of_property_read_u32_array(np, "semtech,combined-sensors",
+- combined, ARRAY_SIZE(combined));
+- for (i = 0; i < ARRAY_SIZE(combined); i++) {
+- if (combined[i] <= SX9310_NUM_CHANNELS)
+- comb_mask |= BIT(combined[i]);
++ count = of_property_count_elems_of_size(np, "semtech,combined-sensors",
++ sizeof(u32));
++ if (count > 0 && count <= ARRAY_SIZE(combined)) {
++ ret = of_property_read_u32_array(np, "semtech,combined-sensors",
++ combined, count);
++ if (ret)
++ break;
++ } else {
++ /*
++ * Either the property does not exist in the DT or the
++ * number of entries is incorrect.
++ */
++ break;
+ }
++ for (i = 0; i < count; i++) {
++ if (combined[i] >= SX9310_NUM_CHANNELS) {
++ /* Invalid sensor (invalid DT). */
++ break;
++ }
++ comb_mask |= BIT(combined[i]);
++ }
++ if (i < count)
++ break;
+
+- comb_mask &= 0xf;
++ reg_def->def &= ~SX9310_REG_PROX_CTRL2_COMBMODE_MASK;
+ if (comb_mask == (BIT(3) | BIT(2) | BIT(1) | BIT(0)))
+ reg_def->def |= SX9310_REG_PROX_CTRL2_COMBMODE_CS0_CS1_CS2_CS3;
+ else if (comb_mask == (BIT(1) | BIT(2)))
--- /dev/null
+From fc948409ccc1e8afe8655cee77c686eedbfbee60 Mon Sep 17 00:00:00 2001
+From: Gwendal Grignou <gwendal@chromium.org>
+Date: Wed, 31 Mar 2021 11:22:22 -0700
+Subject: iio: sx9310: Fix write_.._debounce()
+
+From: Gwendal Grignou <gwendal@chromium.org>
+
+commit fc948409ccc1e8afe8655cee77c686eedbfbee60 upstream.
+
+Check input to be sure it matches Semtech sx9310 specification and
+can fit into debounce register.
+Compare argument writen to thresh_.._period with read from same
+sysfs attribute:
+
+Before: Afer:
+write | read write | read
+-1 | 8 -1 fails: -EINVAL
+0 | 8 0 | 0
+1 | 0 1 | 0
+2..15 | 2^log2(N) 2..15 | 2^log2(N)
+16 | 0 >= 16 fails: -EINVAL
+
+Fixes: 1b6872015f0b ("iio: sx9310: Support setting debounce values")
+Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
+Cc: stable@vger.kernel.org
+Reviewed-by: Stephen Boyd <swboyd@chromium.org>
+Link: https://lore.kernel.org/r/20210331182222.219533-1-gwendal@chromium.org
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/proximity/sx9310.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/proximity/sx9310.c
++++ b/drivers/iio/proximity/sx9310.c
+@@ -763,7 +763,11 @@ static int sx9310_write_far_debounce(str
+ int ret;
+ unsigned int regval;
+
+- val = ilog2(val);
++ if (val > 0)
++ val = ilog2(val);
++ if (!FIELD_FIT(SX9310_REG_PROX_CTRL10_FAR_DEBOUNCE_MASK, val))
++ return -EINVAL;
++
+ regval = FIELD_PREP(SX9310_REG_PROX_CTRL10_FAR_DEBOUNCE_MASK, val);
+
+ mutex_lock(&data->mutex);
+@@ -780,7 +784,11 @@ static int sx9310_write_close_debounce(s
+ int ret;
+ unsigned int regval;
+
+- val = ilog2(val);
++ if (val > 0)
++ val = ilog2(val);
++ if (!FIELD_FIT(SX9310_REG_PROX_CTRL10_CLOSE_DEBOUNCE_MASK, val))
++ return -EINVAL;
++
+ regval = FIELD_PREP(SX9310_REG_PROX_CTRL10_CLOSE_DEBOUNCE_MASK, val);
+
+ mutex_lock(&data->mutex);
--- /dev/null
+From f66c53b3b94f658590e1012bf6d922f8b7e01bda Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 4 Mar 2021 17:10:58 -0800
+Subject: KVM: x86: Defer the MMU unload to the normal path on an global INVPCID
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit f66c53b3b94f658590e1012bf6d922f8b7e01bda upstream.
+
+Defer unloading the MMU after a INVPCID until the instruction emulation
+has completed, i.e. until after RIP has been updated.
+
+On VMX, this is a benign bug as VMX doesn't touch the MMU when skipping
+an emulated instruction. However, on SVM, if nrip is disabled, the
+emulator is used to skip an instruction, which would lead to fireworks
+if the emulator were invoked without a valid MMU.
+
+Fixes: eb4b248e152d ("kvm: vmx: Support INVPCID in shadow paging mode")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20210305011101.3597423-15-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/x86.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -11407,7 +11407,7 @@ int kvm_handle_invpcid(struct kvm_vcpu *
+
+ fallthrough;
+ case INVPCID_TYPE_ALL_INCL_GLOBAL:
+- kvm_mmu_unload(vcpu);
++ kvm_make_request(KVM_REQ_MMU_RELOAD, vcpu);
+ return kvm_skip_emulated_instruction(vcpu);
+
+ default:
--- /dev/null
+From 404a8ef512587b2460107d3272c17a89aef75edf Mon Sep 17 00:00:00 2001
+From: Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com>
+Date: Tue, 13 Apr 2021 04:08:29 +0000
+Subject: md/bitmap: wait for external bitmap writes to complete during tear down
+
+From: Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com>
+
+commit 404a8ef512587b2460107d3272c17a89aef75edf upstream.
+
+NULL pointer dereference was observed in super_written() when it tries
+to access the mddev structure.
+
+[The below stack trace is from an older kernel, but the problem described
+in this patch applies to the mainline kernel.]
+
+[ 1194.474861] task: ffff8fdd20858000 task.stack: ffffb99d40790000
+[ 1194.488000] RIP: 0010:super_written+0x29/0xe1
+[ 1194.499688] RSP: 0018:ffff8ffb7fcc3c78 EFLAGS: 00010046
+[ 1194.512477] RAX: 0000000000000000 RBX: ffff8ffb7bf4a000 RCX: ffff8ffb78991048
+[ 1194.527325] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8ffb56b8a200
+[ 1194.542576] RBP: ffff8ffb7fcc3c90 R08: 000000000000000b R09: 0000000000000000
+[ 1194.558001] R10: ffff8ffb56b8a298 R11: 0000000000000000 R12: ffff8ffb56b8a200
+[ 1194.573070] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
+[ 1194.588117] FS: 0000000000000000(0000) GS:ffff8ffb7fcc0000(0000) knlGS:0000000000000000
+[ 1194.604264] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 1194.617375] CR2: 00000000000002b8 CR3: 00000021e040a002 CR4: 00000000007606e0
+[ 1194.632327] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 1194.647865] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 1194.663316] PKRU: 55555554
+[ 1194.674090] Call Trace:
+[ 1194.683735] <IRQ>
+[ 1194.692948] bio_endio+0xae/0x135
+[ 1194.703580] blk_update_request+0xad/0x2fa
+[ 1194.714990] blk_update_bidi_request+0x20/0x72
+[ 1194.726578] __blk_end_bidi_request+0x2c/0x4d
+[ 1194.738373] __blk_end_request_all+0x31/0x49
+[ 1194.749344] blk_flush_complete_seq+0x377/0x383
+[ 1194.761550] flush_end_io+0x1dd/0x2a7
+[ 1194.772910] blk_finish_request+0x9f/0x13c
+[ 1194.784544] scsi_end_request+0x180/0x25c
+[ 1194.796149] scsi_io_completion+0xc8/0x610
+[ 1194.807503] scsi_finish_command+0xdc/0x125
+[ 1194.818897] scsi_softirq_done+0x81/0xde
+[ 1194.830062] blk_done_softirq+0xa4/0xcc
+[ 1194.841008] __do_softirq+0xd9/0x29f
+[ 1194.851257] irq_exit+0xe6/0xeb
+[ 1194.861290] do_IRQ+0x59/0xe3
+[ 1194.871060] common_interrupt+0x1c6/0x382
+[ 1194.881988] </IRQ>
+[ 1194.890646] RIP: 0010:cpuidle_enter_state+0xdd/0x2a5
+[ 1194.902532] RSP: 0018:ffffb99d40793e68 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff43
+[ 1194.917317] RAX: ffff8ffb7fce27c0 RBX: ffff8ffb7fced800 RCX: 000000000000001f
+[ 1194.932056] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000
+[ 1194.946428] RBP: ffffb99d40793ea0 R08: 0000000000000004 R09: 0000000000002ed2
+[ 1194.960508] R10: 0000000000002664 R11: 0000000000000018 R12: 0000000000000003
+[ 1194.974454] R13: 000000000000000b R14: ffffffff925715a0 R15: 0000011610120d5a
+[ 1194.988607] ? cpuidle_enter_state+0xcc/0x2a5
+[ 1194.999077] cpuidle_enter+0x17/0x19
+[ 1195.008395] call_cpuidle+0x23/0x3a
+[ 1195.017718] do_idle+0x172/0x1d5
+[ 1195.026358] cpu_startup_entry+0x73/0x75
+[ 1195.035769] start_secondary+0x1b9/0x20b
+[ 1195.044894] secondary_startup_64+0xa5/0xa5
+[ 1195.084921] RIP: super_written+0x29/0xe1 RSP: ffff8ffb7fcc3c78
+[ 1195.096354] CR2: 00000000000002b8
+
+bio in the above stack is a bitmap write whose completion is invoked after
+the tear down sequence sets the mddev structure to NULL in rdev.
+
+During tear down, there is an attempt to flush the bitmap writes, but for
+external bitmaps, there is no explicit wait for all the bitmap writes to
+complete. For instance, md_bitmap_flush() is called to flush the bitmap
+writes, but the last call to md_bitmap_daemon_work() in md_bitmap_flush()
+could generate new bitmap writes for which there is no explicit wait to
+complete those writes. The call to md_bitmap_update_sb() will return
+simply for external bitmaps and the follow-up call to md_update_sb() is
+conditional and may not get called for external bitmaps. This results in a
+kernel panic when the completion routine, super_written() is called which
+tries to reference mddev in the rdev that has been set to
+NULL(in unbind_rdev_from_array() by tear down sequence).
+
+The solution is to call md_super_wait() for external bitmaps after the
+last call to md_bitmap_daemon_work() in md_bitmap_flush() to ensure there
+are no pending bitmap writes before proceeding with the tear down.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com>
+Reviewed-by: Zhao Heming <heming.zhao@suse.com>
+Signed-off-by: Song Liu <song@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/md-bitmap.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/md/md-bitmap.c
++++ b/drivers/md/md-bitmap.c
+@@ -1722,6 +1722,8 @@ void md_bitmap_flush(struct mddev *mddev
+ md_bitmap_daemon_work(mddev);
+ bitmap->daemon_lastrun -= sleep;
+ md_bitmap_daemon_work(mddev);
++ if (mddev->bitmap_info.external)
++ md_super_wait(mddev);
+ md_bitmap_update_sb(bitmap);
+ }
+
--- /dev/null
+From c15b99ae2ba9ea30da3c7cd4765b8a4707e530a6 Mon Sep 17 00:00:00 2001
+From: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
+Date: Sat, 6 Mar 2021 20:17:24 -0800
+Subject: MIPS: pci-mt7620: fix PLL lock check
+
+From: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
+
+commit c15b99ae2ba9ea30da3c7cd4765b8a4707e530a6 upstream.
+
+Upstream a long-standing OpenWrt patch [0] that fixes MT7620 PCIe PLL
+lock check. The existing code checks the wrong register bit: PPLL_SW_SET
+is not defined in PPLL_CFG1 and bit 31 of PPLL_CFG1 is marked as reserved
+in the MT7620 Programming Guide. The correct bit to check for PLL lock
+is PPLL_LD (bit 23).
+
+Also reword the error message for clarity.
+
+Without this change it is unlikely that this driver ever worked with
+mainline kernel.
+
+[0]: https://lists.infradead.org/pipermail/lede-commits/2017-July/004441.html
+
+Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
+Cc: John Crispin <john@phrozen.org>
+Cc: linux-mips@vger.kernel.org
+Cc: linux-mediatek@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Cc: stable@vger.kernel.org
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/mips/pci/pci-mt7620.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/mips/pci/pci-mt7620.c
++++ b/arch/mips/pci/pci-mt7620.c
+@@ -30,6 +30,7 @@
+ #define RALINK_GPIOMODE 0x60
+
+ #define PPLL_CFG1 0x9c
++#define PPLL_LD BIT(23)
+
+ #define PPLL_DRV 0xa0
+ #define PDRV_SW_SET BIT(31)
+@@ -239,8 +240,8 @@ static int mt7620_pci_hw_init(struct pla
+ rt_sysc_m32(0, RALINK_PCIE0_CLK_EN, RALINK_CLKCFG1);
+ mdelay(100);
+
+- if (!(rt_sysc_r32(PPLL_CFG1) & PDRV_SW_SET)) {
+- dev_err(&pdev->dev, "MT7620 PPLL unlock\n");
++ if (!(rt_sysc_r32(PPLL_CFG1) & PPLL_LD)) {
++ dev_err(&pdev->dev, "pcie PLL not locked, aborting init\n");
+ reset_control_assert(rstpcie0);
+ rt_sysc_m32(RALINK_PCIE0_CLK_EN, 0, RALINK_CLKCFG1);
+ return -1;
--- /dev/null
+From 8e98b697006d749d745d3b174168a877bb96c500 Mon Sep 17 00:00:00 2001
+From: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
+Date: Tue, 13 Apr 2021 20:12:33 -0700
+Subject: MIPS: pci-rt2880: fix slot 0 configuration
+
+From: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
+
+commit 8e98b697006d749d745d3b174168a877bb96c500 upstream.
+
+pci_fixup_irqs() used to call pcibios_map_irq on every PCI device, which
+for RT2880 included bus 0 slot 0. After pci_fixup_irqs() got removed,
+only slots/funcs with devices attached would be called. While arguably
+the right thing, that left no chance for this driver to ever initialize
+slot 0, effectively bricking PCI and USB on RT2880 devices such as the
+Belkin F5D8235-4 v1.
+
+Slot 0 configuration needs to happen after PCI bus enumeration, but
+before any device at slot 0x11 (func 0 or 1) is talked to. That was
+determined empirically by testing on a Belkin F5D8235-4 v1 device. A
+minimal BAR 0 config write followed by read, then setting slot 0
+PCI_COMMAND to MASTER | IO | MEMORY is all that seems to be required for
+proper functionality.
+
+Tested by ensuring that full- and high-speed USB devices get enumerated
+on the Belkin F5D8235-4 v1 (with an out of tree DTS file from OpenWrt).
+
+Fixes: 04c81c7293df ("MIPS: PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks")
+Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
+Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Cc: Tobias Wolf <dev-NTEO@vplace.de>
+Cc: <stable@vger.kernel.org> # v4.14+
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/mips/pci/pci-rt2880.c | 37 ++++++++++++++++++++++++-------------
+ 1 file changed, 24 insertions(+), 13 deletions(-)
+
+--- a/arch/mips/pci/pci-rt2880.c
++++ b/arch/mips/pci/pci-rt2880.c
+@@ -180,7 +180,6 @@ static inline void rt2880_pci_write_u32(
+
+ int pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+ {
+- u16 cmd;
+ int irq = -1;
+
+ if (dev->bus->number != 0)
+@@ -188,8 +187,6 @@ int pcibios_map_irq(const struct pci_dev
+
+ switch (PCI_SLOT(dev->devfn)) {
+ case 0x00:
+- rt2880_pci_write_u32(PCI_BASE_ADDRESS_0, 0x08000000);
+- (void) rt2880_pci_read_u32(PCI_BASE_ADDRESS_0);
+ break;
+ case 0x11:
+ irq = RT288X_CPU_IRQ_PCI;
+@@ -201,16 +198,6 @@ int pcibios_map_irq(const struct pci_dev
+ break;
+ }
+
+- pci_write_config_byte((struct pci_dev *) dev,
+- PCI_CACHE_LINE_SIZE, 0x14);
+- pci_write_config_byte((struct pci_dev *) dev, PCI_LATENCY_TIMER, 0xFF);
+- pci_read_config_word((struct pci_dev *) dev, PCI_COMMAND, &cmd);
+- cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
+- PCI_COMMAND_INVALIDATE | PCI_COMMAND_FAST_BACK |
+- PCI_COMMAND_SERR | PCI_COMMAND_WAIT | PCI_COMMAND_PARITY;
+- pci_write_config_word((struct pci_dev *) dev, PCI_COMMAND, cmd);
+- pci_write_config_byte((struct pci_dev *) dev, PCI_INTERRUPT_LINE,
+- dev->irq);
+ return irq;
+ }
+
+@@ -251,6 +238,30 @@ static int rt288x_pci_probe(struct platf
+
+ int pcibios_plat_dev_init(struct pci_dev *dev)
+ {
++ static bool slot0_init;
++
++ /*
++ * Nobody seems to initialize slot 0, but this platform requires it, so
++ * do it once when some other slot is being enabled. The PCI subsystem
++ * should configure other slots properly, so no need to do anything
++ * special for those.
++ */
++ if (!slot0_init && dev->bus->number == 0) {
++ u16 cmd;
++ u32 bar0;
++
++ slot0_init = true;
++
++ pci_bus_write_config_dword(dev->bus, 0, PCI_BASE_ADDRESS_0,
++ 0x08000000);
++ pci_bus_read_config_dword(dev->bus, 0, PCI_BASE_ADDRESS_0,
++ &bar0);
++
++ pci_bus_read_config_word(dev->bus, 0, PCI_COMMAND, &cmd);
++ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
++ pci_bus_write_config_word(dev->bus, 0, PCI_COMMAND, cmd);
++ }
++
+ return 0;
+ }
+
--- /dev/null
+From 3641762c1c9c7cfd84a7061a0a73054f09b412e3 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 17 Feb 2021 11:24:59 +0100
+Subject: misc: lis3lv02d: Fix false-positive WARN on various HP models
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 3641762c1c9c7cfd84a7061a0a73054f09b412e3 upstream.
+
+Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch
+a potential divide by 0. WARN macros should only be used to catch internal
+kernel bugs and that is not the case here. We have been receiving a lot of
+bug reports about kernel backtraces caused by this WARN.
+
+The div value being checked comes from the lis3->odrs[] array. Which
+is sized to be a power-of-2 matching the number of bits in lis3->odr_mask.
+
+The only lis3 model where this array is not entirely filled with non zero
+values. IOW the only model where we can hit the div == 0 check is the
+3dc ("8 bits 3DC sensor") model:
+
+int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000};
+
+Note the 0 value at index 0, according to the datasheet an odr index of 0
+means "Power-down mode". HP typically uses a lis3 accelerometer for HDD
+fall protection. What I believe is happening here is that on newer
+HP devices, which only contain a SDD, the BIOS is leaving the lis3 device
+powered-down since it is not used for HDD fall protection.
+
+Note that the lis3_3dc_rates array initializer only specifies 10 values,
+which matches the datasheet. So it also contains 6 zero values at the end.
+
+Replace the WARN with a normal check, which treats an odr index of 0
+as power-down and uses a normal dev_err() to report the error in case
+odr index point past the initialized part of the array.
+
+Fixes: 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked")
+Cc: stable@vger.kernel.org
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=785814
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1817027
+BugLink: https://bugs.centos.org/view.php?id=10720
+Link: https://lore.kernel.org/r/20210217102501.31758-1-hdegoede@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/lis3lv02d/lis3lv02d.c | 21 ++++++++++++++++-----
+ 1 file changed, 16 insertions(+), 5 deletions(-)
+
+--- a/drivers/misc/lis3lv02d/lis3lv02d.c
++++ b/drivers/misc/lis3lv02d/lis3lv02d.c
+@@ -208,7 +208,7 @@ static int lis3_3dc_rates[16] = {0, 1, 1
+ static int lis3_3dlh_rates[4] = {50, 100, 400, 1000};
+
+ /* ODR is Output Data Rate */
+-static int lis3lv02d_get_odr(struct lis3lv02d *lis3)
++static int lis3lv02d_get_odr_index(struct lis3lv02d *lis3)
+ {
+ u8 ctrl;
+ int shift;
+@@ -216,15 +216,23 @@ static int lis3lv02d_get_odr(struct lis3
+ lis3->read(lis3, CTRL_REG1, &ctrl);
+ ctrl &= lis3->odr_mask;
+ shift = ffs(lis3->odr_mask) - 1;
+- return lis3->odrs[(ctrl >> shift)];
++ return (ctrl >> shift);
+ }
+
+ static int lis3lv02d_get_pwron_wait(struct lis3lv02d *lis3)
+ {
+- int div = lis3lv02d_get_odr(lis3);
++ int odr_idx = lis3lv02d_get_odr_index(lis3);
++ int div = lis3->odrs[odr_idx];
+
+- if (WARN_ONCE(div == 0, "device returned spurious data"))
++ if (div == 0) {
++ if (odr_idx == 0) {
++ /* Power-down mode, not sampling no need to sleep */
++ return 0;
++ }
++
++ dev_err(&lis3->pdev->dev, "Error unknown odrs-index: %d\n", odr_idx);
+ return -ENXIO;
++ }
+
+ /* LIS3 power on delay is quite long */
+ msleep(lis3->pwron_delay / div);
+@@ -816,9 +824,12 @@ static ssize_t lis3lv02d_rate_show(struc
+ struct device_attribute *attr, char *buf)
+ {
+ struct lis3lv02d *lis3 = dev_get_drvdata(dev);
++ int odr_idx;
+
+ lis3lv02d_sysfs_poweron(lis3);
+- return sprintf(buf, "%d\n", lis3lv02d_get_odr(lis3));
++
++ odr_idx = lis3lv02d_get_odr_index(lis3);
++ return sprintf(buf, "%d\n", lis3->odrs[odr_idx]);
+ }
+
+ static ssize_t lis3lv02d_rate_set(struct device *dev,
--- /dev/null
+From b2192cfeba8481224da0a4ec3b4a7ccd80b1623b Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Fri, 2 Apr 2021 21:17:42 +0900
+Subject: misc: vmw_vmci: explicitly initialize vmci_datagram payload
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+commit b2192cfeba8481224da0a4ec3b4a7ccd80b1623b upstream.
+
+KMSAN complains that vmci_check_host_caps() left the payload part of
+check_msg uninitialized.
+
+ =====================================================
+ BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10
+ CPU: 1 PID: 1 Comm: swapper/0 Tainted: G B 5.11.0-rc7+ #4
+ Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
+ Call Trace:
+ dump_stack+0x21c/0x280
+ kmsan_report+0xfb/0x1e0
+ kmsan_internal_check_memory+0x202/0x520
+ kmsan_check_memory+0xd/0x10
+ iowrite8_rep+0x86/0x380
+ vmci_guest_probe_device+0xf0b/0x1e70
+ pci_device_probe+0xab3/0xe70
+ really_probe+0xd16/0x24d0
+ driver_probe_device+0x29d/0x3a0
+ device_driver_attach+0x25a/0x490
+ __driver_attach+0x78c/0x840
+ bus_for_each_dev+0x210/0x340
+ driver_attach+0x89/0xb0
+ bus_add_driver+0x677/0xc40
+ driver_register+0x485/0x8e0
+ __pci_register_driver+0x1ff/0x350
+ vmci_guest_init+0x3e/0x41
+ vmci_drv_init+0x1d6/0x43f
+ do_one_initcall+0x39c/0x9a0
+ do_initcall_level+0x1d7/0x259
+ do_initcalls+0x127/0x1cb
+ do_basic_setup+0x33/0x36
+ kernel_init_freeable+0x29a/0x3ed
+ kernel_init+0x1f/0x840
+ ret_from_fork+0x1f/0x30
+
+ Uninit was created at:
+ kmsan_internal_poison_shadow+0x5c/0xf0
+ kmsan_slab_alloc+0x8d/0xe0
+ kmem_cache_alloc+0x84f/0xe30
+ vmci_guest_probe_device+0xd11/0x1e70
+ pci_device_probe+0xab3/0xe70
+ really_probe+0xd16/0x24d0
+ driver_probe_device+0x29d/0x3a0
+ device_driver_attach+0x25a/0x490
+ __driver_attach+0x78c/0x840
+ bus_for_each_dev+0x210/0x340
+ driver_attach+0x89/0xb0
+ bus_add_driver+0x677/0xc40
+ driver_register+0x485/0x8e0
+ __pci_register_driver+0x1ff/0x350
+ vmci_guest_init+0x3e/0x41
+ vmci_drv_init+0x1d6/0x43f
+ do_one_initcall+0x39c/0x9a0
+ do_initcall_level+0x1d7/0x259
+ do_initcalls+0x127/0x1cb
+ do_basic_setup+0x33/0x36
+ kernel_init_freeable+0x29a/0x3ed
+ kernel_init+0x1f/0x840
+ ret_from_fork+0x1f/0x30
+
+ Bytes 28-31 of 36 are uninitialized
+ Memory access of size 36 starts at ffff8881675e5f00
+ =====================================================
+
+Fixes: 1f166439917b69d3 ("VMCI: guest side driver implementation.")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Link: https://lore.kernel.org/r/20210402121742.3917-2-penguin-kernel@I-love.SAKURA.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/vmw_vmci/vmci_guest.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/misc/vmw_vmci/vmci_guest.c
++++ b/drivers/misc/vmw_vmci/vmci_guest.c
+@@ -168,7 +168,7 @@ static int vmci_check_host_caps(struct p
+ VMCI_UTIL_NUM_RESOURCES * sizeof(u32);
+ struct vmci_datagram *check_msg;
+
+- check_msg = kmalloc(msg_size, GFP_KERNEL);
++ check_msg = kzalloc(msg_size, GFP_KERNEL);
+ if (!check_msg) {
+ dev_err(&pdev->dev, "%s: Insufficient memory\n", __func__);
+ return -ENOMEM;
--- /dev/null
+From 376565b9717c30cd58ad33860fa42697615fa2e4 Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Fri, 2 Apr 2021 21:17:41 +0900
+Subject: misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+commit 376565b9717c30cd58ad33860fa42697615fa2e4 upstream.
+
+KMSAN complains that the vmci_use_ppn64() == false path in
+vmci_dbell_register_notification_bitmap() left upper 32bits of
+bitmap_set_msg.bitmap_ppn64 member uninitialized.
+
+ =====================================================
+ BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10
+ CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc7+ #4
+ Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
+ Call Trace:
+ dump_stack+0x21c/0x280
+ kmsan_report+0xfb/0x1e0
+ kmsan_internal_check_memory+0x484/0x520
+ kmsan_check_memory+0xd/0x10
+ iowrite8_rep+0x86/0x380
+ vmci_send_datagram+0x150/0x280
+ vmci_dbell_register_notification_bitmap+0x133/0x1e0
+ vmci_guest_probe_device+0xcab/0x1e70
+ pci_device_probe+0xab3/0xe70
+ really_probe+0xd16/0x24d0
+ driver_probe_device+0x29d/0x3a0
+ device_driver_attach+0x25a/0x490
+ __driver_attach+0x78c/0x840
+ bus_for_each_dev+0x210/0x340
+ driver_attach+0x89/0xb0
+ bus_add_driver+0x677/0xc40
+ driver_register+0x485/0x8e0
+ __pci_register_driver+0x1ff/0x350
+ vmci_guest_init+0x3e/0x41
+ vmci_drv_init+0x1d6/0x43f
+ do_one_initcall+0x39c/0x9a0
+ do_initcall_level+0x1d7/0x259
+ do_initcalls+0x127/0x1cb
+ do_basic_setup+0x33/0x36
+ kernel_init_freeable+0x29a/0x3ed
+ kernel_init+0x1f/0x840
+ ret_from_fork+0x1f/0x30
+
+ Local variable ----bitmap_set_msg@vmci_dbell_register_notification_bitmap created at:
+ vmci_dbell_register_notification_bitmap+0x50/0x1e0
+ vmci_dbell_register_notification_bitmap+0x50/0x1e0
+
+ Bytes 28-31 of 32 are uninitialized
+ Memory access of size 32 starts at ffff88810098f570
+ =====================================================
+
+Fixes: 83e2ec765be03e8a ("VMCI: doorbell implementation.")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Link: https://lore.kernel.org/r/20210402121742.3917-1-penguin-kernel@I-love.SAKURA.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/vmw_vmci/vmci_doorbell.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/misc/vmw_vmci/vmci_doorbell.c
++++ b/drivers/misc/vmw_vmci/vmci_doorbell.c
+@@ -326,7 +326,7 @@ int vmci_dbell_host_context_notify(u32 s
+ bool vmci_dbell_register_notification_bitmap(u64 bitmap_ppn)
+ {
+ int result;
+- struct vmci_notify_bm_set_msg bitmap_set_msg;
++ struct vmci_notify_bm_set_msg bitmap_set_msg = { };
+
+ bitmap_set_msg.hdr.dst = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
+ VMCI_SET_NOTIFY_BITMAP);
--- /dev/null
+From e00dc69b5f17c444a38cd9745a0f76bc989b3af4 Mon Sep 17 00:00:00 2001
+From: Arun Easi <aeasi@marvell.com>
+Date: Fri, 9 Apr 2021 14:51:53 -0700
+Subject: PCI: Allow VPD access for QLogic ISP2722
+
+From: Arun Easi <aeasi@marvell.com>
+
+commit e00dc69b5f17c444a38cd9745a0f76bc989b3af4 upstream.
+
+0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") disabled access
+to VPD of the ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter because
+reading past the end of the VPD caused NMIs.
+
+104daa71b396 ("PCI: Determine actual VPD size on first access") limits
+reads to the actual size of VPD, which should prevent these NMIs.
+
+104daa71b396 was merged *before* 0d5370d1d852, but we think the testing
+that prompted 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722")
+was done with a kernel that lacked 104daa71b396. See [1, 2].
+
+Remove the quirk added by 0d5370d1d852 ("PCI: Prevent VPD access for QLogic
+ISP2722") so customers can read the HBA VPD.
+
+[1] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2012161641230.28924@irv1user01.caveonetworks.com/
+[2] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2104071535110.13940@irv1user01.caveonetworks.com/
+[bhelgaas: commit log]
+Link: https://lore.kernel.org/r/20210409215153.16569-2-aeasi@marvell.com
+Signed-off-by: Arun Easi <aeasi@marvell.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org # v4.6+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/vpd.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/pci/vpd.c
++++ b/drivers/pci/vpd.c
+@@ -570,7 +570,6 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LS
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd);
+ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID,
+ quirk_blacklist_vpd);
+-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_QLOGIC, 0x2261, quirk_blacklist_vpd);
+ /*
+ * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port
+ * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class.
--- /dev/null
+From 3d0b2a3a87ce5ae85de46c4241afd52ab8b566fe Mon Sep 17 00:00:00 2001
+From: Kishon Vijay Abraham I <kishon@ti.com>
+Date: Wed, 17 Mar 2021 18:45:18 +0530
+Subject: PCI: keystone: Let AM65 use the pci_ops defined in pcie-designware-host.c
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Kishon Vijay Abraham I <kishon@ti.com>
+
+commit 3d0b2a3a87ce5ae85de46c4241afd52ab8b566fe upstream.
+
+Both TI's AM65x (K3) and TI's K2 PCIe driver are implemented in
+pci-keystone. However Only K2 PCIe driver should use it's own pci_ops
+for configuration space accesses. But commit 10a797c6e54a
+("PCI: dwc: keystone: Use pci_ops for config space accessors") used
+custom pci_ops for both AM65x and K2. This breaks configuration space
+access for AM65x platform. Fix it here.
+
+Link: https://lore.kernel.org/r/20210317131518.11040-1-kishon@ti.com
+Fixes: 10a797c6e54a ("PCI: dwc: keystone: Use pci_ops for config space accessors")
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
+Cc: <stable@vger.kernel.org> # v5.10
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/dwc/pci-keystone.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/pci/controller/dwc/pci-keystone.c
++++ b/drivers/pci/controller/dwc/pci-keystone.c
+@@ -798,7 +798,8 @@ static int __init ks_pcie_host_init(stru
+ int ret;
+
+ pp->bridge->ops = &ks_pcie_ops;
+- pp->bridge->child_ops = &ks_child_pcie_ops;
++ if (!ks_pcie->is_am6)
++ pp->bridge->child_ops = &ks_child_pcie_ops;
+
+ ret = ks_pcie_config_legacy_irq(ks_pcie);
+ if (ret)
--- /dev/null
+From d4707d79fae08c8996a1ba45965a491045a22dda Mon Sep 17 00:00:00 2001
+From: Dejin Zheng <zhengdejin5@gmail.com>
+Date: Sun, 28 Mar 2021 22:41:18 +0800
+Subject: PCI: xgene: Fix cfg resource mapping
+
+From: Dejin Zheng <zhengdejin5@gmail.com>
+
+commit d4707d79fae08c8996a1ba45965a491045a22dda upstream.
+
+In commit e2dcd20b1645 a change was made to use
+devm_platform_ioremap_resource_byname() to simplify code and remove
+the res variable; this was wrong since the res variable is still needed
+and as an outcome the port->cfg_addr gets an erroneous address.
+
+Revert the change going back to original behaviour.
+
+Link: https://lore.kernel.org/r/20210328144118.305074-1-zhengdejin5@gmail.com
+Fixes: e2dcd20b1645a ("PCI: controller: Convert to devm_platform_ioremap_resource_byname()")
+Reported-by: dann.frazier@canonical.com
+Tested-by: dann frazier <dann.frazier@canonical.com>
+Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Cc: stable@vger.kernel.org # v5.9+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/controller/pci-xgene.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/pci/controller/pci-xgene.c
++++ b/drivers/pci/controller/pci-xgene.c
+@@ -353,7 +353,8 @@ static int xgene_pcie_map_reg(struct xge
+ if (IS_ERR(port->csr_base))
+ return PTR_ERR(port->csr_base);
+
+- port->cfg_base = devm_platform_ioremap_resource_byname(pdev, "cfg");
++ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
++ port->cfg_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(port->cfg_base))
+ return PTR_ERR(port->cfg_base);
+ port->cfg_addr = res->start;
--- /dev/null
+From 5b4f5757f83be34d1428a1ffbb68d4a1966e9aae Mon Sep 17 00:00:00 2001
+From: Kishon Vijay Abraham I <kishon@ti.com>
+Date: Fri, 19 Mar 2021 18:11:16 +0530
+Subject: phy: cadence: Sierra: Fix PHY power_on sequence
+
+From: Kishon Vijay Abraham I <kishon@ti.com>
+
+commit 5b4f5757f83be34d1428a1ffbb68d4a1966e9aae upstream.
+
+Commit 44d30d622821d ("phy: cadence: Add driver for Sierra PHY")
+de-asserts PHY_RESET even before the configurations are loaded in
+phy_init(). However PHY_RESET should be de-asserted only after
+all the configurations has been initialized, instead of de-asserting
+in probe. Fix it here.
+
+Fixes: 44d30d622821d ("phy: cadence: Add driver for Sierra PHY")
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Cc: <stable@vger.kernel.org> # v5.4+
+Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
+Link: https://lore.kernel.org/r/20210319124128.13308-2-kishon@ti.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/phy/cadence/phy-cadence-sierra.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/phy/cadence/phy-cadence-sierra.c
++++ b/drivers/phy/cadence/phy-cadence-sierra.c
+@@ -319,6 +319,12 @@ static int cdns_sierra_phy_on(struct phy
+ u32 val;
+ int ret;
+
++ ret = reset_control_deassert(sp->phy_rst);
++ if (ret) {
++ dev_err(dev, "Failed to take the PHY out of reset\n");
++ return ret;
++ }
++
+ /* Take the PHY lane group out of reset */
+ ret = reset_control_deassert(ins->lnk_rst);
+ if (ret) {
+@@ -616,7 +622,6 @@ static int cdns_sierra_phy_probe(struct
+
+ pm_runtime_enable(dev);
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+- reset_control_deassert(sp->phy_rst);
+ return PTR_ERR_OR_ZERO(phy_provider);
+
+ put_child:
--- /dev/null
+From f7eb147d306ad2efae6837e20d2944f03be42eb4 Mon Sep 17 00:00:00 2001
+From: Kishon Vijay Abraham I <kishon@ti.com>
+Date: Fri, 19 Mar 2021 18:11:17 +0530
+Subject: phy: ti: j721e-wiz: Invoke wiz_init() before of_platform_device_create()
+
+From: Kishon Vijay Abraham I <kishon@ti.com>
+
+commit f7eb147d306ad2efae6837e20d2944f03be42eb4 upstream.
+
+Invoke wiz_init() before configuring anything else in Sierra/Torrent
+(invoked as part of of_platform_device_create()). wiz_init() resets the
+SERDES device and any configuration done in the probe() of
+Sierra/Torrent will be lost. In order to prevent SERDES configuration
+from getting reset, invoke wiz_init() immediately before invoking
+of_platform_device_create().
+
+Fixes: 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC")
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Reviewed-by: Swapnil Jakhade <sjakhade@cadence.com>
+Cc: <stable@vger.kernel.org> # v5.10
+Link: https://lore.kernel.org/r/20210319124128.13308-3-kishon@ti.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/phy/ti/phy-j721e-wiz.c | 17 +++++++----------
+ 1 file changed, 7 insertions(+), 10 deletions(-)
+
+--- a/drivers/phy/ti/phy-j721e-wiz.c
++++ b/drivers/phy/ti/phy-j721e-wiz.c
+@@ -947,27 +947,24 @@ static int wiz_probe(struct platform_dev
+ goto err_get_sync;
+ }
+
++ ret = wiz_init(wiz);
++ if (ret) {
++ dev_err(dev, "WIZ initialization failed\n");
++ goto err_wiz_init;
++ }
++
+ serdes_pdev = of_platform_device_create(child_node, NULL, dev);
+ if (!serdes_pdev) {
+ dev_WARN(dev, "Unable to create SERDES platform device\n");
+ ret = -ENOMEM;
+- goto err_pdev_create;
+- }
+- wiz->serdes_pdev = serdes_pdev;
+-
+- ret = wiz_init(wiz);
+- if (ret) {
+- dev_err(dev, "WIZ initialization failed\n");
+ goto err_wiz_init;
+ }
++ wiz->serdes_pdev = serdes_pdev;
+
+ of_node_put(child_node);
+ return 0;
+
+ err_wiz_init:
+- of_platform_device_destroy(&serdes_pdev->dev, NULL);
+-
+-err_pdev_create:
+ wiz_clock_cleanup(wiz, node);
+
+ err_get_sync:
--- /dev/null
+From 8b50a7995770d41a2e8d9c422cd2882aca0dedd2 Mon Sep 17 00:00:00 2001
+From: Lukasz Luba <lukasz.luba@arm.com>
+Date: Mon, 15 Mar 2021 09:31:23 +0000
+Subject: PM / devfreq: Unlock mutex and free devfreq struct in error path
+
+From: Lukasz Luba <lukasz.luba@arm.com>
+
+commit 8b50a7995770d41a2e8d9c422cd2882aca0dedd2 upstream.
+
+The devfreq->lock is held for time of setup. Release the lock in the
+error path, before jumping to the end of the function.
+
+Change the goto destination which frees the allocated memory.
+
+Cc: v5.9+ <stable@vger.kernel.org> # v5.9+
+Fixes: 4dc3bab8687f ("PM / devfreq: Add support delayed timer for polling mode")
+Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
+Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/devfreq/devfreq.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/devfreq/devfreq.c
++++ b/drivers/devfreq/devfreq.c
+@@ -818,7 +818,8 @@ struct devfreq *devfreq_add_device(struc
+
+ if (devfreq->profile->timer < 0
+ || devfreq->profile->timer >= DEVFREQ_TIMER_NUM) {
+- goto err_out;
++ mutex_unlock(&devfreq->lock);
++ goto err_dev;
+ }
+
+ if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
--- /dev/null
+From 158e800e0fde91014812f5cdfb92ce812e3a33b4 Mon Sep 17 00:00:00 2001
+From: Annaliese McDermond <nh6z@nh6z.net>
+Date: Mon, 29 Mar 2021 20:10:49 +0000
+Subject: sc16is7xx: Defer probe if device read fails
+
+From: Annaliese McDermond <nh6z@nh6z.net>
+
+commit 158e800e0fde91014812f5cdfb92ce812e3a33b4 upstream.
+
+A test was added to the probe function to ensure the device was
+actually connected and working before successfully completing a
+probe. If the device was actually there, but the I2C bus was not
+ready yet for whatever reason, the probe fails permanently.
+
+Change the probe so that we defer the probe on a regmap read
+failure so that we try the probe again when the dependent drivers
+are potentially loaded. This should not affect the case where the
+device truly isn't present because the probe will never successfully
+complete.
+
+Fixes: 2aa916e67db3 ("sc16is7xx: Read the LSR register for basic device presence check")
+Cc: stable@vger.kernel.org
+Signed-off-by: Annaliese McDermond <nh6z@nh6z.net>
+Link: https://lore.kernel.org/r/010101787f9c3fd8-c1815c00-2d6b-4c85-a96a-a13e68597fda-000000@us-west-2.amazonses.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/sc16is7xx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/sc16is7xx.c
++++ b/drivers/tty/serial/sc16is7xx.c
+@@ -1196,7 +1196,7 @@ static int sc16is7xx_probe(struct device
+ ret = regmap_read(regmap,
+ SC16IS7XX_LSR_REG << SC16IS7XX_REG_SHIFT, &val);
+ if (ret < 0)
+- return ret;
++ return -EPROBE_DEFER;
+
+ /* Alloc port structure */
+ s = devm_kzalloc(dev, struct_size(s, p, devtype->nr_uart), GFP_KERNEL);
--- /dev/null
+From e4c82eafb609c2badc56f4e11bc50fcf44b8e9eb Mon Sep 17 00:00:00 2001
+From: Paul Moore <paul@paul-moore.com>
+Date: Wed, 21 Apr 2021 21:15:36 -0400
+Subject: selinux: add proper NULL termination to the secclass_map permissions
+
+From: Paul Moore <paul@paul-moore.com>
+
+commit e4c82eafb609c2badc56f4e11bc50fcf44b8e9eb upstream.
+
+This patch adds the missing NULL termination to the "bpf" and
+"perf_event" object class permission lists.
+
+This missing NULL termination should really only affect the tools
+under scripts/selinux, with the most important being genheaders.c,
+although in practice this has not been an issue on any of my dev/test
+systems. If the problem were to manifest itself it would likely
+result in bogus permissions added to the end of the object class;
+thankfully with no access control checks using these bogus
+permissions and no policies defining these permissions the impact
+would likely be limited to some noise about undefined permissions
+during policy load.
+
+Cc: stable@vger.kernel.org
+Fixes: ec27c3568a34 ("selinux: bpf: Add selinux check for eBPF syscall operations")
+Fixes: da97e18458fb ("perf_event: Add support for LSM and SELinux checks")
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ security/selinux/include/classmap.h | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/security/selinux/include/classmap.h
++++ b/security/selinux/include/classmap.h
+@@ -242,11 +242,12 @@ struct security_class_mapping secclass_m
+ { "infiniband_endport",
+ { "manage_subnet", NULL } },
+ { "bpf",
+- {"map_create", "map_read", "map_write", "prog_load", "prog_run"} },
++ { "map_create", "map_read", "map_write", "prog_load", "prog_run",
++ NULL } },
+ { "xdp_socket",
+ { COMMON_SOCK_PERMS, NULL } },
+ { "perf_event",
+- {"open", "cpu", "kernel", "tracepoint", "read", "write"} },
++ { "open", "cpu", "kernel", "tracepoint", "read", "write", NULL } },
+ { "lockdown",
+ { "integrity", "confidentiality", NULL } },
+ { NULL }
tty-moxa-fix-tiocsserial-permission-check.patch
staging-fwserial-fix-tiocsserial-permission-check.patch
drm-bridge-fix-lontium-use-of-mipi_dsi_-functions.patch
+usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch
+usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch
+usb-typec-tcpm-update-power-supply-once-partner-accepts.patch
+usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch
+usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch
+asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch
+asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch
+asoc-tlv320aic32x4-register-clocks-before-registering-component.patch
+asoc-tlv320aic32x4-increase-maximum-register-in-regmap.patch
+mips-pci-mt7620-fix-pll-lock-check.patch
+mips-pci-rt2880-fix-slot-0-configuration.patch
+fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch
+pci-allow-vpd-access-for-qlogic-isp2722.patch
+kvm-x86-defer-the-mmu-unload-to-the-normal-path-on-an-global-invpcid.patch
+pci-xgene-fix-cfg-resource-mapping.patch
+pci-keystone-let-am65-use-the-pci_ops-defined-in-pcie-designware-host.c.patch
+pm-devfreq-unlock-mutex-and-free-devfreq-struct-in-error-path.patch
+soc-tegra-regulators-fix-locking-up-when-voltage-spread-is-out-of-range.patch
+iio-inv_mpu6050-fully-validate-gyro-and-accel-scale-writes.patch
+iio-sx9310-fix-write_.._debounce.patch
+iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch
+iio-adc-ad7476-fix-remove-handling.patch
+iio-sx9310-fix-access-to-variable-dt-array.patch
+sc16is7xx-defer-probe-if-device-read-fails.patch
+phy-cadence-sierra-fix-phy-power_on-sequence.patch
+misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch
+phy-ti-j721e-wiz-invoke-wiz_init-before-of_platform_device_create.patch
+misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch
+misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch
+selinux-add-proper-null-termination-to-the-secclass_map-permissions.patch
+x86-sched-treat-intel-snc-topology-as-default-cod-as-exception.patch
+async_xor-increase-src_offs-when-dropping-destination-page.patch
+md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch
--- /dev/null
+From ef85bb582c41524e9e68dfdbde48e519dac4ab3d Mon Sep 17 00:00:00 2001
+From: Dmitry Osipenko <digetx@gmail.com>
+Date: Tue, 2 Mar 2021 16:18:00 +0300
+Subject: soc/tegra: regulators: Fix locking up when voltage-spread is out of range
+
+From: Dmitry Osipenko <digetx@gmail.com>
+
+commit ef85bb582c41524e9e68dfdbde48e519dac4ab3d upstream.
+
+Fix voltage coupler lockup which happens when voltage-spread is out
+of range due to a bug in the code. The max-spread requirement shall be
+accounted when CPU regulator doesn't have consumers. This problem is
+observed on Tegra30 Ouya game console once system-wide DVFS is enabled
+in a device-tree.
+
+Fixes: 783807436f36 ("soc/tegra: regulators: Add regulators coupler for Tegra30")
+Cc: stable@vger.kernel.org
+Reported-by: Peter Geis <pgwipeout@gmail.com>
+Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30
+Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30
+Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soc/tegra/regulators-tegra30.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/soc/tegra/regulators-tegra30.c
++++ b/drivers/soc/tegra/regulators-tegra30.c
+@@ -178,7 +178,7 @@ static int tegra30_voltage_update(struct
+ * survive the voltage drop if it's running on a higher frequency.
+ */
+ if (!cpu_min_uV_consumers)
+- cpu_min_uV = cpu_uV;
++ cpu_min_uV = max(cpu_uV, cpu_min_uV);
+
+ /*
+ * Bootloader shall set up voltages correctly, but if it
--- /dev/null
+From f3dedafb8263ca4791a92a23f5230068f5bde008 Mon Sep 17 00:00:00 2001
+From: Badhri Jagan Sridharan <badhri@google.com>
+Date: Wed, 7 Apr 2021 13:07:18 -0700
+Subject: usb: typec: tcpm: Address incorrect values of tcpm psy for fixed supply
+
+From: Badhri Jagan Sridharan <badhri@google.com>
+
+commit f3dedafb8263ca4791a92a23f5230068f5bde008 upstream.
+
+tcpm_pd_build_request overwrites current_limit and supply_voltage
+even before port partner accepts the requests. This leaves stale
+values in current_limit and supply_voltage that get exported by
+"tcpm-source-psy-". Solving this problem by caching the request
+values of current limit/supply voltage in req_current_limit
+and req_supply_voltage. current_limit/supply_voltage gets updated
+once the port partner accepts the request.
+
+Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply")
+Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
+Cc: stable <stable@vger.kernel.org>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
+Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20210407200723.1914388-1-badhri@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/tcpm/tcpm.c | 17 ++++++++++-------
+ 1 file changed, 10 insertions(+), 7 deletions(-)
+
+--- a/drivers/usb/typec/tcpm/tcpm.c
++++ b/drivers/usb/typec/tcpm/tcpm.c
+@@ -338,7 +338,10 @@ struct tcpm_port {
+ unsigned int operating_snk_mw;
+ bool update_sink_caps;
+
+- /* Requested current / voltage */
++ /* Requested current / voltage to the port partner */
++ u32 req_current_limit;
++ u32 req_supply_voltage;
++ /* Actual current / voltage limit of the local port */
+ u32 current_limit;
+ u32 supply_voltage;
+
+@@ -1904,8 +1907,8 @@ static void tcpm_pd_ctrl_request(struct
+ case SNK_TRANSITION_SINK:
+ if (port->vbus_present) {
+ tcpm_set_current_limit(port,
+- port->current_limit,
+- port->supply_voltage);
++ port->req_current_limit,
++ port->req_supply_voltage);
+ port->explicit_contract = true;
+ tcpm_set_auto_vbus_discharge_threshold(port,
+ TYPEC_PWR_MODE_PD,
+@@ -1991,8 +1994,8 @@ static void tcpm_pd_ctrl_request(struct
+ break;
+ case SNK_NEGOTIATE_PPS_CAPABILITIES:
+ port->pps_data.active = true;
+- port->supply_voltage = port->pps_data.out_volt;
+- port->current_limit = port->pps_data.op_curr;
++ port->req_supply_voltage = port->pps_data.out_volt;
++ port->req_current_limit = port->pps_data.op_curr;
+ tcpm_set_state(port, SNK_TRANSITION_SINK, 0);
+ break;
+ case SOFT_RESET_SEND:
+@@ -2609,8 +2612,8 @@ static int tcpm_pd_build_request(struct
+ flags & RDO_CAP_MISMATCH ? " [mismatch]" : "");
+ }
+
+- port->current_limit = ma;
+- port->supply_voltage = mv;
++ port->req_current_limit = ma;
++ port->req_supply_voltage = mv;
+
+ return 0;
+ }
--- /dev/null
+From e3a0720224873587954b55d193d5b4abb14f0443 Mon Sep 17 00:00:00 2001
+From: Badhri Jagan Sridharan <badhri@google.com>
+Date: Wed, 7 Apr 2021 13:07:19 -0700
+Subject: usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply
+
+From: Badhri Jagan Sridharan <badhri@google.com>
+
+commit e3a0720224873587954b55d193d5b4abb14f0443 upstream.
+
+tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt,
+port->pps_data.max_volt, port->pps_data.max_curr even before
+port partner accepts the requests. This leaves incorrect values
+in current_limit and supply_voltage that get exported by
+"tcpm-source-psy-". Solving this problem by caching the request
+values in req_min_volt, req_max_volt, req_max_curr, req_out_volt,
+req_op_curr. min_volt, max_volt, max_curr gets updated once the
+partner accepts the request. current_limit, supply_voltage gets updated
+once local port's tcpm enters SNK_TRANSITION_SINK when the accepted
+current_limit and supply_voltage is enforced.
+
+Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply")
+Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
+Cc: stable <stable@vger.kernel.org>
+Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
+Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20210407200723.1914388-2-badhri@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/tcpm/tcpm.c | 88 +++++++++++++++++++++++++-----------------
+ 1 file changed, 53 insertions(+), 35 deletions(-)
+
+--- a/drivers/usb/typec/tcpm/tcpm.c
++++ b/drivers/usb/typec/tcpm/tcpm.c
+@@ -218,12 +218,27 @@ struct pd_mode_data {
+ struct typec_altmode_desc altmode_desc[ALTMODE_DISCOVERY_MAX];
+ };
+
++/*
++ * @min_volt: Actual min voltage at the local port
++ * @req_min_volt: Requested min voltage to the port partner
++ * @max_volt: Actual max voltage at the local port
++ * @req_max_volt: Requested max voltage to the port partner
++ * @max_curr: Actual max current at the local port
++ * @req_max_curr: Requested max current of the port partner
++ * @req_out_volt: Requested output voltage to the port partner
++ * @req_op_curr: Requested operating current to the port partner
++ * @supported: Parter has atleast one APDO hence supports PPS
++ * @active: PPS mode is active
++ */
+ struct pd_pps_data {
+ u32 min_volt;
++ u32 req_min_volt;
+ u32 max_volt;
++ u32 req_max_volt;
+ u32 max_curr;
+- u32 out_volt;
+- u32 op_curr;
++ u32 req_max_curr;
++ u32 req_out_volt;
++ u32 req_op_curr;
+ bool supported;
+ bool active;
+ };
+@@ -1954,8 +1969,8 @@ static void tcpm_pd_ctrl_request(struct
+ break;
+ case SNK_NEGOTIATE_PPS_CAPABILITIES:
+ /* Revert data back from any requested PPS updates */
+- port->pps_data.out_volt = port->supply_voltage;
+- port->pps_data.op_curr = port->current_limit;
++ port->pps_data.req_out_volt = port->supply_voltage;
++ port->pps_data.req_op_curr = port->current_limit;
+ port->pps_status = (type == PD_CTRL_WAIT ?
+ -EAGAIN : -EOPNOTSUPP);
+ tcpm_set_state(port, SNK_READY, 0);
+@@ -1994,8 +2009,11 @@ static void tcpm_pd_ctrl_request(struct
+ break;
+ case SNK_NEGOTIATE_PPS_CAPABILITIES:
+ port->pps_data.active = true;
+- port->req_supply_voltage = port->pps_data.out_volt;
+- port->req_current_limit = port->pps_data.op_curr;
++ port->pps_data.min_volt = port->pps_data.req_min_volt;
++ port->pps_data.max_volt = port->pps_data.req_max_volt;
++ port->pps_data.max_curr = port->pps_data.req_max_curr;
++ port->req_supply_voltage = port->pps_data.req_out_volt;
++ port->req_current_limit = port->pps_data.req_op_curr;
+ tcpm_set_state(port, SNK_TRANSITION_SINK, 0);
+ break;
+ case SOFT_RESET_SEND:
+@@ -2522,16 +2540,16 @@ static unsigned int tcpm_pd_select_pps_a
+ src = port->source_caps[src_pdo];
+ snk = port->snk_pdo[snk_pdo];
+
+- port->pps_data.min_volt = max(pdo_pps_apdo_min_voltage(src),
+- pdo_pps_apdo_min_voltage(snk));
+- port->pps_data.max_volt = min(pdo_pps_apdo_max_voltage(src),
+- pdo_pps_apdo_max_voltage(snk));
+- port->pps_data.max_curr = min_pps_apdo_current(src, snk);
+- port->pps_data.out_volt = min(port->pps_data.max_volt,
+- max(port->pps_data.min_volt,
+- port->pps_data.out_volt));
+- port->pps_data.op_curr = min(port->pps_data.max_curr,
+- port->pps_data.op_curr);
++ port->pps_data.req_min_volt = max(pdo_pps_apdo_min_voltage(src),
++ pdo_pps_apdo_min_voltage(snk));
++ port->pps_data.req_max_volt = min(pdo_pps_apdo_max_voltage(src),
++ pdo_pps_apdo_max_voltage(snk));
++ port->pps_data.req_max_curr = min_pps_apdo_current(src, snk);
++ port->pps_data.req_out_volt = min(port->pps_data.max_volt,
++ max(port->pps_data.min_volt,
++ port->pps_data.req_out_volt));
++ port->pps_data.req_op_curr = min(port->pps_data.max_curr,
++ port->pps_data.req_op_curr);
+ power_supply_changed(port->psy);
+ }
+
+@@ -2659,10 +2677,10 @@ static int tcpm_pd_build_pps_request(str
+ tcpm_log(port, "Invalid APDO selected!");
+ return -EINVAL;
+ }
+- max_mv = port->pps_data.max_volt;
+- max_ma = port->pps_data.max_curr;
+- out_mv = port->pps_data.out_volt;
+- op_ma = port->pps_data.op_curr;
++ max_mv = port->pps_data.req_max_volt;
++ max_ma = port->pps_data.req_max_curr;
++ out_mv = port->pps_data.req_out_volt;
++ op_ma = port->pps_data.req_op_curr;
+ break;
+ default:
+ tcpm_log(port, "Invalid PDO selected!");
+@@ -2709,8 +2727,8 @@ static int tcpm_pd_build_pps_request(str
+ tcpm_log(port, "Requesting APDO %d: %u mV, %u mA",
+ src_pdo_index, out_mv, op_ma);
+
+- port->pps_data.op_curr = op_ma;
+- port->pps_data.out_volt = out_mv;
++ port->pps_data.req_op_curr = op_ma;
++ port->pps_data.req_out_volt = out_mv;
+
+ return 0;
+ }
+@@ -4634,7 +4652,7 @@ static int tcpm_try_role(struct typec_po
+ return ret;
+ }
+
+-static int tcpm_pps_set_op_curr(struct tcpm_port *port, u16 op_curr)
++static int tcpm_pps_set_op_curr(struct tcpm_port *port, u16 req_op_curr)
+ {
+ unsigned int target_mw;
+ int ret;
+@@ -4652,22 +4670,22 @@ static int tcpm_pps_set_op_curr(struct t
+ goto port_unlock;
+ }
+
+- if (op_curr > port->pps_data.max_curr) {
++ if (req_op_curr > port->pps_data.max_curr) {
+ ret = -EINVAL;
+ goto port_unlock;
+ }
+
+- target_mw = (op_curr * port->pps_data.out_volt) / 1000;
++ target_mw = (req_op_curr * port->supply_voltage) / 1000;
+ if (target_mw < port->operating_snk_mw) {
+ ret = -EINVAL;
+ goto port_unlock;
+ }
+
+ /* Round down operating current to align with PPS valid steps */
+- op_curr = op_curr - (op_curr % RDO_PROG_CURR_MA_STEP);
++ req_op_curr = req_op_curr - (req_op_curr % RDO_PROG_CURR_MA_STEP);
+
+ reinit_completion(&port->pps_complete);
+- port->pps_data.op_curr = op_curr;
++ port->pps_data.req_op_curr = req_op_curr;
+ port->pps_status = 0;
+ port->pps_pending = true;
+ tcpm_set_state(port, SNK_NEGOTIATE_PPS_CAPABILITIES, 0);
+@@ -4689,7 +4707,7 @@ swap_unlock:
+ return ret;
+ }
+
+-static int tcpm_pps_set_out_volt(struct tcpm_port *port, u16 out_volt)
++static int tcpm_pps_set_out_volt(struct tcpm_port *port, u16 req_out_volt)
+ {
+ unsigned int target_mw;
+ int ret;
+@@ -4707,23 +4725,23 @@ static int tcpm_pps_set_out_volt(struct
+ goto port_unlock;
+ }
+
+- if (out_volt < port->pps_data.min_volt ||
+- out_volt > port->pps_data.max_volt) {
++ if (req_out_volt < port->pps_data.min_volt ||
++ req_out_volt > port->pps_data.max_volt) {
+ ret = -EINVAL;
+ goto port_unlock;
+ }
+
+- target_mw = (port->pps_data.op_curr * out_volt) / 1000;
++ target_mw = (port->current_limit * req_out_volt) / 1000;
+ if (target_mw < port->operating_snk_mw) {
+ ret = -EINVAL;
+ goto port_unlock;
+ }
+
+ /* Round down output voltage to align with PPS valid steps */
+- out_volt = out_volt - (out_volt % RDO_PROG_VOLT_MV_STEP);
++ req_out_volt = req_out_volt - (req_out_volt % RDO_PROG_VOLT_MV_STEP);
+
+ reinit_completion(&port->pps_complete);
+- port->pps_data.out_volt = out_volt;
++ port->pps_data.req_out_volt = req_out_volt;
+ port->pps_status = 0;
+ port->pps_pending = true;
+ tcpm_set_state(port, SNK_NEGOTIATE_PPS_CAPABILITIES, 0);
+@@ -4772,8 +4790,8 @@ static int tcpm_pps_activate(struct tcpm
+
+ /* Trigger PPS request or move back to standard PDO contract */
+ if (activate) {
+- port->pps_data.out_volt = port->supply_voltage;
+- port->pps_data.op_curr = port->current_limit;
++ port->pps_data.req_out_volt = port->supply_voltage;
++ port->pps_data.req_op_curr = port->current_limit;
+ tcpm_set_state(port, SNK_NEGOTIATE_PPS_CAPABILITIES, 0);
+ } else {
+ tcpm_set_state(port, SNK_NEGOTIATE_CAPABILITIES, 0);
--- /dev/null
+From 4050f2683f2c3151dc3dd1501ac88c57caf810ff Mon Sep 17 00:00:00 2001
+From: Badhri Jagan Sridharan <badhri@google.com>
+Date: Wed, 7 Apr 2021 13:07:20 -0700
+Subject: usb: typec: tcpm: update power supply once partner accepts
+
+From: Badhri Jagan Sridharan <badhri@google.com>
+
+commit 4050f2683f2c3151dc3dd1501ac88c57caf810ff upstream.
+
+power_supply_changed needs to be called to notify clients
+after the partner accepts the requested values for the pps
+case.
+
+Also, remove the redundant power_supply_changed at the end
+of the tcpm_reset_port as power_supply_changed is already
+called right after usb_type is changed.
+
+Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply")
+Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
+Cc: stable <stable@vger.kernel.org>
+Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
+Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20210407200723.1914388-3-badhri@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/tcpm/tcpm.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/usb/typec/tcpm/tcpm.c
++++ b/drivers/usb/typec/tcpm/tcpm.c
+@@ -2014,6 +2014,7 @@ static void tcpm_pd_ctrl_request(struct
+ port->pps_data.max_curr = port->pps_data.req_max_curr;
+ port->req_supply_voltage = port->pps_data.req_out_volt;
+ port->req_current_limit = port->pps_data.req_op_curr;
++ power_supply_changed(port->psy);
+ tcpm_set_state(port, SNK_TRANSITION_SINK, 0);
+ break;
+ case SOFT_RESET_SEND:
+@@ -2550,7 +2551,6 @@ static unsigned int tcpm_pd_select_pps_a
+ port->pps_data.req_out_volt));
+ port->pps_data.req_op_curr = min(port->pps_data.max_curr,
+ port->pps_data.req_op_curr);
+- power_supply_changed(port->psy);
+ }
+
+ return src_pdo;
+@@ -2966,8 +2966,6 @@ static void tcpm_reset_port(struct tcpm_
+ port->sink_cap_done = false;
+ if (port->tcpc->enable_frs)
+ port->tcpc->enable_frs(port->tcpc, false);
+-
+- power_supply_changed(port->psy);
+ }
+
+ static void tcpm_detach(struct tcpm_port *port)
--- /dev/null
+From e19ee44a3d07c232f9241024dab1ebd0748cdf5f Mon Sep 17 00:00:00 2001
+From: Chunfeng Yun <chunfeng.yun@mediatek.com>
+Date: Mon, 8 Mar 2021 10:51:51 +0800
+Subject: usb: xhci-mtk: improve bandwidth scheduling with TT
+
+From: Chunfeng Yun <chunfeng.yun@mediatek.com>
+
+commit e19ee44a3d07c232f9241024dab1ebd0748cdf5f upstream.
+
+When the USB headset is plug into an external hub, sometimes
+can't set config due to not enough bandwidth, so need improve
+LS/FS INT/ISOC bandwidth scheduling with TT.
+
+Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Yaqii Wu <yaqii.wu@mediatek.com>
+Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
+Link: https://lore.kernel.org/r/2f30e81400a59afef5f8231c98149169c7520519.1615170625.git.chunfeng.yun@mediatek.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-mtk-sch.c | 74 ++++++++++++++++++++++++++++++++--------
+ drivers/usb/host/xhci-mtk.h | 6 ++-
+ 2 files changed, 64 insertions(+), 16 deletions(-)
+
+--- a/drivers/usb/host/xhci-mtk-sch.c
++++ b/drivers/usb/host/xhci-mtk-sch.c
+@@ -378,6 +378,31 @@ static void update_bus_bw(struct mu3h_sc
+ sch_ep->allocated = used;
+ }
+
++static int check_fs_bus_bw(struct mu3h_sch_ep_info *sch_ep, int offset)
++{
++ struct mu3h_sch_tt *tt = sch_ep->sch_tt;
++ u32 num_esit, tmp;
++ int base;
++ int i, j;
++
++ num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
++ for (i = 0; i < num_esit; i++) {
++ base = offset + i * sch_ep->esit;
++
++ /*
++ * Compared with hs bus, no matter what ep type,
++ * the hub will always delay one uframe to send data
++ */
++ for (j = 0; j < sch_ep->cs_count; j++) {
++ tmp = tt->fs_bus_bw[base + j] + sch_ep->bw_cost_per_microframe;
++ if (tmp > FS_PAYLOAD_MAX)
++ return -ERANGE;
++ }
++ }
++
++ return 0;
++}
++
+ static int check_sch_tt(struct usb_device *udev,
+ struct mu3h_sch_ep_info *sch_ep, u32 offset)
+ {
+@@ -402,7 +427,7 @@ static int check_sch_tt(struct usb_devic
+ return -ERANGE;
+
+ for (i = 0; i < sch_ep->cs_count; i++)
+- if (test_bit(offset + i, tt->split_bit_map))
++ if (test_bit(offset + i, tt->ss_bit_map))
+ return -ERANGE;
+
+ } else {
+@@ -432,7 +457,7 @@ static int check_sch_tt(struct usb_devic
+ cs_count = 7; /* HW limit */
+
+ for (i = 0; i < cs_count + 2; i++) {
+- if (test_bit(offset + i, tt->split_bit_map))
++ if (test_bit(offset + i, tt->ss_bit_map))
+ return -ERANGE;
+ }
+
+@@ -448,24 +473,44 @@ static int check_sch_tt(struct usb_devic
+ sch_ep->num_budget_microframes = sch_ep->esit;
+ }
+
+- return 0;
++ return check_fs_bus_bw(sch_ep, offset);
+ }
+
+ static void update_sch_tt(struct usb_device *udev,
+- struct mu3h_sch_ep_info *sch_ep)
++ struct mu3h_sch_ep_info *sch_ep, bool used)
+ {
+ struct mu3h_sch_tt *tt = sch_ep->sch_tt;
+ u32 base, num_esit;
++ int bw_updated;
++ int bits;
+ int i, j;
+
+ num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
++ bits = (sch_ep->ep_type == ISOC_OUT_EP) ? sch_ep->cs_count : 1;
++
++ if (used)
++ bw_updated = sch_ep->bw_cost_per_microframe;
++ else
++ bw_updated = -sch_ep->bw_cost_per_microframe;
++
+ for (i = 0; i < num_esit; i++) {
+ base = sch_ep->offset + i * sch_ep->esit;
+- for (j = 0; j < sch_ep->num_budget_microframes; j++)
+- set_bit(base + j, tt->split_bit_map);
++
++ for (j = 0; j < bits; j++) {
++ if (used)
++ set_bit(base + j, tt->ss_bit_map);
++ else
++ clear_bit(base + j, tt->ss_bit_map);
++ }
++
++ for (j = 0; j < sch_ep->cs_count; j++)
++ tt->fs_bus_bw[base + j] += bw_updated;
+ }
+
+- list_add_tail(&sch_ep->tt_endpoint, &tt->ep_list);
++ if (used)
++ list_add_tail(&sch_ep->tt_endpoint, &tt->ep_list);
++ else
++ list_del(&sch_ep->tt_endpoint);
+ }
+
+ static int check_sch_bw(struct usb_device *udev,
+@@ -535,7 +580,7 @@ static int check_sch_bw(struct usb_devic
+ if (!tt_offset_ok)
+ return -ERANGE;
+
+- update_sch_tt(udev, sch_ep);
++ update_sch_tt(udev, sch_ep, 1);
+ }
+
+ /* update bus bandwidth info */
+@@ -548,15 +593,16 @@ static void destroy_sch_ep(struct usb_de
+ struct mu3h_sch_bw_info *sch_bw, struct mu3h_sch_ep_info *sch_ep)
+ {
+ /* only release ep bw check passed by check_sch_bw() */
+- if (sch_ep->allocated)
++ if (sch_ep->allocated) {
+ update_bus_bw(sch_bw, sch_ep, 0);
++ if (sch_ep->sch_tt)
++ update_sch_tt(udev, sch_ep, 0);
++ }
+
+- list_del(&sch_ep->endpoint);
+-
+- if (sch_ep->sch_tt) {
+- list_del(&sch_ep->tt_endpoint);
++ if (sch_ep->sch_tt)
+ drop_tt(udev);
+- }
++
++ list_del(&sch_ep->endpoint);
+ kfree(sch_ep);
+ }
+
+--- a/drivers/usb/host/xhci-mtk.h
++++ b/drivers/usb/host/xhci-mtk.h
+@@ -20,13 +20,15 @@
+ #define XHCI_MTK_MAX_ESIT 64
+
+ /**
+- * @split_bit_map: used to avoid split microframes overlay
++ * @ss_bit_map: used to avoid start split microframes overlay
++ * @fs_bus_bw: array to keep track of bandwidth already used for FS
+ * @ep_list: Endpoints using this TT
+ * @usb_tt: usb TT related
+ * @tt_port: TT port number
+ */
+ struct mu3h_sch_tt {
+- DECLARE_BITMAP(split_bit_map, XHCI_MTK_MAX_ESIT);
++ DECLARE_BITMAP(ss_bit_map, XHCI_MTK_MAX_ESIT);
++ u32 fs_bus_bw[XHCI_MTK_MAX_ESIT];
+ struct list_head ep_list;
+ struct usb_tt *usb_tt;
+ int tt_port;
--- /dev/null
+From 5fa5827566e3affa1657ccf9b22706c06a5d021a Mon Sep 17 00:00:00 2001
+From: Chunfeng Yun <chunfeng.yun@mediatek.com>
+Date: Mon, 8 Mar 2021 10:51:50 +0800
+Subject: usb: xhci-mtk: remove or operator for setting schedule parameters
+
+From: Chunfeng Yun <chunfeng.yun@mediatek.com>
+
+commit 5fa5827566e3affa1657ccf9b22706c06a5d021a upstream.
+
+Side effect may happen if use or operator to set schedule parameters
+when the parameters are already set before. Set them directly due to
+other bits are reserved.
+
+Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints")
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
+Link: https://lore.kernel.org/r/d287899e6beb2fc1bfb8900c75a872f628ecde55.1615170625.git.chunfeng.yun@mediatek.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-mtk-sch.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/xhci-mtk-sch.c
++++ b/drivers/usb/host/xhci-mtk-sch.c
+@@ -643,7 +643,7 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd
+ */
+ if (usb_endpoint_xfer_int(&ep->desc)
+ || usb_endpoint_xfer_isoc(&ep->desc))
+- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(1));
++ ep_ctx->reserved[0] = cpu_to_le32(EP_BPKTS(1));
+
+ return 0;
+ }
+@@ -730,10 +730,10 @@ int xhci_mtk_check_bandwidth(struct usb_
+ list_move_tail(&sch_ep->endpoint, &sch_bw->bw_ep_list);
+
+ ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
+- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(sch_ep->pkts)
++ ep_ctx->reserved[0] = cpu_to_le32(EP_BPKTS(sch_ep->pkts)
+ | EP_BCSCOUNT(sch_ep->cs_count)
+ | EP_BBM(sch_ep->burst_mode));
+- ep_ctx->reserved[1] |= cpu_to_le32(EP_BOFFSET(sch_ep->offset)
++ ep_ctx->reserved[1] = cpu_to_le32(EP_BOFFSET(sch_ep->offset)
+ | EP_BREPEAT(sch_ep->repeat));
+
+ xhci_dbg(xhci, " PKTS:%x, CSCOUNT:%x, BM:%x, OFFSET:%x, REPEAT:%x\n",
--- /dev/null
+From 2c88d45edbb89029c1190bb3b136d2602f057c98 Mon Sep 17 00:00:00 2001
+From: Alison Schofield <alison.schofield@intel.com>
+Date: Wed, 10 Mar 2021 11:02:33 -0800
+Subject: x86, sched: Treat Intel SNC topology as default, COD as exception
+
+From: Alison Schofield <alison.schofield@intel.com>
+
+commit 2c88d45edbb89029c1190bb3b136d2602f057c98 upstream.
+
+Commit 1340ccfa9a9a ("x86,sched: Allow topologies where NUMA nodes
+share an LLC") added a vendor and model specific check to never
+call topology_sane() for Intel Skylake Server systems where NUMA
+nodes share an LLC.
+
+Intel Ice Lake and Sapphire Rapids CPUs also enumerate an LLC that is
+shared by multiple NUMA nodes. The LLC on these CPUs is shared for
+off-package data access but private to the NUMA node for on-package
+access. Rather than managing a list of allowable SNC topologies, make
+this SNC topology the default, and treat Intel's Cluster-On-Die (COD)
+topology as the exception.
+
+In SNC mode, Sky Lake, Ice Lake, and Sapphire Rapids servers do not
+emit this warning:
+
+sched: CPU #3's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
+
+Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Signed-off-by: Alison Schofield <alison.schofield@intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20210310190233.31752-1-alison.schofield@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/smpboot.c | 90 +++++++++++++++++++++++-----------------------
+ 1 file changed, 46 insertions(+), 44 deletions(-)
+
+--- a/arch/x86/kernel/smpboot.c
++++ b/arch/x86/kernel/smpboot.c
+@@ -458,29 +458,52 @@ static bool match_smt(struct cpuinfo_x86
+ return false;
+ }
+
++static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
++{
++ if (c->phys_proc_id == o->phys_proc_id &&
++ c->cpu_die_id == o->cpu_die_id)
++ return true;
++ return false;
++}
++
+ /*
+- * Define snc_cpu[] for SNC (Sub-NUMA Cluster) CPUs.
++ * Unlike the other levels, we do not enforce keeping a
++ * multicore group inside a NUMA node. If this happens, we will
++ * discard the MC level of the topology later.
++ */
++static bool match_pkg(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
++{
++ if (c->phys_proc_id == o->phys_proc_id)
++ return true;
++ return false;
++}
++
++/*
++ * Define intel_cod_cpu[] for Intel COD (Cluster-on-Die) CPUs.
+ *
+- * These are Intel CPUs that enumerate an LLC that is shared by
+- * multiple NUMA nodes. The LLC on these systems is shared for
+- * off-package data access but private to the NUMA node (half
+- * of the package) for on-package access.
++ * Any Intel CPU that has multiple nodes per package and does not
++ * match intel_cod_cpu[] has the SNC (Sub-NUMA Cluster) topology.
+ *
+- * CPUID (the source of the information about the LLC) can only
+- * enumerate the cache as being shared *or* unshared, but not
+- * this particular configuration. The CPU in this case enumerates
+- * the cache to be shared across the entire package (spanning both
+- * NUMA nodes).
++ * When in SNC mode, these CPUs enumerate an LLC that is shared
++ * by multiple NUMA nodes. The LLC is shared for off-package data
++ * access but private to the NUMA node (half of the package) for
++ * on-package access. CPUID (the source of the information about
++ * the LLC) can only enumerate the cache as shared or unshared,
++ * but not this particular configuration.
+ */
+
+-static const struct x86_cpu_id snc_cpu[] = {
+- X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_X, NULL),
++static const struct x86_cpu_id intel_cod_cpu[] = {
++ X86_MATCH_INTEL_FAM6_MODEL(HASWELL_X, 0), /* COD */
++ X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_X, 0), /* COD */
++ X86_MATCH_INTEL_FAM6_MODEL(ANY, 1), /* SNC */
+ {}
+ };
+
+ static bool match_llc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
+ {
++ const struct x86_cpu_id *id = x86_match_cpu(intel_cod_cpu);
+ int cpu1 = c->cpu_index, cpu2 = o->cpu_index;
++ bool intel_snc = id && id->driver_data;
+
+ /* Do not match if we do not have a valid APICID for cpu: */
+ if (per_cpu(cpu_llc_id, cpu1) == BAD_APICID)
+@@ -495,32 +518,12 @@ static bool match_llc(struct cpuinfo_x86
+ * means 'c' does not share the LLC of 'o'. This will be
+ * reflected to userspace.
+ */
+- if (!topology_same_node(c, o) && x86_match_cpu(snc_cpu))
++ if (match_pkg(c, o) && !topology_same_node(c, o) && intel_snc)
+ return false;
+
+ return topology_sane(c, o, "llc");
+ }
+
+-/*
+- * Unlike the other levels, we do not enforce keeping a
+- * multicore group inside a NUMA node. If this happens, we will
+- * discard the MC level of the topology later.
+- */
+-static bool match_pkg(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
+-{
+- if (c->phys_proc_id == o->phys_proc_id)
+- return true;
+- return false;
+-}
+-
+-static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
+-{
+- if ((c->phys_proc_id == o->phys_proc_id) &&
+- (c->cpu_die_id == o->cpu_die_id))
+- return true;
+- return false;
+-}
+-
+
+ #if defined(CONFIG_SCHED_SMT) || defined(CONFIG_SCHED_MC)
+ static inline int x86_sched_itmt_flags(void)
+@@ -592,14 +595,23 @@ void set_cpu_sibling_map(int cpu)
+ for_each_cpu(i, cpu_sibling_setup_mask) {
+ o = &cpu_data(i);
+
++ if (match_pkg(c, o) && !topology_same_node(c, o))
++ x86_has_numa_in_package = true;
++
+ if ((i == cpu) || (has_smt && match_smt(c, o)))
+ link_mask(topology_sibling_cpumask, cpu, i);
+
+ if ((i == cpu) || (has_mp && match_llc(c, o)))
+ link_mask(cpu_llc_shared_mask, cpu, i);
+
++ if ((i == cpu) || (has_mp && match_die(c, o)))
++ link_mask(topology_die_cpumask, cpu, i);
+ }
+
++ threads = cpumask_weight(topology_sibling_cpumask(cpu));
++ if (threads > __max_smt_threads)
++ __max_smt_threads = threads;
++
+ /*
+ * This needs a separate iteration over the cpus because we rely on all
+ * topology_sibling_cpumask links to be set-up.
+@@ -613,8 +625,7 @@ void set_cpu_sibling_map(int cpu)
+ /*
+ * Does this new cpu bringup a new core?
+ */
+- if (cpumask_weight(
+- topology_sibling_cpumask(cpu)) == 1) {
++ if (threads == 1) {
+ /*
+ * for each core in package, increment
+ * the booted_cores for this new cpu
+@@ -631,16 +642,7 @@ void set_cpu_sibling_map(int cpu)
+ } else if (i != cpu && !c->booted_cores)
+ c->booted_cores = cpu_data(i).booted_cores;
+ }
+- if (match_pkg(c, o) && !topology_same_node(c, o))
+- x86_has_numa_in_package = true;
+-
+- if ((i == cpu) || (has_mp && match_die(c, o)))
+- link_mask(topology_die_cpumask, cpu, i);
+ }
+-
+- threads = cpumask_weight(topology_sibling_cpumask(cpu));
+- if (threads > __max_smt_threads)
+- __max_smt_threads = threads;
+ }
+
+ /* maps the cpu to the sched domain representing multi-core */
projects / thirdparty / kernel / stable-queue.git / commitdiff
