BMC/Intel-BMC/linux.git/sound, branch dev-4.10

ALSA: hda - Fix deadlock of controller device lock at unbinding

2017-05-14T12:08:28+00:00

commit ab949d519601880fd46e8bc1445d6a453bf2dc09 upstream. Imre Deak reported a deadlock of HD-audio driver at unbinding while it's still in probing. Since we probe the codecs asynchronously in a work, the codec driver probe may still be kicked off while the controller itself is being unbound. And, azx_remove() tries to process all pending tasks via cancel_work_sync() for fixing the other races (see commit [0b8c82190c12: ALSA: hda - Cancel probe work instead of flush at remove]), now we may meet a bizarre deadlock: Unbind snd_hda_intel via sysfs: device_release_driver() -> device_lock(snd_hda_intel) -> azx_remove() -> cancel_work_sync(azx_probe_work) azx_probe_work(): codec driver probe() -> __driver_attach() -> device_lock(snd_hda_intel) This deadlock is caused by the fact that both device_release_driver() and driver_probe_device() take both the device and its parent locks at the same time. The codec device sets the controller device as its parent, and this lock is taken before the probe() callback is called, while the controller remove() callback gets called also with the same lock. In this patch, as an ugly workaround, we unlock the controller device temporarily during cancel_work_sync() call. The race against another bind call should be still suppressed by the parent's device lock. Reported-by: Imre Deak Fixes: 0b8c82190c12 ("ALSA: hda - Cancel probe work instead of flush at remove") Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ASoC: intel: Fix PM and non-atomic crash in bytcr drivers

2017-05-03T15:37:43+00:00

commit 6e4cac23c5a648d50b107d1b53e9c4e1120c7943 upstream. The FE setups of Intel SST bytcr_rt5640 and bytcr_rt5651 drivers carry the ignore_suspend flag, and this prevents the suspend/resume working properly while the stream is running, since SST core code has the check of the running streams and returns -EBUSY. Drop these superfluous flags for fixing the behavior. Also, the bytcr_rt5640 driver lacks of nonatomic flag in some FE definitions, which leads to the kernel Oops at suspend/resume like: BUG: scheduling while atomic: systemd-sleep/3144/0x00000003 Call Trace: dump_stack+0x5c/0x7a __schedule_bug+0x55/0x70 __schedule+0x63c/0x8c0 schedule+0x3d/0x90 schedule_timeout+0x16b/0x320 ? del_timer_sync+0x50/0x50 ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core] ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core] ? remove_wait_queue+0x60/0x60 ? sst_prepare_and_post_msg+0x275/0x960 [snd_intel_sst_core] ? sst_pause_stream+0x9b/0x110 [snd_intel_sst_core] .... This patch addresses these appropriately, too. Signed-off-by: Takashi Iwai Acked-by: Vinod Koul Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

ALSA: seq: Don't break snd_use_lock_sync() loop by timeout

2017-05-03T15:37:42+00:00

commit 4e7655fd4f47c23e5249ea260dc802f909a64611 upstream. The snd_use_lock_sync() (thus its implementation snd_use_lock_sync_helper()) has the 5 seconds timeout to break out of the sync loop. It was introduced from the beginning, just to be "safer", in terms of avoiding the stupid bugs. However, as Ben Hutchings suggested, this timeout rather introduces a potential leak or use-after-free that was apparently fixed by the commit 2d7d54002e39 ("ALSA: seq: Fix race during FIFO resize"): for example, snd_seq_fifo_event_in() -> snd_seq_event_dup() -> copy_from_user() could block for a long time, and snd_use_lock_sync() goes timeout and still leaves the cell at releasing the pool. For fixing such a problem, we remove the break by the timeout while still keeping the warning. Suggested-by: Ben Hutchings Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: firewire-lib: fix inappropriate assignment between signed/unsigned type

2017-05-03T15:37:42+00:00

commit dfb00a56935186171abb5280b3407c3f910011f1 upstream. An abstraction of asynchronous transaction for transmission of MIDI messages was introduced in Linux v4.4. Each driver can utilize this abstraction to transfer MIDI messages via fixed-length payload of transaction to a certain unit address. Filling payload of the transaction is done by callback. In this callback, each driver can return negative error code, however current implementation assigns the return value to unsigned variable. This commit changes type of the variable to fix the bug. Reported-by: Julia Lawall Fixes: 585d7cba5e1f ("ALSA: firewire-lib: add helper functions for asynchronous transactions to transfer MIDI messages") Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: oxfw: fix regression to handle Stanton SCS.1m/1d

2017-05-03T15:37:42+00:00

commit 3d016d57fdc5e6caa4cd67896f4b081bccad6e2c upstream. At a commit 6c29230e2a5f ("ALSA: oxfw: delayed registration of sound card"), ALSA oxfw driver fails to handle SCS.1m/1d, due to -EBUSY at a call of snd_card_register(). The cause is that the driver manages to register two rawmidi instances with the same device number 0. This is a regression introduced since kernel 4.7. This commit fixes the regression, by fixing up device property after discovering stream formats. Fixes: 6c29230e2a5f ("ALSA: oxfw: delayed registration of sound card") Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ASoC: Intel: select DW_DMAC_CORE since it's mandatory

2017-04-21T07:32:42+00:00

commit ebf79091bf85d9b2270ab29191de9cd3aaf888c5 upstream. Select DW_DMAC_CORE like the rest of glue drivers do, e.g. drivers/dma/dw/Kconfig. While here group selectors under SND_SOC_INTEL_HASWELL and SND_SOC_INTEL_BAYTRAIL. Make platforms, which are using a common SST firmware driver, to be dependent on DMADEVICES. Signed-off-by: Andy Shevchenko Acked-by: Liam Girdwood Signed-off-by: Mark Brown Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

ASoC: sun4i-i2s: Add quirks to handle a31 compatible

2017-04-12T10:42:11+00:00

[ Upstream commit 2ad6f30de7087515a0bc2a718fca6681a57739a0 ] Some SoCs have a reset line that must be asserted/deasserted. This patch adds a quirk to handle the new compatible "allwinner,sun6i-a31-i2s" which will deassert the reset line on probe function and assert it on remove's one. This new compatible is useful in case of A33 codec driver, for example. Signed-off-by: Mylène Josserand Acked-by: Maxime Ripard Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ASoC: Intel: cht_bsw_rt5645: add Baytrail MCLK support

2017-04-12T10:42:11+00:00

[ Upstream commit a50477e55fff69e1028f25624ee9fc9182d59b1f ] The existing code assumes a 19.2 MHz MCLK as the default hardware configuration. This is valid for CherryTrail but not for Baytrail. Add explicit MCLK configuration to set the 19.2 clock on/off depending on DAPM events. This is a prerequisite step to enable devices with Baytrail and RT5645 such as Asus X205TA Signed-off-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ASoC: Intel: cht_bsw_rt5645: harden ACPI device detection

2017-04-12T10:42:11+00:00

[ Upstream commit 42648c2270ca0c96935dfc5d0f5c4f8d2406cf75 ] Fix classic issue of having multiple codecs listed in DSDT but a single one actually enabled. The previous code did not handle such errors and could also lead to uninitalized configurations Signed-off-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ASoC: Intel: Baytrail: add quirk for Lenovo Thinkpad 10

2017-04-12T10:42:11+00:00

[ Upstream commit fd0138dc5d17c636477b371d99265c406437c583 ] the BIOS reports this codec as RT5640 but it's a rt5670. Use the quirk mechanism to use the cht_bsw_rt5672 machine driver Signed-off-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman