- Feb 06, 2020
-
-
Mohan Kumar authored
RIRB interrupt status getting cleared after the write pointer is read causes a race condition, where last response(s) into RIRB may remain unserviced by IRQ, eventually causing azx_rirb_get_response to fall back to polling mode. Clearing the RIRB interrupt status ahead of write pointer access ensures that this condition is avoided. Signed-off-by:
Mohan Kumar <mkumard@nvidia.com> Signed-off-by:
Viswanath L <viswanathl@nvidia.com> Link: https://lore.kernel.org/r/1580983853-351-1-git-send-email-viswanathl@nvidia.com Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
Kailang Yang authored
HP want to keep BIOS verb table for release platform. So, it need to add 0x19 pin for quirk. Fixes: 5af29028 ("ALSA: hda/realtek - Add Headset Mic supported for HP cPC") Signed-off-by:
Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/r/74636ccb700a4cbda24c58a99dc430ce@realtek.com Signed-off-by:
-
- Feb 05, 2020
-
-
Takashi Iwai authored
Merge tag 'asoc-v5.6-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.6 A collection of updates for bugs fixed since the initial pull request, the most important one being the addition of COMMON_CLK for wcd934x which is needed for MFD to be merged.
-
Nikhil Mahale authored
If dyn_pcm_assign is set, different jack objects are being created for pcm and pins. If dyn_pcm_assign is set, generic_hdmi_build_jack() calls into add_hdmi_jack_kctl() to create and track separate jack object for pcm. Like sync_eld_via_acomp(), hdmi_present_sense_via_verbs() also need to report status change of the pcm jack. Rename pin_idx_to_jack() to pin_idx_to_pcm_jack(). Update hdmi_present_sense_via_verbs() to report plug state of pcm jack object. Unlike sync_eld_via_acomp(), for !acomp drivers the pcm jack's plug state must be consistent with plug state of pin's jack. Fixes: 5398e94f ("ALSA: hda - Add DP-MST support for NVIDIA codecs") Reported-and-tested-by:
Martin Regner <martin@larkos.de> Signed-off-by:
Nikhil Mahale <nmahale@nvidia.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200204102746.1356-1-nmahale@nvidia.com Signed-off-by:
-
- Feb 04, 2020
-
-
Srinivas Kandagatla authored
Looks like some platforms are not yet using COMMON CLK. PowerPC allyesconfig failed with below error in next ld: sound/soc/codecs/wcd934x.o:(.toc+0x0): undefined reference to `of_clk_src_simple_get' ld: sound/soc/codecs/wcd934x.o: in function `.wcd934x_codec_probe': wcd934x.c:(.text.wcd934x_codec_probe+0x3d4): undefined reference to `.__clk_get_name' ld: wcd934x.c:(.text.wcd934x_codec_probe+0x438): undefined reference to `.clk_hw_register' ld: wcd934x.c:(.text.wcd934x_codec_probe+0x474): undefined reference to `.of_clk_add_provider' Add the missing COMMON_CLK dependency to fix this errors. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200204111241.6927-1-srinivas.kandagatla@linaro.org Signed-off-by:
Mark Brown <broonie@kernel.org>
-
Oder Chiou authored
Remove the maintainer "Bard Liao" since he had quitted from Realtek. Signed-off-by:
Oder Chiou <oder_chiou@realtek.com> Link: https://lore.kernel.org/r/3ae27357f98a406a958304386a1457bc@realtek.com Signed-off-by:
-
- Feb 02, 2020
-
-
Jon Hunter authored
Commit f3ee9908 ("ASoC: tegra: Allow 24bit and 32bit samples") added 24-bit and 32-bit support for to the Tegra30 I2S driver. However, there are two additional commits that are also needed to get 24-bit and 32-bit support to work correctly. These commits are not yet applied because there are still some review comments that need to be addressed. With only this change applied, 24-bit and 32-bit support is advertised by the I2S driver, but it does not work and the audio is distorted. Therefore, revert this patch for now until the other changes are also ready. Furthermore, a clock issue with 24-bit support has been identified with this change and so if we revert this now, we can also fix that in the updated version. Reported-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
-
Yong Zhi authored
Mirror ID added for legacy HDaudio. Signed-off-by:
Yong Zhi <yong.zhi@intel.com> Signed-off-by:
Divagar Mohandass <divagar.mohandass@intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200131204032.10213-1-pierre-louis.bossart@linux.intel.com Signed-off-by:
-
Takashi Iwai authored
The firmware loading ioctl that is implemented for hdsp hwdep device takes the reference of the address pointer, hence the current code is rather confusing. Also, due to the recent change in uapi header, sparse also complains about the cast. This patch tries to improve the readability by converting the straightforward copy_from_user of the whole struct (which contains only the pointer). Fixes: d63e63d4 ("ALSA: hdsp: Make uapi/hdsp.h compilable again") Link: https://lore.kernel.org/r/20200202090724.18232-2-tiwai@suse.de Signed-off-by:
-
Takashi Iwai authored
The recent sound/emu10k1.h uapi header change by the commit 2e468867 ("ALSA: emu10k1: Make uapi/emu10k1.h compilable again") made sparse angry because of the inconsistency of __user annotation and the own ctl id struct that were changed in uapi header. This patch addresses those by adjusting the cast and annotations properly again. Fixes: 2e468867 ("ALSA: emu10k1: Make uapi/emu10k1.h compilable again") Link: https://lore.kernel.org/r/20200202090724.18232-1-tiwai@suse.de Signed-off-by:
-
- Feb 01, 2020
-
-
Takashi Iwai authored
The loop termination for iterating over all formats should contain SNDRV_PCM_FORMAT_LAST, not less than it. Fixes: 9b151fec ("ALSA: dummy - Add debug proc file") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200201080530.22390-3-tiwai@suse.de Signed-off-by:
-
Takashi Iwai authored
The Scarlett gen2 mixer quirk code defines a few record types to communicate via USB hub, and those must be all little-endian. This patch changes the field types to LE to annotate endianess properly. It also fixes the incorrect usage of leXX_to_cpu() in a couple of places, which was caught by sparse after this change. Fixes: 9e4d5c1b ("ALSA: usb-audio: Scarlett Gen 2 mixer interface") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200201080530.22390-2-tiwai@suse.de Signed-off-by:
-
Takashi Iwai authored
I overlooked that some fields are words and need the converts from LE in the recently added USB descriptor validation code. This patch fixes those with the proper macro usages. Fixes: 57f87706 ("ALSA: usb-audio: More validations of descriptor units") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200201080530.22390-1-tiwai@suse.de Signed-off-by:
-
Yong Zhi authored
Add HD Audio Device PCI ID and codec vendor_id for the Intel JasperLake REV2/A0 silicon. Signed-off-by:
-
- Jan 31, 2020
-
-
Takashi Iwai authored
Since we have a bitwise definition of snd_pcm_state_t and use it for certain struct fields, a few new (and years old) sparse warnings came up. This patch is an attempt to cover them. - The state fields in snd_pcm_mmap_status* and co are all defined as snd_pcm_state_t type now - The PCM action callbacks take snd_pcm_state_t argument as well; some actions taking special values got the explicit cast and comments - For the PCM action that doesn't need an extra argument receives ACTION_ARG_IGNORE instead of ambiguous 0 While we're at it, the boolean argument is also properly changed to bool and true/false, as well as a slight refactoring of PCM pause helper function to make easier to read. No functional changes, just shutting up chatty sparse. Fixes: 46b770f7 ("ALSA: uapi: Fix sparse warning") Reported-by:
kbuild test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20200131152214.11698-1-tiwai@suse.de Signed-off-by:
-
- Jan 30, 2020
-
-
Takashi Iwai authored
ALSA PCM core recently introduced a new managed PCM buffer allocation mode that does allocate / free automatically at hw_params and hw_free. However, it overlooked the code path directly calling hw_free PCM ops at releasing the PCM substream, and it may result in a memory leak as spotted by syzkaller when no buffer preallocation is used (e.g. vmalloc buffer). This patch papers over it with a slight refactoring. The hw_free ops call and relevant tasks are unified in a new helper function, and call it from both places. Fixes: 0dba808e ("ALSA: pcm: Introduce managed buffer allocation mode") Reported-by:
<syzbot+30edd0f34bfcdc548ac4@syzkaller.appspotmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200129195907.12197-1-tiwai@suse.de Signed-off-by:
-
Ranjani Sridharan authored
Fix the following sparse warning generated due to 64-bit compat type having fields defined explicitly with __s32: sound/soc/sof/sof-audio.c:46:31: warning: incorrect type in assignment (different base types) sound/soc/sof/sof-audio.c:46:31: expected restricted snd_pcm_state_t [usertype] state sound/soc/sof/sof-audio.c:46:31: got signed int [usertype] state Fixes: 80fe7430 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control") Reported-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20200129184448.3005-1-ranjani.sridharan@linux.intel.com Signed-off-by:
-
Takashi Iwai authored
Fix the compile warnings by adding __maybe_unused to PM callbacks: sound/soc/codecs/rt715-sdw.c:566:12: warning: ‘rt715_dev_resume’ defined but not used [-Wunused-function] sound/soc/codecs/rt715-sdw.c:552:12: warning: ‘rt715_dev_suspend’ defined but not used [-Wunused-function] Fixes: d1ede064 ("ASoC: rt715: add RT715 codec driver") Signed-off-by:
-
Takashi Iwai authored
Fix the compile warnings by adding __maybe_unused to PM callbacks: sound/soc/codecs/rt711-sdw.c:504:12: warning: ‘rt711_dev_resume’ defined but not used [-Wunused-function] sound/soc/codecs/rt711-sdw.c:490:12: warning: ‘rt711_dev_suspend’ defined but not used [-Wunused-function] Fixes: 320b8b0d ("ASoC: rt711: add rt711 codec driver") Signed-off-by:
-
Takashi Iwai authored
Fix the compile warnings by adding __maybe_unused to PM callbacks: sound/soc/codecs/rt700-sdw.c:503:12: warning: ‘rt700_dev_resume’ defined but not used [-Wunused-function] sound/soc/codecs/rt700-sdw.c:489:12: warning: ‘rt700_dev_suspend’ defined but not used [-Wunused-function] Fixes: 7d2a5f9a ("ASoC: rt700: add rt700 codec driver") Signed-off-by:
-
Takashi Iwai authored
Fix the compile warnings by adding __maybe_unused to PM callbacks: sound/soc/codecs/rt1308-sdw.c:690:12: warning: ‘rt1308_dev_resume’ defined but not used [-Wunused-function] sound/soc/codecs/rt1308-sdw.c:676:12: warning: ‘rt1308_dev_suspend’ defined but not used [-Wunused-function] Fixes: a87a6653 ("ASoC: rt1308-sdw: add rt1308 SdW amplifier driver") Signed-off-by:
-
Akshu Agrawal authored
Stopping of one stream is killing the other stream when they are running simultaneously. This is because, IER register is cleared which disables I2S and overrides any other block enables. Clearing IER register only when all streams on a channel are disabled, fixes the issue. Signed-off-by:
Akshu Agrawal <akshu.agrawal@amd.com> Link: https://lore.kernel.org/r/20200128103029.128841-1-akshu.agrawal@amd.com Signed-off-by:
-
- Jan 28, 2020
-
-
Mohan Kumar authored
Tegra HDA has FIFO size which can hold upto 10 audio frames to support DVFS. When HDA DMA RUN bit is set to 0 to stop the stream, the DMA RUN bit will be cleared to 0 only after transferring all the remaining audio frames queued up in the fifo. This is not in sync with spec which states the controller will stop transmitting(output) in the beginning of the next frame for the relevant stream. The above behavior with Tegra HDA was resulting in machine check error during the system suspend flow with active audio playback with below kernel error logs. [ 33.524583] mc-err: [mcerr] (hda) csr_hdar: EMEM address decode error [ 33.531088] mc-err: [mcerr] status = 0x20000015; addr = 0x00000000 [ 33.537431] mc-err: [mcerr] secure: no, access-type: read, SMMU fault: none This was due to the fifo has more than one audio frame when the DMA RUN bit is set to 0 during system suspend flow and the timeout handling in snd_hdac_stream_sync() was not designed to handle this scenario. So the DMA will continue running even after timeout hit until all remaining audio frames in the fifo are transferred, but the suspend flow will try to reset the controller and turn off the hda clocks without the knowledge of the DMA is still running and could result in mc-err. The above issue can be resolved by doing stream reset with the help of snd_hdac_stream_reset() which would ensure the DMA RUN bit is cleared if the timeout was hit in snd_hdac_stream_sync(). Signed-off-by:
-
Guennadi Liakhovetski authored
Multiple Intel ASoC machine drivers repeat the same pattern in their .late_probe() methods: they first check whether the common HDMI codec driver is used, if not, they proceed by linking the legacy HDMI driver to each HDMI port. While doing that they use some inconsistent code: 1. after the loop they check, whether the list contained at least one element and if not, they return an error. However, the earlier code to use the common HDMI driver uses the first element of the same list without checking. To fix this we move the check to the top of the function. 2. some of those .late_probe() implementations execute code, only needed for the common HDMI driver, before checking, whether the driver is used. Move the code to after the check. 3. Some of those functions also perform a redundant initialisation of the "err" variable. This patch fixes those issues. Signed-off-by:
Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by:
-
Bard Liao authored
Fix the part id of rt715 (typo with zero in the wrong place) Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by:
-
Pan Xiuli authored
jsl_desc missed default_fw_name, this will fail the probe in nocodec or generice HDA mode due the firmware path is intel/sof/(null) Signed-off-by:
Pan Xiuli <xiuli.pan@linux.intel.com> Signed-off-by:
-
Kai Vehmanen authored
Check if DMA pages were successfully allocated in initialization before calling free. For many types of memory (like sgbufs) the extra free is harmless, but not all backends track allocation state, so add an explicit check. Signed-off-by:
-
Pierre-Louis Bossart authored
The initial intent of releasing resources in the .remove does not work well with HDaudio codecs. If the probe_continue() fails in a work queue, e.g. due to missing firmware or authentication issues, we don't release any resources, and as a result the kernel oopses during suspend operations. The suggested fix is to release all resources during errors in probe_continue(), and use fw_state to track resource allocation state, so that .remove does not attempt to release the same hardware resources twice. PM operations are also modified so that no action is done if DSP resources have been freed due to an error at probe. Reported-by:
-
Pierre-Louis Bossart authored
free_trace() is not called on probe errors, fix Reviewed-by:
-
Guennadi Liakhovetski authored
It is possible to create invalid topology that will cause a kernel Oops when trying to allocate buffers for a NULL substream. Specifically such an Oops was caused by a topology, where a DAI on a capture pipeline was referencing the PCM ID from a playback pipeline. Fix the Oops by explicitly checking for NULL. Signed-off-by:
-
Ravulapati Vishnu vardhan rao authored
If we play audio back to back, which kills one playback and immediately start another, we can hear clicks. This patch fixes the issue. Signed-off-by:
Ravulapati Vishnu vardhan rao <Vishnuvardhanrao.Ravulapati@amd.com> Link: https://lore.kernel.org/r/1580124397-19842-1-git-send-email-Vishnuvardhanrao.Ravulapati@amd.com Signed-off-by:
-
Kai Vehmanen authored
Change HDA probe behaviour slightly so that i915 power is not turned off if i915 audio codecs are found in the initial probe done by SOF Intel driver, and power is kept on until HDA codec driver probe runs. This will reduce number of mode sets on platforms with low minimum CDCLK (like GLK) and brings the SOF probe sequence closer to legacy HDA driver in terms of i915 audio codec power management. BugLink: https://github.com/thesofproject/linux/issues/1642 Signed-off-by:
-
Kai Vehmanen authored
The current interface to control i915 display power is misleading. The hda_codec_i915_get() and hda_codec_i915_put() names suggest a refcounting based interface. This is confusing as no refcounting is done and the underlying HDAC library interface does not support refcounts eithers. Clarify the code by replacing the functions with a single hda_codec_i915_display_power() that is aligned with snd_hdac_display_power(). Signed-off-by:
-
Takashi Iwai authored
Merge tag 'asoc-v5.6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Updates for v5.6 A pretty big release this time around, a lot of new drivers and both Morimoto-san and Takashi were doing subsystem wide updates as well: - Further big refactorings from Morimoto-san simplifying the core interfaces and moving things to the component level. - Transition of drivers to managed buffer allocation and removal of redundant PCM ioctls. - New driver support for Ingenic JZ4770, Mediatek MT6660, Qualcomm WCD934x and WSA881x, and Realtek RT700, RT711, RT715, RT1011, RT1015 and RT1308.
-
- Jan 26, 2020
-
-
Takashi Iwai authored
Resolve conflicts and correct the hex numbers, too. Signed-off-by: -
Nicola Lunghi authored
With firmware 2.82 Line6 changed the usb id of some of the Helix devices but the quirks is still needed. Add it to the quirk list for line6 helix family of devices. Thanks to Jens for pointing out the missing ids. Signed-off-by:
Nicola Lunghi <nick83ola@gmail.com> Link: https://lore.kernel.org/r/20200125150917.5040-1-nick83ola@gmail.com Signed-off-by:
-
Hans de Goede authored
Using HDA power-saving on the Clevo W65_67SB causes the first 0.5 seconds of audio to be missing every time audio starts playing. This commit adds the Clevo W65_67SB the power_save blacklist to avoid this issue. Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104 Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200125181021.70446-1-hdegoede@redhat.com Signed-off-by:
-
- Jan 25, 2020
-
-
Nathan Chancellor authored
Clang warns: ../sound/soc/codecs/rt1015.c:392:14: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier] static const SOC_ENUM_SINGLE_DECL(rt1015_boost_mode_enum, 0, 0, ^ ../include/sound/soc.h:355:2: note: expanded from macro 'SOC_ENUM_SINGLE_DECL' SOC_ENUM_DOUBLE_DECL(name, xreg, xshift, xshift, xtexts) ^ ../include/sound/soc.h:352:2: note: expanded from macro 'SOC_ENUM_DOUBLE_DECL' const struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \ ^ 1 warning generated. Remove the const after static to fix it. Fixes: df310074 ("ASoC: rt1015: add rt1015 amplifier driver") Link: https://github.com/ClangBuiltLinux/linux/issues/845 Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Link: https://lore.kernel.org/r/20200124155750.33753-1-natechancellor@gmail.com Signed-off-by:
-
Marek Szyprowski authored
Commit 08df0d9a ("ASoC: max98090: revert "ASoC: max98090: fix lockdep warning"") provided a good rationale for removing separate lock for the SHDN register access. However it restored the lockdep warning during the system boot. To silence the lockdep warning, mark the mutex taken in the max98090_shdn_save() function with the lockdep class dedicated for the runtime DAPM operations: SND_SOC_DAPM_CLASS_RUNTIME. This finally fixes the following lockdep warning observed on Exynos4412-based Odroid U3 board: ====================================================== WARNING: possible circular locking dependency detected 5.5.0-rc7-next-20200123 #7329 Not tainted ------------------------------------------------------ alsactl/1105 is trying to acquire lock: ed4f7cf4 (&card->dapm_mutex){+.+.}, at: max98090_shdn_save+0x1c/0x28 but task is already holding lock: edb8d49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&card->controls_rwsem){++++}: snd_ctl_add_replace+0x3c/0x84 dapm_create_or_share_kcontrol+0x24c/0x2e0 snd_soc_dapm_new_widgets+0x308/0x594 snd_soc_bind_card+0x834/0xa94 devm_snd_soc_register_card+0x34/0x6c odroid_audio_probe+0x288/0x34c platform_drv_probe+0x6c/0xa4 really_probe+0x200/0x48c driver_probe_device+0x78/0x1f8 bus_for_each_drv+0x74/0xb8 __device_attach+0xd4/0x16c bus_probe_device+0x88/0x90 deferred_probe_work_func+0x3c/0xd0 process_one_work+0x230/0x7bc worker_thread+0x44/0x524 kthread+0x130/0x164 ret_from_fork+0x14/0x20 0x0 -> #0 (&card->dapm_mutex){+.+.}: lock_acquire+0xe8/0x270 __mutex_lock+0x9c/0xb18 mutex_lock_nested+0x1c/0x24 max98090_shdn_save+0x1c/0x28 max98090_put_enum_double+0x20/0x40 snd_ctl_ioctl+0x190/0xbb8 ksys_ioctl+0x484/0xb10 ret_fast_syscall+0x0/0x28 0xbede0564 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&card->controls_rwsem); lock(&card->dapm_mutex); lock(&card->controls_rwsem); lock(&card->dapm_mutex); *** DEADLOCK *** 1 lock held by alsactl/1105: #0: edb8d49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8 stack backtrace: CPU: 2 PID: 1105 Comm: alsactl Not tainted 5.5.0-rc7-next-20200123 #7329 Hardware name: Samsung Exynos (Flattened Device Tree) [<c01126f0>] (unwind_backtrace) from [<c010e1e8>] (show_stack+0x10/0x14) [<c010e1e8>] (show_stack) from [<c0b5234c>] (dump_stack+0xb4/0xe0) [<c0b5234c>] (dump_stack) from [<c018a610>] (check_noncircular+0x1ec/0x208) [<c018a610>] (check_noncircular) from [<c018ca2c>] (__lock_acquire+0x1210/0x25ec) [<c018ca2c>] (__lock_acquire) from [<c018e728>] (lock_acquire+0xe8/0x270) [<c018e728>] (lock_acquire) from [<c0b71928>] (__mutex_lock+0x9c/0xb18) [<c0b71928>] (__mutex_lock) from [<c0b723c0>] (mutex_lock_nested+0x1c/0x24) [<c0b723c0>] (mutex_lock_nested) from [<c086097c>] (max98090_shdn_save+0x1c/0x28) [<c086097c>] (max98090_shdn_save) from [<c08613f8>] (max98090_put_enum_double+0x20/0x40) [<c08613f8>] (max98090_put_enum_double) from [<c0833f20>] (snd_ctl_ioctl+0x190/0xbb8) [<c0833f20>] (snd_ctl_ioctl) from [<c02cae14>] (ksys_ioctl+0x484/0xb10) [<c02cae14>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xed331fa8 to 0xed331ff0) ... Fixes: 08df0d9a ("ASoC: max98090: revert "ASoC: max98090: fix lockdep warning"") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20200123134046.9769-1-m.szyprowski@samsung.com Signed-off-by:
-
- Jan 23, 2020
-
-
Mark Brown authored
-
