- 20 Dec, 2019 1 commit
-
-
Johan Hovold authored
Make sure to check the return value of usb_altnum_to_altsetting() to avoid dereferencing a NULL pointer when the requested alternate settings is missing. The format altsetting number may come from a quirk table and there does not seem to be any other validation of it (the corresponding index is checked however). Fixes: b099b969 ("ALSA: usb-audio: Avoid superfluous usb_set_interface() calls") Cc: stable <stable@vger.kernel.org> # 4.18 Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191220093134.1248-1-johan@kernel.orgSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
- 19 Dec, 2019 1 commit
-
-
Kailang Yang authored
Chrome machine had humming noise from external speaker plugin at codec D3 state. Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/2692449396954c6c968f5b75e2660358@realtek.comSigned-off-by:
-
- 18 Dec, 2019 1 commit
-
-
Hui Wang authored
Recently we found the headset-mic on the Dell Dock WD19 doesn't work anymore after s3 (s2i or deep), this problem could be workarounded by closing (pcm_close) the app and then reopening (pcm_open) the app, so this bug is not easy to be detected by users. When problem happens, retire_capture_urb() could still be called periodically, but the size of captured data is always 0, it could be a firmware bug on the dock. Anyway I found after resuming, the snd_usb_pcm_prepare() will be called, and if we forcibly run set_format() to set the interface and its endpoint, the capture size will be normal again. This problem and workaound also apply to playback. To fix it in the kernel, add a quirk to let set_format() run forcibly once after resume. Signed-off-by:
Hui Wang <hui.wang@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191218132650.6303-1-hui.wang@canonical.comSigned-off-by:
-
- 17 Dec, 2019 1 commit
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.5-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.5 A collection of fixes since the merge window, mostly driver specific but there's a few in the core that clean up fallout from the refactorings done in the last cycle.
-
- 16 Dec, 2019 2 commits
-
-
Takashi Iwai authored
We made the error message for the CORB/RIRB communication clearer by upgrading to dev_WARN() so that user can notice better. But this struck us like a boomerang: now it caught syzbot and reported back as a fatal issue although it's not really any too serious bug that worth for stopping the whole system. OK, OK, let's be softy, downgrade it to the standard dev_err() again. Fixes: dd65f7e1 ("ALSA: hda - Show the fatal CORB/RIRB error more clearly") Reported-by: syzbot+b3028ac3933f5c466389@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20191216151224.30013-1-tiwai@suse.deSigned-off-by:
-
Shengjiu Wang authored
According to user manual, it is required that FLL_LAMBDA > 0 in all cases (Integer and Franctional modes). Fixes: 9a76f1ff ("ASoC: Add initial WM8962 CODEC driver") Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/1576065442-19763-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 14 Dec, 2019 5 commits
-
-
Takashi Iwai authored
The commit e38e486d ("ALSA: hda: Modify stream stripe mask only when needed") tried to address the regression by the unconditional application of the stripe mask, but this caused yet another regression for the previously working devices. Namely, the patch clears the azx_dev->stripe flag at snd_hdac_stream_clear(), but this may be called multiple times before restarting the stream, so this ended up with clearance of the flag for the whole time. This patch fixes the regression by moving the azx_dev->stripe flag clearance at the counter-part, the close callback of HDMI codec driver instead. Fixes: e38e486d ("ALSA: hda: Modify stream stripe mask only when needed") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205855 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191214175217.31852-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
CA0132 has the delayed HP jack detection code that is invoked from the unsol handler, but it does a few weird things: it contains the cancel of a work inside the work handler, and yet it misses the cancel-sync call at (runtime-)suspend. This patch addresses those issues. Fixes: 15c2b3cc ("ALSA: hda/ca0132 - Fix possible workqueue stall") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191213085111.22855-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Introduce a timeout to dspio_clear_response_queue() so that it won't be caught in an endless loop even if the hardware doesn't respond properly. Fixes: a73d511c ("ALSA: hda/ca0132: Add unsol handler for DSP and jack detection") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191213085111.22855-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
We need to keep power on while processing the DSP response via unsol event. Each snd_hda_codec_read() call does the power management, so it should work normally, but still it's safer to keep the power up for the whole function. Fixes: a73d511c ("ALSA: hda/ca0132: Add unsol handler for DSP and jack detection") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191213085111.22855-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The current PCM code doesn't initialize explicitly the buffers allocated for PCM streams, hence it might leak some uninitialized kernel data or previous stream contents by mmapping or reading the buffer before actually starting the stream. Since this is a common problem, this patch simply adds the clearance of the buffer data at hw_params callback. Although this does only zero-clear no matter which format is used, which doesn't mean the silence for some formats, but it should be OK because the intention is just to clear the previous data on the buffer. Reported-by:
Lionel Koenig <lionel.koenig@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191211155742.3213-1-tiwai@suse.deSigned-off-by:
-
- 11 Dec, 2019 1 commit
-
-
Hui Wang authored
After applying the fixup ALC274_FIXUP_DELL_AIO_LINEOUT_VERB, the Line-out jack works well. And instead of adding a new set of pin definition in the pin_fixup_tbl, we put a more generic matching entry in the fallback_pin_fixup_tbl. Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 10 Dec, 2019 8 commits
-
-
Lukas Wunner authored
Nicholas Johnson reports a null pointer deref as well as a refcount underflow upon hot-removal of a Thunderbolt-attached AMD eGPU. He's bisected the issue down to commit 586bc4aa ("ALSA: hda/hdmi - fix vgaswitcheroo detection for AMD"). The commit iterates over PCI devices using pci_get_class() and unreferences each device found, even though pci_get_class() subsequently unreferences the device as well. Fix it. Fixes: 586bc4aa ("ALSA: hda/hdmi - fix vgaswitcheroo detection for AMD") Link: https://lore.kernel.org/r/PSXP216MB0438BFEAA0617283A834E11580580@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM/Reported-and-tested-by:
Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Alexander Deucher <alexander.deucher@amd.com> Cc: Bjorn Helgaas <helgaas@kernel.org> Link: https://lore.kernel.org/r/77aa6c01aefe1ebc4004e87b0bc714f2759f15c4.1575985006.git.lukas@wunner.deSigned-off-by:
-
Amery Song authored
On CML boards with the RT5682 headset codec and RT1011 speaker amplifier, the platform firmware exposes three ACPI HIDs (10EC5682, 10EC1011 and MX98357A). The last HID is a mistake in DSDT tables, which causes the wrong machine driver to be loaded. This patch changes the key used to identify boards and changes the order of entries in the table to load the correct machine driver. The order does matter and should not be modified to work-around this firmware issue. Signed-off-by:
Amery Song <chao.song@intel.com> Signed-off-by:
Keyon Jie <yang.jie@linux.intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191210004854.16845-9-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Curtis Malainey authored
Turns out SSP 3-5 are only available on cht, to avoid dumping on undefined registers let's split the definition. Signed-off-by:
Curtis Malainey <cujomalainey@chromium.org> Signed-off-by:
-
Karol Trzcinski authored
An error occurs during parsing more than one ext_data from the mailbox, because of invalid data offset handling. Fix by removing the incorrect duplicate increment of the offset. The return value is also reset in the switch case. This does not change the behavior but improves readability - there is no longer a need to check what the return value of get_ext_windows is. Signed-off-by:
Karol Trzcinski <karolx.trzcinski@linux.intel.com> Signed-off-by:
Bartosz Kokoszko <bartoszx.kokoszko@linux.intel.com> Signed-off-by:
-
Karol Trzcinski authored
Added warning log when found some unknown FW boot ext header, to improve debuggability. Signed-off-by:
-
Daniel Baluta authored
In normal sound case all DAIs are detected as CPU-Codec. simple_dai_link_of supports the presence of a platform but it counts it as a CPU DAI resulting in the creation of an extra link. Adding a platform property to a link description like: simple-audio-card,dai-link { cpu { sound-dai = <&sai1>; }; plat { sound-dai = <&dsp>; }; codec { sound-dai = <&wm8960>; } will result in the creation of two links: * sai1 <-> wm8960 * dsp <-> wm8960 which is obviously not what we want. We just want one single link with: * sai1 <-> wm8960 (and platform set to dsp). Signed-off-by:Daniel Baluta <daniel.baluta@nxp.com> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20191209135353.17427-1-daniel.baluta@nxp.comSigned-off-by:
-
Dragos Tarcatu authored
The return value of soc_tplg_pcm_create() is currently not checked in soc_tplg_pcm_elems_load(). If an error is to occur there, the topology ignores it and continues loading. Fix that by checking the status and rejecting the topology on error. Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by:
Dragos Tarcatu <dragos_tarcatu@mentor.com> Signed-off-by:
-
Dragos Tarcatu authored
snd_soc_add_dai_link() might fail. This situation occurs for instance in a very specific use case where a PCM device and a Back End DAI link are given identical names in the topology. When this happens, soc_new_pcm_runtime() fails and then snd_soc_add_dai_link() returns -ENOMEM when called from soc_tplg_fe_link_create(). Because of that, the link will not get added into the card list, so any attempt to remove it later ends up in a panic. Fix that by checking the return status and free the memory in case of an error. Reviewed-by:
-
- 09 Dec, 2019 4 commits
-
-
Takashi Sakamoto authored
Even if isochronous resources reservation fails, error code doesn't return in pcm.hw_params callback. Cc: <stable@vger.kernel.org> #5.3+ Fixes: 55162d2b ("ALSA: fireface: reserve/release isochronous resources in pcm.hw_params/hw_free callbacks") Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20191209151655.GA8090@workstationSigned-off-by:
-
Takashi Sakamoto authored
Even if isochronous resources reservation fails, error code doesn't return in pcm.hw_params callback. Cc: <stable@vger.kernel.org> #5.3+ Fixes: 4f380d00 ("ALSA: oxfw: configure packet format in pcm.hw_params callback") Signed-off-by:
-
Curtis Malainey authored
There are many paths to soc_free_pcm_runtime which can both have and have not yet inited the workqueue yet. When we flush the queue when we have not yet inited the queue we cause warnings to be printed. An example is soc_cleanup_card_resources which is called by snd_soc_bind_card which has multiple failure points before and after soc_link_init -> soc_new_pcm which is where the queue is inited. Signed-off-by:
-
Takashi Sakamoto authored
Mutex is doubly unlocked in some error path of pcm.open. This commit fixes ALSA firewire-motu driver in Linux kernel v5.5. Reported-by:
kbuild test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 3fd80b20 ("ALSA: firewire-motu: use the same size of period for PCM substream in AMDTP streams") Fixes: 0f5482e7 ("ALSA: firewire-motu: share PCM buffer size for both direction") Signed-off-by:
-
- 08 Dec, 2019 1 commit
-
-
Olof Johansson authored
The loop optimizer seems to go astray here, and produces some warnings that don't seem valid. Still, the code can be simplified -- just clear the whole array at the beginning, and fill in whatever values are valid on the platform. Warnings before this change (GCC 8.2.0 ARM allmodconfig): In file included from ../sound/pci/echoaudio/gina24.c:115: ../sound/pci/echoaudio/echoaudio.c: In function 'snd_echo_vumeters_get': ../sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations] In file included from ../sound/pci/echoaudio/layla24.c:112: ../sound/pci/echoaudio/echoaudio.c: In function 'snd_echo_vumeters_get': ../sound/pci/echoaudio/echoaudio_dsp.c:658:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations] ../sound/pci/echoaudio/echoaudio_dsp.c:647:9: warning: iteration 1073741824 invokes undefined behavior [-Waggressive-loop-optimizations] Signed-off-by:
Olof Johansson <olof@lixom.net> Link: https://lore.kernel.org/r/20191207224953.25944-1-olof@lixom.netSigned-off-by:
-
- 04 Dec, 2019 3 commits
-
-
Takashi Iwai authored
syzkaller reported an invalid access in PCM OSS read, and this seems to be an overflow of the internal buffer allocated for a plugin. Since the rate plugin adjusts its transfer size dynamically, the calculation for the chained plugin might be bigger than the given buffer size in some extreme cases, which lead to such an buffer overflow as caught by KASAN. Fix it by limiting the max transfer size properly by checking against the destination size in each plugin transfer callback. Reported-by: syzbot+f153bde47a62e0b05f83@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191204144824.17801-1-tiwai@suse.deSigned-off-by:
-
Hans de Goede authored
When the Teclast X89 quirk was added we did not have jack-detection support yet. Note the over-current detection limit is set to 2mA instead of the usual 1.5mA because this tablet tends to give false-positive button-presses when it is set to 1.5mA. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Curtis Malainey authored
There are cases where we fail before we reach soc_new_pcm which would init the workqueue. When we fail we attempt to flush the queue which generates warnings from the workqueue subsystem when we have not inited the queue. Solution is to use a proxy function to get around this issue. Signed-off-by:
-
- 03 Dec, 2019 3 commits
-
-
Takashi Iwai authored
The commit 609f5485 ("ALSA: hda: hdmi - preserve non-MST PCM routing for Intel platforms") tried to restore the old behavior wrt assignment of the PCM slot for Intel platforms, but this didn't do it right. As found in the later discussion, a positive pipe id on Intel platforms can be passed for single monitor attachment case. This patch reverts the previous attempt and applies a simpler workaround instead. Actually, for Intel platforms, we can handle as if per_pin->dev_id=0, assign the primary slot at the first try. This assures the compatible behavior with the previous versions regarding the slot assignment. Fixes: 609f5485 ("ALSA: hda: hdmi - preserve non-MST PCM routing for Intel platforms") Link: https://lore.kernel.org/r/20191203154105.30414-1-tiwai@suse.deSigned-off-by:
-
YueHaibing authored
Fix build error: sound/soc/intel/atom/sst/sst.c: In function intel_sst_interrupt_mrfld: sound/soc/intel/atom/sst/sst.c:93:5: error: implicit declaration of function memcpy_fromio; did you mean memcpy32_fromio? [-Werror=implicit-function-declaration] memcpy_fromio(msg->mailbox_data, ^~~~~~~~~~~~~ memcpy32_fromio Reported-by:Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
-
Takashi Iwai authored
The recent commit in HD-audio stream management for changing the stripe control seems causing a regression on some platforms. The stripe control is currently used only by HDMI codec, and applying the stripe mask unconditionally may lead to scratchy and static noises as seen on some MacBooks. For addressing the regression, this patch changes the stream management code to apply the stripe mask conditionally only when the codec driver requested. Fixes: 9b6f7e7a ("ALSA: hda: program stripe bits for controller") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477Tested-by:
Michael Pobega <mpobega@neverware.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191202074947.1617-1-tiwai@suse.deSigned-off-by:
-
- 29 Nov, 2019 3 commits
-
-
Jaroslav Kysela authored
The auto-parser assigns the bass speaker to DAC3 (NID 0x06) which is without the volume control. I do not see a reason to use DAC2, because the shared output to all speakers produces the sufficient and well balanced sound. The stereo support is enough for this purpose (laptop). Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20191129144027.14765-1-perex@perex.czSigned-off-by:
-
Kai Vehmanen authored
Commit 5398e94f ("ALSA: hda - Add DP-MST support for NVIDIA codecs") introduced a slight change of behaviour how non-MST monitors are assigned to PCMs on Intel platforms. In the drm_audio_component.h interface, the third parameter to pin_eld_notify() is pipe number. On Intel platforms, this value is -1 for MST. On other platforms, a non-zero pipe id is used to signal MST use. This difference leads to some subtle differences in hdmi_find_pcm_slot() with regards to how non-MST monitors are assigned to PCMs. This patch restores the original behaviour on Intel platforms while keeping the new allocation policy on other platforms. Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20191129143756.23941-2-kai.vehmanen@linux.intel.comSigned-off-by:
-
Kai Vehmanen authored
Add additional check in hdmi_find_pcm_slot() to not return a pcm index that points to unallocated pcm. This could happen if codec driver is set up in codec->mst_no_extra_pcms mode. On some platforms, this leads to a kernel oops in snd_ctl_notify(), called via update_eld(). BugLink: https://github.com/thesofproject/linux/issues/1536 Fixes: 5398e94f ALSA: hda - Add DP-MST support for NVIDIA codecs Signed-off-by:
-
- 28 Nov, 2019 2 commits
-
-
Takashi Iwai authored
We've added the bass speaker support on Acer 8951G by the commit 00066e97 ("Add Acer Aspire Ethos 8951G model quirk"), but it seems that the GPIO pin was wrongly set: while the commit turns off the bit to power up the amp, the actual hardware reacts other way round, i.e. GPIO bit on = amp on. So this patch fixes the bug, turning on the GPIO bit 0x02 as default. Since turning on the GPIO bit can be more easily managed with alc_setup_gpio() call, we simplify the quirk code by integrating the GPIO setup into the existing alc662_fixup_aspire_ethos_hp() and dropping the whole ALC669_FIXUP_ACER_ASPIRE_ETHOS_SUBWOOFER quirk. Fixes: 00066e97 ("Add Acer Aspire Ethos 8951G model quirk") Reported-and-tested-by:
Sergey 'Jin' Bostandzhyan <jin@mediatomb.cc> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191128202630.6626-1-tiwai@suse.deSigned-off-by:
-
Kailang Yang authored
headphone have noise even the volume is very small. Let it fill up pcbeep hidden register to default value. The issue was gone. Fixes: 4344aec8 ("ALSA: hda/realtek - New codec support for ALC256") Fixes: 736f20a7 ("ALSA: hda/realtek - Add support for ALC236/ALC3204") Signed-off-by:
-
- 27 Nov, 2019 4 commits
-
-
Kai Vehmanen authored
Fix regression in how intel_haswell_fixup_connect_list() results are used in hda_read_pin_conn(). Use of snd_hda_get_raw_connections() in hda_read_pin_conn() bypasses the cache and thus also bypasses the overridden pin connection list. On platforms that require the connection list fixup, mux list will be empty and HDMI playback will fail to -EBUSY at open. Fix the regression in hda_read_pinn_conn(). Simplify code as suggested by Takashi Iwai to remove old intel_haswell_fixup_connect_list() and copy the cvt_nid list directly and not use snd_hda_override_conn_list() at all. Fixes: 9c32fea8 ("ALSA: hda - Add DP-MST support for non-acomp codecs") BugLink: https://github.com/thesofproject/linux/issues/1537 Cc: Nikhil Mahale <nmahale@nvidia.com> Signed-off-by:
-
Tzung-Bi Shih authored
max98090_interrupt() and max98090_pll_work() run in 2 different threads. There are 2 possible races: Note: M98090_REG_DEVICE_STATUS = 0x01. Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked. max98090_interrupt max98090_pll_work ---------------------------------------------- schedule max98090_pll_work restart max98090 codec receive ULK INT assert ULK == 0 schedule max98090_pll_work (1). In the case (1), the PLL is locked but max98090_interrupt unnecessarily schedules another max98090_pll_work. max98090_interrupt max98090_pll_work max98090 codec ---------------------------------------------------------------------- ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) schedule max98090_pll_work restart max98090 codec ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) read 0x01 assert ULK == 0 (2). In the case (2), both max98090_interrupt and max98090_pll_work read the same clear-on-read register. max98090_pll_work would falsely thought PLL is locked. Note: the case (2) race is introduced by the previous commit ("ASoC: max98090: exit workaround earlier if PLL is locked") to check the status and exit the loop earlier in max98090_pll_work. There are 2 possible solution options: A. turn off ULK interrupt before scheduling max98090_pll_work; and turn on again before exiting max98090_pll_work. B. remove the second thread of execution. Option A cannot fix the case (2) race because it still has 2 threads access the same clear-on-read register simultaneously. Although we could suppose the register is volatile and read the status via I2C could be much slower than the hardware raises the bits. Option B introduces a maximum 10~12 msec penalty delay in the interrupt handler. However, it could only punish the jack detection by extra 10~12 msec. Adopts option B which is the better solution overall. Signed-off-by:Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20191122073114.219945-4-tzungbi@google.comReviewed-by:
-
Tzung-Bi Shih authored
According to the datasheet, PLL lock time typically takes 2 msec and at most takes 7 msec. Check the lock status every 1 msec and exit the workaround if PLL is locked. Signed-off-by:
-
Tzung-Bi Shih authored
It was observed Baytrail-based chromebooks could cause continuous PLL unlocked when using playback stream and capture stream simultaneously. Specifically, starting a capture stream after started a playback stream. As a result, the audio data could corrupt or turn completely silent. As the datasheet suggested, the maximum PLL lock time should be 7 msec. The workaround resets the codec softly by toggling SHDN off and on if PLL failed to lock for 10 msec. Notably, there is no suggested hold time for SHDN off. On Baytrail-based chromebooks, it would easily happen continuous PLL unlocked if there is a 10 msec delay between SHDN off and on. Removes the msleep(). Signed-off-by:
-
