June 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 1/3] ASoC: jz4740-i2s: Make probe function __init_or_module
by Paul Cercueil 08 Jun '19

08 Jun '19

This allows the probe function to be dropped after the kernel finished its initialization, in the case where the driver was not compiled as a module. Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- sound/soc/jz4740/jz4740-i2s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/jz4740/jz4740-i2s.c b/sound/soc/jz4740/jz4740-i2s.c index 13408de34055..1f596770b01a 100644 --- a/sound/soc/jz4740/jz4740-i2s.c +++ b/sound/soc/jz4740/jz4740-i2s.c @@ -492,7 +492,7 @@ static const struct of_device_id jz4740_of_matches[] = { MODULE_DEVICE_TABLE(of, jz4740_of_matches); #endif -static int jz4740_i2s_dev_probe(struct platform_device *pdev) +static int __init_or_module jz4740_i2s_dev_probe(struct platform_device *pdev) { struct jz4740_i2s *i2s; struct resource *mem; -- 2.21.0.593.g511ec345e18

1 3

[alsa-devel] [PATCH] ASoC: Intel: sst: fix kmalloc call with wrong flags
by Alex Levin 08 Jun '19

08 Jun '19

When calling kmalloc with GFP_KERNEL in case CONFIG_SLOB is unset, kmem_cache_alloc_trace is called. In case CONFIG_TRACING is set, kmem_cache_alloc_trace will ball slab_alloc, which will call slab_pre_alloc_hook which might_sleep_if. The context in which it is called in this case, the intel_sst_interrupt_mrfld, calling a sleeping kmalloc generates a BUG(): Fixes: 972b0d456e64 ("ASoC: Intel: remove GFP_ATOMIC, use GFP_KERNEL") [ 20.250671] BUG: sleeping function called from invalid context at mm/slab.h:422 [ 20.250683] in_atomic(): 1, irqs_disabled(): 1, pid: 1791, name: Chrome_IOThread [ 20.250690] CPU: 0 PID: 1791 Comm: Chrome_IOThread Tainted: G W 4.19.43 #61 [ 20.250693] Hardware name: GOOGLE Kefka, BIOS Google_Kefka.7287.337.0 03/02/2017 [ 20.250697] Call Trace: [ 20.250704] <IRQ> [ 20.250716] dump_stack+0x7e/0xc3 [ 20.250725] ___might_sleep+0x12a/0x140 [ 20.250731] kmem_cache_alloc_trace+0x53/0x1c5 [ 20.250736] ? update_cfs_rq_load_avg+0x17e/0x1aa [ 20.250740] ? cpu_load_update+0x6c/0xc2 [ 20.250746] sst_create_ipc_msg+0x2d/0x88 [ 20.250752] intel_sst_interrupt_mrfld+0x12a/0x22c [ 20.250758] __handle_irq_event_percpu+0x133/0x228 [ 20.250764] handle_irq_event_percpu+0x35/0x7a [ 20.250768] handle_irq_event+0x36/0x55 [ 20.250773] handle_fasteoi_irq+0xab/0x16c [ 20.250779] handle_irq+0xd9/0x11e [ 20.250785] do_IRQ+0x54/0xe0 [ 20.250791] common_interrupt+0xf/0xf [ 20.250795] </IRQ> [ 20.250800] RIP: 0010:__lru_cache_add+0x4e/0xad [ 20.250806] Code: 00 01 48 c7 c7 b8 df 01 00 65 48 03 3c 25 28 f1 00 00 48 8b 48 08 48 89 ca 48 ff ca f6 c1 01 48 0f 44 d0 f0 ff 42 34 0f b6 0f <89> ca fe c2 88 17 48 89 44 cf 08 80 fa 0f 74 0e 48 8b 08 66 85 c9 [ 20.250809] RSP: 0000:ffffa568810bfd98 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffd6 [ 20.250814] RAX: ffffd3b904eb1940 RBX: ffffd3b904eb1940 RCX: 0000000000000004 [ 20.250817] RDX: ffffd3b904eb1940 RSI: ffffa10ee5c47450 RDI: ffffa10efba1dfb8 [ 20.250821] RBP: ffffa568810bfda8 R08: ffffa10ef9c741c1 R09: dead000000000100 [ 20.250824] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa10ee8d52a40 [ 20.250827] R13: ffffa10ee8d52000 R14: ffffa10ee5c47450 R15: 800000013ac65067 [ 20.250835] lru_cache_add_active_or_unevictable+0x4e/0xb8 [ 20.250841] handle_mm_fault+0xd98/0x10c4 [ 20.250848] __do_page_fault+0x235/0x42d [ 20.250853] ? page_fault+0x8/0x30 [ 20.250858] do_page_fault+0x3d/0x17a [ 20.250862] ? page_fault+0x8/0x30 [ 20.250866] page_fault+0x1e/0x30 [ 20.250872] RIP: 0033:0x7962fdea9304 [ 20.250875] Code: 0f 11 4c 17 f0 c3 48 3b 15 f1 26 31 00 0f 83 e2 00 00 00 48 39 f7 72 0f 74 12 4c 8d 0c 16 4c 39 cf 0f 82 63 01 00 00 48 89 d1 <f3> a4 c3 80 fa 08 73 12 80 fa 04 73 1e 80 fa 01 77 26 72 05 0f b6 [ 20.250879] RSP: 002b:00007962f4db5468 EFLAGS: 00010206 [ 20.250883] RAX: 00003c8cc9d47008 RBX: 0000000000000000 RCX: 0000000000001b48 [ 20.250886] RDX: 0000000000002b40 RSI: 00003c8cc9551000 RDI: 00003c8cc9d48000 [ 20.250890] RBP: 00007962f4db5820 R08: 0000000000000000 R09: 00003c8cc9552b48 [ 20.250893] R10: 0000562dd1064d30 R11: 00003c8cc825b908 R12: 00003c8cc966d3c0 [ 20.250896] R13: 00003c8cc9e280c0 R14: 0000000000000000 R15: 0000000000000000 Signed-off-by: Alex Levin <levinale(a)chromium.org> --- sound/soc/intel/atom/sst/sst_pvt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/atom/sst/sst_pvt.c b/sound/soc/intel/atom/sst/sst_pvt.c index 00a37a09dc9b..dba0ca07ebf9 100644 --- a/sound/soc/intel/atom/sst/sst_pvt.c +++ b/sound/soc/intel/atom/sst/sst_pvt.c @@ -166,11 +166,11 @@ int sst_create_ipc_msg(struct ipc_post **arg, bool large) { struct ipc_post *msg; - msg = kzalloc(sizeof(*msg), GFP_KERNEL); + msg = kzalloc(sizeof(*msg), GFP_ATOMIC); if (!msg) return -ENOMEM; if (large) { - msg->mailbox_data = kzalloc(SST_MAILBOX_SIZE, GFP_KERNEL); + msg->mailbox_data = kzalloc(SST_MAILBOX_SIZE, GFP_ATOMIC); if (!msg->mailbox_data) { kfree(msg); return -ENOMEM; -- 2.22.0.rc2.383.gf4fbbf30c2-goog

3 3

[alsa-devel] [PATCH] ASoC: core: Fix deadlock in snd_soc_instantiate_card()
by Ranjani Sridharan 08 Jun '19

08 Jun '19

Move the client_mutex lock to snd_soc_unbind_card() before removing link components. This prevents the deadlock in the error path in snd_soc_instantiate_card(). Fixes: 34ac3c3eb8 (ASoC: core: lock client_mutex while removing link components) Reported-by: kernelci.org bot <bot(a)kernelci.org> Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> --- sound/soc/soc-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index f0fa289c90d8..23538868ed76 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1018,14 +1018,12 @@ static void soc_remove_link_components(struct snd_soc_card *card, struct snd_soc_component *component; struct snd_soc_rtdcom_list *rtdcom; - mutex_lock(&client_mutex); for_each_rtdcom(rtd, rtdcom) { component = rtdcom->component; if (component->driver->remove_order == order) soc_remove_component(component); } - mutex_unlock(&client_mutex); } static void soc_remove_dai_links(struct snd_soc_card *card) @@ -2749,12 +2747,14 @@ static void snd_soc_unbind_card(struct snd_soc_card *card, bool unregister) snd_soc_dapm_shutdown(card); snd_soc_flush_all_delayed_work(card); + mutex_lock(&client_mutex); /* remove all components used by DAI links on this card */ for_each_comp_order(order) { for_each_card_rtds(card, rtd) { soc_remove_link_components(card, rtd, order); } } + mutex_unlock(&client_mutex); soc_cleanup_card_resources(card); if (!unregister) -- 2.17.1

1 0

[alsa-devel] [RFC/RFT PATCH v2] ASoC: fsl_esai: Revert "ETDR and TX0~5 registers are non volatile"
by Nicolin Chen 08 Jun '19

08 Jun '19

Commit 8973112aa41b ("ASoC: fsl_esai: ETDR and TX0~5 registers are non volatile") removed TX data registers from the volatile_reg list and appended default values for them. However, being data registers of TX, they should not have been removed from the list because they should not be cached -- see the following reason. When doing regcache_sync(), this operation might accidentally write some dirty data to these registers, in case that cached data happen to be different from the default ones, which might also result in a channel shift or swap situation, since the number of write-via-sync operations at ETDR would very unlikely match the channel number. So this patch reverts the original commit to keep TX data registers in volatile_reg list in order to prevent them from being written by regcache_sync(). Note: this revert is not a complete revert as it keeps those macros of registers remaining in the default value list while the original commit also changed other entries in the list. And this patch isn't very necessary to Cc stable tree since there has been always a FIFO reset operation around the regcache_sync() call, even prior to this reverted commit. Signed-off-by: Nicolin Chen <nicoleotsuka(a)gmail.com> Cc: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- Hi Mark, In case there's no objection against the patch, I'd still like to wait for a Tested-by from NXP folks before submitting it. Thanks! Changelog v1->v2 * Fixed subject by following subsystem format. * Revised commit message to emphasize the real issue. sound/soc/fsl/fsl_esai.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index 10d2210c91ef..8f0a86335f73 100644 --- a/sound/soc/fsl/fsl_esai.c +++ b/sound/soc/fsl/fsl_esai.c @@ -652,16 +652,9 @@ static const struct snd_soc_component_driver fsl_esai_component = { }; static const struct reg_default fsl_esai_reg_defaults[] = { - {REG_ESAI_ETDR, 0x00000000}, {REG_ESAI_ECR, 0x00000000}, {REG_ESAI_TFCR, 0x00000000}, {REG_ESAI_RFCR, 0x00000000}, - {REG_ESAI_TX0, 0x00000000}, - {REG_ESAI_TX1, 0x00000000}, - {REG_ESAI_TX2, 0x00000000}, - {REG_ESAI_TX3, 0x00000000}, - {REG_ESAI_TX4, 0x00000000}, - {REG_ESAI_TX5, 0x00000000}, {REG_ESAI_TSR, 0x00000000}, {REG_ESAI_SAICR, 0x00000000}, {REG_ESAI_TCR, 0x00000000}, @@ -711,10 +704,17 @@ static bool fsl_esai_readable_reg(struct device *dev, unsigned int reg) static bool fsl_esai_volatile_reg(struct device *dev, unsigned int reg) { switch (reg) { + case REG_ESAI_ETDR: case REG_ESAI_ERDR: case REG_ESAI_ESR: case REG_ESAI_TFSR: case REG_ESAI_RFSR: + case REG_ESAI_TX0: + case REG_ESAI_TX1: + case REG_ESAI_TX2: + case REG_ESAI_TX3: + case REG_ESAI_TX4: + case REG_ESAI_TX5: case REG_ESAI_RX0: case REG_ESAI_RX1: case REG_ESAI_RX2: -- 2.17.1

1 0

[alsa-devel] [RFC/RFT PATCH] Revert "ASoC: fsl_esai: ETDR and TX0~5 registers are non volatile"
by Nicolin Chen 08 Jun '19

08 Jun '19

This reverts commit 8973112aa41b8ad956a5b47f2fe17bc2a5cf2645. ETDR and TX0~5 are TX data registers. There are a couple of reasons to revert the change: 1) Though ETDR and TX0~5 are not volatile but write-only registers, they should not be cached either. According to the definition of "volatile_reg", one should be put in the volatile list if it can not be cached. 2) When doing regcache_sync(), the operation may accidentally write some "dirty" data into these registers, in case that cached data happen to be different from the default ones. It may also result in a channel shift/swap situation since the number of write-via- sync operations at ETDR would unlikely match the channel number. Note: this revert is not a complete revert as it keeps those macros of registers remaining in the default value list while the original commit also changed other entries in the list. And this patch isn't very necessary to Cc stable tree since there has been always a FIFO reset operation around the regcache_sync() call, even prior to this reverted commit. Signed-off-by: Nicolin Chen <nicoleotsuka(a)gmail.com> Cc: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- Hi Mark, In case there's no objection against the patch, I'd still like to wait for a Tested-by from NXP folks before submitting it. Thanks! sound/soc/fsl/fsl_esai.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index 10d2210c91ef..8f0a86335f73 100644 --- a/sound/soc/fsl/fsl_esai.c +++ b/sound/soc/fsl/fsl_esai.c @@ -652,16 +652,9 @@ static const struct snd_soc_component_driver fsl_esai_component = { }; static const struct reg_default fsl_esai_reg_defaults[] = { - {REG_ESAI_ETDR, 0x00000000}, {REG_ESAI_ECR, 0x00000000}, {REG_ESAI_TFCR, 0x00000000}, {REG_ESAI_RFCR, 0x00000000}, - {REG_ESAI_TX0, 0x00000000}, - {REG_ESAI_TX1, 0x00000000}, - {REG_ESAI_TX2, 0x00000000}, - {REG_ESAI_TX3, 0x00000000}, - {REG_ESAI_TX4, 0x00000000}, - {REG_ESAI_TX5, 0x00000000}, {REG_ESAI_TSR, 0x00000000}, {REG_ESAI_SAICR, 0x00000000}, {REG_ESAI_TCR, 0x00000000}, @@ -711,10 +704,17 @@ static bool fsl_esai_readable_reg(struct device *dev, unsigned int reg) static bool fsl_esai_volatile_reg(struct device *dev, unsigned int reg) { switch (reg) { + case REG_ESAI_ETDR: case REG_ESAI_ERDR: case REG_ESAI_ESR: case REG_ESAI_TFSR: case REG_ESAI_RFSR: + case REG_ESAI_TX0: + case REG_ESAI_TX1: + case REG_ESAI_TX2: + case REG_ESAI_TX3: + case REG_ESAI_TX4: + case REG_ESAI_TX5: case REG_ESAI_RX0: case REG_ESAI_RX1: case REG_ESAI_RX2: -- 2.17.1

2 2

Re: [alsa-devel] next/master boot bisection: next-20190528 on sun8i-h3-libretech-all-h3-cc
by Pierre-Louis Bossart 07 Jun '19

07 Jun '19

On 6/7/19 2:00 PM, Mark Brown wrote: > On Fri, Jun 07, 2019 at 05:31:12PM +0100, Guillaume Tucker wrote: >> On 30/05/2019 16:53, Takashi Iwai wrote: > >>>> + mutex_lock(&client_mutex); >>>> for_each_rtdcom(rtd, rtdcom) { >>>> component = rtdcom->component; >>>> >>>> if (component->driver->remove_order == order) >>>> soc_remove_component(component); >>>> } >>>> + mutex_unlock(&client_mutex); > >>> Ranjani, which code path your patch tries to address? Maybe better to >>> wrap client_mutex() in the caller side like snd_soc_unbind_card()? > >> Is anyone looking into this issue? > >> It is still occurring in next-20190606, there was a bisection >> today which landed on the same commit. There just hasn't been >> any new bisection reports because they have been temporarily >> disabled while we fix some issues on kernelci.org. > > I was expecting that Ranjani or one of the other Intel people was > looking into it... Ack. We've all been underwater this week and this wasn't addressed, sorry about the delay. It's probably wise to revert this commit at this point while we look for an alternate solution? There was an initial proposal submitted on GitHub [1] (patch attached) which implemented what Takashi suggested in his comments. This proposal was later optimized further, it could be that the optimization was one bridge too far. Could you let us know if this attached patch has any negative effects on non-Intel platforms? Thanks! [1] https://github.com/thesofproject/linux/commit/9fd09dd417bc8be7a4a8bdd162155…

1 0

[alsa-devel] next/master boot bisection: next-20190528 on sun8i-h3-libretech-all-h3-cc
by kernelci.org bot 07 Jun '19

07 Jun '19

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This automated bisection report was sent to you on the basis * * that you may be involved with the breaking commit it has * * found. No manual investigation has been done to verify it, * * and the root cause of the problem may be somewhere else. * * Hope this helps! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * next/master boot bisection: next-20190528 on sun8i-h3-libretech-all-h3-cc Summary: Start: 531b0a360899 Add linux-next specific files for 20190528 Details: https://kernelci.org/boot/id/5cece0fd59b5144bc47a362b Plain log: https://storage.kernelci.org//next/master/next-20190528/arm/sunxi_defconfig… HTML log: https://storage.kernelci.org//next/master/next-20190528/arm/sunxi_defconfig… Result: 34ac3c3eb8f0 ASoC: core: lock client_mutex while removing link components Checks: revert: PASS verify: PASS Parameters: Tree: next URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Branch: master Target: sun8i-h3-libretech-all-h3-cc CPU arch: arm Lab: lab-baylibre Compiler: gcc-8 Config: sunxi_defconfig Test suite: boot Breaking commit found: ------------------------------------------------------------------------------- commit 34ac3c3eb8f0c07252ceddf0a22dd240e5c91ccb Author: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Date: Thu May 23 10:12:01 2019 -0700 ASoC: core: lock client_mutex while removing link components Removing link components results in topology unloading. So, acquire the client_mutex before removing components in soc_remove_link_components. This will prevent the lockdep warning seen when dai links are removed during topology removal. Signed-off-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 2403bec2fccf..7c9415987ac7 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1005,12 +1005,14 @@ static void soc_remove_link_components(struct snd_soc_card *card, struct snd_soc_component *component; struct snd_soc_rtdcom_list *rtdcom; + mutex_lock(&client_mutex); for_each_rtdcom(rtd, rtdcom) { component = rtdcom->component; if (component->driver->remove_order == order) soc_remove_component(component); } + mutex_unlock(&client_mutex); } static void soc_remove_dai_links(struct snd_soc_card *card) ------------------------------------------------------------------------------- Git bisection log: ------------------------------------------------------------------------------- git bisect start # good: [cd6c84d8f0cdc911df435bb075ba22ce3c605b07] Linux 5.2-rc2 git bisect good cd6c84d8f0cdc911df435bb075ba22ce3c605b07 # bad: [531b0a360899269bd99a38ba9852a8ba46852bcd] Add linux-next specific files for 20190528 git bisect bad 531b0a360899269bd99a38ba9852a8ba46852bcd # bad: [0b61d4c3b7d7938ef0014778c328e3f65c0d6d57] Merge remote-tracking branch 'crypto/master' git bisect bad 0b61d4c3b7d7938ef0014778c328e3f65c0d6d57 # bad: [6179e21b065dc0f592cd3d9d3676bd64d4278025] Merge remote-tracking branch 'xtensa/xtensa-for-next' git bisect bad 6179e21b065dc0f592cd3d9d3676bd64d4278025 # bad: [3e085f66fe7e93575f2a583a3d434415cef2d860] Merge remote-tracking branch 'amlogic/for-next' git bisect bad 3e085f66fe7e93575f2a583a3d434415cef2d860 # bad: [b9afa223a3420432bc483d2b43429c88c6a5d0e0] Merge remote-tracking branch 'staging.current/staging-linus' git bisect bad b9afa223a3420432bc483d2b43429c88c6a5d0e0 # good: [fc6557648e19dbd207dc815c6e09fc6452f01e63] Merge remote-tracking branch 'bpf/master' git bisect good fc6557648e19dbd207dc815c6e09fc6452f01e63 # bad: [6c3f2a0e0f236f31b47d63ab7d3f4ec889821d0d] Merge remote-tracking branch 'spi-fixes/for-linus' git bisect bad 6c3f2a0e0f236f31b47d63ab7d3f4ec889821d0d # bad: [20a5f9c8649d74407aa657ce5b76cf8b0bbb17e3] Merge branch 'asoc-5.2' into asoc-linus git bisect bad 20a5f9c8649d74407aa657ce5b76cf8b0bbb17e3 # good: [ad6eecbfc01c987e0253371f274c3872042e4350] ASoC: cs42xx8: Add regcache mask dirty git bisect good ad6eecbfc01c987e0253371f274c3872042e4350 # good: [069d037aea98ffa64c26d4b1dc958fb8f39f5c2b] ASoC: simple-card: Fix configuration of DAI format git bisect good 069d037aea98ffa64c26d4b1dc958fb8f39f5c2b # good: [df9366131a452296d040a7a496d93108f1fc240c] ASoC: Intel: sof-rt5682: fix AMP quirk support git bisect good df9366131a452296d040a7a496d93108f1fc240c # bad: [34ac3c3eb8f0c07252ceddf0a22dd240e5c91ccb] ASoC: core: lock client_mutex while removing link components git bisect bad 34ac3c3eb8f0c07252ceddf0a22dd240e5c91ccb # good: [4819d06292c9b57eabdd6d1603e49a27baf183be] ASoC: simple-card: Restore original configuration of DAI format git bisect good 4819d06292c9b57eabdd6d1603e49a27baf183be # first bad commit: [34ac3c3eb8f0c07252ceddf0a22dd240e5c91ccb] ASoC: core: lock client_mutex while removing link components -------------------------------------------------------------------------------

3 2

[alsa-devel] [PATCH] ASoC: Remove erroneous soc_cleanup_card_resources() call
by Sylwester Nawrocki 07 Jun '19

07 Jun '19

When soc_init_dai_link() call at the beginning of snd_soc_instantiate_card function fails soc_cleanup_card_resources() and then snd_soc_dapm_free() gets called with an incompletely initialized card->dapm. In particular card->dapm.card is NULL and it gets dereferenced in dapm_free_widgets(). Also dapm->list is invalid and there is an invalid pointer dereference from list_del(). The function call stack (deferred probing) on Chromebook Snow where this issue has shown up in today's -next is: snd_soc_dapm_free soc_cleanup_card_resources snd_soc_instantiate_card snd_soc_register_card devm_snd_soc_register_card snow_probe In patch 70fc53734e71 "ASoC: core: move DAI pre-links initiation to snd_soc_instantiate_card" there is an soc_cleanup_platform() call instead of soc_cleanup_card_resources() as in current -next. soc_cleanup_platform got renamed to soc_cleanup_legacy, then removed in commit adb76b5b9c47 "ASoC: soc-core: remove legacy style dai_link". It seems in merge conflict resolution the soc_cleanup_platform() call got renamed to soc_cleanup_card_resources(), instead of being removed. Correct this by removing an unnecessary soc_cleanup_card_resources() call. Fixes: a8e992342ce4 ("Merge branch 'asoc-5.2' into asoc-5.3") Reported-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Suggested-by: Tzung-Bi Shih <tzungbi(a)google.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> --- sound/soc/soc-core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 94a36ee8eb22..f0fa289c90d8 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1986,7 +1986,6 @@ static int snd_soc_instantiate_card(struct snd_soc_card *card) for_each_card_prelinks(card, i, dai_link) { ret = soc_init_dai_link(card, dai_link); if (ret) { - soc_cleanup_card_resources(card); dev_err(card->dev, "ASoC: failed to init link %s: %d\n", dai_link->name, ret); mutex_unlock(&client_mutex); -- 2.17.1

2 1

[alsa-devel] [PATCH] ASoC: Fix freeing of incompletely initialized snd_soc_dapm_context
by Sylwester Nawrocki 07 Jun '19

07 Jun '19

When soc_init_dai_link() call at the beginning of snd_soc_instantiate_card function fails soc_cleanup_card_resources() and then snd_soc_dapm_free() gets called with an incompletely initialized card->dapm. In particular card->dapm.card is NULL and it gets dereferenced in dapm_free_widgets(). Also dapm->list is invalid and there is an invalid pointer dereference from list_del(). The function call stack (deferred probing) on Chromebook Snow where this issue has shown up in todays -next: snd_soc_dapm_free soc_cleanup_card_resources snd_soc_instantiate_card snd_soc_register_card devm_snd_soc_register_card snow_probe Fix this by testing dapm->card before attempting to free dapm widgets. Fixes: 70fc53734e71 ("ASoC: core: move DAI pre-links initiation to snd_soc_instantiate_card") Reported-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> --- sound/soc/soc-dapm.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 6b44b4a78b8e..5774cbd393fe 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -4658,8 +4658,11 @@ EXPORT_SYMBOL_GPL(snd_soc_dapm_ignore_suspend); void snd_soc_dapm_free(struct snd_soc_dapm_context *dapm) { dapm_debugfs_cleanup(dapm); - dapm_free_widgets(dapm); - list_del(&dapm->list); + + if (dapm->card) { + dapm_free_widgets(dapm); + list_del(&dapm->list); + } } EXPORT_SYMBOL_GPL(snd_soc_dapm_free); -- 2.17.1

2 2

[alsa-devel] ALSA: snd_ice1712: Check correct return value to snd_i2c_sendbytes (EWS/DMX 6Fire)
by Rui Nuno Capela 07 Jun '19

07 Jun '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Check for exact and correct return value to snd_i2c_sendbytes call for EWS/DMX 6Fire (snd_ice1712). Fixes a systemic error on every boot to snd_ice1712 driver ("cannot send pca") on Terratec EWS/DMX 6Fire PCI soundcards. Signed-off-by: Rui Nuno Capela <rncbc(a)rncbc.org> Cheers - -- rncbc aka. Rui Nuno Capela rncbc(a)rncbc.org -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEml2OG8nT8/KXriugSepTUDAa1MgFAlz6beYACgkQSepTUDAa 1MgAggf+LVoDgtUTSU6OsBipvlZ9Ro8ll4qBIPC8JtECk6iHur3C/xEHYqirVRQa HVBuNxN4RiaJI/upALZ/6n2XY3cjB04qgfCg+lQTQFAY7Or6G3L3vzyg8C/y7q2n uqkZTgbfNwQ01Xbq7Xa9QQ02eJKFCAmAOscBXwBQTpzzoThwFj0edUqvHleYuWOT b6qsVUSJJmJQlJe/10zyg+btmQEtLAWtLsIg0pkvJQJCmQgxeCvDspoH8THs/ov3 eCZNVUjnK1qkkl1Z7yFLjp7wx8RV28YZ5kMtDmkiDac66JfEO80qtJvxwbAY/hOm B/mII9niJLCEGV2cdNwPGpr2n4EdLg== =g9Fk -----END PGP SIGNATURE-----

1 0