From: Sasha Levin Date: Sun, 20 Jun 2021 23:13:03 +0000 (-0400) Subject: Fixes for 4.19 X-Git-Tag: v5.4.128~46 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0b3ad8cfa22dfb6ec92a45e1b0e0ab965c36a5cf;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.19 Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/asoc-rt5659-fix-the-lost-powers-for-the-hda-header.patch b/queue-4.19/asoc-rt5659-fix-the-lost-powers-for-the-hda-header.patch new file mode 100644 index 00000000000..0b6268af9c3 --- /dev/null +++ b/queue-4.19/asoc-rt5659-fix-the-lost-powers-for-the-hda-header.patch @@ -0,0 +1,85 @@ +From 6a105872df1423ad6eab58a6733447da6fcd7272 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 b331b3ba61a9..ab73f84b5970 100644 +--- a/sound/soc/codecs/rt5659.c ++++ b/sound/soc/codecs/rt5659.c +@@ -2473,13 +2473,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), + +@@ -2504,8 +2509,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, +@@ -3700,10 +3703,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-4.19/hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch b/queue-4.19/hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch new file mode 100644 index 00000000000..448edf44d17 --- /dev/null +++ b/queue-4.19/hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch @@ -0,0 +1,46 @@ +From 174055e3c5472749d3942d7493a120d06462c4aa 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 7e49da50bc69..562f3e287297 100644 +--- a/drivers/hwmon/scpi-hwmon.c ++++ b/drivers/hwmon/scpi-hwmon.c +@@ -107,6 +107,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-4.19/pinctrl-ralink-rt2880-avoid-to-error-in-calls-is-pin.patch b/queue-4.19/pinctrl-ralink-rt2880-avoid-to-error-in-calls-is-pin.patch new file mode 100644 index 00000000000..591029ed575 --- /dev/null +++ b/queue-4.19/pinctrl-ralink-rt2880-avoid-to-error-in-calls-is-pin.patch @@ -0,0 +1,45 @@ +From 5291cf1e10d07313abd7c556e8c36d0aac6ebe88 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 80e7067cfb79..ad811c0438cc 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-4.19/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch b/queue-4.19/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch new file mode 100644 index 00000000000..f28834cda31 --- /dev/null +++ b/queue-4.19/radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch @@ -0,0 +1,57 @@ +From e58268d0380a829e4b9aeff27f8d602f04a955bb 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 95f4db70dd22..fde9c69ecc86 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-4.19/series b/queue-4.19/series index addc6e62c04..4678ee9cfb8 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -51,3 +51,7 @@ net-hamradio-fix-memory-leak-in-mkiss_close.patch net-cdc_eem-fix-tx-fixup-skb-leak.patch icmp-don-t-send-out-icmp-messages-with-a-source-addr.patch net-ethernet-fix-potential-use-after-free-in-ec_bhf_.patch +asoc-rt5659-fix-the-lost-powers-for-the-hda-header.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