From: Greg Kroah-Hartman Date: Sat, 23 May 2020 11:13:10 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v4.4.225~51 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=09ed42ecc7981dff3ea576ea4836093bc8004620;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: alsa-hda-realtek-add-more-fixup-entries-for-clevo-machines.patch alsa-hda-realtek-fix-silent-output-on-gigabyte-x570-aorus-xtreme.patch alsa-iec1712-initialize-stdsp24-properly-when-using-the-model-staudio-option.patch alsa-pcm-fix-incorrect-hw_base-increase.patch scsi-qla2xxx-do-not-log-message-when-reading-port-speed-via-sysfs.patch scsi-target-put-lun_ref-at-end-of-tmr-processing.patch --- diff --git a/queue-5.4/alsa-hda-realtek-add-more-fixup-entries-for-clevo-machines.patch b/queue-5.4/alsa-hda-realtek-add-more-fixup-entries-for-clevo-machines.patch new file mode 100644 index 00000000000..e73e2c5e435 --- /dev/null +++ b/queue-5.4/alsa-hda-realtek-add-more-fixup-entries-for-clevo-machines.patch @@ -0,0 +1,34 @@ +From 259eb82475316672a5d682a94dc8bdd53cf8d8c3 Mon Sep 17 00:00:00 2001 +From: PeiSen Hou +Date: Tue, 19 May 2020 08:50:12 +0200 +Subject: ALSA: hda/realtek - Add more fixup entries for Clevo machines + +From: PeiSen Hou + +commit 259eb82475316672a5d682a94dc8bdd53cf8d8c3 upstream. + +A few known Clevo machines (PC50, PC70, X170) with ALC1220 codec need +the existing quirk for pins for PB51 and co. + +Signed-off-by: PeiSen Hou +Cc: +Link: https://lore.kernel.org/r/20200519065012.13119-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -2473,6 +2473,9 @@ static const struct snd_pci_quirk alc882 + SND_PCI_QUIRK(0x1558, 0x97e1, "Clevo P970[ER][CDFN]", ALC1220_FIXUP_CLEVO_P950), + SND_PCI_QUIRK(0x1558, 0x65d1, "Clevo PB51[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS), + SND_PCI_QUIRK(0x1558, 0x67d1, "Clevo PB71[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS), ++ SND_PCI_QUIRK(0x1558, 0x50d3, "Clevo PC50[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS), ++ SND_PCI_QUIRK(0x1558, 0x70d1, "Clevo PC70[ER][CDF]", ALC1220_FIXUP_CLEVO_PB51ED_PINS), ++ SND_PCI_QUIRK(0x1558, 0x7714, "Clevo X170", ALC1220_FIXUP_CLEVO_PB51ED_PINS), + SND_PCI_QUIRK_VENDOR(0x1558, "Clevo laptop", ALC882_FIXUP_EAPD), + SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_FIXUP_EAPD), + SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo Y530", ALC882_FIXUP_LENOVO_Y530), diff --git a/queue-5.4/alsa-hda-realtek-fix-silent-output-on-gigabyte-x570-aorus-xtreme.patch b/queue-5.4/alsa-hda-realtek-fix-silent-output-on-gigabyte-x570-aorus-xtreme.patch new file mode 100644 index 00000000000..ae8d5878c3a --- /dev/null +++ b/queue-5.4/alsa-hda-realtek-fix-silent-output-on-gigabyte-x570-aorus-xtreme.patch @@ -0,0 +1,34 @@ +From d9e8fe0cffbfdd18de96fa68ee2a8b667a0b046e Mon Sep 17 00:00:00 2001 +From: Christian Lachner +Date: Mon, 18 May 2020 07:38:44 +0200 +Subject: ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme + +From: Christian Lachner + +commit d9e8fe0cffbfdd18de96fa68ee2a8b667a0b046e upstream. + +The Gigabyte X570 Aorus Xtreme motherboard with ALC1220 codec +requires a similar workaround for Clevo laptops to enforce the +DAC/mixer connection path. Set up a quirk entry for that. + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275 +Signed-off-by: Christian Lachner +Cc: +Link: https://lore.kernel.org/r/20200518053844.42743-2-gladiac@gmail.com +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 +@@ -2457,6 +2457,7 @@ static const struct snd_pci_quirk alc882 + SND_PCI_QUIRK(0x1458, 0xa002, "Gigabyte EP45-DS3/Z87X-UD3H", ALC889_FIXUP_FRONT_HP_NO_PRESENCE), + SND_PCI_QUIRK(0x1458, 0xa0b8, "Gigabyte AZ370-Gaming", ALC1220_FIXUP_GB_DUAL_CODECS), + SND_PCI_QUIRK(0x1458, 0xa0cd, "Gigabyte X570 Aorus Master", ALC1220_FIXUP_CLEVO_P950), ++ SND_PCI_QUIRK(0x1458, 0xa0ce, "Gigabyte X570 Aorus Xtreme", ALC1220_FIXUP_CLEVO_P950), + SND_PCI_QUIRK(0x1462, 0x1228, "MSI-GP63", ALC1220_FIXUP_CLEVO_P950), + SND_PCI_QUIRK(0x1462, 0x1275, "MSI-GL63", ALC1220_FIXUP_CLEVO_P950), + SND_PCI_QUIRK(0x1462, 0x1276, "MSI-GL73", ALC1220_FIXUP_CLEVO_P950), diff --git a/queue-5.4/alsa-iec1712-initialize-stdsp24-properly-when-using-the-model-staudio-option.patch b/queue-5.4/alsa-iec1712-initialize-stdsp24-properly-when-using-the-model-staudio-option.patch new file mode 100644 index 00000000000..f4a3ecef8ad --- /dev/null +++ b/queue-5.4/alsa-iec1712-initialize-stdsp24-properly-when-using-the-model-staudio-option.patch @@ -0,0 +1,38 @@ +From b0cb099062b0c18246c3a20caaab4c0afc303255 Mon Sep 17 00:00:00 2001 +From: Scott Bahling +Date: Mon, 18 May 2020 19:57:28 +0200 +Subject: ALSA: iec1712: Initialize STDSP24 properly when using the model=staudio option + +From: Scott Bahling + +commit b0cb099062b0c18246c3a20caaab4c0afc303255 upstream. + +The ST Audio ADCIII is an STDSP24 card plus extension box. With commit +e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII") we +enabled the ADCIII ports using the model=staudio option but forgot +this part to ensure the STDSP24 card is initialized properly. + +Fixes: e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII") +Signed-off-by: Scott Bahling +Cc: +BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1048934 +Link: https://lore.kernel.org/r/20200518175728.28766-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/ice1712/ice1712.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/sound/pci/ice1712/ice1712.c ++++ b/sound/pci/ice1712/ice1712.c +@@ -2360,7 +2360,8 @@ static int snd_ice1712_chip_init(struct + pci_write_config_byte(ice->pci, 0x61, ice->eeprom.data[ICE_EEP1_ACLINK]); + pci_write_config_byte(ice->pci, 0x62, ice->eeprom.data[ICE_EEP1_I2SID]); + pci_write_config_byte(ice->pci, 0x63, ice->eeprom.data[ICE_EEP1_SPDIF]); +- if (ice->eeprom.subvendor != ICE1712_SUBDEVICE_STDSP24) { ++ if (ice->eeprom.subvendor != ICE1712_SUBDEVICE_STDSP24 && ++ ice->eeprom.subvendor != ICE1712_SUBDEVICE_STAUDIO_ADCIII) { + ice->gpio.write_mask = ice->eeprom.gpiomask; + ice->gpio.direction = ice->eeprom.gpiodir; + snd_ice1712_write(ice, ICE1712_IREG_GPIO_WRITE_MASK, diff --git a/queue-5.4/alsa-pcm-fix-incorrect-hw_base-increase.patch b/queue-5.4/alsa-pcm-fix-incorrect-hw_base-increase.patch new file mode 100644 index 00000000000..2e1cc793dde --- /dev/null +++ b/queue-5.4/alsa-pcm-fix-incorrect-hw_base-increase.patch @@ -0,0 +1,80 @@ +From e7513c5786f8b33f0c107b3759e433bc6cbb2efa Mon Sep 17 00:00:00 2001 +From: Brent Lu +Date: Mon, 18 May 2020 12:30:38 +0800 +Subject: ALSA: pcm: fix incorrect hw_base increase + +From: Brent Lu + +commit e7513c5786f8b33f0c107b3759e433bc6cbb2efa upstream. + +There is a corner case that ALSA keeps increasing the hw_ptr but DMA +already stop working/updating the position for a long time. + +In following log we can see the position returned from DMA driver does +not move at all but the hw_ptr got increased at some point of time so +snd_pcm_avail() will return a large number which seems to be a buffer +underrun event from user space program point of view. The program +thinks there is space in the buffer and fill more data. + +[ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368 +[ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554 +... +[ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362 +[ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 +[ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368 + +This is because the hw_base will be increased by runtime->buffer_size +frames unconditionally if the hw_ptr is not updated for over half of +buffer time. As the hw_base increases, so does the hw_ptr increased +by the same number. + +The avail value returned from snd_pcm_avail() could exceed the limit +(buffer_size) easily becase the hw_ptr itself got increased by same +buffer_size samples when the corner case happens. In following log, +the buffer_size is 16368 samples but the avail is 21810 samples so +CRAS server complains about it. + +[ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442 +[ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810 + +cras_server[1907]: pcm_avail returned frames larger than buf_size: +sof-glkda7219max: :0,5: 21810 > 16368 + +By updating runtime->hw_ptr_jiffies each time the HWSYNC is called, +the hw_base will keep the same when buffer stall happens at long as +the interval between each HWSYNC call is shorter than half of buffer +time. + +Following is a log captured by a patched kernel. The hw_base/hw_ptr +value is fixed in this corner case and user space program should be +aware of the buffer stall and handle it. + +[ 293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368 +[ 293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584 +[ 293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488 +[ 293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392 +[ 293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 +... +[ 381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 + +Signed-off-by: Brent Lu +Reviewed-by: Jaroslav Kysela +Cc: +Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/core/pcm_lib.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/core/pcm_lib.c ++++ b/sound/core/pcm_lib.c +@@ -423,6 +423,7 @@ static int snd_pcm_update_hw_ptr0(struct + + no_delta_check: + if (runtime->status->hw_ptr == new_hw_ptr) { ++ runtime->hw_ptr_jiffies = curr_jiffies; + update_audio_tstamp(substream, &curr_tstamp, &audio_tstamp); + return 0; + } diff --git a/queue-5.4/scsi-qla2xxx-do-not-log-message-when-reading-port-speed-via-sysfs.patch b/queue-5.4/scsi-qla2xxx-do-not-log-message-when-reading-port-speed-via-sysfs.patch new file mode 100644 index 00000000000..a6a62941d34 --- /dev/null +++ b/queue-5.4/scsi-qla2xxx-do-not-log-message-when-reading-port-speed-via-sysfs.patch @@ -0,0 +1,41 @@ +From fb9024b0646939e59d8a0b6799b317070619795a Mon Sep 17 00:00:00 2001 +From: "Ewan D. Milne" +Date: Mon, 4 May 2020 13:54:16 -0400 +Subject: scsi: qla2xxx: Do not log message when reading port speed via sysfs + +From: Ewan D. Milne + +commit fb9024b0646939e59d8a0b6799b317070619795a upstream. + +Calling ql_log() inside qla2x00_port_speed_show() is causing messages to be +output to the console for no particularly good reason. The sysfs read +routine should just return the information to userspace. The only reason +to log a message is when the port speed actually changes, and this already +occurs elsewhere. + +Link: https://lore.kernel.org/r/20200504175416.15417-1-emilne@redhat.com +Fixes: 4910b524ac9e ("scsi: qla2xxx: Add support for setting port speed") +Cc: # v5.1+ +Reviewed-by: Lee Duncan +Reviewed-by: Laurence Oberman +Reviewed-by: Himanshu Madhani +Signed-off-by: Ewan D. Milne +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/qla2xxx/qla_attr.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/drivers/scsi/qla2xxx/qla_attr.c ++++ b/drivers/scsi/qla2xxx/qla_attr.c +@@ -1775,9 +1775,6 @@ qla2x00_port_speed_show(struct device *d + return -EINVAL; + } + +- ql_log(ql_log_info, vha, 0x70d6, +- "port speed:%d\n", ha->link_data_rate); +- + return scnprintf(buf, PAGE_SIZE, "%s\n", spd[ha->link_data_rate]); + } + diff --git a/queue-5.4/scsi-target-put-lun_ref-at-end-of-tmr-processing.patch b/queue-5.4/scsi-target-put-lun_ref-at-end-of-tmr-processing.patch new file mode 100644 index 00000000000..5904e91a0ff --- /dev/null +++ b/queue-5.4/scsi-target-put-lun_ref-at-end-of-tmr-processing.patch @@ -0,0 +1,61 @@ +From f2e6b75f6ee82308ef7b00f29e71e5f1c6b3d52a Mon Sep 17 00:00:00 2001 +From: Bodo Stroesser +Date: Wed, 13 May 2020 17:34:43 +0200 +Subject: scsi: target: Put lun_ref at end of tmr processing + +From: Bodo Stroesser + +commit f2e6b75f6ee82308ef7b00f29e71e5f1c6b3d52a upstream. + +Testing with Loopback I found that, after a Loopback LUN has executed a +TMR, I can no longer unlink the LUN. The rm command hangs in +transport_clear_lun_ref() at wait_for_completion(&lun->lun_shutdown_comp) +The reason is, that transport_lun_remove_cmd() is not called at the end of +target_tmr_work(). + +It seems, that in other fabrics this call happens implicitly when the +fabric drivers call transport_generic_free_cmd() during their +->queue_tm_rsp(). + +Unfortunately Loopback seems to not comply to the common way +of calling transport_generic_free_cmd() from ->queue_*(). +Instead it calls transport_generic_free_cmd() from its + ->check_stop_free() only. + +But the ->check_stop_free() is called by +transport_cmd_check_stop_to_fabric() after it has reset the se_cmd->se_lun +pointer. Therefore the following transport_generic_free_cmd() skips the +transport_lun_remove_cmd(). + +So this patch re-adds the transport_lun_remove_cmd() at the end of +target_tmr_work(), which was removed during commit 2c9fa49e100f ("scsi: +target/core: Make ABORT and LUN RESET handling synchronous"). + +For fabrics using transport_generic_free_cmd() in the usual way the double +call to transport_lun_remove_cmd() doesn't harm, as +transport_lun_remove_cmd() checks for this situation and does not release +lun_ref twice. + +Link: https://lore.kernel.org/r/20200513153443.3554-1-bstroesser@ts.fujitsu.com +Fixes: 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous") +Cc: stable@vger.kernel.org +Tested-by: Bryant G. Ly +Reviewed-by: Bart van Assche +Signed-off-by: Bodo Stroesser +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/target/target_core_transport.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/target/target_core_transport.c ++++ b/drivers/target/target_core_transport.c +@@ -3336,6 +3336,7 @@ static void target_tmr_work(struct work_ + + cmd->se_tfo->queue_tm_rsp(cmd); + ++ transport_lun_remove_cmd(cmd); + transport_cmd_check_stop_to_fabric(cmd); + return; + diff --git a/queue-5.4/series b/queue-5.4/series index cdf0c64fa96..da3f2f9add5 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -56,3 +56,9 @@ alsa-hda-realtek-enable-headset-mic-of-asus-gl503vm-.patch alsa-hda-realtek-enable-headset-mic-of-asus-ux550ge-.patch alsa-hda-realtek-enable-headset-mic-of-asus-ux581lv-.patch kvm-x86-fix-pkru-save-restore-when-guest-cr4.pke-0-move-it-to-x86.c.patch +alsa-iec1712-initialize-stdsp24-properly-when-using-the-model-staudio-option.patch +alsa-pcm-fix-incorrect-hw_base-increase.patch +alsa-hda-realtek-fix-silent-output-on-gigabyte-x570-aorus-xtreme.patch +alsa-hda-realtek-add-more-fixup-entries-for-clevo-machines.patch +scsi-qla2xxx-do-not-log-message-when-reading-port-speed-via-sysfs.patch +scsi-target-put-lun_ref-at-end-of-tmr-processing.patch