Before the micmute_led_set() is introduced, the function of
alc_gpio_micmute_update() will set the gpio value with the
!micmute_led.led_value, and the machines have the correct micmute led
status. After the micmute_led_set() is introduced, it sets the gpio
value with !!micmute_led.led_value, so the led status is not correct
anymore, we need to set micmute_led_polarity = 1 to workaround it.
Now we fix the micmute_led_set() and remove micmute_led_polarity = 1.
Fixes: 87dc36482cab ("ALSA: hda/realtek - Add LED class support for micmute LED")
Reported-and-suggested-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang(a)canonical.com>
---
sound/pci/hda/patch_realtek.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 09d93dd88713..073029aeaf3c 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4125,7 +4125,7 @@ static int micmute_led_set(struct led_classdev *led_cdev,
struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mic_led_mask,
- spec->micmute_led_polarity, !!brightness);
+ spec->micmute_led_polarity, !brightness);
return 0;
}
@@ -4162,8 +4162,6 @@ static void alc285_fixup_hp_gpio_led(struct hda_codec *codec,
{
struct alc_spec *spec = codec->spec;
- spec->micmute_led_polarity = 1;
-
alc_fixup_hp_gpio_led(codec, action, 0x04, 0x01);
}
@@ -4414,7 +4412,6 @@ static void alc233_fixup_lenovo_line2_mic_hotkey(struct hda_codec *codec,
{
struct alc_spec *spec = codec->spec;
- spec->micmute_led_polarity = 1;
alc_fixup_hp_gpio_led(codec, action, 0, 0x04);
if (action == HDA_FIXUP_ACT_PRE_PROBE) {
spec->init_amp = ALC_INIT_DEFAULT;
--
2.17.1
After installing the Ubuntu Linux, the micmute led status is not
correct. Users expect that the led is on if the capture is disabled,
but with the current kernel, the led is off with the capture disabled.
We tried the old linux kernel like linux-4.15, there is no this issue.
It looks like we introduced this issue when switching to the led_cdev.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang(a)canonical.com>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index daedcc0adc21..09d93dd88713 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4414,6 +4414,7 @@ static void alc233_fixup_lenovo_line2_mic_hotkey(struct hda_codec *codec,
{
struct alc_spec *spec = codec->spec;
+ spec->micmute_led_polarity = 1;
alc_fixup_hp_gpio_led(codec, action, 0, 0x04);
if (action == HDA_FIXUP_ACT_PRE_PROBE) {
spec->init_amp = ALC_INIT_DEFAULT;
--
2.17.1
The patch titled
Subject: mm/vunmap: add cond_resched() in vunmap_pmd_range
has been added to the -mm tree. Its filename is
mm-vunmap-add-cond_resched-in-vunmap_pmd_range.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-vunmap-add-cond_resched-in-vunm…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-vunmap-add-cond_resched-in-vunm…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.ibm.com>
Subject: mm/vunmap: add cond_resched() in vunmap_pmd_range
Like zap_pte_range add cond_resched so that we can avoid softlockups as
reported below. On non-preemptible kernel with large I/O map region (like
the one we get when using persistent memory with sector mode), an unmap of
the namespace can report below softlockups.
22724.027334] watchdog: BUG: soft lockup - CPU#49 stuck for 23s! [ndctl:50777]
NIP [c0000000000dc224] plpar_hcall+0x38/0x58
LR [c0000000000d8898] pSeries_lpar_hpte_invalidate+0x68/0xb0
Call Trace:
[c0000004e87a7780] [c0000004fb197c00] 0xc0000004fb197c00 (unreliable)
[c0000004e87a7810] [c00000000007f4e4] flush_hash_page+0x114/0x200
[c0000004e87a7890] [c0000000000833cc] hpte_need_flush+0x2dc/0x540
[c0000004e87a7950] [c0000000003f5798] vunmap_page_range+0x538/0x6f0
[c0000004e87a7a70] [c0000000003f76d0] free_unmap_vmap_area+0x30/0x70
[c0000004e87a7aa0] [c0000000003f7a6c] remove_vm_area+0xfc/0x140
[c0000004e87a7ad0] [c0000000003f7dd8] __vunmap+0x68/0x270
[c0000004e87a7b50] [c000000000079de4] __iounmap.part.0+0x34/0x60
[c0000004e87a7bb0] [c000000000376394] memunmap+0x54/0x70
[c0000004e87a7bd0] [c000000000881d7c] release_nodes+0x28c/0x300
[c0000004e87a7c40] [c00000000087a65c] device_release_driver_internal+0x16c/0x280
[c0000004e87a7c80] [c000000000876fc4] unbind_store+0x124/0x170
[c0000004e87a7cd0] [c000000000875be4] drv_attr_store+0x44/0x60
[c0000004e87a7cf0] [c00000000057c734] sysfs_kf_write+0x64/0x90
[c0000004e87a7d10] [c00000000057bc10] kernfs_fop_write+0x1b0/0x290
[c0000004e87a7d60] [c000000000488e6c] __vfs_write+0x3c/0x70
[c0000004e87a7d80] [c00000000048c868] vfs_write+0xd8/0x260
[c0000004e87a7dd0] [c00000000048ccac] ksys_write+0xdc/0x130
[c0000004e87a7e20] [c00000000000b588] system_call+0x5c/0x70
Link: http://lkml.kernel.org/r/20200807075933.310240-1-aneesh.kumar@linux.ibm.com
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
Reported-by: Harish Sriram <harish(a)linux.ibm.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/vmalloc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/vmalloc.c~mm-vunmap-add-cond_resched-in-vunmap_pmd_range
+++ a/mm/vmalloc.c
@@ -104,6 +104,8 @@ static void vunmap_pmd_range(pud_t *pud,
if (pmd_none_or_clear_bad(pmd))
continue;
vunmap_pte_range(pmd, addr, next, mask);
+
+ cond_resched();
} while (pmd++, addr = next, addr != end);
}
_
Patches currently in -mm which might be from aneesh.kumar(a)linux.ibm.com are
mm-vunmap-add-cond_resched-in-vunmap_pmd_range.patch