From: Sasha Levin Date: Sun, 20 Jun 2021 23:13:02 +0000 (-0400) Subject: Fixes for 5.4 X-Git-Tag: v5.4.128~47 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=be5fed132fe7134323f0e03b05d6558085d681de;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.4 Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/asoc-rt5659-fix-the-lost-powers-for-the-hda-header.patch b/queue-5.4/asoc-rt5659-fix-the-lost-powers-for-the-hda-header.patch new file mode 100644 index 00000000000..77ef3d7619c --- /dev/null +++ b/queue-5.4/asoc-rt5659-fix-the-lost-powers-for-the-hda-header.patch @@ -0,0 +1,85 @@ +From a27417a77bc8d33fe7f0c17e338af40f5c61032d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 May 2021 01:06:51 +0000 +Subject: ASoC: rt5659: Fix the lost powers for the HDA header + +From: Jack Yu + +[ 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 +Signed-off-by: Jack Yu +Message-Id: <15fced51977b458798ca4eebf03dafb9@realtek.com> +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch b/queue-5.4/hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch new file mode 100644 index 00000000000..1b55da7f40e --- /dev/null +++ b/queue-5.4/hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch @@ -0,0 +1,46 @@ +From 24ed6e078ed9641646dc29708b7875c706345ebb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 4 Jun 2021 11:09:59 +0800 +Subject: hwmon: (scpi-hwmon) shows the negative temperature properly + +From: Riwen Lu + +[ 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 +Tested-by: Xin Chen +Link: https://lore.kernel.org/r/20210604030959.736379-1-luriwen@kylinos.cn +Signed-off-by: Guenter Roeck +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/pinctrl-ralink-rt2880-avoid-to-error-in-calls-is-pin.patch b/queue-5.4/pinctrl-ralink-rt2880-avoid-to-error-in-calls-is-pin.patch new file mode 100644 index 00000000000..253c33fe80a --- /dev/null +++ b/queue-5.4/pinctrl-ralink-rt2880-avoid-to-error-in-calls-is-pin.patch @@ -0,0 +1,45 @@ +From 6ed54ebddd65569ebb6bd3c2e9415b5d33169293 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://lore.kernel.org/r/20210604055337.20407-1-sergio.paracuellos@gmail.com +Signed-off-by: Linus Walleij +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch b/queue-5.4/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch new file mode 100644 index 00000000000..aa5cbecd8a6 --- /dev/null +++ b/queue-5.4/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch @@ -0,0 +1,57 @@ +From 0dcbbbc3d1d38395c00110b12fab9ad1f9d6e0b8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Christian König +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/regulator-bd70528-fix-off-by-one-for-buck123-.n_volt.patch b/queue-5.4/regulator-bd70528-fix-off-by-one-for-buck123-.n_volt.patch new file mode 100644 index 00000000000..6c1d4af465e --- /dev/null +++ b/queue-5.4/regulator-bd70528-fix-off-by-one-for-buck123-.n_volt.patch @@ -0,0 +1,40 @@ +From 7926f563d751fd952b853768968e8b5d4ff8e879 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 23 May 2021 15:10:44 +0800 +Subject: regulator: bd70528: Fix off-by-one for buck123 .n_voltages setting + +From: Axel Lin + +[ 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 +Acked-by: Matti Vaittinen +Link: https://lore.kernel.org/r/20210523071045.2168904-1-axel.lin@ingics.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-5.4/series b/queue-5.4/series index 19053050b8c..4eb724de23b 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -40,3 +40,9 @@ bnxt_en-rediscover-phy-capabilities-after-firmware-r.patch 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 diff --git a/queue-5.4/spi-stm32-qspi-always-wait-busy-bit-to-be-cleared-in.patch b/queue-5.4/spi-stm32-qspi-always-wait-busy-bit-to-be-cleared-in.patch new file mode 100644 index 00000000000..1e9373de51a --- /dev/null +++ b/queue-5.4/spi-stm32-qspi-always-wait-busy-bit-to-be-cleared-in.patch @@ -0,0 +1,52 @@ +From 9f89a9bb4987ca880ac5fb1b7882d7a01b27bb32 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Link: https://lore.kernel.org/r/20210603073421.8441-1-patrice.chotard@foss.st.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + 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 +