August 2020 - Alsa-devel - mailman.alsa-project.org

[PATCH AUTOSEL 5.8 01/62] ALSA: hda/hdmi: Add quirk to force connectivity
by Sasha Levin 21 Aug '20

21 Aug '20

From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> [ Upstream commit cd72c317a0a11f64225b9a3f1fe503bb8c7327b5 ] HDMI on some platforms doesn't enable audio support because its Port Connectivity [31:30] is set to AC_JACK_PORT_NONE: Node 0x05 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x58560010: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 3 0x02 0x03* 0x04 For now, use a quirk to force connectivity based on SSID. If there are more platforms affected by the same issue, we can eye for a more generic solution. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Link: https://lore.kernel.org/r/20200804155836.16252-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_hdmi.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index cd46247988e4d..b62cd3abb8273 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -160,6 +160,7 @@ struct hdmi_spec { bool use_acomp_notifier; /* use eld_notify callback for hotplug */ bool acomp_registered; /* audio component registered in this driver */ + bool force_connect; /* force connectivity */ struct drm_audio_component_audio_ops drm_audio_ops; int (*port2pin)(struct hda_codec *, int); /* reverse port/pin mapping */ @@ -1701,7 +1702,8 @@ static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid) * all device entries on the same pin */ config = snd_hda_codec_get_pincfg(codec, pin_nid); - if (get_defcfg_connect(config) == AC_JACK_PORT_NONE) + if (get_defcfg_connect(config) == AC_JACK_PORT_NONE && + !spec->force_connect) return 0; /* @@ -1803,11 +1805,18 @@ static int hdmi_add_cvt(struct hda_codec *codec, hda_nid_t cvt_nid) return 0; } +static const struct snd_pci_quirk force_connect_list[] = { + SND_PCI_QUIRK(0x103c, 0x871a, "HP", 1), + {} +}; + static int hdmi_parse_codec(struct hda_codec *codec) { + struct hdmi_spec *spec = codec->spec; hda_nid_t start_nid; unsigned int caps; int i, nodes; + const struct snd_pci_quirk *q; nodes = snd_hda_get_sub_nodes(codec, codec->core.afg, &start_nid); if (!start_nid || nodes < 0) { @@ -1815,6 +1824,11 @@ static int hdmi_parse_codec(struct hda_codec *codec) return -EINVAL; } + q = snd_pci_quirk_lookup(codec->bus->pci, force_connect_list); + + if (q && q->value) + spec->force_connect = true; + /* * hdmi_add_pin() assumes total amount of converters to * be known, so first discover all converters -- 2.25.1

1 8

[PATCH] soundwire: intel: fix CONFIG_PM and CONFIG_PM_SLEEP confusion
by Bard Liao 21 Aug '20

21 Aug '20

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> When CONFIG_PM_SLEEP is not defined, GCC throws compilation warnings: drivers/soundwire/intel.c:1816:12: warning: ‘intel_resume’ defined but not used [-Wunused-function] 1816 | static int intel_resume(struct device *dev) | ^~~~~~~~~~~~ drivers/soundwire/intel.c:1697:12: warning: ‘intel_suspend’ defined but not used [-Wunused-function] 1697 | static int intel_suspend(struct device *dev) Fix by adding the missing CONFIG_PM_SLEEP. Note that we could move code around and use only 2 ifdefs, but this will generate conflicts so let's do this when all the pm handling is merged. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- drivers/soundwire/intel.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index dbcbe2708563..a2f0026cb2c1 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -1525,7 +1525,7 @@ int intel_master_process_wakeen_event(struct platform_device *pdev) * PM calls */ -#ifdef CONFIG_PM +#ifdef CONFIG_PM_SLEEP static int intel_suspend(struct device *dev) { @@ -1562,6 +1562,9 @@ static int intel_suspend(struct device *dev) return 0; } +#endif + +#ifdef CONFIG_PM static int intel_suspend_runtime(struct device *dev) { @@ -1624,6 +1627,9 @@ static int intel_suspend_runtime(struct device *dev) return ret; } +#endif + +#ifdef CONFIG_PM_SLEEP static int intel_resume(struct device *dev) { @@ -1691,6 +1697,9 @@ static int intel_resume(struct device *dev) return ret; } +#endif + +#ifdef CONFIG_PM static int intel_resume_runtime(struct device *dev) { @@ -1797,7 +1806,6 @@ static int intel_resume_runtime(struct device *dev) return ret; } - #endif static const struct dev_pm_ops intel_pm = { -- 2.17.1

3 2

[alsa-devel] Attempting to understand odd snd-usb-audio code and behavior
by Keith A. Milner 21 Aug '20

21 Aug '20

Over the last few weeks I've been trying to dig through the snd-usb-audio code to try to get an understanding of it. I've used ftrace and also a local version which I have heavily polluted with kprintf(KERN_INFO statements so I can track what it's doing in practice. I've been playing with this with some USB audio interfaces I have some which work, and some which don't, and trying to understand the differences and, ultimately, what I can do to make the non-functioning ones work. I've got to the point where I have a fairly good understanding of some parts, but I'm struggling to understand why the code is behaving as it does in practice. My observation when plugging the USB device in is that, as expected, it tries to build the audio device, and add components to it including attaching capture and playback streams. It seems to go through this phase without too many surprises, and we get to the standard dmesg output: usbcore: registered new interface driver snd-usb-audio After this, it gets confusing. It seems to open and close the PCMs (e.g, snd_usb_capture_open) several times in a row. Each time it sets up the hardware info, checks and sets the format and then closes the PCM. I don't see anything obviously different between most of these cycles. Here's an example my logging output (hopefully this will make sense): Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Called: pcm.c - snd_usb_capture_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Called: pcm.c - snd_usb_pcm_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Setting up hw info Aug 22 20:04:16 kerneldev kernel: [ 923.140789] Checking format: Aug 22 20:04:16 kerneldev kernel: [ 923.140790] Interface number = 2 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] alt setting = 1 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] alt setting index = 1 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] format type = 1 Aug 22 20:04:16 kerneldev kernel: [ 923.140790] frame size = 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140791] Setting pt=125 ptmin=125 Aug 22 20:04:16 kerneldev kernel: [ 923.140792] Checking for unusual bit rates Aug 22 20:04:16 kerneldev kernel: [ 923.140794] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.140921] Called: pcm.c - snd_usb_hw_params for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.140945] Setting format: Aug 22 20:04:16 kerneldev kernel: [ 923.140945] Bytes per period = 8816 Aug 22 20:04:16 kerneldev kernel: [ 923.140945] Frames per period = 1102 Aug 22 20:04:16 kerneldev kernel: [ 923.140946] Periods per buffer = 4 Aug 22 20:04:16 kerneldev kernel: [ 923.140946] Channels = 2 Aug 22 20:04:16 kerneldev kernel: [ 923.140946] Rate = 44100 Aug 22 20:04:16 kerneldev kernel: [ 923.141279] Called: endpoint.c - snd_usb_add_endpoint of type 0 with direction 1 Aug 22 20:04:16 kerneldev kernel: [ 923.141292] Called: pcm.c - snd_usb_pcm_prepare for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.141293] Called: pcm.c - configure_endpoint Aug 22 20:04:16 kerneldev kernel: [ 923.141294] Called: endpoint.c - snd_usb_endpoint_set_params for endpoint 142, type 0 Aug 22 20:04:16 kerneldev kernel: [ 923.141294] Setting endpoint params for endpoint num 142 Aug 22 20:04:16 kerneldev kernel: [ 923.141294] channels=2 Aug 22 20:04:16 kerneldev kernel: [ 923.141294] period bytes=8816 Aug 22 20:04:16 kerneldev kernel: [ 923.141295] frames per period=1102 Aug 22 20:04:16 kerneldev kernel: [ 923.141295] periods per buffer=4 Aug 22 20:04:16 kerneldev kernel: [ 923.141296] Called: endpoint.c - data_ep_set_params for endpoint 142, type 0 Aug 22 20:04:16 kerneldev kernel: [ 923.141301] Called: pcm.c - snd_usb_pcm_prepare for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.142768] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.142772] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.142774] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.142830] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.142836] Called: pcm.c - snd_usb_hw_free for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.142837] Called: endpoint.c - snd_usb_endpoint_deactivate for endpoint 142, type 0 Aug 22 20:04:16 kerneldev kernel: [ 923.142846] Called: pcm.c - snd_usb_capture_close for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.146760] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.146834] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.146838] Called: init.c - snd_card_file_remove Aug 22 20:04:16 kerneldev kernel: [ 923.146841] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.146845] Called: init.c - snd_card_file_add Aug 22 20:04:16 kerneldev kernel: [ 923.146848] Called: pcm.c - snd_usb_capture_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.146849] Called: pcm.c - snd_usb_pcm_open for pcm substream 0 Aug 22 20:04:16 kerneldev kernel: [ 923.146849] Setting up hw info It seems to do this several times, before the behavior changing slightly, as it now starts to try to set the endpoint parameters and seems to leave the stream open. However, it then tries to open the stream and set the endpoint parameters again resulting in errors: Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] Called: endpoint.c - snd_usb_endpoint_set_params for endpoint 142, type 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] Setting endpoint params for endpoint num 142 Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] channels=2 Aug 22 20:22:00 kerneldev kernel: [ 1987.452945] period bytes=1768 Aug 22 20:22:00 kerneldev kernel: [ 1987.452946] frames per period=221 Aug 22 20:22:00 kerneldev kernel: [ 1987.452946] periods per buffer=593 Aug 22 20:22:00 kerneldev kernel: [ 1987.452947] usb 1-1: Unable to change format on ep #8e: already in use Maybe this is driven by hotplug or something, but it seems to be performing a lot of pointless activities. Eventually it seems to try to open the PCM playback or capture stream (with some devices it opens playback, with others capture) and then checks the pointer: Aug 22 20:22:00 kerneldev kernel: [ 1987.470194] Called: pcm.c - snd_usb_substream_playback_trigger for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470198] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470198] Pointer is 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470656] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470657] Pointer is 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470660] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:00 kerneldev kernel: [ 1987.470660] Pointer is 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473567] Called: pcm.c - snd_usb_pcm_pointer for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473569] Pointer is 0 The above is from a non-working device. For a working device the pointer increments. Eventually this activity ends: Aug 22 20:22:05 kerneldev kernel: [ 1992.473575] Called: pcm.c - snd_usb_substream_playback_trigger for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473576] Called: endpoint.c - snd_usb_endpoint_stop for endpoint 142, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473578] Called: endpoint.c - snd_usb_endpoint_stop for endpoint 13, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.473602] Called: pcm.c - snd_usb_hw_free for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503287] Called: endpoint.c - snd_usb_endpoint_deactivate for endpoint 142, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503288] Called: endpoint.c - snd_usb_endpoint_deactivate for endpoint 13, type 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503323] Called: pcm.c - snd_usb_playback_close for pcm substream 0 Aug 22 20:22:05 kerneldev kernel: [ 1992.503656] Called: init.c - snd_card_file_remove This seems as if it might be some sort of test of the PCMs, to make sure they are working. Certainly in non-working devices the pcm_pointer stays at zero and in working devices it increments. It also seems to try harder with some devices than others, even though the device descriptors seem very similar. Can anyone explain any of this to me, particularly why it's exhibiting this behaviour. I've uploaded one of the logs from a non-working device to Pastebin if anyone wants to look at a full example: https://pastebin.com/uBZEuQ57 Also, is this the best way to approach this, or are there other tools/techniques that can help? I've experimented with ftrace and that was useful, but didn't give the level of detail I wanted. Cheers, Keith

3 10

[PATCH 0/2] soundwire: fix port_ready[] dynamic allocation in
by Bard Liao 21 Aug '20

21 Aug '20

The existing code allocates memory for the total number of ports. This only works if the ports are contiguous, but will break if e.g. a Devices uses port0, 1, and 14. The port_ready[] array would contain 3 elements, which would lead to an out-of-bounds access. Conversely in other cases, the wrong port index would be used leading to timeouts on prepare. This can be fixed by allocating for the worst-case of 15 ports (DP0..DP14). In addition since the number is now fixed, we can use an array instead of a dynamic allocation. Pierre-Louis Bossart (2): soundwire: add definition for maximum number of ports soundwire: fix port_ready[] dynamic allocation in mipi_disco and ASoC codecs drivers/soundwire/mipi_disco.c | 18 +----------------- drivers/soundwire/slave.c | 4 ++++ include/linux/soundwire/sdw.h | 5 +++-- sound/soc/codecs/max98373-sdw.c | 15 +-------------- sound/soc/codecs/rt1308-sdw.c | 14 +------------- sound/soc/codecs/rt5682-sdw.c | 15 +-------------- sound/soc/codecs/rt700-sdw.c | 15 +-------------- sound/soc/codecs/rt711-sdw.c | 15 +-------------- sound/soc/codecs/rt715-sdw.c | 33 +-------------------------------- 9 files changed, 14 insertions(+), 120 deletions(-) -- 2.17.1

4 9

[PATCH v2] soundwire: SDCA: add helper macro to access controls
by Bard Liao 21 Aug '20

21 Aug '20

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> The upcoming SDCA (SoundWire Device Class Audio) specification defines a hiearchical encoding to interface with Class-defined capabilities, based on which audio function, entity, control and channel being used. The specification is not yet accessible to the general public but this information is released with explicit permission from the MIPI Board to avoid delays with SDCA support on Linux platforms. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- Changelog: v2: - add SDW_SDCA_MBQ_CTL --- include/linux/soundwire/sdw_registers.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/include/linux/soundwire/sdw_registers.h b/include/linux/soundwire/sdw_registers.h index 5d3c271af7d1..4517c0f65b4f 100644 --- a/include/linux/soundwire/sdw_registers.h +++ b/include/linux/soundwire/sdw_registers.h @@ -305,4 +305,16 @@ #define SDW_CASC_PORT_MASK_INTSTAT3 1 #define SDW_CASC_PORT_REG_OFFSET_INTSTAT3 2 +/* v1.2 device - SDCA address mapping */ +#define SDW_SDCA_CTL(fun, ent, ctl, ch) (BIT(30) | \ + (((fun) & 0x7) << 22) | \ + (((ent) & 0x40) << 15) | \ + (((ent) & 0x3f) << 7) | \ + (((ctl) & 0x30) << 15) | \ + (((ctl) & 0x0f) << 3) | \ + (((ch) & 0x38) << 12) | \ + ((ch) & 0x07)) + +#define SDW_SDCA_MBQ_CTL(reg) ((reg) | BIT(13)) + #endif /* __SDW_REGISTERS_H */ -- 2.17.1

3 3

[RESEND] ASoC: SOF: Intel: add build support for SoundWire
by Bard Liao 20 Aug '20

20 Aug '20

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Select SoundWire capabilities on newer Intel platforms, starting with CannonLake/CoffeeLake/CometLake. As done for HDaudio, the SoundWire link is an opt-in capability. We explicitly test for ACPI to avoid warnings on unmet dependencies on the SoundWire side. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- sound/soc/sof/intel/Kconfig | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig index 3aaf25e4f766..f644010cc568 100644 --- a/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/Kconfig @@ -166,6 +166,7 @@ config SND_SOC_SOF_CANNONLAKE_SUPPORT config SND_SOC_SOF_CANNONLAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -181,6 +182,7 @@ config SND_SOC_SOF_COFFEELAKE_SUPPORT config SND_SOC_SOF_COFFEELAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -196,6 +198,7 @@ config SND_SOC_SOF_ICELAKE_SUPPORT config SND_SOC_SOF_ICELAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -203,6 +206,7 @@ config SND_SOC_SOF_ICELAKE config SND_SOC_SOF_COMETLAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -229,6 +233,7 @@ config SND_SOC_SOF_TIGERLAKE_SUPPORT config SND_SOC_SOF_TIGERLAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -244,6 +249,7 @@ config SND_SOC_SOF_ELKHARTLAKE_SUPPORT config SND_SOC_SOF_ELKHARTLAKE tristate select SND_SOC_SOF_HDA_COMMON + select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE help This option is not user-selectable but automagically handled by 'select' statements at a higher level @@ -329,6 +335,29 @@ config SND_SOC_SOF_HDA This option is not user-selectable but automagically handled by 'select' statements at a higher level +config SND_SOC_SOF_INTEL_SOUNDWIRE_LINK + bool "SOF support for SoundWire" + depends on SOUNDWIRE && ACPI + help + This adds support for SoundWire with Sound Open Firmware + for Intel(R) platforms. + Say Y if you want to enable SoundWire links with SOF. + If unsure select "N". + +config SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE + tristate + select SND_SOC_SOF_INTEL_SOUNDWIRE if SND_SOC_SOF_INTEL_SOUNDWIRE_LINK + help + This option is not user-selectable but automagically handled by + 'select' statements at a higher level + +config SND_SOC_SOF_INTEL_SOUNDWIRE + tristate + select SOUNDWIRE_INTEL + help + This option is not user-selectable but automagically handled by + 'select' statements at a higher level + endif ## SND_SOC_SOF_INTEL_PCI endif ## SND_SOC_SOF_INTEL_TOPLEVEL -- 2.17.1

4 3

[RESEND] ASoC: SOF: Intel: hda: import SOUNDWIRE_INIT namespace
by Bard Liao 20 Aug '20

20 Aug '20

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Make sure the SoundWire driver can be loaded Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- sound/soc/sof/intel/hda.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 63ca920c8e6e..c0b75d682750 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -1207,3 +1207,4 @@ MODULE_LICENSE("Dual BSD/GPL"); MODULE_IMPORT_NS(SND_SOC_SOF_HDA_AUDIO_CODEC); MODULE_IMPORT_NS(SND_SOC_SOF_HDA_AUDIO_CODEC_I915); MODULE_IMPORT_NS(SND_SOC_SOF_XTENSA); +MODULE_IMPORT_NS(SOUNDWIRE_INTEL_INIT); -- 2.17.1

2 1

[PATCH][next] ASoC: qcom: add missing out of memory check on drvdata->clks allocation
by Colin King 20 Aug '20

20 Aug '20

From: Colin Ian King <colin.king(a)canonical.com> Currently drvdata->clks is not being checked for an allocation failure, leading to potential null pointer dereferencing. Fix this by adding a check and returning -ENOMEM if an error occurred. Addresses-Coverity: ("Dereference null return value") Fixes: 1220f6a76e77 ("ASoC: qcom: Add common array to initialize soc based core clocks") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/qcom/lpass-apq8016.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c index dd9e3dd014f6..5c8ae225cd5d 100644 --- a/sound/soc/qcom/lpass-apq8016.c +++ b/sound/soc/qcom/lpass-apq8016.c @@ -168,6 +168,8 @@ static int apq8016_lpass_init(struct platform_device *pdev) drvdata->clks = devm_kcalloc(dev, variant->num_clks, sizeof(*drvdata->clks), GFP_KERNEL); + if (!drvdata->clks) + return -ENOMEM; drvdata->num_clks = variant->num_clks; for (i = 0; i < drvdata->num_clks; i++) -- 2.27.0

3 2

Re: [PATCH v2 00/41] spi / fbdev / cpufreq / usb / mmc / hwmon / ARM: Prepare for multiplatform S3C
by Krzysztof Kozlowski 20 Aug '20

20 Aug '20

On Thu, Aug 06, 2020 at 08:19:32PM +0200, Krzysztof Kozlowski wrote: > Hi All, > > Shortly > ======= > This is a continuation of Arnd's work from 2019 [1]. The goal is to > cleanup, merge and finally make the Samsung S3C24xx and S3C64xx > architectures multiplatform. The multiplatform did not happen yet > here... just cleaning up and merging into one mach-s3c. > > I intend to take it through Samsung SoC tree so all Acks are welcomed. > > Changes since v1 > ================ > 1. Rebased, > 2. Addressed comments (including mine), > 3. Few new patches. > > Please see individual changelogs (per patch). > > [1] https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=185855&… > Hi All, I applied second part of the set which finishes this step of S3C cleanup. Thanks to Arnd for the work! Best regards, Krzysztof

1 0

JamVOX usb soundcard works only after windows reboot
by Krabador 20 Aug '20

20 Aug '20

Hi alsa-devel team. This device from linux from 5.2 (my first plug) to now with 5.8.1, the only way to use it properly is to run linux after windows reboot. If linux is run at poweron, the device is correctly seen by the kernel but muted. Here the results of alsa-info.sh when card is working , not working, a diff, dmesg and lsusb -v https://paste.ee/p/YrJSP#pRmvQ58T7sCeulHr1ZSluw2cTQt7exsh Waiting to give more information, Best Regards.

1 1