From f3a12ed92b5714b4c884e489e80b7e92422af427 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 30 Jan 2021 16:41:24 +0100 Subject: [PATCH] 5.10-stable patches added patches: acpi-sysfs-prefer-compatible-modalias.patch acpi-thermal-do-not-call-acpi_thermal_check-directly.patch alsa-hda-realtek-enable-headset-of-asus-b1400cepe-with-alc256.patch alsa-hda-via-apply-the-workaround-generically-for-clevo-machines.patch kernel-kexec-remove-the-lock-operation-of-system_transition_mutex.patch --- ...cpi-sysfs-prefer-compatible-modalias.patch | 65 ++++++++ ...not-call-acpi_thermal_check-directly.patch | 151 ++++++++++++++++++ ...eadset-of-asus-b1400cepe-with-alc256.patch | 45 ++++++ ...round-generically-for-clevo-machines.patch | 35 ++++ ...operation-of-system_transition_mutex.patch | 49 ++++++ queue-5.10/series | 5 + 6 files changed, 350 insertions(+) create mode 100644 queue-5.10/acpi-sysfs-prefer-compatible-modalias.patch create mode 100644 queue-5.10/acpi-thermal-do-not-call-acpi_thermal_check-directly.patch create mode 100644 queue-5.10/alsa-hda-realtek-enable-headset-of-asus-b1400cepe-with-alc256.patch create mode 100644 queue-5.10/alsa-hda-via-apply-the-workaround-generically-for-clevo-machines.patch create mode 100644 queue-5.10/kernel-kexec-remove-the-lock-operation-of-system_transition_mutex.patch diff --git a/queue-5.10/acpi-sysfs-prefer-compatible-modalias.patch b/queue-5.10/acpi-sysfs-prefer-compatible-modalias.patch new file mode 100644 index 00000000000..dd1138bdccf --- /dev/null +++ b/queue-5.10/acpi-sysfs-prefer-compatible-modalias.patch @@ -0,0 +1,65 @@ +From 36af2d5c4433fb40ee2af912c4ac0a30991aecfc Mon Sep 17 00:00:00 2001 +From: Kai-Heng Feng +Date: Fri, 22 Jan 2021 20:53:02 +0800 +Subject: ACPI: sysfs: Prefer "compatible" modalias + +From: Kai-Heng Feng + +commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream. + +Commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when +"compatible" is present") may create two "MODALIAS=" in one uevent +file if specific conditions are met. + +This breaks systemd-udevd, which assumes each "key" in one uevent file +to be unique. The internal implementation of systemd-udevd overwrites +the first MODALIAS with the second one, so its kmod rule doesn't load +the driver for the first MODALIAS. + +So if both the ACPI modalias and the OF modalias are present, use the +latter to ensure that there will be only one MODALIAS. + +Link: https://github.com/systemd/systemd/pull/18163 +Suggested-by: Mika Westerberg +Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present") +Signed-off-by: Kai-Heng Feng +Reviewed-by: Mika Westerberg +Reviewed-by: Greg Kroah-Hartman +Cc: 4.1+ # 4.1+ +[ rjw: Subject and changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/device_sysfs.c | 20 ++++++-------------- + 1 file changed, 6 insertions(+), 14 deletions(-) + +--- a/drivers/acpi/device_sysfs.c ++++ b/drivers/acpi/device_sysfs.c +@@ -251,20 +251,12 @@ int __acpi_device_uevent_modalias(struct + if (add_uevent_var(env, "MODALIAS=")) + return -ENOMEM; + +- len = create_pnp_modalias(adev, &env->buf[env->buflen - 1], +- sizeof(env->buf) - env->buflen); +- if (len < 0) +- return len; +- +- env->buflen += len; +- if (!adev->data.of_compatible) +- return 0; +- +- if (len > 0 && add_uevent_var(env, "MODALIAS=")) +- return -ENOMEM; +- +- len = create_of_modalias(adev, &env->buf[env->buflen - 1], +- sizeof(env->buf) - env->buflen); ++ if (adev->data.of_compatible) ++ len = create_of_modalias(adev, &env->buf[env->buflen - 1], ++ sizeof(env->buf) - env->buflen); ++ else ++ len = create_pnp_modalias(adev, &env->buf[env->buflen - 1], ++ sizeof(env->buf) - env->buflen); + if (len < 0) + return len; + diff --git a/queue-5.10/acpi-thermal-do-not-call-acpi_thermal_check-directly.patch b/queue-5.10/acpi-thermal-do-not-call-acpi_thermal_check-directly.patch new file mode 100644 index 00000000000..33f3a67a62c --- /dev/null +++ b/queue-5.10/acpi-thermal-do-not-call-acpi_thermal_check-directly.patch @@ -0,0 +1,151 @@ +From 81b704d3e4674e09781d331df73d76675d5ad8cb Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Thu, 14 Jan 2021 19:34:22 +0100 +Subject: ACPI: thermal: Do not call acpi_thermal_check() directly + +From: Rafael J. Wysocki + +commit 81b704d3e4674e09781d331df73d76675d5ad8cb upstream. + +Calling acpi_thermal_check() from acpi_thermal_notify() directly +is problematic if _TMP triggers Notify () on the thermal zone for +which it has been evaluated (which happens on some systems), because +it causes a new acpi_thermal_notify() invocation to be queued up +every time and if that takes place too often, an indefinite number of +pending work items may accumulate in kacpi_notify_wq over time. + +Besides, it is not really useful to queue up a new invocation of +acpi_thermal_check() if one of them is pending already. + +For these reasons, rework acpi_thermal_notify() to queue up a thermal +check instead of calling acpi_thermal_check() directly and only allow +one thermal check to be pending at a time. Moreover, only allow one +acpi_thermal_check_fn() instance at a time to run +thermal_zone_device_update() for one thermal zone and make it return +early if it sees other instances running for the same thermal zone. + +While at it, fold acpi_thermal_check() into acpi_thermal_check_fn(), +as it is only called from there after the other changes made here. + +[This issue appears to have been exposed by commit 6d25be5782e4 + ("sched/core, workqueues: Distangle worker accounting from rq + lock"), but it is unclear why it was not visible earlier.] + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208877 +Reported-by: Stephen Berman +Diagnosed-by: Sebastian Andrzej Siewior +Signed-off-by: Rafael J. Wysocki +Reviewed-by: Sebastian Andrzej Siewior +Tested-by: Stephen Berman +Cc: All applicable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/thermal.c | 46 +++++++++++++++++++++++++++++++++------------- + 1 file changed, 33 insertions(+), 13 deletions(-) + +--- a/drivers/acpi/thermal.c ++++ b/drivers/acpi/thermal.c +@@ -174,6 +174,8 @@ struct acpi_thermal { + struct thermal_zone_device *thermal_zone; + int kelvin_offset; /* in millidegrees */ + struct work_struct thermal_check_work; ++ struct mutex thermal_check_lock; ++ refcount_t thermal_check_count; + }; + + /* -------------------------------------------------------------------------- +@@ -495,14 +497,6 @@ static int acpi_thermal_get_trip_points( + return 0; + } + +-static void acpi_thermal_check(void *data) +-{ +- struct acpi_thermal *tz = data; +- +- thermal_zone_device_update(tz->thermal_zone, +- THERMAL_EVENT_UNSPECIFIED); +-} +- + /* sys I/F for generic thermal sysfs support */ + + static int thermal_get_temp(struct thermal_zone_device *thermal, int *temp) +@@ -900,6 +894,12 @@ static void acpi_thermal_unregister_ther + Driver Interface + -------------------------------------------------------------------------- */ + ++static void acpi_queue_thermal_check(struct acpi_thermal *tz) ++{ ++ if (!work_pending(&tz->thermal_check_work)) ++ queue_work(acpi_thermal_pm_queue, &tz->thermal_check_work); ++} ++ + static void acpi_thermal_notify(struct acpi_device *device, u32 event) + { + struct acpi_thermal *tz = acpi_driver_data(device); +@@ -910,17 +910,17 @@ static void acpi_thermal_notify(struct a + + switch (event) { + case ACPI_THERMAL_NOTIFY_TEMPERATURE: +- acpi_thermal_check(tz); ++ acpi_queue_thermal_check(tz); + break; + case ACPI_THERMAL_NOTIFY_THRESHOLDS: + acpi_thermal_trips_update(tz, ACPI_TRIPS_REFRESH_THRESHOLDS); +- acpi_thermal_check(tz); ++ acpi_queue_thermal_check(tz); + acpi_bus_generate_netlink_event(device->pnp.device_class, + dev_name(&device->dev), event, 0); + break; + case ACPI_THERMAL_NOTIFY_DEVICES: + acpi_thermal_trips_update(tz, ACPI_TRIPS_REFRESH_DEVICES); +- acpi_thermal_check(tz); ++ acpi_queue_thermal_check(tz); + acpi_bus_generate_netlink_event(device->pnp.device_class, + dev_name(&device->dev), event, 0); + break; +@@ -1020,7 +1020,25 @@ static void acpi_thermal_check_fn(struct + { + struct acpi_thermal *tz = container_of(work, struct acpi_thermal, + thermal_check_work); +- acpi_thermal_check(tz); ++ ++ /* ++ * In general, it is not sufficient to check the pending bit, because ++ * subsequent instances of this function may be queued after one of them ++ * has started running (e.g. if _TMP sleeps). Avoid bailing out if just ++ * one of them is running, though, because it may have done the actual ++ * check some time ago, so allow at least one of them to block on the ++ * mutex while another one is running the update. ++ */ ++ if (!refcount_dec_not_one(&tz->thermal_check_count)) ++ return; ++ ++ mutex_lock(&tz->thermal_check_lock); ++ ++ thermal_zone_device_update(tz->thermal_zone, THERMAL_EVENT_UNSPECIFIED); ++ ++ refcount_inc(&tz->thermal_check_count); ++ ++ mutex_unlock(&tz->thermal_check_lock); + } + + static int acpi_thermal_add(struct acpi_device *device) +@@ -1052,6 +1070,8 @@ static int acpi_thermal_add(struct acpi_ + if (result) + goto free_memory; + ++ refcount_set(&tz->thermal_check_count, 3); ++ mutex_init(&tz->thermal_check_lock); + INIT_WORK(&tz->thermal_check_work, acpi_thermal_check_fn); + + pr_info(PREFIX "%s [%s] (%ld C)\n", acpi_device_name(device), +@@ -1117,7 +1137,7 @@ static int acpi_thermal_resume(struct de + tz->state.active |= tz->trips.active[i].flags.enabled; + } + +- queue_work(acpi_thermal_pm_queue, &tz->thermal_check_work); ++ acpi_queue_thermal_check(tz); + + return AE_OK; + } diff --git a/queue-5.10/alsa-hda-realtek-enable-headset-of-asus-b1400cepe-with-alc256.patch b/queue-5.10/alsa-hda-realtek-enable-headset-of-asus-b1400cepe-with-alc256.patch new file mode 100644 index 00000000000..0a96a827b56 --- /dev/null +++ b/queue-5.10/alsa-hda-realtek-enable-headset-of-asus-b1400cepe-with-alc256.patch @@ -0,0 +1,45 @@ +From 5de3b9430221b11a5e1fc2f5687af80777c8392a Mon Sep 17 00:00:00 2001 +From: Jian-Hong Pan +Date: Fri, 22 Jan 2021 13:47:06 +0800 +Subject: ALSA: hda/realtek: Enable headset of ASUS B1400CEPE with ALC256 + +From: Jian-Hong Pan + +commit 5de3b9430221b11a5e1fc2f5687af80777c8392a upstream. + +ASUS B1400CEPE laptop's headset audio is not enabled until +ALC256_FIXUP_ASUS_HPE quirk is applied. + +Here is the original pin node values: + +0x12 0x40000000 +0x13 0x411111f0 +0x14 0x90170110 +0x18 0x411111f0 +0x19 0x411111f0 +0x1a 0x411111f0 +0x1b 0x411111f0 +0x1d 0x40461b45 +0x1e 0x411111f0 +0x21 0x04211020 + +Signed-off-by: Jian-Hong Pan +Cc: +Link: https://lore.kernel.org/r/20210122054705.48804-1-jhp@endlessos.org +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -8006,6 +8006,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA", ALC256_FIXUP_ASUS_HEADSET_MIC), + SND_PCI_QUIRK(0x1043, 0x18f1, "Asus FX505DT", ALC256_FIXUP_ASUS_HEADSET_MIC), + SND_PCI_QUIRK(0x1043, 0x194e, "ASUS UX563FD", ALC294_FIXUP_ASUS_HPE), ++ SND_PCI_QUIRK(0x1043, 0x1982, "ASUS B1400CEPE", ALC256_FIXUP_ASUS_HPE), + SND_PCI_QUIRK(0x1043, 0x19ce, "ASUS B9450FA", ALC294_FIXUP_ASUS_HPE), + SND_PCI_QUIRK(0x1043, 0x19e1, "ASUS UX581LV", ALC295_FIXUP_ASUS_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW), diff --git a/queue-5.10/alsa-hda-via-apply-the-workaround-generically-for-clevo-machines.patch b/queue-5.10/alsa-hda-via-apply-the-workaround-generically-for-clevo-machines.patch new file mode 100644 index 00000000000..81cb3bc26b1 --- /dev/null +++ b/queue-5.10/alsa-hda-via-apply-the-workaround-generically-for-clevo-machines.patch @@ -0,0 +1,35 @@ +From 4961167bf7482944ca09a6f71263b9e47f949851 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Tue, 26 Jan 2021 17:56:03 +0100 +Subject: ALSA: hda/via: Apply the workaround generically for Clevo machines + +From: Takashi Iwai + +commit 4961167bf7482944ca09a6f71263b9e47f949851 upstream. + +We've got another report indicating a similar problem wrt the +power-saving behavior with VIA codec on Clevo machines. Let's apply +the existing workaround generically to all Clevo devices with VIA +codecs to cover all in once. + +BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1181330 +Cc: +Link: https://lore.kernel.org/r/20210126165603.11683-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_via.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/pci/hda/patch_via.c ++++ b/sound/pci/hda/patch_via.c +@@ -1043,7 +1043,7 @@ static const struct hda_fixup via_fixups + static const struct snd_pci_quirk vt2002p_fixups[] = { + SND_PCI_QUIRK(0x1043, 0x1487, "Asus G75", VIA_FIXUP_ASUS_G75), + SND_PCI_QUIRK(0x1043, 0x8532, "Asus X202E", VIA_FIXUP_INTMIC_BOOST), +- SND_PCI_QUIRK(0x1558, 0x3501, "Clevo W35xSS_370SS", VIA_FIXUP_POWER_SAVE), ++ SND_PCI_QUIRK_VENDOR(0x1558, "Clevo", VIA_FIXUP_POWER_SAVE), + {} + }; + diff --git a/queue-5.10/kernel-kexec-remove-the-lock-operation-of-system_transition_mutex.patch b/queue-5.10/kernel-kexec-remove-the-lock-operation-of-system_transition_mutex.patch new file mode 100644 index 00000000000..4048245b652 --- /dev/null +++ b/queue-5.10/kernel-kexec-remove-the-lock-operation-of-system_transition_mutex.patch @@ -0,0 +1,49 @@ +From 56c91a18432b631ca18438841fd1831ef756cabf Mon Sep 17 00:00:00 2001 +From: Baoquan He +Date: Fri, 22 Jan 2021 15:42:14 +0800 +Subject: kernel: kexec: remove the lock operation of system_transition_mutex + +From: Baoquan He + +commit 56c91a18432b631ca18438841fd1831ef756cabf upstream. + +Function kernel_kexec() is called with lock system_transition_mutex +held in reboot system call. While inside kernel_kexec(), it will +acquire system_transition_mutex agin. This will lead to dead lock. + +The dead lock should be easily triggered, it hasn't caused any +failure report just because the feature 'kexec jump' is almost not +used by anyone as far as I know. An inquiry can be made about who +is using 'kexec jump' and where it's used. Before that, let's simply +remove the lock operation inside CONFIG_KEXEC_JUMP ifdeffery scope. + +Fixes: 55f2503c3b69 ("PM / reboot: Eliminate race between reboot and suspend") +Signed-off-by: Baoquan He +Reported-by: Dan Carpenter +Reviewed-by: Pingfan Liu +Cc: 4.19+ # 4.19+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/kexec_core.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/kernel/kexec_core.c ++++ b/kernel/kexec_core.c +@@ -1135,7 +1135,6 @@ int kernel_kexec(void) + + #ifdef CONFIG_KEXEC_JUMP + if (kexec_image->preserve_context) { +- lock_system_sleep(); + pm_prepare_console(); + error = freeze_processes(); + if (error) { +@@ -1198,7 +1197,6 @@ int kernel_kexec(void) + thaw_processes(); + Restore_console: + pm_restore_console(); +- unlock_system_sleep(); + } + #endif + diff --git a/queue-5.10/series b/queue-5.10/series index 38aaa88473e..3cca0e88cec 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -1,3 +1,8 @@ iwlwifi-provide-gso_type-to-gso-packets.patch nbd-freeze-the-queue-while-we-re-adding-connections.patch tty-avoid-using-vfs_iocb_iter_write-for-redirected-console-writes.patch +acpi-sysfs-prefer-compatible-modalias.patch +acpi-thermal-do-not-call-acpi_thermal_check-directly.patch +kernel-kexec-remove-the-lock-operation-of-system_transition_mutex.patch +alsa-hda-realtek-enable-headset-of-asus-b1400cepe-with-alc256.patch +alsa-hda-via-apply-the-workaround-generically-for-clevo-machines.patch -- 2.47.3