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

[alsa-devel] [PATCH] ASoC: Fail card instantiation if DAI format setup fails
by Ricard Wanderlof 24 Jul '19

24 Jul '19

If the DAI format setup fails, there is no valid communication format between CPU and CODEC, so fail card instantiation, rather than continue with a card that will most likely not function properly. Signed-off-by: Ricard Wanderlof <ricardw(a)axis.com> --- I've had the problem of a sound card coming up even though an incorrect DAI format was selected in the devicetree, apparently caused by not checking the return value of snd_soc_runtime_set_dai_fmt() when the card is instantiated, with the result in this particular case that that the audio data was not transferred correctly (capture data was shifted one bit up). I'm unsure though if this is intentional, I can't think why it should be, since the DAI format is only set up at this time and not for instance later when a stream is enabled, but perhaps I'm missing something here. At any rate, with this patch, the card does not come up under these circumstances. The error message from snd_soc_runtime_set_dai_fmt() is still printed to the kernel log so it's possible to see what the reason is. /Ricard sound/soc/soc-core.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 7ecfe641ca46..06697b2d96b1 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1511,8 +1511,11 @@ static int soc_probe_link_dais(struct snd_soc_card *card, } } - if (dai_link->dai_fmt) - snd_soc_runtime_set_dai_fmt(rtd, dai_link->dai_fmt); + if (dai_link->dai_fmt) { + ret = snd_soc_runtime_set_dai_fmt(rtd, dai_link->dai_fmt); + if (ret) + return ret; + } ret = soc_post_component_init(rtd, dai_link->name); if (ret) -- 2.11.0 -- Ricard Wolf Wanderlof ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 1

[alsa-devel] [PATCH] ASoC: wm8955: Fix a typo in 'wm8995_pll_factors()' function name
by Christophe JAILLET 24 Jul '19

24 Jul '19

This should be 'wm8955_pll_factors()' instead. Fix it and use it. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- sound/soc/codecs/wm8955.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm8955.c b/sound/soc/codecs/wm8955.c index cd204f79647d..ec82a8fafdf6 100644 --- a/sound/soc/codecs/wm8955.c +++ b/sound/soc/codecs/wm8955.c @@ -143,7 +143,7 @@ struct pll_factors { * to allow rounding later */ #define FIXED_FLL_SIZE ((1 << 22) * 10) -static int wm8995_pll_factors(struct device *dev, +static int wm8955_pll_factors(struct device *dev, int Fref, int Fout, struct pll_factors *pll) { u64 Kpart; @@ -282,7 +282,7 @@ static int wm8955_configure_clocking(struct snd_soc_component *component) /* Use the last divider configuration we saw for the * sample rate. */ - ret = wm8995_pll_factors(component->dev, wm8955->mclk_rate, + ret = wm8955_pll_factors(component->dev, wm8955->mclk_rate, clock_cfgs[sr].mclk, &pll); if (ret != 0) { dev_err(component->dev, -- 2.20.1

3 2

[alsa-devel] [PATCH] ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips
by Takashi Iwai 24 Jul '19

24 Jul '19

It turned out that the recent Intel HD-audio controller chips show a significant stall during the system PM resume intermittently. It doesn't happen so often and usually it may read back successfully after one or more seconds, but in some rare worst cases the driver went into fallback mode. After trial-and-error, we found out that the communication stall seems covered by issuing the sync after each verb write, as already done for AMD and other chipsets. So this patch enables the write-sync flag for the recent Intel chips, Skylake and onward, as a workaround. Also, since Broxton and co have the very same driver flags as Skylake, refer to the Skylake driver flags instead of defining the same contents again for simplification. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201901 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index cb8b0945547c..1e14d7270adf 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -313,11 +313,10 @@ enum { #define AZX_DCAPS_INTEL_SKYLAKE \ (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_PM_RUNTIME |\ + AZX_DCAPS_SYNC_WRITE |\ AZX_DCAPS_SEPARATE_STREAM_TAG | AZX_DCAPS_I915_COMPONENT) -#define AZX_DCAPS_INTEL_BROXTON \ - (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_PM_RUNTIME |\ - AZX_DCAPS_SEPARATE_STREAM_TAG | AZX_DCAPS_I915_COMPONENT) +#define AZX_DCAPS_INTEL_BROXTON AZX_DCAPS_INTEL_SKYLAKE /* quirks for ATI SB / AMD Hudson */ #define AZX_DCAPS_PRESET_ATI_SB \ -- 2.16.4

1 0

[alsa-devel] Reminder: 1 open syzbot bug in sound subsystem
by Eric Biggers 24 Jul '19

24 Jul '19

[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the sound subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the sound subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: -------------------------------------------------------------------------------- Title: KASAN: use-after-free Read in wake_up_if_idle Last occurred: 131 days ago Reported: 267 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=b1e300cd7b124fc83dd4199d4d1df26310111b… Original thread: https://lkml.kernel.org/lkml/00000000000066ab7105795f245e@google.com/T/#u Unfortunately, this bug does not have a reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+2c1253bc508adef78a7f(a)syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/00000000000066ab7105795f245e@google.com

2 2

[alsa-devel] [PATCH 0/2 v2] Open Alsa dshare without channel binding
by Adam Miartus 24 Jul '19

24 Jul '19

The general idea of this patch is to be able to open the device without defined bindings. As a result, it allows starting the audio clock of underlying device without blocking a channel. This might be useful for creating a dummy dsnoop pcm for hardware that requires running clock early at system start. This clock is then present even without application streaming audio data. Patch n.1 is intended to check for null pointer of pcm callbacks, it is not intended to alter any current functionality, properly defined plugins should not suffer from this change Patch n.2 is not intended to alter any current functionality, only extend it V2 of the patch, changes from V1: - instead of creating new "pcm_unsupported.c" with ops and fast_ops callbacks returning -ENOSYS, callback == NULL is checked directly in core implementation and error is returned when pcm has no callback defined Adam Miartus (2): alsa: pcm: return -ENOSYS when ops or fast_ops callback is NULL alsa: dshare: allow missing bindings src/pcm/pcm.c | 134 +++++++++++++++++++++++++++++++++++++++++---------- src/pcm/pcm_dshare.c | 29 ++++++----- src/pcm/pcm_local.h | 20 ++++++++ src/pcm/pcm_mmap.c | 15 ++++-- src/pcm/pcm_params.c | 10 +++- 5 files changed, 166 insertions(+), 42 deletions(-) -- 2.7.4

2 3

[alsa-devel] [PATCH] ASoC: Intel: Skylake: Use dev_get_drvdata where possible
by Chuhong Yuan 24 Jul '19

24 Jul '19

Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96(a)gmail.com> --- sound/soc/intel/skylake/skl-nhlt.c | 3 +-- sound/soc/intel/skylake/skl.c | 12 ++++-------- 2 files changed, 5 insertions(+), 10 deletions(-) diff --git a/sound/soc/intel/skylake/skl-nhlt.c b/sound/soc/intel/skylake/skl-nhlt.c index 1132109cb992..46d9977224d1 100644 --- a/sound/soc/intel/skylake/skl-nhlt.c +++ b/sound/soc/intel/skylake/skl-nhlt.c @@ -241,8 +241,7 @@ int skl_nhlt_update_topology_bin(struct skl *skl) static ssize_t skl_nhlt_platform_id_show(struct device *dev, struct device_attribute *attr, char *buf) { - struct pci_dev *pci = to_pci_dev(dev); - struct hdac_bus *bus = pci_get_drvdata(pci); + struct hdac_bus *bus = dev_get_drvdata(dev); struct skl *skl = bus_to_skl(bus); struct nhlt_acpi_table *nhlt = (struct nhlt_acpi_table *)skl->nhlt; char platform_id[32]; diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c index 3362e71b4563..1f625fc65307 100644 --- a/sound/soc/intel/skylake/skl.c +++ b/sound/soc/intel/skylake/skl.c @@ -141,8 +141,7 @@ static int skl_init_chip(struct hdac_bus *bus, bool full_reset) void skl_update_d0i3c(struct device *dev, bool enable) { - struct pci_dev *pci = to_pci_dev(dev); - struct hdac_bus *bus = pci_get_drvdata(pci); + struct hdac_bus *bus = dev_get_drvdata(dev); u8 reg; int timeout = 50; @@ -274,8 +273,7 @@ static int skl_acquire_irq(struct hdac_bus *bus, int do_disconnect) static int skl_suspend_late(struct device *dev) { - struct pci_dev *pci = to_pci_dev(dev); - struct hdac_bus *bus = pci_get_drvdata(pci); + struct hdac_bus *bus = dev_get_drvdata(dev); struct skl *skl = bus_to_skl(bus); return skl_suspend_late_dsp(skl); @@ -400,8 +398,7 @@ static int skl_resume(struct device *dev) #ifdef CONFIG_PM static int skl_runtime_suspend(struct device *dev) { - struct pci_dev *pci = to_pci_dev(dev); - struct hdac_bus *bus = pci_get_drvdata(pci); + struct hdac_bus *bus = dev_get_drvdata(dev); dev_dbg(bus->dev, "in %s\n", __func__); @@ -410,8 +407,7 @@ static int skl_runtime_suspend(struct device *dev) static int skl_runtime_resume(struct device *dev) { - struct pci_dev *pci = to_pci_dev(dev); - struct hdac_bus *bus = pci_get_drvdata(pci); + struct hdac_bus *bus = dev_get_drvdata(dev); dev_dbg(bus->dev, "in %s\n", __func__); -- 2.20.1

1 0

[alsa-devel] [PATCH] sound: line6: sizeof (byte) is always 1, use that fact.
by Pavel Machek 24 Jul '19

24 Jul '19

sizeof (byte) is always 1, use that fact and make interesting code explicit. Signed-off-by: Pavel Machek <pavel(a)denx.de> diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c index ab2ec89..387c5c2 100644 --- a/sound/usb/line6/driver.c +++ b/sound/usb/line6/driver.c @@ -342,7 +342,7 @@ int line6_read_data(struct usb_line6 *line6, unsigned address, void *data, if (address > 0xffff || datalen > 0xff) return -EINVAL; - len = kmalloc(sizeof(*len), GFP_KERNEL); + len = kmalloc(1, GFP_KERNEL); if (!len) return -ENOMEM; @@ -418,7 +421,7 @@ int line6_write_data(struct usb_line6 *line6, unsigned address, void *data, if (address > 0xffff || datalen > 0xffff) return -EINVAL; - status = kmalloc(sizeof(*status), GFP_KERNEL); + status = kmalloc(1, GFP_KERNEL); if (!status) return -ENOMEM; -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2 1

[alsa-devel] [PATCH] ALSA: core: Fix possible null-pointer dereferences in snd_timer_proc_read()
by Jia-Ju Bai 24 Jul '19

24 Jul '19

In snd_timer_proc_read(), there is an if statement on line 1204 to check whether timer->card is NULL: if (timer->card && timer->card->shutdown) When timer->card is NULL, it is used on lines 1212 and 1215: timer->card->number Thus, possible null-pointer dereferences may occur. To fix these bugs, timer->card is checked before being used. These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)gmail.com> --- sound/core/timer.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/sound/core/timer.c b/sound/core/timer.c index 5c9fbf3f4340..967d06a3cdec 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -1208,11 +1208,13 @@ static void snd_timer_proc_read(struct snd_info_entry *entry, snd_iprintf(buffer, "G%i: ", timer->tmr_device); break; case SNDRV_TIMER_CLASS_CARD: - snd_iprintf(buffer, "C%i-%i: ", - timer->card->number, timer->tmr_device); + snd_iprintf(buffer, "C%i-%i: ", + timer->card ? timer->card->number : -1, + timer->tmr_device); break; case SNDRV_TIMER_CLASS_PCM: - snd_iprintf(buffer, "P%i-%i-%i: ", timer->card->number, + snd_iprintf(buffer, "P%i-%i-%i: ", + timer->card ? timer->card->number : -1, timer->tmr_device, timer->tmr_subdevice); break; default: -- 2.17.0

2 1

[alsa-devel] [PATCH 00/16] ASoC: add soc-dai.c
by Kuninori Morimoto 23 Jul '19

23 Jul '19

Hi Mark I want to cleanup ALSA SoC. It will do nothing from "technical" point of view, but, will makes code readable. I already have many cleanup patches in my local branch. This is first patch-set for it. Kuninori Morimoto (16): ASoC: add soc-dai.c ASoC: soc-dai: mv soc_dai_hw_params() to soc-dai ASoC: soc-dai: add snd_soc_dai_hw_free() ASoC: soc-dai: add snd_soc_dai_startup() ASoC: soc-dai: add snd_soc_dai_shutdown() ASoC: soc-dai: add snd_soc_dai_prepare() ASoC: soc-dai: add snd_soc_dai_trigger() ASoC: soc-dai: add snd_soc_dai_bespoke_trigger() ASoC: soc-dai: add snd_soc_dai_delay() ASoC: soc-dai: add snd_soc_dai_suspend() ASoC: soc-dai: add snd_soc_dai_resume() ASoC: soc-dai: add snd_soc_dai_probe() ASoC: soc-dai: add snd_soc_dai_remove() ASoC: soc-dai: add snd_soc_dai_compress_new() ASoC: soc-dai: move snd_soc_dai_stream_valid() to soc-dai.c ASoC: soc-core: use existing snd_soc_dai_digital_mute() include/sound/soc-dai.h | 25 +++ include/sound/soc.h | 4 - sound/soc/Makefile | 2 +- sound/soc/soc-compress.c | 9 +- sound/soc/soc-core.c | 316 ++++-------------------------------- sound/soc/soc-dai.c | 407 +++++++++++++++++++++++++++++++++++++++++++++++ sound/soc/soc-dapm.c | 46 ++---- sound/soc/soc-pcm.c | 200 +++++++---------------- 8 files changed, 548 insertions(+), 461 deletions(-) create mode 100644 sound/soc/soc-dai.c -- 2.7.4

2 33

[alsa-devel] [PATCH 0/5] ASoC: Intel: IPC framework updates
by Cezary Rojewski 23 Jul '19

23 Jul '19

Existing IPC framework omits crucial part of the entire communication: reply header. Some IPCs cannot function at all without the access to said header. Update the sst-ipc with new sst_ipc_message structure to represent both request and reply allowing reply-processing handlers to save received responses. Despite the range of changes required for model to be updated, no functional changes are made for core hanswell, baytrail and skylake message handlers. Reply-processing handlers now save received response header yet no usage is added by default. To allow for future changes, righful kings of IPC kingdom need to be put back on the throne. This update addresses one of them: LARGE_CONFIG_GET. Cezary Rojewski (5): ASoC: Intel: Update request-reply IPC model ASoC: Intel: Haswell: Align with updated request-reply model ASoC: Intel: Baytrail: Align with updated request-reply model ASoC: Intel: Skylake: Align with updated request-reply model ASoC: Intel: Skylake: large_config_get overhaul sound/soc/intel/baytrail/sst-baytrail-ipc.c | 65 ++++---- sound/soc/intel/common/sst-ipc.c | 68 ++++---- sound/soc/intel/common/sst-ipc.h | 27 ++-- sound/soc/intel/haswell/sst-haswell-ipc.c | 164 +++++++++++--------- sound/soc/intel/skylake/cnl-sst.c | 6 +- sound/soc/intel/skylake/skl-messages.c | 3 +- sound/soc/intel/skylake/skl-sst-ipc.c | 152 ++++++++++-------- sound/soc/intel/skylake/skl-sst-ipc.h | 3 +- 8 files changed, 259 insertions(+), 229 deletions(-) -- 2.17.1

3 12