August 2018 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 1/3] ASoC: AMD: Make ACP->SYSMEM DMA non circular
by Akshu Agrawal 06 Aug '18

06 Aug '18

In capture case we don't want ACP to SYSMEM dma to be circular. This is because if an in place DSP filter is applied to captured output then circular DMA can overwrite the filter value with stale data. Signed-off-by: Akshu Agrawal <akshu.agrawal(a)amd.com> --- sound/soc/amd/acp-pcm-dma.c | 36 +++++++++++++++++++++++++++++++----- 1 file changed, 31 insertions(+), 5 deletions(-) diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c index 94bcf69..816abd6 100644 --- a/sound/soc/amd/acp-pcm-dma.c +++ b/sound/soc/amd/acp-pcm-dma.c @@ -400,7 +400,7 @@ static void acp_dma_cap_channel_disable(void __iomem *acp_mmio, } /* Start a given DMA channel transfer */ -static void acp_dma_start(void __iomem *acp_mmio, u16 ch_num) +static void acp_dma_start(void __iomem *acp_mmio, u16 ch_num, bool is_circular) { u32 dma_ctrl; @@ -429,8 +429,11 @@ static void acp_dma_start(void __iomem *acp_mmio, u16 ch_num) break; } - /* circular for both DMA channel */ - dma_ctrl |= ACP_DMA_CNTL_0__Circular_DMA_En_MASK; + /* enable for ACP to SRAM DMA channel */ + if (is_circular == true) + dma_ctrl |= ACP_DMA_CNTL_0__Circular_DMA_En_MASK; + else + dma_ctrl &= ~ACP_DMA_CNTL_0__Circular_DMA_En_MASK; acp_reg_write(dma_ctrl, acp_mmio, mmACP_DMA_CNTL_0 + ch_num); } @@ -674,6 +677,7 @@ static int acp_deinit(void __iomem *acp_mmio) /* ACP DMA irq handler routine for playback, capture usecases */ static irqreturn_t dma_irq_handler(int irq, void *arg) { + u16 dscr_idx; u32 intr_flag, ext_intr_status; struct audio_drv_data *irq_data; void __iomem *acp_mmio; @@ -705,6 +709,15 @@ static irqreturn_t dma_irq_handler(int irq, void *arg) if ((intr_flag & BIT(I2S_TO_ACP_DMA_CH_NUM)) != 0) { valid_irq = true; + if (acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_14) == + CAPTURE_START_DMA_DESCR_CH15) + dscr_idx = CAPTURE_END_DMA_DESCR_CH14; + else + dscr_idx = CAPTURE_START_DMA_DESCR_CH14; + config_acp_dma_channel(acp_mmio, ACP_TO_SYSRAM_CH_NUM, dscr_idx, + 1, 0); + acp_dma_start(acp_mmio, ACP_TO_SYSRAM_CH_NUM, false); + snd_pcm_period_elapsed(irq_data->capture_i2ssp_stream); acp_reg_write((intr_flag & BIT(I2S_TO_ACP_DMA_CH_NUM)) << 16, acp_mmio, mmACP_EXTERNAL_INTR_STAT); @@ -712,6 +725,17 @@ static irqreturn_t dma_irq_handler(int irq, void *arg) if ((intr_flag & BIT(I2S_TO_ACP_DMA_BT_INSTANCE_CH_NUM)) != 0) { valid_irq = true; + if (acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_10) == + CAPTURE_START_DMA_DESCR_CH11) + dscr_idx = CAPTURE_END_DMA_DESCR_CH10; + else + dscr_idx = CAPTURE_START_DMA_DESCR_CH10; + config_acp_dma_channel(acp_mmio, + ACP_TO_SYSRAM_BT_INSTANCE_CH_NUM, + dscr_idx, 1, 0); + acp_dma_start(acp_mmio, ACP_TO_SYSRAM_BT_INSTANCE_CH_NUM, + false); + snd_pcm_period_elapsed(irq_data->capture_i2sbt_stream); acp_reg_write((intr_flag & BIT(I2S_TO_ACP_DMA_BT_INSTANCE_CH_NUM)) << 16, @@ -1053,9 +1077,11 @@ static int acp_dma_trigger(struct snd_pcm_substream *substream, int cmd) acp_dma_cap_channel_enable(rtd->acp_mmio, CAP_CHANNEL1); } + acp_dma_start(rtd->acp_mmio, rtd->ch1, true); + } else { + acp_dma_start(rtd->acp_mmio, rtd->ch1, true); + acp_dma_start(rtd->acp_mmio, rtd->ch2, true); } - acp_dma_start(rtd->acp_mmio, rtd->ch1); - acp_dma_start(rtd->acp_mmio, rtd->ch2); ret = 0; break; case SNDRV_PCM_TRIGGER_STOP: -- 1.9.1

3 4

[alsa-devel] A question about period
by Yu-hsuan Hsu 06 Aug '18

06 Aug '18

Hi all, I have a question about the period we set in hw_params. I found different boards may have different explanations about it. I have two guesses about its meaning. 1. The period_size is the size of each hardware's consumption. If we set period size to N, the pcm will consume N frames each time. 2. The period_size is the size to control when hardware call interrupt. If we set period size to N, the pcm consume frames in its step. When the number of frames it consumes more than N, it will call interrupt. We can use snd_pcm_avail function to check the real available frames in the device. If guess 1 is correct, the size of consumption should be fixed. Else, setting period_size is nothing to do with hardware's consumption. I've checked some boards and found that each board has different behavior (Most of them meet guess 2). I'm confuse which one is correct. Thanks!

2 8

Re: [alsa-devel] 答复: 答复: A bug about cache inconsistency report
by Takashi Iwai 06 Aug '18

06 Aug '18

On Thu, 02 Aug 2018 15:59:31 +0200, Hans Hu(SH-RD) wrote: > > > 1. noise relate test: > > When I annotate the return after set_pages_array_wc, then > > set_memory_wc works, noise disappear static void > > __mark_pages_wc(struct azx *chip, struct snd_dma_buffer *dmab, bool > > on) { ... > > set_pages_array_wb(sgbuf->page_table, sgbuf->pages); //return; } > > #endif > > > set_memory_uc() performs __pa() for the given address, and in this case, it's vmapped address. Something bogus in your test, I'm afraid. > > [Hans:] I know __pa() handle the vmapped address is wrong, that why I don't know how to fix the problem, I try this because I see kernel older than 3.7.6. [bogus? pretending to be real or genuine?] no no no, but the noise problem machine(8086:1c20) in another city, I will make sure it again. I meant about the reliability of the test result. Or whether we're heading to a wrong fish. In anyway, which kernel version are you testing? And exactly what is your problem? Which machine, which hardware setup (codec, etc) and which output, and how is the sound backend (PulseAudio or direct ALSA write)? > > And moreover, all Intel chipsets do work with snooping well, AFAIK. > [Hans:] yes, all Intel chipsets do work with snooping well here too. And the problem case here is "non-snoop"+"aplay -D plughw:*.*"+"44.1k 16bit"+"8086:1c20", I will see if I can find more machine do the test. Ah, so you explicitly test with non-snoop mode for this chipset? For what purpose...? > > 2. change *_SG relate test: > > Just followed your proposal > > -snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, > > +snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, > > >OK, you need one more oneliner: > > >diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index a12e594d4e3b..2eaed4956e7f 100644 > >--- a/sound/pci/hda/hda_controller.c > >+++ b/sound/pci/hda/hda_controller.c > >@@ -707,7 +707,7 @@ static const struct snd_pcm_ops azx_pcm_ops = { > >.pointer = azx_pcm_pointer, > >.get_time_info = azx_get_time_info, > >.mmap = azx_pcm_mmap, > >-.page = snd_pcm_sgbuf_ops_page, > >+// .page = snd_pcm_sgbuf_ops_page, > > }; > > > static void azx_pcm_free(struct snd_pcm *pcm) > [Hans :] I did this, and the Oops report as the same. My bad, there are other SG-buffer codes in sound/hda/*, too. So scratch these two oneliners. The only thing you'd need is the big-hammer change (again oneliner :) --- a/sound/core/Kconfig +++ b/sound/core/Kconfig @@ -181,7 +181,7 @@ config SND_VMASTER bool config SND_DMA_SGBUF - def_bool y + def_bool n depends on X86 source "sound/core/seq/Kconfig" > >And, again, please avoid top-posting. > [Hans :] sorry, I didn't understand at first. My mailbox is Outlook, am I right now? Yes, looks better now. thanks, Takashi

2 2

[alsa-devel] ca0132 firmware files
by Connor McAdams 06 Aug '18

06 Aug '18

Hi! I acquired permission from Creative Labs to distribute their firmware in the same fashion as the current Chromebook firmware a month or two ago, but the email had a disclaimer at the bottom saying I couldn't forward or copy the email to anyone else. Anyways, after requesting that the email be sent again without this, they have sent me the following email: >Dear Connor, > >Thank you for your reply. > >Based on your feedback, the updated linux driver is based on Chromebook project has been >accepted in the ALSA tree, which means that the code has been reviewed and approved by ALSA >maintainers. You may follow what has been done on Chromebook's project. The firmware must >remain in ALSA firmware tree and not subjected to GPL. > >If you require further assistance, please reply to this email and we will get back to you. > > >Regards, >Anthony Now, I don't really know what to do with that. I feel as though Creative probably has to initiate sending the firmware themselves, but I'm not sure. Any information on the next step I should take would be very helpful. Thanks, Connor.

1 0

Re: [alsa-devel] ALSA queries
by Chakravarthi Pradeep 05 Aug '18

05 Aug '18

On Sun 5 Aug, 2018, 14:19 Chakravarthi Pradeep, <doubleq7(a)gmail.com> wrote: > Hello Takashi, > > Thanks for your reply. > > periods_min = the minimal number of periods > period_bytes_min = the minimal size of bytes for one period > period_bytes_max = the maximal size of bytes for one period > > > periods_min = the minimal number of periods : what is meaning of > periods , is it minimal number of interrupts ? > period_bytes_min = the minimal size of bytes for one period : it > means, minimal size of bytes per interrupt in case of device, Is it > correct ? > what about period_max ? > > It's most likely the ALSA PCM core's safety stop; your driver seem to > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't > updated, resulting in XRUN. ALSA PCM core checks such XRUN condition > with the own timer. > > I'm attaching my driver thread along with this mail. Can you please > let me know if I have missed something in audio thread. ?. How to make > sure in driver that, trigger stop should be called only when stop > command is sent from application. > > I'm getting cut cut cut ... noise along with audio in VLC application. > Initially for 2 or 4 seconds, cut cut cut noise is not heard in VLC > application, However after almost after 5 sec ,I can hear cut cut cut > noise in VLC application. With my analysis, hwptr is getting updated > properly however I have doubt in app_ptr. I'm attaching the excl sheet > with hw_ptr,app_ptr and buf_pos values. > > How to remove the cut cut cut ... noise in audio ? > > Regards, > Chakravarthi > > On Fri, Aug 3, 2018 at 1:05 PM Takashi Iwai <tiwai(a)suse.de> wrote: > > > > On Thu, 02 Aug 2018 16:31:13 +0200, > > Chakravarthi Pradeep wrote: > > > > > > I'm working on ALSA driver for PCIe card. My ALSA driver and it's > > > initializing struct snd_pcm_hardware with below parameter. > > > > > > /************************ code start > > > ************************************************/ > > > static struct snd_pcm_hardware audio_pcm_hardware = { > > > .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_MMAP | > > > SNDRV_PCM_INFO_MMAP_VALID | > > > SNDRV_PCM_INFO_BLOCK_TRANSFER | > > > SNDRV_PCM_INFO_RESUME ), > > > .formats = (SNDRV_PCM_FORMAT_S16_LE | SNDRV_PCM_FORMAT_S24_LE), > > > .rates = (SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | > > > SNDRV_PCM_RATE_96000 | SNDRV_PCM_RATE_192000), > > > .rate_min = 44100, > > > .rate_max = 192000, > > > .channels_min = 2, > > > .channels_max = 8, > > > .buffer_bytes_max = 76800, /*75 kbytes */ > > > .period_bytes_min = 512,//4410, /* (channel (2) * sample_rate (44100) > > > * bit width (24)) / (60 * 8) */ > > > .period_bytes_max = 16*1024, > > > .periods_min = 10, > > > .periods_max = 255, > > > > > > }; > > > /************************ code end > > > ************************************************/ > > > > > > 1) I did not understand what is significance of periods_min , > > > period_bytes_min , period_bytes_max and periods_max. Can you please > > > tell me what is importance of these parameter and what value should be > > > mentioned according into ALSA. > > > > These three defines the values your hardware may accept: > > periods_min = the minimal number of periods > > period_bytes_min = the minimal size of bytes for one period > > period_bytes_max = the maximal size of bytes for one period > > > > > 2) snd_pcm_ops trigger callback is getting called in the driver when > > > application sends "start" command. But ALSA driver is stopping by > > > itself after one frame is copied to ALSA framework, without waiting > > > for "stop" command. > > > > > > For instance: > > > In trigger callback , I'm getting these logs after one frame is copied. > > > Trigger:Start (When Play button is selected/clicked in application, > > > Start command is sent to ALSA driver) > > > Dma transfer is completed. > > > Trigger:Stop. (When Stop button is selected/clicked in application, > > > Stop command is sent to ALSA driver. But stop button is not clicked in > > > this case) > > > > It's most likely the ALSA PCM core's safety stop; your driver seem to > > have missed snd_pcm_period_elapsed() calls, so the hwptr isn't > > updated, resulting in XRUN. ALSA PCM core checks such XRUN condition > > with the own timer. > > > > > > Takashi > > > > -- > Thanks and Regards > Chakravarthi Pradeep.K > Ph: 91 9980434900 >

1 0

[alsa-devel] Help with TASCAM US-122
by Joseph Spencer 05 Aug '18

05 Aug '18

Hello, I'm on Fedora 28 (Linux localhost.localdomain 4.17.11-200.fc28.x86_64 #1 SMP Mon Jul 30 15:21:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux), and I'm trying to use the TASCAM US-122 Audio/MIDI Interface <https://alsa-project.org/main/index.php/Matrix:Vendor-Tascam>. It seems as though the alsa-firmware package is able to detect the USB device just fine; however, after a few moments my entire system freezes (mouse cursor doesn't move etc.). I'm left to forcefully power off. I'm wondering if anyone can point me in the right direction. I'm comfortable with C (haven't done much kernel development), good with shell scripts, not so familiar with alsa. I'd be more than happy to contribute to hopefully fix this for others and (of course) myself. I had journalctl -f up in a terminal when I plugged in the interface and was able to capture the system logs (in the post script of this email). Any help would be appreciated. Thanks, Joe Spencer 602.777.2307 P.S. Here's the relevant system logs of the issue: Aug 04 03:13:50 localhost.localdomain kernel: usb 3-1: new full-speed USB device number 2 using xhci_hcd Aug 04 03:13:50 localhost.localdomain kernel: usb 3-1: New USB device found, idVendor=1604, idProduct=8006, bcdDevice= 1.00 Aug 04 03:13:50 localhost.localdomain kernel: usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Aug 04 03:13:50 localhost.localdomain /lib/udev/tascam_fw[2834]: load /usr/share/alsa/firmware/usx2yloader/us122fw.ihx for 1604/8006/100 to /dev/bus/usb/003/002 Aug 04 03:13:50 localhost.localdomain /lib/udev/tascam_fw[2837]: load /usr/share/alsa/firmware/usx2yloader/us122fw.ihx for 1604/8006/100 to Aug 04 03:13:50 localhost.localdomain kernel: usb 3-1: USB disconnect, device number 2 Aug 04 03:13:52 localhost.localdomain kernel: usb 3-1: new full-speed USB device number 3 using xhci_hcd Aug 04 03:13:52 localhost.localdomain kernel: usb 3-1: New USB device found, idVendor=1604, idProduct=8007, bcdDevice= 0.01 Aug 04 03:13:52 localhost.localdomain kernel: usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Aug 04 03:13:52 localhost.localdomain /lib/udev/tascam_fpga[2859]: calling /usr/bin/usx2yloader for Aug 04 03:13:52 localhost.localdomain /lib/udev/tascam_fpga[2861]: leaving Aug 04 03:13:52 localhost.localdomain kernel: usbcore: registered new interface driver snd-usb-usx2y Aug 04 03:13:52 localhost.localdomain /lib/udev/tascam_fpga[2864]: calling /usr/bin/usx2yloader for *Aug 04 03:13:54 localhost.localdomain /lib/udev/tascam_fpga[2867]: leaving (this was the last log entry before my screen froze, the following logs were obtained after a reboot with my device disconnected)* Aug 04 03:13:58 localhost.localdomain kernel: BUG: unable to handle kernel paging request at 00000000178f90ca Aug 04 03:13:58 localhost.localdomain kernel: PGD 800000040aa8b067 P4D 800000040aa8b067 PUD 4050d8067 PMD 0 Aug 04 03:13:58 localhost.localdomain kernel: Oops: 0000 [#1] SMP PTI Aug 04 03:13:58 localhost.localdomain kernel: Modules linked in: snd_seq_midi snd_seq_midi_event snd_usb_usx2y snd_usbmidi_lib snd_rawmidi ccm rfcomm fuse vboxnetadp(OE) vboxnetflt(OE) vboxdrv> Aug 04 03:13:58 localhost.localdomain kernel: snd_hwdep snd_seq wmi snd_seq_device snd_pcm snd_timer parport_pc parport snd mei_me soundcore mei dell_rbtn rfkill lpc_ich shpchp dell_smo8800 p> Aug 04 03:13:58 localhost.localdomain kernel: CPU: 1 PID: 1125 Comm: Xorg Tainted: G OE 4.17.11-200.fc28.x86_64 #1 Aug 04 03:13:58 localhost.localdomain kernel: Hardware name: Dell Inc. Latitude E6530/, BIOS A17 08/19/2015 Aug 04 03:13:58 localhost.localdomain kernel: RIP: 0010:__kmalloc_track_caller+0xa2/0x230 Aug 04 03:13:58 localhost.localdomain kernel: RSP: 0018:ffffb4c7c22bfab8 EFLAGS: 00010206 Aug 04 03:13:58 localhost.localdomain kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 Aug 04 03:13:58 localhost.localdomain kernel: RDX: 0000000000004956 RSI: 00000000014000c0 RDI: 0000000000026120 Aug 04 03:13:58 localhost.localdomain kernel: RBP: 00000000014000c0 R08: 00000000178f90ca R09: ffff930a8d803200 Aug 04 03:13:58 localhost.localdomain kernel: R10: ffff930a860b2c00 R11: 0000000000000000 R12: 00000000000000d0 Aug 04 03:13:58 localhost.localdomain kernel: R13: ffffffffc04a7e80 R14: ffff930a8d803200 R15: 00000000178f90ca Aug 04 03:13:58 localhost.localdomain kernel: FS: 00007f11c22baac0(0000) GS:ffff930a9e280000(0000) knlGS:0000000000000000 Aug 04 03:13:58 localhost.localdomain kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Aug 04 03:13:58 localhost.localdomain kernel: CR2: 00000000178f90ca CR3: 0000000406ab4004 CR4: 00000000001606e0 Aug 04 03:13:58 localhost.localdomain kernel: Call Trace: Aug 04 03:13:58 localhost.localdomain kernel: kmemdup+0x17/0x40 Aug 04 03:13:58 localhost.localdomain kernel: intel_plane_duplicate_state+0x20/0x50 [i915] Aug 04 03:13:58 localhost.localdomain kernel: drm_atomic_get_plane_state+0x6a/0x110 [drm] Aug 04 03:13:58 localhost.localdomain kernel: drm_atomic_helper_disable_plane+0x36/0xc0 [drm_kms_helper] Aug 04 03:13:58 localhost.localdomain kernel: __setplane_internal+0x1bd/0x260 [drm] Aug 04 03:13:58 localhost.localdomain kernel: ? sock_wfree+0x3a/0x60 Aug 04 03:13:58 localhost.localdomain kernel: ? unix_destruct_scm+0x80/0xa0 Aug 04 03:13:58 localhost.localdomain kernel: drm_mode_cursor_universal+0x1b7/0x1f0 [drm] Aug 04 03:13:58 localhost.localdomain kernel: drm_mode_cursor_common+0x18b/0x1f0 [drm] Aug 04 03:13:58 localhost.localdomain kernel: ? drm_mode_setplane+0x230/0x230 [drm] Aug 04 03:13:58 localhost.localdomain kernel: drm_mode_cursor_ioctl+0x4d/0x70 [drm] Aug 04 03:13:58 localhost.localdomain kernel: drm_ioctl_kernel+0x5b/0xb0 [drm] Aug 04 03:13:58 localhost.localdomain kernel: drm_ioctl+0x1b3/0x370 [drm] Aug 04 03:13:58 localhost.localdomain kernel: ? drm_mode_setplane+0x230/0x230 [drm] Aug 04 03:13:58 localhost.localdomain kernel: ? timerqueue_add+0x52/0x80 Aug 04 03:13:58 localhost.localdomain kernel: ? selinux_file_ioctl+0x161/0x200 Aug 04 03:13:58 localhost.localdomain kernel: do_vfs_ioctl+0xa4/0x610 Aug 04 03:13:58 localhost.localdomain kernel: ksys_ioctl+0x60/0x90 Aug 04 03:13:58 localhost.localdomain kernel: __x64_sys_ioctl+0x16/0x20 Aug 04 03:13:58 localhost.localdomain kernel: do_syscall_64+0x5b/0x160 Aug 04 03:13:58 localhost.localdomain kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Aug 04 03:13:58 localhost.localdomain kernel: RIP: 0033:0x7f11bf53dec7 Aug 04 03:13:58 localhost.localdomain kernel: RSP: 002b:00007fffa0ee58d8 EFLAGS: 00003246 ORIG_RAX: 0000000000000010 Aug 04 03:13:58 localhost.localdomain kernel: RAX: ffffffffffffffda RBX: 00000000013cc100 RCX: 00007f11bf53dec7 Aug 04 03:13:58 localhost.localdomain kernel: RDX: 00007fffa0ee5910 RSI: 00000000c01c64a3 RDI: 0000000000000010 Aug 04 03:13:58 localhost.localdomain kernel: RBP: 00007fffa0ee5910 R08: 00007f11c2136000 R09: 0000000000000001 Aug 04 03:13:58 localhost.localdomain kernel: R10: 0000000000000780 R11: 0000000000003246 R12: 00000000c01c64a3 Aug 04 03:13:58 localhost.localdomain kernel: R13: 0000000000000010 R14: 000000000124c0d0 R15: 00000000000001cd Aug 04 03:13:58 localhost.localdomain kernel: Code: 50 08 65 4c 03 05 e7 26 da 5e 49 83 78 10 00 4d 8b 38 0f 84 22 01 00 00 4d 85 ff 0f 84 19 01 00 00 45 8b 41 20 49 8b 39 4d 01 f8 <4d> 8b 10 > Aug 04 03:13:58 localhost.localdomain kernel: RIP: __kmalloc_track_caller+0xa2/0x230 RSP: ffffb4c7c22bfab8 Aug 04 03:13:58 localhost.localdomain kernel: CR2: 00000000178f90ca Aug 04 03:13:58 localhost.localdomain kernel: ---[ end trace 59cb442553c1594d ]--- Aug 04 03:13:59 localhost.localdomain abrt-dump-journal-oops[1205]: abrt-dump-journal-oops: Found oopses: 1 Aug 04 03:13:59 localhost.localdomain abrt-dump-journal-oops[1205]: abrt-dump-journal-oops: Creating problem directories Aug 04 03:13:59 localhost.localdomain kernel: BUG: unable to handle kernel paging request at 00000000178f90ca Aug 04 03:13:59 localhost.localdomain kernel: PGD 0 P4D 0 Aug 04 03:13:59 localhost.localdomain kernel: Oops: 0000 [#2] SMP PTI Aug 04 03:13:59 localhost.localdomain kernel: Modules linked in: snd_seq_midi snd_seq_midi_event snd_usb_usx2y snd_usbmidi_lib snd_rawmidi ccm rfcomm fuse vboxnetadp(OE) vboxnetflt(OE) vboxdrv> Aug 04 03:13:59 localhost.localdomain kernel: snd_hwdep snd_seq wmi snd_seq_device snd_pcm snd_timer parport_pc parport snd mei_me soundcore mei dell_rbtn rfkill lpc_ich shpchp dell_smo8800 p> Aug 04 03:13:59 localhost.localdomain kernel: CPU: 1 PID: 1205 Comm: abrt-dump-journ Tainted: G D OE 4.17.11-200.fc28.x86_64 #1 Aug 04 03:13:59 localhost.localdomain kernel: Hardware name: Dell Inc. Latitude E6530/, BIOS A17 08/19/2015 Aug 04 03:13:59 localhost.localdomain kernel: RIP: 0010:kmem_cache_alloc_trace+0x8d/0x1d0 Aug 04 03:13:59 localhost.localdomain kernel: RSP: 0018:ffffb4c7c25dfc60 EFLAGS: 00010206 Aug 04 03:13:59 localhost.localdomain kernel: RAX: 0000000000000000 RBX: 00000000178f90ca RCX: 0000000000000002 Aug 04 03:13:59 localhost.localdomain kernel: RDX: 0000000000004956 RSI: 00000000014080c0 RDI: 0000000000026120 Aug 04 03:13:59 localhost.localdomain kernel: RBP: ffff930a8d803200 R08: ffff930a9e2a6120 R09: 0000000000000000 Aug 04 03:13:59 localhost.localdomain kernel: R10: 0000000000000000 R11: e7825477348aeba9 R12: 00000000014080c0 Aug 04 03:13:59 localhost.localdomain kernel: R13: 00000000000000f8 R14: ffff930a8d803200 R15: 00000000178f90ca Aug 04 03:13:59 localhost.localdomain kernel: FS: 00007f0fd1a99ac0(0000) GS:ffff930a9e280000(0000) knlGS:0000000000000000 Aug 04 03:13:59 localhost.localdomain kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Aug 04 03:13:59 localhost.localdomain kernel: CR2: 00000000178f90ca CR3: 00000004082c2006 CR4: 00000000001606e0 Aug 04 03:13:59 localhost.localdomain kernel: Call Trace: Aug 04 03:13:59 localhost.localdomain kernel: ? full_proxy_open+0xc0/0x1d0 Aug 04 03:13:59 localhost.localdomain kernel: full_proxy_open+0xc0/0x1d0 Aug 04 03:13:59 localhost.localdomain kernel: ? debugfs_create_devm_seqfile+0x80/0x80 Aug 04 03:13:59 localhost.localdomain kernel: do_dentry_open+0x1af/0x2e0 Aug 04 03:13:59 localhost.localdomain kernel: path_openat+0x46e/0x15f0 Aug 04 03:13:59 localhost.localdomain kernel: ? 0xffffffffc02a8000 Aug 04 03:13:59 localhost.localdomain kernel: ? seq_puts+0x3a/0x50 Aug 04 03:13:59 localhost.localdomain kernel: ? __kmalloc_node+0x208/0x2d0 Aug 04 03:13:59 localhost.localdomain kernel: ? seq_read+0x2de/0x460 Aug 04 03:13:59 localhost.localdomain kernel: do_filp_open+0x93/0x100 Aug 04 03:13:59 localhost.localdomain kernel: ? __check_object_size+0x9c/0x171 Aug 04 03:13:59 localhost.localdomain kernel: do_sys_open+0x186/0x210 Aug 04 03:13:59 localhost.localdomain kernel: do_syscall_64+0x5b/0x160 Aug 04 03:13:59 localhost.localdomain kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Aug 04 03:13:59 localhost.localdomain kernel: RIP: 0033:0x7f0fd03b0c9e Aug 04 03:13:59 localhost.localdomain kernel: RSP: 002b:00007ffd7905f8b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 Aug 04 03:13:59 localhost.localdomain kernel: RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f0fd03b0c9e Aug 04 03:13:59 localhost.localdomain kernel: RDX: 0000000000000000 RSI: 000055cf0bd89780 RDI: 00000000ffffff9c Aug 04 03:13:59 localhost.localdomain kernel: RBP: 0000000000000000 R08: 00007f0fd067fc40 R09: 0000000000000007 Aug 04 03:13:59 localhost.localdomain kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Aug 04 03:13:59 localhost.localdomain kernel: R13: 000055cf0d8c5700 R14: 0000000000000003 R15: 000055cf0d936d50 Aug 04 03:13:59 localhost.localdomain kernel: Code: 50 08 65 4c 03 05 7c 5f da 5e 49 83 78 10 00 4d 8b 38 0f 84 10 01 00 00 4d 85 ff 0f 84 07 01 00 00 41 8b 5e 20 49 8b 3e 4c 01 fb <48> 33 1b > Aug 04 03:13:59 localhost.localdomain kernel: RIP: kmem_cache_alloc_trace+0x8d/0x1d0 RSP: ffffb4c7c25dfc60 Aug 04 03:13:59 localhost.localdomain kernel: CR2: 00000000178f90ca Aug 04 03:13:59 localhost.localdomain kernel: ---[ end trace 59cb442553c1594e ]--- Aug 04 03:13:59 localhost.localdomain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=abrt-oops comm="systemd" exe="/usr/lib/system> Aug 04 03:13:59 localhost.localdomain systemd[1]: abrt-oops.service: Main process exited, code=killed, status=9/KILL Aug 04 03:13:59 localhost.localdomain systemd[1]: abrt-oops.service: Failed with result 'signal'. Aug 04 03:15:24 localhost.localdomain chronyd[1036]: Selected source 208.75.89.4 Aug 04 03:15:56 localhost.localdomain systemd-logind[1024]: Power key pressed. Aug 04 03:15:56 localhost.localdomain systemd-logind[1024]: Suspending... Aug 04 03:15:56 localhost.localdomain NetworkManager[1054]: <info> [1533377756.3501] manager: sleep: sleep requested (sleeping: no enabled: yes) Aug 04 03:15:56 localhost.localdomain NetworkManager[1054]: <info> [1533377756.3506] manager: NetworkManager state is now ASLEEP Aug 04 03:15:56 localhost.localdomain NetworkManager[1054]: <info> [1533377756.3510] device (wlp2s0): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed') Aug 04 03:15:56 localhost.localdomain NetworkManager[1054]: <info> [1533377756.3714] device (wlp2s0): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed') Aug 04 03:15:56 localhost.localdomain dbus-daemon[1046]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' request> Aug 04 03:15:56 localhost.localdomain avahi-daemon[1030]: Withdrawing address record for fe80::f3ca:ecd8:3b4f:e72a on wlp2s0. Aug 04 03:15:56 localhost.localdomain avahi-daemon[1030]: Leaving mDNS multicast group on interface wlp2s0.IPv6 with address fe80::f3ca:ecd8:3b4f:e72a. Aug 04 03:15:56 localhost.localdomain avahi-daemon[1030]: Interface wlp2s0.IPv6 no longer relevant for mDNS. Aug 04 03:15:56 localhost.localdomain systemd[1]: Starting Network Manager Script Dispatcher Service... Aug 04 03:15:56 localhost.localdomain kernel: BUG: unable to handle kernel paging request at 00000000178f90ca Aug 04 03:15:56 localhost.localdomain kernel: PGD 0 P4D 0 Aug 04 03:15:56 localhost.localdomain kernel: Oops: 0000 [#3] SMP PTI Aug 04 03:15:56 localhost.localdomain kernel: Modules linked in: snd_seq_midi snd_seq_midi_event snd_usb_usx2y snd_usbmidi_lib snd_rawmidi ccm rfcomm fuse vboxnetadp(OE) vboxnetflt(OE) vboxdrv> Aug 04 03:15:56 localhost.localdomain kernel: snd_hwdep snd_seq wmi snd_seq_device snd_pcm snd_timer parport_pc parport snd mei_me soundcore mei dell_rbtn rfkill lpc_ich shpchp dell_smo8800 p> Aug 04 03:15:56 localhost.localdomain kernel: CPU: 1 PID: 2878 Comm: (spatcher) Tainted: G D OE 4.17.11-200.fc28.x86_64 #1 Aug 04 03:15:56 localhost.localdomain kernel: Hardware name: Dell Inc. Latitude E6530/, BIOS A17 08/19/2015 Aug 04 03:15:56 localhost.localdomain kernel: RIP: 0010:kmem_cache_alloc_trace+0x8d/0x1d0 Aug 04 03:15:56 localhost.localdomain kernel: RSP: 0018:ffffb4c7c261fe68 EFLAGS: 00010206 Aug 04 03:15:56 localhost.localdomain kernel: RAX: 0000000000000000 RBX: 00000000178f90ca RCX: 0000000000000000 Aug 04 03:15:56 localhost.localdomain kernel: RDX: 0000000000004956 RSI: 00000000014080c0 RDI: 0000000000026120 Aug 04 03:15:56 localhost.localdomain kernel: RBP: ffff930a8d803200 R08: ffff930a9e2a6120 R09: 0000555a9cca5d60 Aug 04 03:15:56 localhost.localdomain kernel: R10: fefefefefefefeff R11: 0000000000000fe0 R12: 00000000014080c0 Aug 04 03:15:56 localhost.localdomain kernel: R13: 0000000000000100 R14: ffff930a8d803200 R15: 00000000178f90ca Aug 04 03:15:56 localhost.localdomain kernel: FS: 00007f413dfaae40(0000) GS:ffff930a9e280000(0000) knlGS:0000000000000000 Aug 04 03:15:56 localhost.localdomain kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Aug 04 03:15:56 localhost.localdomain kernel: CR2: 00000000178f90ca CR3: 00000003c9d3e001 CR4: 00000000001606e0 Aug 04 03:15:56 localhost.localdomain kernel: Call Trace: Aug 04 03:15:56 localhost.localdomain kernel: ? do_execveat_common.isra.37+0xeb/0x790 Aug 04 03:15:56 localhost.localdomain kernel: do_execveat_common.isra.37+0xeb/0x790 Aug 04 03:15:56 localhost.localdomain kernel: ? strncpy_from_user+0x4a/0x170 Aug 04 03:15:56 localhost.localdomain kernel: __x64_sys_execve+0x32/0x40 Aug 04 03:15:56 localhost.localdomain kernel: do_syscall_64+0x5b/0x160 Aug 04 03:15:56 localhost.localdomain kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Aug 04 03:15:56 localhost.localdomain kernel: RIP: 0033:0x7f413bc5dde7 Aug 04 03:15:56 localhost.localdomain kernel: RSP: 002b:00007ffc55bb2748 EFLAGS: 00000246 ORIG_RAX: 000000000000003b Aug 04 03:15:56 localhost.localdomain kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f413bc5dde7 Aug 04 03:15:56 localhost.localdomain kernel: RDX: 0000555a9cca5d60 RSI: 0000555a9cd8e4c0 RDI: 0000555a9cd92bc0 Aug 04 03:15:56 localhost.localdomain kernel: RBP: 00007ffc55bb29b0 R08: 000000000000fefe R09: 0000000000000000 Aug 04 03:15:56 localhost.localdomain kernel: R10: 0000555a9cd4a900 R11: 0000000000000246 R12: 0000555a9cd8e4c0 Aug 04 03:15:56 localhost.localdomain kernel: R13: 0000555a9cd933a0 R14: 0000555a9cd93840 R15: 0000000000000000 Aug 04 03:15:56 localhost.localdomain kernel: Code: 50 08 65 4c 03 05 7c 5f da 5e 49 83 78 10 00 4d 8b 38 0f 84 10 01 00 00 4d 85 ff 0f 84 07 01 00 00 41 8b 5e 20 49 8b 3e 4c 01 fb <48> 33 1b > Aug 04 03:15:56 localhost.localdomain kernel: RIP: kmem_cache_alloc_trace+0x8d/0x1d0 RSP: ffffb4c7c261fe68 Aug 04 03:15:56 localhost.localdomain kernel: CR2: 00000000178f90ca Aug 04 03:15:56 localhost.localdomain kernel: ---[ end trace 59cb442553c1594f ]--- Aug 04 03:15:56 localhost.localdomain kernel: wlp2s0: deauthenticating from 84:1b:5e:03:b3:bd by local choice (Reason: 3=DEAUTH_LEAVING) Aug 04 03:15:56 localhost.localdomain kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready Aug 04 03:15:56 localhost.localdomain kernel: BUG: unable to handle kernel paging request at 00000000178f90ca -- Reboot -- Aug 04 03:16:21 localhost.localdomain kernel: microcode: microcode updated early to revision 0x1f, date = 2018-02-07 Aug 04 03:16:21 localhost.localdomain kernel: Linux version 4.17.11-200.fc28.x86_64 (mockbuild(a)bkernel01.phx2.fedoraproject.org) (gcc version 8.1.1 20180712 (Red Hat 8.1.1-5) (GCC)) #1 SMP Mon> Aug 04 03:16:21 localhost.localdomain kernel: Command line: BOOT_IMAGE=/vmlinuz-4.17.11-200.fc28.x86_64 root=/dev/mapper/fedora-root ro rd.luks.uuid=luks-9c1123dd-5aee-41e5-b3c4-b91249d5ed64 r> Aug 04 03:16:21 localhost.localdomain kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Aug 04 03:16:21 localhost.localdomain kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Aug 04 03:16:21 localhost.localdomain kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Aug 04 03:16:21 localhost.localdomain kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Aug 04 03:16:21 localhost.localdomain kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Aug 04 03:16:21 localhost.localdomain kernel: e820: BIOS-provided physical RAM map: Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009d3ff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x000000000009d400-0x000000000009ffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x0000000020200000-0x0000000040003fff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x0000000040004000-0x0000000040004fff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x0000000040005000-0x00000000d7f09fff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000d7f0a000-0x00000000d7ffffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000d8000000-0x00000000d8752fff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000d8753000-0x00000000d87fffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000d8800000-0x00000000d8fb2fff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000d8fb3000-0x00000000d8ffffff] ACPI data Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000d9000000-0x00000000da6fbfff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000da6fc000-0x00000000da7fffff] ACPI NVS Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000da800000-0x00000000dbb1bfff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000dbb1c000-0x00000000dc7a6fff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000dc7a7000-0x00000000dc7e9fff] ACPI NVS Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000dc7ea000-0x00000000dcab2fff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000dcab3000-0x00000000dcfeffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000dcff0000-0x00000000dcffffff] usable Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000dd800000-0x00000000df9fffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved Aug 04 03:16:21 localhost.localdomain kernel: BIOS-e820: [mem 0x0000000100000000-0x000000041e5fffff] usable Aug 04 03:16:21 localhost.localdomain kernel: NX (Execute Disable) protection: active Aug 04 03:16:21 localhost.localdomain kernel: random: fast init done Aug 04 03:16:21 localhost.localdomain kernel: SMBIOS 2.7 present. Aug 04 03:16:21 localhost.localdomain kernel: DMI: Dell Inc. Latitude E6530/, BIOS A17 08/19/2015 Aug 04 03:16:21 localhost.localdomain kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved Aug 04 03:16:21 localhost.localdomain kernel: e820: remove [mem 0x000a0000-0x000fffff] usable Aug 04 03:16:21 localhost.localdomain kernel: e820: last_pfn = 0x41e600 max_arch_pfn = 0x400000000 Aug 04 03:16:21 localhost.localdomain kernel: MTRR default type: uncachable Aug 04 03:16:21 localhost.localdomain kernel: MTRR fixed ranges enabled: Aug 04 03:16:21 localhost.localdomain kernel: 00000-9FFFF write-back

2 1

[alsa-devel] [PATCH] alsabat: Allow custom sample format for round trip latency test
by net147＠gmail.com 05 Aug '18

05 Aug '18

From: Jonathan Liu <net147(a)gmail.com> Setting the format to BAT_PCM_FORMAT_S16_LE in the round trip latency test initialization is redundant as it is already set by default to BAT_PCM_FORMAT_S16_LE unless a sample format is specified on the command line. Signed-off-by: Jonathan Liu <net147(a)gmail.com> --- bat/latencytest.c | 1 - 1 file changed, 1 deletion(-) diff --git a/bat/latencytest.c b/bat/latencytest.c index fae191c..ec3abe2 100644 --- a/bat/latencytest.c +++ b/bat/latencytest.c @@ -178,7 +178,6 @@ void roundtrip_latency_init(struct bat *bat) bat->latency.is_playing = false; bat->latency.error = 0; bat->latency.xrun_error = false; - bat->format = BAT_PCM_FORMAT_S16_LE; bat->frames = LATENCY_TEST_TIME_LIMIT * bat->rate; bat->periods_played = 0; } -- 2.18.0

2 1

[alsa-devel] [PATCH] ALSA: echoaudio: Mark expected switch fall-throughs
by Gustavo A. R. Silva 05 Aug '18

05 Aug '18

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 115156 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> --- sound/pci/echoaudio/echoaudio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/echoaudio/echoaudio.c b/sound/pci/echoaudio/echoaudio.c index 358ef7d..907cf1a 100644 --- a/sound/pci/echoaudio/echoaudio.c +++ b/sound/pci/echoaudio/echoaudio.c @@ -713,6 +713,7 @@ static int pcm_prepare(struct snd_pcm_substream *substream) break; case SNDRV_PCM_FORMAT_S32_BE: format.data_are_bigendian = 1; + /* fall through */ case SNDRV_PCM_FORMAT_S32_LE: format.bits_per_sample = 32; break; @@ -764,6 +765,7 @@ static int pcm_trigger(struct snd_pcm_substream *substream, int cmd) pipe->last_counter = 0; pipe->position = 0; *pipe->dma_counter = 0; + /* fall through */ case PIPE_STATE_PAUSED: pipe->state = PIPE_STATE_STARTED; break; -- 2.7.4

2 1

[alsa-devel] [PATCH] ALSA: emu10k1: Mark expected switch fall-throughs
by Gustavo A. R. Silva 05 Aug '18

05 Aug '18

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case, I replaced the code comment with a proper "fall through" annotation, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> --- sound/pci/emu10k1/emupcm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/emu10k1/emupcm.c b/sound/pci/emu10k1/emupcm.c index 26f6eda..9f2b609 100644 --- a/sound/pci/emu10k1/emupcm.c +++ b/sound/pci/emu10k1/emupcm.c @@ -778,7 +778,7 @@ static int snd_emu10k1_playback_trigger(struct snd_pcm_substream *substream, case SNDRV_PCM_TRIGGER_START: snd_emu10k1_playback_invalidate_cache(emu, 1, epcm->extra); /* do we need this? */ snd_emu10k1_playback_invalidate_cache(emu, 0, epcm->voices[0]); - /* follow thru */ + /* fall through */ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: case SNDRV_PCM_TRIGGER_RESUME: if (cmd == SNDRV_PCM_TRIGGER_PAUSE_RELEASE) @@ -928,7 +928,7 @@ static int snd_emu10k1_efx_playback_trigger(struct snd_pcm_substream *substream, } snd_emu10k1_playback_invalidate_cache(emu, 1, epcm->extra); - /* follow thru */ + /* fall through */ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: case SNDRV_PCM_TRIGGER_RESUME: snd_emu10k1_playback_prepare_voice(emu, epcm->extra, 1, 1, NULL); -- 2.7.4

2 1

[alsa-devel] [PATCH] ALSA: mixart: Mark expected switch fall-through
by Gustavo A. R. Silva 05 Aug '18

05 Aug '18

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com> --- sound/pci/mixart/mixart.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/mixart/mixart.c b/sound/pci/mixart/mixart.c index a74f1ad..9cd297a 100644 --- a/sound/pci/mixart/mixart.c +++ b/sound/pci/mixart/mixart.c @@ -182,6 +182,7 @@ static int mixart_set_clock(struct mixart_mgr *mgr, case PIPE_RUNNING: if(rate != 0) break; + /* fall through */ default: if(rate == 0) return 0; /* nothing to do */ -- 2.7.4

2 1