- 06 Mar, 2020 3 commits
-
-
Takashi Iwai authored
The struct s1810c_state_packet contains the array in the first field hence zero-initialization requires a more couple of braces. Fix the compile warning pointing it out: sound/usb/mixer_s1810c.c: In function 'snd_sc1810c_get_status_field': sound/usb/mixer_s1810c.c:178:9: warning: missing braces around initializer [-Wmissing-braces] Reported-by:
kbuild test robot <lkp@intel.com> Fixes: 8dc5efe3 ("ALSA: usb-audio: Add support for Presonus Studio 1810c") Link: https://lore.kernel.org/r/202002210251.WgMfvKJP%lkp@intel.com Link: https://lore.kernel.org/r/20200306081231.7940-1-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Alexander Tsoy authored
MicroBook IIc operates in UAC2 mode by default. This patch addresses several issues with it: - MicroBook II and IIc shares the same USB ID. We can distinguish them by interface class. - MaxPacketsOnly attribute is erroneously set in endpoint descriptors. As a result this card produces noise with all sample rates other than 96 KHz. This also causes issues like IOMMU page faults and other problems with host controller. - Sample rate changes takes more than 2 seconds for this device. Clock validity request returns false during that period, so the clock validity quirk is required. Signed-off-by:
Alexander Tsoy <alexander@tsoy.me> Link: https://lore.kernel.org/r/20200229151815.14199-1-alexander@tsoy.meSigned-off-by:
-
Randy Dunlap authored
Fix gcc warnings when -Wextra is used by using an empty do-while block instead of <nothing>. Fixes these build warnings: ../sound/pci/korg1212/korg1212.c:674:44: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:708:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:730:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:853:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:1013:44: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:1035:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:1052:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:1066:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:1087:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:1094:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:1208:43: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../sound/pci/korg1212/korg1212.c:2360:102: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/91fb1e97-a773-5790-3f65-8198403341e1@infradead.orgSigned-off-by:
-
- 17 Feb, 2020 3 commits
-
-
Takashi Iwai authored
Merging the UAC2 effect unit parser improvement. As it's based on the previous usb-audio driver fix, it was deviated from for-next branch. Signed-off-by: -
Takashi Iwai authored
During parsing the input source, we currently cut off at the Effect Unit node without parsing further its source id. It's no big problem, so far, but it should be more consistent to parse it properly. This patch adds the recursive parsing in parse_term_effect_unit(). It doesn't add anything in the audio unit parser itself, and the effect unit itself is still skipped, though. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206147 Link: https://lore.kernel.org/r/20200213112059.18745-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The UAC2 Effect Unit Descriptor has a slightly different definition from other similar ones like Processing Unit or Extension Unit. Define it here so that it can be used in USB-audio driver in a later patch. Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20200213112059.18745-2-tiwai@suse.deSigned-off-by:
-
- 15 Feb, 2020 1 commit
-
-
Nick Kossifidis authored
This patch adds support for Presonus Studio 1810c, a usb interface that's UAC2 compliant with a few quirks and a few extra hw-specific controls. I've tested all 3 altsettings and the added switch controls and they work as expected. More infos on the card: https://www.presonus.com/products/Studio-1810c Note that this work is based on packet inspection with usbmon. I just wanted to get this card to work for using it on our open-source radio station: https://github.com/UoC-Radio v2 address issues reported by Takashi: * Properly get/set enum type controls * Prevent race condition on switch_get/set * Various control naming changes * Various coding style fixes v3 improve readability of sample rate filtering and some other minor changes. Signed-off-by:
Nick Kossifidis <mickflemm@gmail.com> Link: https://lore.kernel.org/r/5e47481a.1c69fb81.befb3.8dac@mx.google.comSigned-off-by:
-
- 14 Feb, 2020 5 commits
-
-
Takashi Iwai authored
ALSA PCM OSS layer calls the generic __snd_pcm_lib_xfer() helper for the actual transfer of the audio data. The xfer helper may sleep long for waiting for the enough space becoming empty for read/write, and it does unlock/relock for the substream lock. This works fine, so far, but a slight problem specific to OSS layer is that OSS layer wraps yet more mutex (runtime->oss.params_lock) over __snd_pcm_lib_xfer() call; so this mutex is still locked during a possible long sleep, and it prevents the whole ioctl and other actions applied to the given stream. This patch adds the temporarily unlock and relock of the mutex around __snd_pcm_lib_xfer() call in the OSS layer to be more friendly to the concurrent accesses. The long mutex protection itself shouldn't be a real issue for the normal systems, and its influence appears only on strange things like fuzzers. Link: https://lore.kernel.org/r/20200214171643.26212-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The rawmidi state flags (opened, append, active_sensing) are stored in bit fields that can be potentially racy when concurrently accessed without any locks. Although the current code should be fine, there is also no any real benefit by keeping the bitfields for this kind of short number of members. This patch changes those bit fields flags to the simple bool fields. There should be no size increase of the snd_rawmidi_substream by this change. Reported-by: syzbot+576cc007eb9f2c968200@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20200214111316.26939-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
snd_seq_check_queue() passes the current tick and time of the given queue as a pointer to snd_seq_prioq_cell_out(), but those might be updated concurrently by the seq timer update. Fix it by retrieving the current tick and time via the proper helper functions at first, and pass those values to snd_seq_prioq_cell_out() later in the loops. snd_seq_timer_get_cur_time() takes a new argument and adjusts with the current system time only when it's requested so; this update isn't needed for snd_seq_check_queue(), as it's called either from the interrupt handler or right after queuing. Also, snd_seq_timer_get_cur_tick() is changed to read the value in the spinlock for the concurrency, too. Reported-by: syzbot+fd5e0eaa1a32999173b2@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20200214111316.26939-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The queue flags are represented in bit fields and the concurrent access may result in unexpected results. Although the current code should be mostly OK as it's only reading a field while writing other fields as KCSAN reported, it's safer to cover both with a proper spinlock protection. This patch fixes the possible concurrent read by protecting with q->owner_lock. Also the queue owner field is protected as well since it's the field to be protected by the lock itself. Reported-by: syzbot+65c6c92d04304d0a8efc@syzkaller.appspotmail.com Reported-by: syzbot+e60ddfa48717579799dd@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20200214111316.26939-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Some USB-audio descriptors provide a bogus volume range (e.g. volume min and max are identical), which confuses user-space. This patch makes the driver skipping such a control element. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206221 Link: https://lore.kernel.org/r/20200214144928.23628-1-tiwai@suse.deSigned-off-by:
-
- 13 Feb, 2020 2 commits
-
-
Takashi Iwai authored
The commit 66f2d19f ("ALSA: pcm: Fix memory leak at closing a stream without hw_free") tried to fix the regression wrt the missing hw_free call at closing without SNDRV_PCM_IOCTL_HW_FREE ioctl. However, the code change dropped mistakenly the state check, resulting in calling hw_free twice when SNDRV_PCM_IOCTL_HW_FRE got called beforehand. For most drivers, this is almost harmless, but the drivers like SOF show another regression now. This patch adds the state condition check before calling do_hw_free() at releasing the stream for avoiding the double hw_free calls. Fixes: 66f2d19f ("ALSA: pcm: Fix memory leak at closing a stream without hw_free") Reported-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Reported-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Tested-by:
-
Alexander Tsoy authored
It should be safe to ignore clock validity check result if the following conditions are met: - only one single sample rate is supported; - the terminal is directly connected to the clock source; - the clock type is internal. This is to deal with some Denon DJ controllers that always reports that clock is invalid. Tested-by:
Tobias Oszlanyi <toszlanyi@yahoo.de> Signed-off-by:
-
- 12 Feb, 2020 6 commits
-
-
Takashi Iwai authored
MSI-GL73 laptop with ALC1220 codec requires a similar workaround for Clevo laptops to enforce the DAC/mixer connection path. Set up a quirk entry for that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204159 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200212081047.27727-1-tiwai@suse.deSigned-off-by:
-
Kailang Yang authored
Add supported Headset Button for ALC215/ALC285/ALC289. Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/948f70b4488f4cc2b629a39ce4e4be33@realtek.comSigned-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200211200739.GA12948@embeddedorSigned-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:
-
- 11 Feb, 2020 3 commits
-
-
Arvind Sankar authored
The Audioengine D1 (0x2912:0x30c8) does support reading the sample rate, but it returns the rate in byte-reversed order. When setting sampling rate, the driver produces these warning messages: [168840.944226] usb 3-2.2: current rate 4500480 is different from the runtime rate 44100 [168854.930414] usb 3-2.2: current rate 8436480 is different from the runtime rate 48000 [168905.185825] usb 3-2.1.2: current rate 30465 is different from the runtime rate 96000 As can be seen from the hexadecimal conversion, the current rate read back is byte-reversed from the rate that was set. 44100 == 0x00ac44, 4500480 == 0x44ac00 48000 == 0x00bb80, 8436480 == 0x80bb00 96000 == 0x017700, 30465 == 0x007701 Rather than implementing a new quirk to reverse the order, just skip checking the rate to avoid spamming the log. Signed-off-by:
Arvind Sankar <nivedita@alum.mit.edu> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200211162235.1639889-1-nivedita@alum.mit.eduSigned-off-by:
-
Takashi Iwai authored
We've got a regression report about M-Audio Fast Track C400 device, and the git bisection resulted in the commit e0ccdef9 ("ALSA: usb-audio: Clean up check_input_term()"). This commit was about the rewrite of the input terminal parser, and it's not too obvious from the change what really broke. The answer is: it's the interpretation of UAC2/3 effect units. In the original code, UAC2 effect unit is as if through UAC1 processing unit because both UAC1 PU and UAC2/3 EU share the same number (0x07). The old code went through a complex switch-case fallthrough, finally bailing out in the middle: if (protocol == UAC_VERSION_2 && hdr[2] == UAC2_EFFECT_UNIT) { /* UAC2/UAC1 unit IDs overlap here in an * uncompatible way. Ignore this unit for now. */ return 0; } ... and this special handling was missing in the new code; the new code treats UAC2/3 effect unit as if it were equivalent with the processing unit. Actually, the old code was too confusing. The effect unit has an incompatible unit description with the processing unit, so we shouldn't have dealt with EU in the same way. This patch addresses the regression by changing the effect unit handling to the own parser function. The own parser function makes the clear distinct with PU, so it improves the readability, too. The EU parser just sets the type and the id like the old kernels. Once when the proper effect unit support is added, we can revisit this parser function, but for now, let's keep this simple setup as is. Fixes: e0ccdef9 ("ALSA: usb-audio: Clean up check_input_term()") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206147 Link: https://lore.kernel.org/r/20200211160521.31990-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Jabra Evolve 65 headset appears as if supporting lower rates than 48kHz, but it actually doesn't work but with 48kHz for playback. This patch applies a workaround to enforce the 48kHz like LINE6 devices already did. The workaround is put in a unified helper function, set_fixed_rate(), to be called from both places now. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206149 Link: https://lore.kernel.org/r/20200211111419.5895-1-tiwai@suse.deSigned-off-by:
-
- 10 Feb, 2020 17 commits
-
-
Colin Ian King authored
Variable c is being assigned with the value -1 that is never read, it is assigned a new value in a following while-loop. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200208224206.38540-1-colin.king@canonical.comSigned-off-by:
-
Colin Ian King authored
Variable capture_flag is only ever assigned values, it is never read and hence it is redundant. Remove it. Addresses-Coverity ("Unused value") Signed-off-by: -
Colin Ian King authored
Variable timeout is being assigned with the value 200 that is never read, it is assigned a new value in a following do-loop. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Colin Ian King authored
Variable err is being assigned with a value that is never read, it is assigned a new value in the next statement. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Takashi Iwai authored
Make a common helper for validating the format type. This reduces the number of cast in the code that are needed for suppressing sparse warnings. No functional changes, just minor refactoring. Link: https://lore.kernel.org/r/20200206163945.6797-9-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The new macro can fix the sparse warnings gracefully: sound/core/pcm_dmaengine.c:429:50: warning: restricted snd_pcm_format_t degrades to integer sound/core/pcm_dmaengine.c:429:55: warning: restricted snd_pcm_format_t degrades to integer sound/core/pcm_dmaengine.c:429:79: warning: restricted snd_pcm_format_t degrades to integer No functional changes, just sparse warning fixes. Link: https://lore.kernel.org/r/20200206163945.6797-8-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The parameter bit mask needs often explicit cast with __force, e.g. for the PCM subformat type. Instead of adding __force at each place, which is error prone, this patch introduces a new macro and replaces the all bit shift with it. This fixes the sparse warnings like the following: sound/core/pcm_native.c:2508:30: warning: restricted snd_pcm_access_t degrades to integer No functional changes, just sparse warning fixes. Link: https://lore.kernel.org/r/20200206163945.6797-7-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Simplify the code with the new macros for PCM format type iterations. This fixes the sparse warnings nicely: sound/core/pcm_native.c:2302:26: warning: restricted snd_pcm_format_t degrades to integer sound/core/pcm_native.c:2306:54: warning: incorrect type in argument 1 (different base types) sound/core/pcm_native.c:2306:54: expected restricted snd_pcm_format_t [usertype] format sound/core/pcm_native.c:2306:54: got unsigned int [assigned] k .... No functional changes, just sparse warning fixes. Link: https://lore.kernel.org/r/20200206163945.6797-6-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Simplify the code with the new macros for PCM format type iterations. This fixes the sparse warnings nicely: sound/drivers/dummy.c:906:25: warning: restricted snd_pcm_format_t degrades to integer sound/drivers/dummy.c:908:25: warning: incorrect type in argument 1 (different base types) sound/drivers/dummy.c:908:25: expected restricted snd_pcm_format_t [usertype] format sound/drivers/dummy.c:908:25: got int [assigned] i No functional changes, just sparse warning fixes. Link: https://lore.kernel.org/r/20200206163945.6797-5-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The new macro can fix the sparse warnings gracefully: sound/usb/proc.c:73:31: warning: restricted snd_pcm_format_t degrades to integer sound/usb/proc.c:73:38: warning: restricted snd_pcm_format_t degrades to integer sound/usb/proc.c:73:61: warning: restricted snd_pcm_format_t degrades to integer No functional changes, just sparse warning fixes. Link: https://lore.kernel.org/r/20200206163945.6797-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
snd_pcm_format_t is a strong-typed integer and requires the explicit cast with __force if converted or compared with a normal integer value. Since most of use cases do iterate over all formats and test / set the mask, provide a couple of new helper macros that do the explicit cast. Link: https://lore.kernel.org/r/20200206163945.6797-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Fix sparse warnings about PCM format assignment regarding the strong typed snd_pcm_format_t: sound/drivers/aloop.c:352:45: warning: restricted snd_pcm_format_t degrades to integer sound/drivers/aloop.c:355:39: warning: incorrect type in assignment (different base types) sound/drivers/aloop.c:355:39: expected unsigned int format sound/drivers/aloop.c:355:39: got restricted snd_pcm_format_t [usertype] format sound/drivers/aloop.c:1435:34: warning: incorrect type in assignment (different base types) sound/drivers/aloop.c:1435:34: expected long max sound/drivers/aloop.c:1435:34: got restricted snd_pcm_format_t [usertype] sound/drivers/aloop.c:1565:39: warning: incorrect type in assignment (different base types) sound/drivers/aloop.c:1565:39: expected unsigned int format sound/drivers/aloop.c:1565:39: got restricted snd_pcm_format_t [usertype] Some code in this driver assigns an integer value to snd_pcm_format_t via control API, and they need to be with the explicit cast. No functional changes, just sparse warning fixes. Link: https://lore.kernel.org/r/20200206163945.6797-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Fixes the sparse warnings. The cast to __user pointer needs __force: sound/isa/sb/emu8000_pcm.c:528:9: warning: cast removes address space '<asn:1>' of expression No functional changes, just sparse warning fixes. Link: https://lore.kernel.org/r/20200206163152.6073-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The internal page tables are little endian, hence they should be __le32 type. This fixes the relevant sparse warning: sound/pci/emu10k1/emu10k1_main.c:2013:51: warning: incorrect type in assignment (different base types) sound/pci/emu10k1/emu10k1_main.c:2013:51: expected unsigned int [usertype] sound/pci/emu10k1/emu10k1_main.c:2013:51: got restricted __le32 [usertype] No functional changes, just sparse warning fixes. Link: https://lore.kernel.org/r/20200206163152.6073-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
The internal page tables are in little endian, hence they should be __le32 type. This fixes the relevant sparse warnings: sound/pci/via82xx.c:454:60: warning: incorrect type in assignment (different base types) sound/pci/via82xx.c:454:60: expected unsigned int [usertype] sound/pci/via82xx.c:454:60: got restricted __le32 [usertype] .... No functional changes, just sparse warning fixes. Link: https://lore.kernel.org/r/20200206163152.6073-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
This is a final step of the cleanup series: move the HDMI ELD parser call into update_eld() function so that we can unify the calls. The ELD validity check is unified in update_eld(), too. Along with it, the repoll scheduling is moved to update_eld() as well, where sync_eld_via_acomp() just passes 0 for skipping it. Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Nikhil Mahale <nmahale@nvidia.com> Link: https://lore.kernel.org/r/20200206162804.4734-5-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
For improving the readability, move the runtime PM handling code from hdmi_present_sense() to hdmi_present_sense_via_verbs(). Now hdmi_present_sense() became symmetric for both audio-component and legacy cases. Just a minor code refactoring. Reviewed-by:
-
