- 16 Apr, 2019 2 commits
-
-
Takashi Iwai authored
There is a small race window in the card disconnection code that allows the registration of another card with the very same card id. This leads to a warning in procfs creation as caught by syzkaller. The problem is that we delete snd_cards and snd_cards_lock entries at the very beginning of the disconnection procedure. This makes the slot available to be assigned for another card object while the disconnection procedure is being processed. Then it becomes possible to issue a procfs registration with the existing file name although we check the conflict beforehand. The fix is simply to move the snd_cards and snd_cards_lock clearances at the end of the disconnection procedure. The references to these entries are merely either from the global proc files like /proc/asound/cards or from the card registration / disconnection, so it should be fine to shift at the very end. Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The ALSA proc helper manages the child nodes in a linked list, but its addition and deletion is done without any lock. This leads to a corruption if they are operated concurrently. Usually this isn't a problem because the proc entries are added sequentially in the driver probe procedure itself. But the card registrations are done often asynchronously, and the crash could be actually reproduced with syzkaller. This patch papers over it by protecting the link addition and deletion with the parent's mutex. There is "access" mutex that is used for the file access, and this can be reused for this purpose as well. Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 13 Apr, 2019 1 commit
-
-
Takashi Iwai authored
The recent commit 98081ca6 ("ALSA: hda - Record the current power state before suspend/resume calls") made the HD-audio driver to store the PM state in power_state field. This forgot, however, the initialization at power up. Although the codec drivers usually don't need to refer to this field in the normal operation, let's initialize it properly for consistency. Fixes: 98081ca6 ("ALSA: hda - Record the current power state before suspend/resume calls") Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 11 Apr, 2019 1 commit
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.1 A few core fixes along with the driver specific ones, mainly fixing small issues that only affect x86 platforms for various reasons (their unusual machine enumeration mechanisms mainly, plus a fix for error handling in topology). There's some of the driver fixes that look larger than they are, like the hdmi-codec changes which resulted in an indentation change, and most of the other large changes are for new drivers like the STM32 changes.
-
- 10 Apr, 2019 5 commits
-
-
Marc Gonzalez authored
wcd9335.c: undefined reference to 'devm_regmap_add_irq_chip' Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Takashi Iwai authored
snd_hdac_display_power() doesn't handle the concurrent calls carefully enough, and it may lead to the doubly get_power or put_power calls, when a runtime PM and an async work get called in racy way. This patch addresses it by reusing the bus->lock mutex that has been used for protecting the link state change in ext bus code, so that it can protect against racy display state changes. The initialization of bus->lock was moved from snd_hdac_ext_bus_init() to snd_hdac_bus_init() as well accordingly. Testcase: igt/i915_pm_rpm/module-reload #glk-dsi Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Ranjani Sridharan authored
Handle error before returning when try_module_get() fails to prevent inconsistent mutex lock/unlock. Fixes: 52034add (ASoC: pcm: update module refcount if module_get_upon_open is set) Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Olivier Moysan authored
When master clock is used, master clock rate is set exclusively. Parent clocks of master clock cannot be changed after a call to clk_set_rate_exclusive(). So the parent clock of SAI kernel clock must be set before. Ensure also that exclusive rate operations are balanced in STM32 SAI driver. Signed-off-by: Olivier Moysan <olivier.moysan@st.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Tzung-Bi Shih authored
Fix wrong setting on number of channels. The context wants to set constraint to 2 channels instead of 4. Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 08 Apr, 2019 5 commits
-
-
Hui Wang authored
Recently we set CONFIG_SND_HDA_POWER_SAVE_DEFAULT to 1 when configuring the kernel, then two machines were reported to have noise after installing the new kernel. Put them in the blacklist, the noise disappears. https://bugs.launchpad.net/bugs/1821663 Cc: <stable@vger.kernel.org> Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Ranjani Sridharan authored
Setting the module_get_upon_open field for component driver prevents the module refcount from being incremented during component probe(). This could lead to the module being allowed to be unloaded when a pcm stream is open. So, if this field is set, the module's refcount should be incremented during pcm open to prevent module removal when the component is in use. And, the refcount should be decremented upon pcm close. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Ranjani Sridharan authored
Recently, for Intel platforms the "ignore_module_refcount" field was introduced for the component driver. In order to avoid a deadlock preventing the PCI modules from being removed even when the card was idle, the refcounts were not incremented for the device driver module during component probe. However, this change introduced a nasty side effect: the device driver module can be unloaded while a pcm stream is open. This patch proposes to change the field to be renamed as "module_get_upon_open". When this field is set, the module refcount should be incremented on pcm open amd decremented upon pcm close. This will enable modules to be removed when no PCM playback/capture happens and prevent removal when the component is actually in use. Also, align with the skylake component driver with the new name. Fixes: b450b878('ASoC: core: don't increase component module refcount unconditionally' Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Arnaud Pouliquen authored
This patch fixes the sai driver structure overwriting which results in a cpu dai name equal NULL. Fixes: 3e086edf ("ASoC: stm32: add SAI driver") Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Ranjani Sridharan authored
The control values and texts of the enum kcontrol associated with a widget need to be freed when the widget is removed. However, both struct snd_soc_dapm_widget and struct soc_enum contain a dobj member, which resulted in a confusion. The existing code generates a null pointer dereference by attempting to free the values and texts from the dobj which belongs to the widget instead of the dobj belonging to the enum kcontrol. The suggested fix is to use the correct dobj member (se->dobj) of the enum kcontrol. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 05 Apr, 2019 3 commits
-
-
Zubin Mithra authored
When ioctl calls are made with non-null-terminated userspace strings, strlcpy causes an OOB-read from within strlen. Fix by changing to use strscpy instead. Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Ranjani Sridharan authored
Topology is not unloaded in the core during unregister_component() anymore. So, add the remove() callback that will unload the topology. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
The chips main power supplies VA and VP are enabled during probe but then never disabled, this will cause warnings from the regulator framework on driver removal. Fix this by adding a remove callback and disabling the supplies, whilst doing so follow best practice and put the chip back into reset as well. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 04 Apr, 2019 6 commits
-
-
Oleksandr Andrushchenko authored
This fixes the regression introduced while moving to Xen shared buffer implementation. Fixes: 58f9d806 ("ALSA: xen-front: Use Xen common shared buffer implementation") Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Sugar Zhang authored
This patch decreases the transfer bursts to avoid the fifo overrun. Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Sugar Zhang authored
This is because set_fmt ops maybe called when PD is off, and in such case, regmap_ops will lead system hang. enale PD before doing regmap_ops. Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
commit da215354 ("ASoC: simple-card: merge simple-scu-card") merged simple-scu-audio-card which can handle DPCM into simple-audio-card. By this patch, the judgement to select "normal sound card" or "DPCM sound card" is based on its CPU/Codec DAI count. But, because of it, existing "simple-audio-card" user who is assuming "normal sound card" might select DPCM unintentionally. To solve this issue, this patch allows "simple-audio-card" user can select "normal sound card", and "simple-scu-audio-card" user can select both "normal sound card" and "DPCM sound card". This keeps compatibility collectry. Fixes: da215354 ("ASoC: simple-card: merge simple-scu-card") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
commit ae3cb579 ("ASoC: audio-graph-card: merge audio-graph-scu-card") merged audio-graph-scu-card which can handle DPCM into audio-graph-card. By this patch, the judgement to select "normal sound card" or "DPCM sound card" is based on its OF-graph endpoint connection. But, because of it, existing "audio-graph-card" user who is assuming "normal sound card" might select DPCM unintentionally. To solve this issue, this patch allows "audio-graph-card" user can select "normal sound card", and "audio-graph-scu-card" user can select both "normal sound card" and "DPCM sound card". This keeps compatibility collectry. Fixes: ae3cb579 ("ASoC: audio-graph-card: merge audio-graph-scu-card") Reported-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Annaliese McDermond authored
The author of these files has changed her name. Update instances in the code of her dead name to current legal name. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 03 Apr, 2019 4 commits
-
-
Richard Sailer authored
This adds a SND_PCI_QUIRK(...) line for the Tuxedo XC 1509. The Tuxedo XC 1509 and the System76 oryp5 are the same barebone notebooks manufactured by Clevo. To name the fixups both use after the actual underlying hardware, this patch also changes System76_orpy5 to clevo_pb51ed in 2 enum symbols and one function name, matching the other pci_quirk entries which are also named after the device ODM. Fixes: 7f665b1c ("ALSA: hda/realtek - Headset microphone and internal speaker support for System76 oryp5") Signed-off-by: Richard Sailer <rs@tuxedocomputers.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Kailang Yang authored
It will be lose Mic JD state when Chrome OS boot and headset was plugged. Just Implement of reset combo jack JD verb for ACT_PRE_PROBE state. Intel test result was also failed. It test passed until changed the initial state to ACT_INIT. Mic JD will show every time. This patch also changed the model name as 'alc-chrome-book' for application of Chrome OS. Fixes: 10f5b1b8 ("ALSA: hda/realtek - Fixed Headset Mic JD not stable") Signed-off-by: Kailang Yang <kailang@realtek.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Hans de Goede authored
Users have been seeing sound stability issues with max98090 codecs since: commit 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") At first that commit broke sound for Chromebook Swanky and Clapper models, the problem was that the machine-driver has been controlling the wrong clock on those models since support for them was added. This was hidden by clk-pmc-atom.c keeping the actual clk on unconditionally. With the machine-driver controlling the proper clock, sound works again but we are seeing bug reports describing it as: low volume, "sounds like played at 10x speed" and instable. When these issues are hit the following message is seen in dmesg: "max98090 i2c-193C9890:00: PLL unlocked". Attempts have been made to fix this by inserting a delay between enabling the clk and enabling and checking the pll, but this has not helped. It seems that at least on boards which use pmc_plt_clk_0 as clock, if we ever disable the clk, the pll looses its lock and after that we get various issues. This commit fixes this by enabling the clock once at probe time on these boards. In essence this restores the old behavior of clk-pmc-atom.c always keeping the clk on on these boards. Fixes: 648e9218 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Reported-by: Mogens Jensen <mogens-jensen@protonmail.com> Reported-by: Dean Wallace <duffydack73@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
Trigger stop can be called in situations where trigger start failed and as such it can't be assumed the buffer is already attached to the compressed stream or a NULL pointer may be dereferenced. Fixes: 639e5eb3 ("ASoC: wm_adsp: Correct handling of compressed streams that restart") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 02 Apr, 2019 4 commits
-
-
Daniel Mentz authored
The uapi header asound.h defines types based on struct timespec. We need to #include <time.h> to get access to the definition of this struct. Previously, we encountered the following error message when building applications with a clang/bionic toolchain: kernel-headers/sound/asound.h:350:19: error: field has incomplete type 'struct timespec' struct timespec trigger_tstamp; ^ The absence of the time.h #include statement does not cause build errors with glibc, because its version of stdlib.h indirectly includes time.h. Signed-off-by: Daniel Mentz <danielmentz@google.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Jian-Hong Pan authored
The Acer TravelMate B114-21 laptop cannot detect and record sound from headset MIC. This patch adds the ALC233_FIXUP_ACER_HEADSET_MIC HDA verb quirk chained with ALC233_FIXUP_ASUS_MIC_NO_PRESENCE pin quirk to fix this issue. [ fixed the missing brace and reordered the entry -- tiwai ] Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Daniel Drake <drake@endlessm.com> Reviewed-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Ranjani Sridharan authored
Currently, buffers, schedulers, src's, encoders, decoders and effect type dapm widgets remain always on as their power_check method is not set. Setting this callback allows these widgets in the audio path to be powered managed properly. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Jerome Brunet authored
If for any reason, the backend does not have the requested substream (like capture on a playback only backend), the BE will be skipped in dpcm_be_dai_startup(). However, dpcm_apply_symmetry() does not skip those BE and will dereference the be_substream (NULL) pointer anyway. Like in dpcm_be_dai_startup(), just skip those BE. Fixes: 906c7d69 ("ASoC: dpcm: Apply symmetry for DPCM") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 01 Apr, 2019 1 commit
-
-
Annaliese McDermond authored
The common pins were mistakenly not added to the DAPM graph. Adding these pins will allow valid graphs to be created. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 26 Mar, 2019 2 commits
-
-
Bernhard Rosenkraenzer authored
On an Acer Predator Helios 500 (Ryzen version), the laptop's speakers don't work out of the box. The problem can be worked around with hdajackretask, remapping the "Black Headphone, Right side" pin (0x21) to the Internal speaker. This patch adds a quirk to change this mapping by default. [ corrected ALC299_FIXUP_PREDATOR_SPK definition and adapted for the latest tree by tiwai ] Signed-off-by: Bernhard Rosenkraenzer <bero@lindev.ch> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Jenny TC authored
To enable S24_LE format, sample_type in topology fw has to be set to 1. But sample_type defined in topology firmware configuration is not getting reflected in the dsp param. This patch sets sample_type in base config so that the sample type defined in the topology firmware is reflected in the dsp params. This issues was uncovered while debugging the S24_LE format which require the MSB byte in 32 bit word to be skipped. Setting sample_type in topology firmware to 1 helps to skip MSB byte word. Signed-off-by: Jenny TC <jenny.tc@intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 25 Mar, 2019 3 commits
-
-
Takashi Iwai authored
Currently PCM core sets each opened stream forcibly to SUSPENDED state via snd_pcm_suspend_all() call, and the user-space is responsible for re-triggering the resume manually either via snd_pcm_resume() or prepare call. The scheme works fine usually, but there are corner cases where the stream can't be resumed by that call: the streams still in OPEN state before finishing hw_params. When they are suspended, user-space cannot perform resume or prepare because they haven't been set up yet. The only possible recovery is to re-open the device, which isn't nice at all. Similarly, when a stream is in DISCONNECTED state, it makes no sense to change it to SUSPENDED state. Ditto for in SETUP state; which you can re-prepare directly. So, this patch addresses these issues by filtering the PCM streams to be suspended by checking the PCM state. When a stream is in either OPEN, SETUP or DISCONNECTED as well as already SUSPENDED, the suspend action is skipped. To be noted, this problem was originally reported for the PCM runtime PM on HD-audio. And, the runtime PM problem itself was already addressed (although not intended) by the code refactoring commits 3d21ef0b ("ALSA: pcm: Suspend streams globally via device type PM ops") and 17bc4815 ("ALSA: pci: Remove superfluous snd_pcm_suspend*() calls"). These commits eliminated the snd_pcm_suspend*() calls from the runtime PM suspend callback code path, hence the racy OPEN state won't appear while runtime PM. (FWIW, the race window is between snd_pcm_open_substream() and the first power up in azx_pcm_open().) Although the runtime PM issue was already "fixed", the same problem is still present for the system PM, hence this patch is still needed. And for stable trees, this patch alone should suffice for fixing the runtime PM problem, too. Reported-and-tested-by: Jon Hunter <jonathanh@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Pankaj Bharadiya authored
w_text_param can be NULL and it is being dereferenced without checking. Add the missing sanity check to prevent NULL pointer dereference. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
Guenter Roeck authored
If codec registration fails after the ASoC Intel SST driver has been probed, the kernel will Oops and crash at suspend/resume. general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 2811 Comm: cat Tainted: G W 4.19.30 #15 Hardware name: GOOGLE Clapper, BIOS Google_Clapper.5216.199.7 08/22/2014 RIP: 0010:snd_soc_suspend+0x5a/0xd21 Code: 03 80 3c 10 00 49 89 d7 74 0b 48 89 df e8 71 72 c4 fe 4c 89 fa 48 8b 03 48 89 45 d0 48 8d 98 a0 01 00 00 48 89 d8 48 c1 e8 03 <8a> 04 10 84 c0 0f 85 85 0c 00 00 80 3b 00 0f 84 6b 0c 00 00 48 8b RSP: 0018:ffff888035407750 EFLAGS: 00010202 RAX: 0000000000000034 RBX: 00000000000001a0 RCX: 0000000000000000 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88805c417098 RBP: ffff8880354077b0 R08: dffffc0000000000 R09: ffffed100b975718 R10: 0000000000000001 R11: ffffffff949ea4a3 R12: 1ffff1100b975746 R13: dffffc0000000000 R14: ffff88805cba4588 R15: dffffc0000000000 FS: 0000794a78e91b80(0000) GS:ffff888068d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007bd5283ccf58 CR3: 000000004b7aa000 CR4: 00000000001006e0 Call Trace: ? dpm_complete+0x67b/0x67b ? i915_gem_suspend+0x14d/0x1ad sst_soc_prepare+0x91/0x1dd ? sst_be_hw_params+0x7e/0x7e dpm_prepare+0x39a/0x88b dpm_suspend_start+0x13/0x9d suspend_devices_and_enter+0x18f/0xbd7 ? arch_suspend_enable_irqs+0x11/0x11 ? printk+0xd9/0x12d ? lock_release+0x95f/0x95f ? log_buf_vmcoreinfo_setup+0x131/0x131 ? rcu_read_lock_sched_held+0x140/0x22a ? __bpf_trace_rcu_utilization+0xa/0xa ? __pm_pr_dbg+0x186/0x190 ? pm_notifier_call_chain+0x39/0x39 ? suspend_test+0x9d/0x9d pm_suspend+0x2f4/0x728 ? trace_suspend_resume+0x3da/0x3da ? lock_release+0x95f/0x95f ? kernfs_fop_write+0x19f/0x32d state_store+0xd8/0x147 ? sysfs_kf_read+0x155/0x155 kernfs_fop_write+0x23e/0x32d __vfs_write+0x108/0x608 ? vfs_read+0x2e9/0x2e9 ? rcu_read_lock_sched_held+0x140/0x22a ? __bpf_trace_rcu_utilization+0xa/0xa ? debug_smp_processor_id+0x10/0x10 ? selinux_file_permission+0x1c5/0x3c8 ? rcu_sync_lockdep_assert+0x6a/0xad ? __sb_start_write+0x129/0x2ac vfs_write+0x1aa/0x434 ksys_write+0xfe/0x1be ? __ia32_sys_read+0x82/0x82 do_syscall_64+0xcd/0x120 entry_SYSCALL_64_after_hwframe+0x49/0xbe In the observed situation, the problem is seen because the codec driver failed to probe due to a hardware problem. max98090 i2c-193C9890:00: Failed to read device revision: -1 max98090 i2c-193C9890:00: ASoC: failed to probe component -1 cht-bsw-max98090 cht-bsw-max98090: ASoC: failed to instantiate card -1 cht-bsw-max98090 cht-bsw-max98090: snd_soc_register_card failed -1 cht-bsw-max98090: probe of cht-bsw-max98090 failed with error -1 The problem is similar to the problem solved with commit 2fc995a8 ("ASoC: intel: Fix crash at suspend/resume without card registration"), but codec registration fails at a later point. At that time, the pointer checked with the above mentioned commit is already set, but it is not cleared if the device is subsequently removed. Adding a remove function to clear the pointer fixes the problem. Cc: stable@vger.kernel.org Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com> Cc: Curtis Malainey <cujomalainey@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 22 Mar, 2019 3 commits
-
-
Takashi Iwai authored
ca0132 codec driver loads the firmware selectively depending on the model in addition to the fallback of the default firmware. The code works good, but a minor problem is that the current code seems confusing for Clang where it spews a warning about uninitialized variable. This patch simplifies the code flow for such a false-positive warning. After this refactoring, the ca0132_spec.alt_firmware_present field is no longer used, hence it's eliminated as well. Reported-and-tested-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM OSS emulation converts and transfers the data on the fly via "plugins". The data is converted over the dynamically allocated buffer for each plugin, and recently syzkaller caught OOB in this flow. Although the bisection by syzbot pointed out to the commit 65766ee0 ("ALSA: oss: Use kvzalloc() for local buffer allocations"), this is merely a commit to replace vmalloc() with kvmalloc(), hence it can't be the cause. The further debug action revealed that this happens in the case where a slave PCM doesn't support only the stereo channels while the OSS stream is set up for a mono channel. Below is a brief explanation: At each OSS parameter change, the driver sets up the PCM hw_params again in snd_pcm_oss_change_params_lock(). This is also the place where plugins are created and local buffers are allocated. The problem is that the plugins are created before the final hw_params is determined. Namely, two snd_pcm_hw_param_near() calls for setting the period size and periods may influence on the final result of channels, rates, etc, too, while the current code has already created plugins beforehand with the premature values. So, the plugin believes that channels=1, while the actual I/O is with channels=2, which makes the driver reading/writing over the allocated buffer size. The fix is simply to move the plugin allocation code after the final hw_params call. Reported-by: syzbot+d4503ae45b65c5bc1194@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Jian-Hong Pan authored
The ASUS X430UN and X512DK with ALC256 cannot detect the headset MIC until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied. Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Daniel Drake <drake@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-