- 10 Feb, 2020 1 commit
-
-
Arnd Bergmann authored
The ssc audio driver can call into both pdc and dma backends. With the latest rework, the logic to do this in a safe way avoiding link errors was removed, bringing back link errors that were fixed long ago in commit 061981ff ("ASoC: atmel: properly select dma driver state") such as sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio': atmel_ssc_dai.c:(.text+0xac): undefined reference to `atmel_pcm_pdc_platform_register' Fix it this time using Makefile hacks and a comment to prevent this from accidentally getting removed again rather than Kconfig hacks. Fixes: 18291410 ("ASoC: atmel: enable SOC_SSC_PDC and SOC_SSC_DMA in Kconfig") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Link: https://lore.kernel.org/r/20200130130545.31148-1-codrin.ciubotariu@microchip.comReviewed-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
Mark Brown <broonie@kernel.org>
-
- 06 Feb, 2020 1 commit
-
-
Oleksandr Suvorov authored
If the imx-sdma driver is built as a module, the fsl-sai device doesn't disable on probing failure, which causes the warning in the next probing: ================================================================== fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable! fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable! fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable! fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable! fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable! fsl-sai 308a0000.sai: Unbalanced pm_runtime_enable! ================================================================== Disabling the device properly fixes the issue. Fixes: 812ad463 ("ASoC: fsl_sai: Add support for runtime pm") Signed-off-by:
Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Link: https://lore.kernel.org/r/20200205160436.3813642-1-oleksandr.suvorov@toradex.comSigned-off-by:
-
- 05 Feb, 2020 1 commit
-
-
Geert Uytterhoeven authored
Just adding a dependency on COMMON_CLK to SND_SOC_WCD934X is not sufficient, as enabling SND_SOC_ALL_CODECS will still select it, breaking the build later: WARNING: unmet direct dependencies detected for SND_SOC_WCD934X Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && COMMON_CLK [=n] && MFD_WCD934X [=m] Selected by [m]: - SND_SOC_ALL_CODECS [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && COMPILE_TEST [=y] && MFD_WCD934X [=m] ... ERROR: "of_clk_add_provider" [sound/soc/codecs/snd-soc-wcd934x.ko] undefined! ERROR: "of_clk_src_simple_get" [sound/soc/codecs/snd-soc-wcd934x.ko] undefined! ERROR: "clk_hw_register" [sound/soc/codecs/snd-soc-wcd934x.ko] undefined! ERROR: "__clk_get_name" [sound/soc/codecs/snd-soc-wcd934x.ko] undefined! Fix this by adding the missing dependency to SND_SOC_ALL_CODECS Fixes: 42b71635 ("ASoC: wcd934x: Add missing COMMON_CLK dependency") Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/20200204131857.7634-1-geert@linux-m68k.orgSigned-off-by:
-
- 04 Feb, 2020 2 commits
-
-
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:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200204111241.6927-1-srinivas.kandagatla@linaro.orgSigned-off-by:
-
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.comSigned-off-by:
-
- 02 Feb, 2020 2 commits
-
-
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.comSigned-off-by:
-
- 29 Jan, 2020 5 commits
-
-
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 <tiwai@suse.de> Link: https://lore.kernel.org/r/20200127192831.14057-5-tiwai@suse.deSigned-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.comSigned-off-by:
-
- 27 Jan, 2020 10 commits
-
-
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:
Kai Vehmanen <kai.vehmanen@linux.intel.com> 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.comSigned-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/1642Signed-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:
-
- 24 Jan, 2020 2 commits
-
-
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/845Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Link: https://lore.kernel.org/r/20200124155750.33753-1-natechancellor@gmail.comSigned-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.comSigned-off-by:
-
- 23 Jan, 2020 9 commits
-
-
Kuninori Morimoto authored
All rtd->dai_link callback functions are controlled by soc_rtd_xxxx(), and checking rtd->dai_link->ops. We don't need to have null_snd_soc_ops anymore. This patch removes it. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87zhegl3oz.wl-kuninori.morimoto.gx@renesas.comReviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
-
Kuninori Morimoto authored
Add soc_rtd_trigger() to make the code easier to read Signed-off-by:
-
Kuninori Morimoto authored
Add soc_rtd_hw_free() to make the code easier to read Signed-off-by:
-
Kuninori Morimoto authored
Add soc_rtd_hw_params() to make the code easier to read Signed-off-by:
-
Kuninori Morimoto authored
Add soc_rtd_prepare() to make the code easier to read Signed-off-by:
-
Kuninori Morimoto authored
Add soc_rtd_shutdown() to make the code easier to read Signed-off-by:
-
Kuninori Morimoto authored
Add soc_rtd_startup() to make the code easier to read Signed-off-by:
-
Jack Yu authored
This is initial amplifier driver for rt1015. Signed-off-by:
Jack Yu <jack.yu@realtek.com> Link: https://lore.kernel.org/r/20200115112519.22050-1-jack.yu@realtek.comSigned-off-by:
-
Charles Keepax authored
Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200122104559.17043-1-ckeepax@opensource.cirrus.comSigned-off-by:
-
- 21 Jan, 2020 7 commits
-
-
Jeff Chang authored
The MT6660 is a boosted BTL class-D amplifier with V/I sensing. A built-in DC-DC step-up converter is used to provide efficient power for class-D amplifier with multi-level class-G operation. The digital audio interface supports I2S, left-justified, right-justified, TDM and DSP A/B format for audio in with a data out used for chip information like voltage sense and current sense, which are able to be monitored via DATAO through proper Signed-off-by:
Jeff Chang <jeff_chang@richtek.com> Link: https://lore.kernel.org/r/1579153597-23286-1-git-send-email-richtek.jeff.chang@gmail.comSigned-off-by:
-
Matthias Brugger authored
The rt5645 and rt5650 have two suppliers, document them. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20200114150151.8537-1-matthias.bgg@kernel.orgSigned-off-by:
-
Tzung-Bi Shih authored
Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers SHDN bit") uses dapm_mutex to protect SHDN bit. However, snd_soc_dapm_put_enum_double() in max98090_dapm_put_enum_double() acquires the dapm_mutex again which cause a deadlock. Use snd_soc_dapm_put_enum_double_locked() instead to fix the deadlock. Fixes: 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers SHDN bit") Signed-off-by:
-
Tzung-Bi Shih authored
Adds snd_soc_dapm_put_enum_double_locked() for those use cases if dapm_mutex has already locked. Signed-off-by:
-
Tzung-Bi Shih authored
Commit 2dc98af6 ("ASoC: max98090: fix lockdep warning") introduced a helpful-less small lock: shdn_lock. Reverts the commit. Reasons: 1. Lockdep should not be happy by either the original or current code. From lockdep's point of view, there is a lock inversion anyway. Let d = dapm_mutex, c = controls_rwsem, s = shdn_lock, From the reported calling stack: lock acquisition order of snd_soc_register_card() is: d -> c. > snd_ctl_add_replace+0x3c/0x84 > dapm_create_or_share_kcontrol+0x24c/0x2e0 > snd_soc_dapm_new_widgets+0x308/0x594 > snd_soc_bind_card+0x80c/0xad4 > devm_snd_soc_register_card+0x34/0x6c If calling snd_soc_dapm_put_enum_double() in kcontrol's put (e.g. SOC_DAPM_ENUM_EXT), lock acquisition order is: c -> d. Note that, snd_soc_dapm_put_enum_double() acquires d. The possible lock inversion is always there if registering sound card and putting mixer control happen at the same time. In fact, it never happens because the control device don't show up to the userspace until the sound card build success. Commit 2dc98af6 ("ASoC: max98090: fix lockdep warning") changes the order to: c -> s -> d. The lock inversion is still there. 2. Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers SHDN bit") designed to use dapm_mutex to protect SHDN bit. Use a separate lock breaks the protection. DAPM changes SHDN bit automatically when it finds the path. Thus, any code wants to change the SHDN bit, need to acquire the dapm_mutex first. > SND_SOC_DAPM_SUPPLY("SHDN", M98090_REG_DEVICE_SHUTDOWN, > M98090_SHDNN_SHIFT, 0, NULL, 0), Fixes: 2dc98af6 ("ASoC: max98090: fix lockdep warning") Signed-off-by:
-
Kuninori Morimoto authored
Now, snd_soc_dai_driver::bus_control is used for how to resume. But, no driver which has bus_control has DAI driver suspend/resume support. This patch removes pointless bus_control from ALSA SoC. Signed-off-by:
-
Kuninori Morimoto authored
Historically, CPU and Codec were implemented different, but now it is merged as Component. ALSA SoC is supporting suspend/resume at DAI and Component level. The method is like below. 1) Suspend/Resume all CPU DAI if bus-control was 0 2) Suspend/Resume all Component 3) Suspend/Resume all CPU DAI if bus-control was 1 Historically 2) was Codec special operation. Because CPU and Codec were merged into Component, CPU suspend/resume has 3 chance to suspend(= 1/2/3), but Codec suspend/resume has 1 chance (= 2). Here, DAI side suspend/resume is caring bus-control, but no driver which is supporting suspend/resume is setting bus-control. This means 3) was never used. Here, used parameter for suspend/resume component->dev and dai->dev are same pointer. For that reason, we can merge DAI and Component suspend/resume. One note is that we should use 2), because it is caring BIAS level. This patch removes 1) and 3). Signed-off-by:
-
