- 30 Jul, 2018 2 commits
-
-
Takashi Iwai authored
The trigger flag in vmidi object can be referred in different contexts concurrently, hence it's better to be put with READ_ONCE() and WRITE_ONCE() macros to assure the accesses. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The virmidi sequencer stuff tries to translate the rawmidi bytes to sequencer events and deliver the packets at trigger callback. The amount of the whole process of these translations and deliveries depends on the incoming rawmidi bytes, and we have no limit for that; this was the cause of a CPU soft lockup that had been reported and fixed recently. Although we've fixed the soft lockup by putting the temporary unlock and cond_resched(), it's rather a quick band aid. In this patch, meanwhile, the event parsing and delivery process is offloaded to a dedicated work, and the trigger callback just kicks it off. It has three merits, at least: - The processing is always done in a sleepable context, which can assure the event delivery with non-atomic flag without hackish is_atomic() usage. - Other relevant codes can be simplified, reducing the lines - It makes me happier Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 29 Jul, 2018 2 commits
-
-
Takashi Iwai authored
Pull the latest ALSA sequencer fixes for the further development of virmidi. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Instead of calling mutex_unlock() at each error path multiple times, take the standard goto-and-a-single-unlock approach. This will simplify the code and make easier to find the unbalanced mutex locks. No functional changes, but only the code readability improvement as a preliminary work for further changes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 28 Jul, 2018 2 commits
-
-
Park Ju Hyung authored
On rare occasions, we are still noticing that the internal speaker spitting out spurious noises even after adding the problematic codec to the list. Adding a 10ms artificial delay before rebooting fixes the issue entirely. Patch for Realtek codecs also adds the same amount of delay after entering D3. Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Park Ju Hyung authored
As an equivalent codec with CX20724, CX8200 is also subject to the reboot bug. Late 2017 and 2018 LG Gram and some HP Spectre laptops are known victims to this issue, causing extremely loud noises upon reboot. Now that we know that this bug is subject to multiple codecs, fix the comment as well. Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 27 Jul, 2018 28 commits
-
-
Jia-Ju Bai authored
hw_pll_init(), hw_dac_stop(), hw_dac_start() and hw_adc_init() are never called in atomic context. They call mdelay() to busily wait, which is not necessary. mdelay() can be replaced with msleep(). This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Jia-Ju Bai authored
hw_pll_init(), hw_reset_dac() and hw_card_init() are never called in atomic context. They calls mdelay() to busily wait, which is not necessary. mdelay() can be replaced with msleep(). This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Jia-Ju Bai authored
snd_usb_select_mode_quirk(), snd_usb_set_interface_quirk() and snd_usb_ctl_msg_quirk() are never called in atomic context. They call mdelay() to busily wait, which is not necessary. mdelay() can be replaced with msleep() and usleep_range(). This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The data types defined in SB CSP driver code are all in little-endian, hence the proper type like __le32 should be used. Spotted by sparse, a warning like: sound/isa/sb/sb16_csp.c:330:14: warning: cast to restricted __le32 Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The DMA address table in atiixp modem driver is in little-endian, hence we should define it with __le32 properly. Spotted by sparse, a warning like: sound/pci/atiixp_modem.c:360:28: warning: incorrect type in assignment (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The DMA address table in atiixp driver is in little-endian, hence we should define it with __le32 properly. Spotted by sparse, a warning like: sound/pci/atiixp.c:393:28: warning: incorrect type in assignment (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The RISC data in bt87x is in little-endian, hence we should define it with __le32 properly. Spotted by sparse, a warning like: sound/pci/bt87x.c:240:17: warning: incorrect type in assignment (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Many data fields defined in echoaudio drivers are in little-endian, hence they should be defined with __le16 or __le32. This makes it easier to catch the forgotten conversions. Spotted by sparse, a warning like: sound/pci/echoaudio/echoaudio_dsp.c:990:36: warning: incorrect type in assignment (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The ASSP data passed to maestro3 driver is in little-endian format, hence the data pointer should be with __le16. Spotted by sparse, warnings like: sound/pci/maestro3.c:2128:35: warning: cast to restricted __le16 Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The BD address tables in intel8x0m driver are in little-endian, hence they should be represented as __le32 instead u32. Spotted by sparse, warnings like: sound/pci/intel8x0m.c:406:40: warning: incorrect type in assignment (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The BD address tables in intel8x0 driver are in little-endian, hence they should be represented as __le32 instead u32. Spotted by sparse, warnings like: sound/pci/intel8x0.c:688:40: warning: incorrect type in assignment (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The BDL entries in lola driver are little-endian while we code them as u32. This leads to sparse warnings like: sound/pci/lola/lola.c:105:40: warning: incorrect type in assignment (different base types) sound/pci/lola/lola.c:105:40: expected unsigned int [unsigned] [usertype] <noident> sound/pci/lola/lola.c:105:40: got restricted __le32 [usertype] <noident> This patch fixes the declarations to the proper __le32 type. Also, there was a typo in the original code, where __user was used that was intended as __iomem. This was caused also by sparse: sound/pci/lola/lola_mixer.c:132:27: warning: incorrect type in assignment (different address spaces) Fixed in this patch as well. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The miXart driver deals with big-endian values as raw data, while it declares most of variables as u32. This leads to sparse warnings like sound/pci/mixart/mixart.c:1203:23: warning: cast to restricted __be32 Fix them by properly defining the structs and add the explicit cast to macros. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The SG descriptor of Riptide contains the little-endian values, hence we need to define with __le32 properly. This fixes sparse warnings like: sound/pci/riptide/riptide.c:1112:40: warning: cast to restricted __le32 Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The BDL pointer used in snd_hdac_dsp_prepare() should be declared as __le32, as warned by sparse: sound/hda/hdac_stream.c:655:47: warning: incorrect type in argument 4 (different base types) sound/hda/hdac_stream.c:655:47: expected restricted __le32 [usertype] **bdlp sound/hda/hdac_stream.c:655:47: got unsigned int [usertype] **<noident> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The TLB entries in Trident driver are represented in little-endian, hence they should be declared as __le32. This patch fixes the sparse warnings like: sound/pci/trident/trident_memory.c:226:17: warning: incorrect type in assignment (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The bank values are all little-endians, so they should be defined with __le32. This fixes lots of sparse warnings like: sound/pci/ymfpci/ymfpci_main.c:315:23: warning: cast to restricted __le32 sound/pci/ymfpci/ymfpci_main.c:342:32: warning: incorrect type in assignment (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The open codes with the bit shift in xen_snd_front_alsa.c give sparse warnings as the PCM format type is with __bitwise. There is already a standard macro to get the format bits, so let's use it instead. This fixes sparse warnings like: sound/xen/xen_snd_front_alsa.c:191:47: warning: restricted snd_pcm_format_t degrades to integer Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM format type is with __bitwise, and it can't be converted from integer implicitly. Instead of an ugly cast, declare the function argument of snd_sb_csp_autoload() with the proper snd_pcm_format_t type. This fixes the sparse warnings like: sound/isa/sb/sb16_csp.c:743:22: warning: restricted snd_pcm_format_t degrades to integer Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM format type in snd_pcm_format_t can't be treated as integer implicitly since it's with __bitwise. We have already a helper function to get the bit index of the given type, and use it in each place instead. This fixes sparse warnings like: sound/isa/sb/sb16_main.c:61:44: warning: restricted snd_pcm_format_t degrades to integer Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM format type is with __bitwise, and it can't be converted from integer implicitly. Instead of an ugly cast, declare the function argument of snd_wss_get_format() with the proper snd_pcm_format_t type. This fixes the sparse warnings like: sound/isa/wss/wss_lib.c:551:14: warning: restricted snd_pcm_format_t degrades to integer Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
asihpi driver treats -1 as an own invalid PCM format, but this needs a proper cast with __force prefix since PCM format type is __bitwise. Define a constant with the proper type and use it allover. This fixes sparse warnings like: sound/pci/asihpi/asihpi.c:315:9: warning: incorrect type in initializer (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM format type is with __bitwise, and it can't be converted from integer implicitly. Instead of an ugly cast, declare the function argument of vortex_alsafmt_aspfmt() with the proper snd_pcm_format_t type. This fixes the sparse warning like: sound/pci/au88x0/au88x0_core.c:2778:14: warning: restricted snd_pcm_format_t degrades to integer Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM format type is with __bitwise, and it can't be converted from integer implicitly. Instead of an ugly cast, declare the function argument of snd_ad1816a_get_format() with the proper snd_pcm_format_t type. This fixes the sparse warning like: sound/isa/ad1816a/ad1816a_lib.c:93:14: warning: restricted snd_pcm_format_t degrades to integer Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM format type is with __bitwise, hence it needs the explicit cast with __force. It's ugly, but there is a reason for that cost... This fixes the sparse warning: sound/core/oss/pcm_oss.c:1854:55: warning: incorrect type in argument 1 (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM format type is with __bitwise, hence it needs to be explicitly declared as snd_pcm_format_t, as warned by sparse: sound/pci/riptide/riptide.c:1028:34: warning: incorrect type in argument 1 (different base types) sound/pci/riptide/riptide.c:1028:34: expected restricted snd_pcm_format_t [usertype] format sound/pci/riptide/riptide.c:1028:34: got unsigned char [unsigned] format Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The PCM format type is defined with __bitwise, hence it can't be passed as integer but needs an explicit cast. In this patch, instead of the messy cast flood, define the format argument of snd_hdac_calc_stream_format() to be the proper snd_pcm_format_t type. This fixes sparse warnings like: sound/hda/hdac_device.c:760:38: warning: incorrect type in argument 1 (different base types) Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The virmidi output trigger tries to parse the all available bytes and process sequencer events as much as possible. In a normal situation, this is supposed to be relatively short, but a program may give a huge buffer and it'll take a long time in a single spin lock, which may eventually lead to a soft lockup. This patch simply adds a workaround, a cond_resched() call in the loop if applicable. A better solution would be to move the event processor into a work, but let's put a duct-tape quickly at first. Reported-and-tested-by: Dae R. Jeong <threeearcat@gmail.com> Reported-by: syzbot+619d9f40141d826b097e@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 26 Jul, 2018 6 commits
-
-
Takashi Iwai authored
The meddlesome gcc warns about the possible shortname string in trident driver code: sound/pci/trident/trident.c: In function ‘snd_trident_probe’: sound/pci/trident/trident.c:126:2: warning: ‘strcat’ accessing 17 or more bytes at offsets 36 and 20 may overlap 1 byte at offset 36 [-Wrestrict] strcat(card->shortname, card->driver); It happens since gcc calculates the possible string size from card->driver, but this can't be true since we did set the string just before that, and they are much shorter. For shutting it up, use the exactly same string set to card->driver for strcat() to card->shortname, too. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The cast between user-space and kernel-space needs an explicit __force prefix, but it's missing in many places in emu10k1 driver code. Spotted by sparse as a warning like: sound/pci/emu10k1/emufx.c:529:33: warning: cast removes address space of expression Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The user-copy callbacks in korg1212 driver contain the explicit cast from a user pointer to a kernel pointer, but they missed __force prefix. It's mandatory for converting between them. Spotted by sparse, a warning like: sound/pci/korg1212/korg1212.c:1329:33: warning: cast removes address space of expression Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Instead of open codes, use the standard macros for obtaining the lower and upper 32bit values. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The snd_pcm_lib_read() and snd_pcm_lib_write() inline functions have the explicit cast from a user pointer to a kernel pointer, but they lacks of __force prefix. This fixes sparse warnings like: ./include/sound/pcm.h:1093:47: warning: cast removes address space of expression Fixes: 68541213 ("ALSA: pcm: Direct in-kernel read/write support") Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
Declare snd_usb_feature_unit_ctl properly in mixer.h. Otherwise it's error-prone. This fixes the sparse warning: sound/usb/mixer.c:1464:25: warning: symbol 'snd_usb_feature_unit_ctl' was not declared. Should it be static? Signed-off-by: Takashi Iwai <tiwai@suse.de>
-