--- /dev/null
+From a27417a77bc8d33fe7f0c17e338af40f5c61032d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 May 2021 01:06:51 +0000
+Subject: ASoC: rt5659: Fix the lost powers for the HDA header
+
+From: Jack Yu <jack.yu@realtek.com>
+
+[ Upstream commit 6308c44ed6eeadf65c0a7ba68d609773ed860fbb ]
+
+The power of "LDO2", "MICBIAS1" and "Mic Det Power" were powered off after
+the DAPM widgets were added, and these powers were set by the JD settings
+"RT5659_JD_HDA_HEADER" in the probe function. In the codec probe function,
+these powers were ignored to prevent them controlled by DAPM.
+
+Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
+Signed-off-by: Jack Yu <jack.yu@realtek.com>
+Message-Id: <15fced51977b458798ca4eebf03dafb9@realtek.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/soc/codecs/rt5659.c | 26 +++++++++++++++++++++-----
+ 1 file changed, 21 insertions(+), 5 deletions(-)
+
+diff --git a/sound/soc/codecs/rt5659.c b/sound/soc/codecs/rt5659.c
+index afd61599d94c..a28afb480060 100644
+--- a/sound/soc/codecs/rt5659.c
++++ b/sound/soc/codecs/rt5659.c
+@@ -2470,13 +2470,18 @@ static int set_dmic_power(struct snd_soc_dapm_widget *w,
+ return 0;
+ }
+
+-static const struct snd_soc_dapm_widget rt5659_dapm_widgets[] = {
++static const struct snd_soc_dapm_widget rt5659_particular_dapm_widgets[] = {
+ SND_SOC_DAPM_SUPPLY("LDO2", RT5659_PWR_ANLG_3, RT5659_PWR_LDO2_BIT, 0,
+ NULL, 0),
+- SND_SOC_DAPM_SUPPLY("PLL", RT5659_PWR_ANLG_3, RT5659_PWR_PLL_BIT, 0,
+- NULL, 0),
++ SND_SOC_DAPM_SUPPLY("MICBIAS1", RT5659_PWR_ANLG_2, RT5659_PWR_MB1_BIT,
++ 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("Mic Det Power", RT5659_PWR_VOL,
+ RT5659_PWR_MIC_DET_BIT, 0, NULL, 0),
++};
++
++static const struct snd_soc_dapm_widget rt5659_dapm_widgets[] = {
++ SND_SOC_DAPM_SUPPLY("PLL", RT5659_PWR_ANLG_3, RT5659_PWR_PLL_BIT, 0,
++ NULL, 0),
+ SND_SOC_DAPM_SUPPLY("Mono Vref", RT5659_PWR_ANLG_1,
+ RT5659_PWR_VREF3_BIT, 0, NULL, 0),
+
+@@ -2501,8 +2506,6 @@ static const struct snd_soc_dapm_widget rt5659_dapm_widgets[] = {
+ RT5659_ADC_MONO_R_ASRC_SFT, 0, NULL, 0),
+
+ /* Input Side */
+- SND_SOC_DAPM_SUPPLY("MICBIAS1", RT5659_PWR_ANLG_2, RT5659_PWR_MB1_BIT,
+- 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("MICBIAS2", RT5659_PWR_ANLG_2, RT5659_PWR_MB2_BIT,
+ 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("MICBIAS3", RT5659_PWR_ANLG_2, RT5659_PWR_MB3_BIT,
+@@ -3697,10 +3700,23 @@ static int rt5659_set_bias_level(struct snd_soc_component *component,
+
+ static int rt5659_probe(struct snd_soc_component *component)
+ {
++ struct snd_soc_dapm_context *dapm =
++ snd_soc_component_get_dapm(component);
+ struct rt5659_priv *rt5659 = snd_soc_component_get_drvdata(component);
+
+ rt5659->component = component;
+
++ switch (rt5659->pdata.jd_src) {
++ case RT5659_JD_HDA_HEADER:
++ break;
++
++ default:
++ snd_soc_dapm_new_controls(dapm,
++ rt5659_particular_dapm_widgets,
++ ARRAY_SIZE(rt5659_particular_dapm_widgets));
++ break;
++ }
++
+ return 0;
+ }
+
+--
+2.30.2
+
--- /dev/null
+From 24ed6e078ed9641646dc29708b7875c706345ebb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Jun 2021 11:09:59 +0800
+Subject: hwmon: (scpi-hwmon) shows the negative temperature properly
+
+From: Riwen Lu <luriwen@kylinos.cn>
+
+[ Upstream commit 78d13552346289bad4a9bf8eabb5eec5e5a321a5 ]
+
+The scpi hwmon shows the sub-zero temperature in an unsigned integer,
+which would confuse the users when the machine works in low temperature
+environment. This shows the sub-zero temperature in an signed value and
+users can get it properly from sensors.
+
+Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
+Tested-by: Xin Chen <chenxin@kylinos.cn>
+Link: https://lore.kernel.org/r/20210604030959.736379-1-luriwen@kylinos.cn
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hwmon/scpi-hwmon.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+diff --git a/drivers/hwmon/scpi-hwmon.c b/drivers/hwmon/scpi-hwmon.c
+index 25aac40f2764..919877970ae3 100644
+--- a/drivers/hwmon/scpi-hwmon.c
++++ b/drivers/hwmon/scpi-hwmon.c
+@@ -99,6 +99,15 @@ scpi_show_sensor(struct device *dev, struct device_attribute *attr, char *buf)
+
+ scpi_scale_reading(&value, sensor);
+
++ /*
++ * Temperature sensor values are treated as signed values based on
++ * observation even though that is not explicitly specified, and
++ * because an unsigned u64 temperature does not really make practical
++ * sense especially when the temperature is below zero degrees Celsius.
++ */
++ if (sensor->info.class == TEMPERATURE)
++ return sprintf(buf, "%lld\n", (s64)value);
++
+ return sprintf(buf, "%llu\n", value);
+ }
+
+--
+2.30.2
+
--- /dev/null
+From 6ed54ebddd65569ebb6bd3c2e9415b5d33169293 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Jun 2021 07:53:37 +0200
+Subject: pinctrl: ralink: rt2880: avoid to error in calls is pin is already
+ enabled
+
+From: Sergio Paracuellos <sergio.paracuellos@gmail.com>
+
+[ Upstream commit eb367d875f94a228c17c8538e3f2efcf2eb07ead ]
+
+In 'rt2880_pmx_group_enable' driver is printing an error and returning
+-EBUSY if a pin has been already enabled. This begets anoying messages
+in the caller when this happens like the following:
+
+rt2880-pinmux pinctrl: pcie is already enabled
+mt7621-pci 1e140000.pcie: Error applying setting, reverse things back
+
+To avoid this just print the already enabled message in the pinctrl
+driver and return 0 instead to not confuse the user with a real
+bad problem.
+
+Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
+Link: https://lore.kernel.org/r/20210604055337.20407-1-sergio.paracuellos@gmail.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
+index d0f06790d38f..0ba4e4e070a9 100644
+--- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
++++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
+@@ -127,7 +127,7 @@ static int rt2880_pmx_group_enable(struct pinctrl_dev *pctrldev,
+ if (p->groups[group].enabled) {
+ dev_err(p->dev, "%s is already enabled\n",
+ p->groups[group].name);
+- return -EBUSY;
++ return 0;
+ }
+
+ p->groups[group].enabled = 1;
+--
+2.30.2
+
--- /dev/null
+From 0dcbbbc3d1d38395c00110b12fab9ad1f9d6e0b8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 4 Jun 2021 16:43:02 +0800
+Subject: radeon: use memcpy_to/fromio for UVD fw upload
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Chen Li <chenli@uniontech.com>
+
+[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
+
+I met a gpu addr bug recently and the kernel log
+tells me the pc is memcpy/memset and link register is
+radeon_uvd_resume.
+
+As we know, in some architectures, optimized memcpy/memset
+may not work well on device memory. Trival memcpy_toio/memset_io
+can fix this problem.
+
+BTW, amdgpu has already done it in:
+commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
+that's why it has no this issue on the same gpu and platform.
+
+Signed-off-by: Chen Li <chenli@uniontech.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/radeon/radeon_uvd.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c b/drivers/gpu/drm/radeon/radeon_uvd.c
+index 1ad5c3b86b64..a18bf70a251e 100644
+--- a/drivers/gpu/drm/radeon/radeon_uvd.c
++++ b/drivers/gpu/drm/radeon/radeon_uvd.c
+@@ -286,7 +286,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
+ if (rdev->uvd.vcpu_bo == NULL)
+ return -EINVAL;
+
+- memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
++ memcpy_toio((void __iomem *)rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
+
+ size = radeon_bo_size(rdev->uvd.vcpu_bo);
+ size -= rdev->uvd_fw->size;
+@@ -294,7 +294,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
+ ptr = rdev->uvd.cpu_addr;
+ ptr += rdev->uvd_fw->size;
+
+- memset(ptr, 0, size);
++ memset_io((void __iomem *)ptr, 0, size);
+
+ return 0;
+ }
+--
+2.30.2
+
--- /dev/null
+From 7926f563d751fd952b853768968e8b5d4ff8e879 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 23 May 2021 15:10:44 +0800
+Subject: regulator: bd70528: Fix off-by-one for buck123 .n_voltages setting
+
+From: Axel Lin <axel.lin@ingics.com>
+
+[ Upstream commit 0514582a1a5b4ac1a3fd64792826d392d7ae9ddc ]
+
+The valid selectors for bd70528 bucks are 0 ~ 0xf, so the .n_voltages
+should be 16 (0x10). Use 0x10 to make it consistent with BD70528_LDO_VOLTS.
+Also remove redundant defines for BD70528_BUCK_VOLTS.
+
+Signed-off-by: Axel Lin <axel.lin@ingics.com>
+Acked-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
+Link: https://lore.kernel.org/r/20210523071045.2168904-1-axel.lin@ingics.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/mfd/rohm-bd70528.h | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/include/linux/mfd/rohm-bd70528.h b/include/linux/mfd/rohm-bd70528.h
+index b0109ee6dae2..1c3014d2f28b 100644
+--- a/include/linux/mfd/rohm-bd70528.h
++++ b/include/linux/mfd/rohm-bd70528.h
+@@ -25,9 +25,7 @@ struct bd70528_data {
+ struct mutex rtc_timer_lock;
+ };
+
+-#define BD70528_BUCK_VOLTS 17
+-#define BD70528_BUCK_VOLTS 17
+-#define BD70528_BUCK_VOLTS 17
++#define BD70528_BUCK_VOLTS 0x10
+ #define BD70528_LDO_VOLTS 0x20
+
+ #define BD70528_REG_BUCK1_EN 0x0F
+--
+2.30.2
+
bnxt_en-call-bnxt_ethtool_free-in-bnxt_init_one-erro.patch
icmp-don-t-send-out-icmp-messages-with-a-source-addr.patch
net-ethernet-fix-potential-use-after-free-in-ec_bhf_.patch
+regulator-bd70528-fix-off-by-one-for-buck123-.n_volt.patch
+asoc-rt5659-fix-the-lost-powers-for-the-hda-header.patch
+spi-stm32-qspi-always-wait-busy-bit-to-be-cleared-in.patch
+pinctrl-ralink-rt2880-avoid-to-error-in-calls-is-pin.patch
+radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch
+hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch
--- /dev/null
+From 9f89a9bb4987ca880ac5fb1b7882d7a01b27bb32 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 3 Jun 2021 09:34:21 +0200
+Subject: spi: stm32-qspi: Always wait BUSY bit to be cleared in
+ stm32_qspi_wait_cmd()
+
+From: Patrice Chotard <patrice.chotard@foss.st.com>
+
+[ Upstream commit d38fa9a155b2829b7e2cfcf8a4171b6dd3672808 ]
+
+In U-boot side, an issue has been encountered when QSPI source clock is
+running at low frequency (24 MHz for example), waiting for TCF bit to be
+set didn't ensure that all data has been send out the FIFO, we should also
+wait that BUSY bit is cleared.
+
+To prevent similar issue in kernel driver, we implement similar behavior
+by always waiting BUSY bit to be cleared.
+
+Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
+Link: https://lore.kernel.org/r/20210603073421.8441-1-patrice.chotard@foss.st.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-stm32-qspi.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
+index 4e726929bb4f..ea77d915216a 100644
+--- a/drivers/spi/spi-stm32-qspi.c
++++ b/drivers/spi/spi-stm32-qspi.c
+@@ -291,7 +291,7 @@ static int stm32_qspi_wait_cmd(struct stm32_qspi *qspi,
+ int err = 0;
+
+ if (!op->data.nbytes)
+- return stm32_qspi_wait_nobusy(qspi);
++ goto wait_nobusy;
+
+ if (readl_relaxed(qspi->io_base + QSPI_SR) & SR_TCF)
+ goto out;
+@@ -312,6 +312,9 @@ static int stm32_qspi_wait_cmd(struct stm32_qspi *qspi,
+ out:
+ /* clear flags */
+ writel_relaxed(FCR_CTCF | FCR_CTEF, qspi->io_base + QSPI_FCR);
++wait_nobusy:
++ if (!err)
++ err = stm32_qspi_wait_nobusy(qspi);
+
+ return err;
+ }
+--
+2.30.2
+