summaryrefslogtreecommitdiffstats
path: root/sound/firewire
Commit message (Collapse)AuthorAgeFilesLines
* ALSA: dice: fix kernel NULL pointer dereference due to invalid calculation ↵Takashi Sakamoto2018-04-291-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for array index At a commit f91c9d7610a ('ALSA: firewire-lib: cache maximum length of payload to reduce function calls'), maximum size of payload for tx isochronous packet is cached to reduce the number of function calls. This cache was programmed to updated at a first callback of ohci1394 IR context. However, the maximum size is required to queueing packets before starting the isochronous context. As a result, the cached value is reused to queue packets in next time to starting the isochronous context. Then the cache is updated in a first callback of the isochronous context. This can cause kernel NULL pointer dereference in a below call graph: (sound/firewire/amdtp-stream.c) amdtp_stream_start() ->queue_in_packet() ->queue_packet() (drivers/firewire/core-iso.c) ->fw_iso_context_queue() ->struct fw_card_driver.queue_iso() (drivers/firewire/ohci.c) = ohci_queue_iso() ->queue_iso_packet_per_buffer() buffer->pages[page] The issued dereference occurs in a case that: - target unit supports different stream formats for sampling transmission frequency. - maximum length of payload for tx stream in a first trial is bigger than the length in a second trial. In this case, correct number of pages are allocated for DMA and the 'pages' array has enough elements, while index of the element is wrongly calculated according to the old value of length of payload in a call of 'queue_in_packet()'. Then it causes the issue. This commit fixes the critical bug. This affects all of drivers in ALSA firewire stack in Linux kernel v4.12 or later. [12665.302360] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 [12665.302415] IP: ohci_queue_iso+0x47c/0x800 [firewire_ohci] [12665.302439] PGD 0 [12665.302440] P4D 0 [12665.302450] [12665.302470] Oops: 0000 [#1] SMP PTI [12665.302487] Modules linked in: ... [12665.303096] CPU: 1 PID: 12760 Comm: jackd Tainted: P OE 4.13.0-38-generic #43-Ubuntu [12665.303154] Hardware name: /DH77DF, BIOS KCH7710H.86A.0069.2012.0224.1825 02/24/2012 [12665.303215] task: ffff9ce87da2ae80 task.stack: ffffb5b8823d0000 [12665.303258] RIP: 0010:ohci_queue_iso+0x47c/0x800 [firewire_ohci] [12665.303301] RSP: 0018:ffffb5b8823d3ab8 EFLAGS: 00010086 [12665.303337] RAX: ffff9ce4f4876930 RBX: 0000000000000008 RCX: ffff9ce88a3955e0 [12665.303384] RDX: 0000000000000000 RSI: 0000000034877f00 RDI: 0000000000000000 [12665.303427] RBP: ffffb5b8823d3b68 R08: ffff9ce8ccb390a0 R09: ffff9ce877639ab0 [12665.303475] R10: 0000000000000108 R11: 0000000000000000 R12: 0000000000000003 [12665.303513] R13: 0000000000000000 R14: ffff9ce4f4876950 R15: 0000000000000000 [12665.303554] FS: 00007f2ec467f8c0(0000) GS:ffff9ce8df280000(0000) knlGS:0000000000000000 [12665.303600] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [12665.303633] CR2: 0000000000000030 CR3: 00000002dcf90004 CR4: 00000000000606e0 [12665.303674] Call Trace: [12665.303698] fw_iso_context_queue+0x18/0x20 [firewire_core] [12665.303735] queue_packet+0x88/0xe0 [snd_firewire_lib] [12665.303770] amdtp_stream_start+0x19b/0x270 [snd_firewire_lib] [12665.303811] start_streams+0x276/0x3c0 [snd_dice] [12665.303840] snd_dice_stream_start_duplex+0x1bf/0x480 [snd_dice] [12665.303882] ? vma_gap_callbacks_rotate+0x1e/0x30 [12665.303914] ? __rb_insert_augmented+0xab/0x240 [12665.303936] capture_prepare+0x3c/0x70 [snd_dice] [12665.303961] snd_pcm_do_prepare+0x1d/0x30 [snd_pcm] [12665.303985] snd_pcm_action_single+0x3b/0x90 [snd_pcm] [12665.304009] snd_pcm_action_nonatomic+0x68/0x70 [snd_pcm] [12665.304035] snd_pcm_prepare+0x68/0x90 [snd_pcm] [12665.304058] snd_pcm_common_ioctl1+0x4c0/0x940 [snd_pcm] [12665.304083] snd_pcm_capture_ioctl1+0x19b/0x250 [snd_pcm] [12665.304108] snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm] [12665.304131] do_vfs_ioctl+0xa8/0x630 [12665.304148] ? entry_SYSCALL_64_after_hwframe+0xe9/0x139 [12665.304172] ? entry_SYSCALL_64_after_hwframe+0xe2/0x139 [12665.304195] ? entry_SYSCALL_64_after_hwframe+0xdb/0x139 [12665.304218] ? entry_SYSCALL_64_after_hwframe+0xd4/0x139 [12665.304242] ? entry_SYSCALL_64_after_hwframe+0xcd/0x139 [12665.304265] ? entry_SYSCALL_64_after_hwframe+0xc6/0x139 [12665.304288] ? entry_SYSCALL_64_after_hwframe+0xbf/0x139 [12665.304312] ? entry_SYSCALL_64_after_hwframe+0xb8/0x139 [12665.304335] ? entry_SYSCALL_64_after_hwframe+0xb1/0x139 [12665.304358] SyS_ioctl+0x79/0x90 [12665.304374] ? entry_SYSCALL_64_after_hwframe+0x72/0x139 [12665.304397] entry_SYSCALL_64_fastpath+0x24/0xab [12665.304417] RIP: 0033:0x7f2ec3750ef7 [12665.304433] RSP: 002b:00007fff99e31388 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [12665.304465] RAX: ffffffffffffffda RBX: 00007fff99e312f0 RCX: 00007f2ec3750ef7 [12665.304494] RDX: 0000000000000000 RSI: 0000000000004140 RDI: 0000000000000007 [12665.304522] RBP: 0000556ebc63fd60 R08: 0000556ebc640560 R09: 0000000000000000 [12665.304553] R10: 0000000000000001 R11: 0000000000000246 R12: 0000556ebc63fcf0 [12665.304584] R13: 0000000000000000 R14: 0000000000000007 R15: 0000000000000000 [12665.304612] Code: 01 00 00 44 89 eb 45 31 ed 45 31 db 66 41 89 1e 66 41 89 5e 0c 66 45 89 5e 0e 49 8b 49 08 49 63 d4 4d 85 c0 49 63 ff 48 8b 14 d1 <48> 8b 72 30 41 8d 14 37 41 89 56 04 48 63 d3 0f 84 ce 00 00 00 [12665.304713] RIP: ohci_queue_iso+0x47c/0x800 [firewire_ohci] RSP: ffffb5b8823d3ab8 [12665.304743] CR2: 0000000000000030 [12665.317701] ---[ end trace 9d55b056dd52a19f ]--- Fixes: f91c9d7610a ('ALSA: firewire-lib: cache maximum length of payload to reduce function calls') Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: dice: fix error path to destroy initialized stream dataTakashi Sakamoto2018-04-261-1/+1
| | | | | | | | | | | | In error path of snd_dice_stream_init_duplex(), stream data for incoming packet can be left to be initialized. This commit fixes it. Fixes: 436b5abe2224 ('ALSA: dice: handle whole available isochronous streams') Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: dice: fix OUI for TC groupTakashi Sakamoto2018-04-241-1/+1
| | | | | | | | | | | OUI for TC Electronic is 0x000166, for TC GROUP A/S. 0x001486 is for Echo Digital Audio Corporation. Fixes: 7cafc65b3aa1 ('ALSA: dice: force to add two pcm devices for listed models') Cc: <stable@vger.kernel.org> # v4.6+ Reference: http://standards-oui.ieee.org/oui/oui.txt Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* treewide: remove large struct-pass-by-value from tracepoint argumentsAlexei Starovoitov2018-03-281-1/+1
| | | | | | | | | | | | | | - fix trace_hfi1_ctxt_info() to pass large struct by reference instead of by value - convert 'type array[]' tracepoint arguments into 'type *array', since compiler will warn that sizeof('type array[]') == sizeof('type *array') and later should be used instead The CAST_TO_U64 macro in the later patch will enforce that tracepoint arguments can only be integers, pointers, or less than 8 byte structures. Larger structures should be passed by reference. Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
* vfs: do bulk POLL* -> EPOLL* replacementLinus Torvalds2018-02-118-10/+10
| | | | | | | | | | | | | | | | | | | | | | | This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* sound: annotate ->poll() instancesAl Viro2017-11-278-16/+16
| | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* Merge branch 'linus' into locking/core, to resolve conflictsIngo Molnar2017-11-0711-0/+11
|\ | | | | | | | | | | | | | | | | | | Conflicts: include/linux/compiler-clang.h include/linux/compiler-gcc.h include/linux/compiler-intel.h include/uapi/linux/stddef.h Signed-off-by: Ingo Molnar <mingo@kernel.org>
| * License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman2017-11-0211-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns ↵Mark Rutland2017-10-2512-52/+51
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to READ_ONCE()/WRITE_ONCE() Please do not apply this to mainline directly, instead please re-run the coccinelle script shown below and apply its output. For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't harmful, and changing them results in churn. However, for some features, the read/write distinction is critical to correct operation. To distinguish these cases, separate read/write accessors must be used. This patch migrates (most) remaining ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following coccinelle script: ---- // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and // WRITE_ONCE() // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch virtual patch @ depends on patch @ expression E1, E2; @@ - ACCESS_ONCE(E1) = E2 + WRITE_ONCE(E1, E2) @ depends on patch @ expression E; @@ - ACCESS_ONCE(E) + READ_ONCE(E) ---- Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: davem@davemloft.net Cc: linux-arch@vger.kernel.org Cc: mpe@ellerman.id.au Cc: shuah@kernel.org Cc: snitzer@redhat.com Cc: thor.thayer@linux.intel.com Cc: tj@kernel.org Cc: viro@zeniv.linux.org.uk Cc: will.deacon@arm.com Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
* ALSA: firewire: Use common error handling code in snd_motu_stream_start_duplex()Markus Elfring2017-09-121-8/+8
| | | | | | | | | | Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: fireface: Use common error handling code in pcm_open()Markus Elfring2017-08-231-10/+10
| | | | | | | | | | | Add a jump target so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire: add const qualifier to identifiers for read-only symbolsTakashi Sakamoto2017-08-2213-23/+22
| | | | | | | | Drivers in ALSA firewire stack still includes some symbols which can be moved to a section for read-only symbols. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge branch 'for-linus' into for-nextTakashi Iwai2017-08-222-1/+7
|\ | | | | | | | | Conflicts: sound/core/control.c
| * ALSA: firewire-motu: destroy stream data surely at failure of card ↵Takashi Sakamoto2017-08-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | initialization When failing sound card registration after initializing stream data, this module leaves allocated data in stream data. This commit fixes the bug. Fixes: 9b2bb4f2f4a2 ('ALSA: firewire-motu: add stream management functionality') Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: firewire: fix NULL pointer dereference when releasing uninitialized ↵Takashi Sakamoto2017-08-201-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | data of iso-resource When calling 'iso_resource_free()' for uninitialized data, this function causes NULL pointer dereference due to its 'unit' member. This occurs when unplugging audio and music units on IEEE 1394 bus at failure of card registration. This commit fixes the bug. The bug exists since kernel v4.5. Fixes: 324540c4e05c ('ALSA: fireface: postpone sound card registration') at v4.12 Fixes: 8865a31e0fd8 ('ALSA: firewire-motu: postpone sound card registration') at v4.12 Fixes: b610386c8afb ('ALSA: firewire-tascam: deleyed registration of sound card') at v4.7 Fixes: 86c8dd7f4da3 ('ALSA: firewire-digi00x: delayed registration of sound card') at v4.7 Fixes: 6c29230e2a5f ('ALSA: oxfw: delayed registration of sound card') at v4.7 Fixes: 7d3c1d5901aa ('ALSA: fireworks: delayed registration of sound card') at v4.7 Fixes: 04a2c73c97eb ('ALSA: bebob: delayed registration of sound card') at v4.7 Fixes: b59fb1900b4f ('ALSA: dice: postpone card registration') at v4.5 Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-motu: add support for MOTU Audio ExpressTakashi Sakamoto2017-08-211-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MOTU Audio Express is one of third generation in MOTU FireWire series, produced in 2011. This model consists of three chips: * TI TSB41AB2 (Physical layer for IEEE 1394 bus) * Microchip USB3300 (Hi-Speed USB Device with ULPI interface) * Xilinx Spartan-3A FPGA, XC3S400A (Link layer for IEEE 1394 bus, packet processing and data block processing layer) This commit adds support for this model. As I expected, it works with current implementaion of protocol version 3. On the other hand, the unit has a quirk to request subaction originated by any driver. 11:45:51.287643 firewire_ohci 0000:03:00.0: AT spd 2 tl 1f, ffc1 -> ffc0, -reserved-, QW req, fffff0000b14 = 02000200 11:45:51.289193 firewire_ohci 0000:03:00.0: AR spd 2 tl 1f, ffc0 -> ffc1, ack_complete, W resp 11:45:51.289381 fireire_core 0000:03:00.0: unsolicited response (source ffc0, tlabel 1f) 11:45:51.313071 firewire_ohci 0000:03:00.0: AT spd 2 tl 20, ffc1 -> ffc0, ack_pending , QW req, fffff0000b14 = 02000200 11:45:51.314539 firewire_ohci 0000:03:00.0: AR spd 2 tl 20, ffc0 -> ffc1, ack_complete, W resp In 1394 OHCI (rev.1.1), after OUTPUT_LAST* descriptors is processed, 'xferStaus' field is filled with 'ContextControl[0:15]' (see clause 7.1.3). 5 bits in LSB side of the field has ack code in acknowledge from the unit (see clause 7.2.2). A list of the code is shown in Table 3-2. As long as I investigated, in a case of the '-reserved-' acknowledge message from the unit, the field has 0x10. On the table, this value is 'Reserved for definition by future 1394 standards'. As long as I know, any specifications of IEEE 1394 has no such extensions, thus the unit is out of specification. Besides, I note that the unit does not always acknowledge with the invalid code. I guess this is a bug of firmware. I confirmed the bug in firmware version 1.04 and this is the latest one. $ cd linux-firewire-utils $ python2 ./src/crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 0410a756 bus_info_length 4, crc_length 16, crc 42838 404 31333934 bus_name "1394" 408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256) 40c 0001f200 company_id 0001f2 | 410 000a8a7b device_id 00000a8a7b | EUI-64 0001f200000a8a7b root directory ----------------------------------------------------------------- 414 0004ef04 directory_length 4, crc 61188 418 030001f2 vendor 41c 0c0083c0 node capabilities per IEEE 1394 420 d1000002 --> unit directory at 428 424 8d000005 --> eui-64 leaf at 438 unit directory at 428 ----------------------------------------------------------------- 428 00031680 directory_length 3, crc 5760 42c 120001f2 specifier id 430 13000033 version 434 17104800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 00025ef3 leaf_length 2, crc 24307 43c 0001f200 company_id 0001f2 | 440 000a8a7b device_id 00000a8a7b | EUI-64 0001f200000a8a7b Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-motu: add specification flag for position of flag for MIDI ↵Takashi Sakamoto2017-08-216-17/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | messages In protocols of MOTU FireWire series, when transferring MIDI messages, transmitter set existence flag to one byte on first several quadlets. The position differs depending on protocols and models, however two cases are confirmed; in 5th byte and 8th byte from MSB side. This commit adds a series of specification flag to describe them. When the existence flag is in the 5th byte, SND_MOTU_SPEC_[R|T]X_MIDI_2ND_Q is used. Else, another set of the flag is used. Here, '_Q' means quadlet. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire: constify snd_pcm_ops structuresArvind Yadav2017-08-192-3/+3
| | | | | | | | | | | | | | | | | | snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by <sound/pcm.h> work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-motu: constify snd_rawmidi_ops structuresJulia Lawall2017-08-151-2/+2
|/ | | | | | | | | | | | These snd_rawmidi_ops structures are only passed as the third argument of snd_rawmidi_set_ops. This argument is const, so the snd_rawmidi_ops structures can be const too. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge branch 'for-linus' into for-nextTakashi Iwai2017-06-202-3/+7
|\
| * ALSA: firewire-lib: Fix stall of process context at packet errorTakashi Sakamoto2017-06-192-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At Linux v3.5, packet processing can be done in process context of ALSA PCM application as well as software IRQ context for OHCI 1394. Below is an example of the callgraph (some calls are omitted). ioctl(2) with e.g. HWSYNC (sound/core/pcm_native.c) ->snd_pcm_common_ioctl1() ->snd_pcm_hwsync() ->snd_pcm_stream_lock_irq (sound/core/pcm_lib.c) ->snd_pcm_update_hw_ptr() ->snd_pcm_udpate_hw_ptr0() ->struct snd_pcm_ops.pointer() (sound/firewire/*) = Each handler on drivers in ALSA firewire stack (sound/firewire/amdtp-stream.c) ->amdtp_stream_pcm_pointer() (drivers/firewire/core-iso.c) ->fw_iso_context_flush_completions() ->struct fw_card_driver.flush_iso_completion() (drivers/firewire/ohci.c) = flush_iso_completions() ->struct fw_iso_context.callback.sc (sound/firewire/amdtp-stream.c) = in_stream_callback() or out_stream_callback() ->... ->snd_pcm_stream_unlock_irq When packet queueing error occurs or detecting invalid packets in 'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()' is called on local CPU with disabled IRQ. (sound/firewire/amdtp-stream.c) in_stream_callback() or out_stream_callback() ->amdtp_stream_pcm_abort() ->snd_pcm_stop_xrun() ->snd_pcm_stream_lock_irqsave() ->snd_pcm_stop() ->snd_pcm_stream_unlock_irqrestore() The process is stalled on the CPU due to attempt to acquire recursive lock. [ 562.630853] INFO: rcu_sched detected stalls on CPUs/tasks: [ 562.630861] 2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140 [ 562.630862] (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933) [ 562.630866] Task dump for CPU 2: [ 562.630867] alsa-source-OXF R running task 0 6619 1 0x00000008 [ 562.630870] Call Trace: [ 562.630876] ? vt_console_print+0x79/0x3e0 [ 562.630880] ? msg_print_text+0x9d/0x100 [ 562.630883] ? up+0x32/0x50 [ 562.630885] ? irq_work_queue+0x8d/0xa0 [ 562.630886] ? console_unlock+0x2b6/0x4b0 [ 562.630888] ? vprintk_emit+0x312/0x4a0 [ 562.630892] ? dev_vprintk_emit+0xbf/0x230 [ 562.630895] ? do_sys_poll+0x37a/0x550 [ 562.630897] ? dev_printk_emit+0x4e/0x70 [ 562.630900] ? __dev_printk+0x3c/0x80 [ 562.630903] ? _raw_spin_lock+0x20/0x30 [ 562.630909] ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm] [ 562.630914] ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm] [ 562.630918] ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm] [ 562.630922] ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib] [ 562.630925] ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci] [ 562.630928] ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci] [ 562.630932] ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core] [ 562.630935] ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib] [ 562.630938] ? pcm_capture_pointer+0x19/0x20 [snd_oxfw] [ 562.630943] ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm] [ 562.630945] ? poll_select_copy_remaining+0x150/0x150 [ 562.630947] ? poll_select_copy_remaining+0x150/0x150 [ 562.630952] ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm] [ 562.630956] ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm] [ 562.630960] ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm] [ 562.630962] ? futex_wake+0x90/0x170 [ 562.630966] ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm] [ 562.630970] ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm] [ 562.630972] ? do_vfs_ioctl+0xa3/0x610 [ 562.630974] ? vfs_read+0x11b/0x130 [ 562.630976] ? SyS_ioctl+0x79/0x90 [ 562.630978] ? entry_SYSCALL_64_fastpath+0x1e/0xad This commit fixes the above bug. This assumes two cases: 1. Any error is detected in software IRQ context of OHCI 1394 context. In this case, PCM substream should be aborted in packet handler. On the other hand, it should not be done in any process context. TO distinguish these two context, use 'in_interrupt()' macro. 2. Any error is detect in process context of ALSA PCM application. In this case, PCM substream should not be aborted in packet handler because PCM substream lock is acquired. The task to abort PCM substream should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is returned at 'struct snd_pcm_ops.pointer()'. Suggested-by: Clemens Ladisch <clemens@ladisch.de> Fixes: e9148dddc3c7("ALSA: firewire-lib: flush completed packets when reading PCM position") Cc: <stable@vger.kernel.org> # 4.9+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire: arrange common PCM info/constraints for AMDTP engine ↵Takashi Sakamoto2017-06-089-174/+36
| | | | | | | | | | | | | | | | | | | | | | | | applications In ALSA firewire stack, 8 drivers uses IEC 61883-1/6 engine for data transmission. They have common PCM info/constraints and duplicated codes. This commit unifies the codes into fireiwre-lib. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: fireface: constify ALSA specific operationsTakashi Sakamoto2017-06-072-39/+35
| | | | | | | | | | | | | | | | | | ALSA fireface driver has ALSA specific operations for MIDI/PCM data. Structured data for the operations can be constified. Additionally, The structured data can be function local. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire: process packets in 'struct snd_pcm_ops.ack' callbackTakashi Sakamoto2017-06-0710-0/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In recent commit for ALSA PCM core, some arrangement is done for 'struct snd_pcm_ops.ack' callback. This is called when appl_ptr is explicitly moved in intermediate buffer for PCM frames, except for some cases described later. For drivers in ALSA firewire stack, usage of this callback has a merit to reduce latency between time of PCM frame queueing and handling actual packets in recent isochronous cycle, because no need to wait for software IRQ context from isochronous context of OHCI 1394. If this works well in a case that mapped page frame is used for the intermediate buffer, user process should execute some commands for ioctl(2) to tell the number of handled PCM frames in the intermediate buffer just after handling them. Therefore, at present, with a combination of below conditions, this doesn't work as expected and user process should wait for the software IRQ context as usual: - when ALSA PCM core judges page frame mapping is available for status data (struct snd_pcm_mmap_status) and control data (struct snd_pcm_mmap_control). - user process handles PCM frames by loop just with 'snd_pcm_mmap_begin()' and 'snd_pcm_mmap_commit()'. - user process uses PCM hw plugin in alsa-lib to operate I/O without 'sync_ptr_ioctl' option. Unfortunately, major use case include these three conditions. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: declare snd_kcontrol_new structures as constBhumika Goyal2017-05-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Declare snd_kcontrol_new structures as const as they are only passed an argument to the function snd_ctl_new1. This argument is of type const, so snd_kcontrol_new structures having this property can be made const. Done using Coccinelle: @r disable optional_qualifier@ identifier x; position p; @@ static struct snd_kcontrol_new x@p={...}; @ok@ identifier r.x; position p; @@ snd_ctl_new1(&x@p,...) @bad@ position p != {r.p,ok.p}; identifier r.x; @@ x@p @depends on !bad disable optional_qualifier@ identifier r.x; @@ +const struct snd_kcontrol_new x; Cross compiled these files: sound/aoa/codecs/tas.c - powerpc sound/mips/{hal2.c/sgio2audio.c} - mips sound/ppc/{awacs.c/beep.c/tumbler.c} - powerpc sound/soc/sh/siu_dai.c - sh Could not find an architecture to compile sound/sh/aica.c. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire: remove support for 16 bit PCM samples in playback substreamTakashi Sakamoto2017-05-2212-227/+9
|/ | | | | | | | | | | | | | | | | | | | | | | | | In IEC 61883-6, AM824 is described as format of data block. In this format, one data block consists of several data channels, which is aligned to 32 bit. One data channel has 8 bit label field and 24 bit data field. PCM frames are transferred in Multi Bit Linear Audio (MBLA) data channel. This channel can include 16/20/24 bit PCM sample. As long as I know, models which support IEC 61883-1/6 doesn't allow to switch bit length of PCM sample in MBLA data channel. They always transmit/receive PCM frames of 24 bit length. This can be seen for the other models which support protocols similar to IEC 61883-1/6. On the other hand, current drivers for these protocols supports 16 bit length PCM sample in playback substream. In this case, PCM sample is put into the MBLA data channel with 8 bit padding in LSB side. Although 16 bit PCM sample is major because it's in CD format, this doesn't represent device capability as is. This commit removes support for 16 bit PCM samples in playback substream. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: fireface: obsolete usage of ktime_set() for zero assignmentTakashi Sakamoto2017-04-201-1/+1
| | | | | | | | | | In development period for Linux v4.10, ktime_t became an alias of s64, instead of union. I forgot it. We can just assign zero, instead of usage of ktime_set(0, 0). Fixes: 19174295788 ("ALSA: fireface: add transaction support") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire-motu: mark trace helpers as __maybe_unusedArnd Bergmann2017-04-201-4/+6
| | | | | | | | | | | | | | | | | Two functions were introduced for the purpose of tracing but cause warnings when tracing is disabled: sound/firewire/motu/amdtp-motu.c:284:13: error: 'copy_message' defined but not used [-Werror=unused-function] static void copy_message(u64 *frames, __be32 *buffer, unsigned int data_blocks, sound/firewire/motu/amdtp-motu.c:271:13: error: 'copy_sph' defined but not used [-Werror=unused-function] static void copy_sph(u32 *frames, __be32 *buffer, unsigned int data_blocks, Marking them as __maybe_unused will do the right thing here. Fixes: 17909c1b3058 ("ALSA: firewire-motu: add tracepoints for SPH in IEC 61883-1 fashion") Fixes: c6b0b9e65f09 ("ALSA: firewire-motu: add tracepoints for messages for unique protocol") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire-tascam: support drain callback for MIDI playback substreamTakashi Sakamoto2017-04-141-2/+6
| | | | | | | | | | | | | | ALSA driver for TASCAM FireWire series transfers MIDI messages in system workqueue. In current design of the driver, applications should wait for sequence of transmission when they close ALSA rawmidi character devices. However, when considering design of rawmidi interface, it's preferable to wait in drain ioctl. This commit adds support for the drain ioctl to wait for the end of the transmission. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire-tascam: move message parameters for async midi portTakashi Sakamoto2017-04-143-21/+19
| | | | | | | | | | | | | | Units on TASCAM FireWire series handle MIDI messages with support for running status. Drivers for the series should remember current running status and transfer valid MIDI messages. For this purpose, current ALSA driver for the series has some members in its top-level structure. This is due to better abstraction of async midi port. Nowadays, the abstraction was localized just for the driver. This commit moves the members to structure for async midi port. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire-tascam: initialize parameters at open of rawmidi character ↵Takashi Sakamoto2017-04-143-14/+7
| | | | | | | | | | | | | | | devices In current design of ALSA driver for TASCAM FireWire series, initialization of members in asymc midi port structure is done at device probing. Some of the members should be initialized every time to use rawmidi devices because they're changed in sequence of transmission for MIDI messages. This commit adds a new function to initialize them. Invariant parameters during object lifetime are kept as is. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire-tascam: use fixed-length array for message cache to async ↵Takashi Sakamoto2017-04-142-17/+2
| | | | | | | | | | | | | | | midi port ALSA driver for TASCAM FireWire series internally allocates 4 byte buffer for asynchronous transaction to transfer MIDI messages. However, the buffer can be allocated with memory object of parent structure. This commit adds 4 byte array as a member of the structure and obsoletes the redundant allocation. This is deallocated with memory object of parent structure. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire-tascam: use the same address for asynchronous transaction for ↵Takashi Sakamoto2017-04-142-7/+5
| | | | | | | | | | | | | MIDI message Units on TASCAM FireWire series receive MIDI messages by asynchronous transactions on IEEE 1394 bus. Although the transaction is sent to a certain register, current ALSA driver for this series has a redundant design. This commit use the same address for the transaction. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire-tascam: send fixed-length transaction for async midi portTakashi Sakamoto2017-04-142-17/+8
| | | | | | | | | | | TASCAM FireWire series uses asynchronous transactions with fixed length payload for MIDI messaging. On the other hand, ALSA driver for the series has a redundant design to handle different length of payload. This commit removes the redundant abstraction. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire-tascam: remove callback function from async midi portTakashi Sakamoto2017-04-142-13/+4
| | | | | | | | | | | As a result of localization of async midi port, ALSA driver for TASCAM FireWire series can call helper function directly instead of callback registration. This commit removes the redundant design. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: firewire-lib/firewire-tascam: localize async midi portTakashi Sakamoto2017-04-144-195/+170
| | | | | | | | | | | | | | In Linux kernel 4.4, firewire-lib got a feature called as 'async midi port' for transmission of MIDI message via IEEE 1394 asynchronous communication, however actual consumer of this feature is ALSA driver for TASCAM FireWire series only. When adding this feature, I assumed that ALSA driver for Digi00x might also be a consumer, actually it's not. This commit moves the feature from firewire-lib to firewire-tascam module. Two minor kernel APIs are removed. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge branch 'for-linus' into for-nextTakashi Iwai2017-04-141-1/+1
|\ | | | | | | Back-merge to prepare for applying more FireWire updates.
| * ALSA: firewire-lib: fix inappropriate assignment between signed/unsigned typeTakashi Sakamoto2017-04-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An abstraction of asynchronous transaction for transmission of MIDI messages was introduced in Linux v4.4. Each driver can utilize this abstraction to transfer MIDI messages via fixed-length payload of transaction to a certain unit address. Filling payload of the transaction is done by callback. In this callback, each driver can return negative error code, however current implementation assigns the return value to unsigned variable. This commit changes type of the variable to fix the bug. Reported-by: Julia Lawall <Julia.Lawall@lip6.fr> Cc: <stable@vger.kernel.org> # 4.4+ Fixes: 585d7cba5e1f ("ALSA: firewire-lib: add helper functions for asynchronous transactions to transfer MIDI messages") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-lib: cache maximum length of payload to reduce function callsTakashi Sakamoto2017-04-122-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During packet streaming, maximum length of payload for isochronous packet is invariable, therefore no need to recalculate. Current ALSA IEC 61883-1/6 engine calls a function to calculate it 8,000 or more times per second for incoming packet processing. This commit adds a member to have maximum length of payload into 'struct amdtp_stream', to reduces the function calls. At first callback from isochronous context, the length is calculated and stored for later processing. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | Merge branch 'for-linus' into for-nextTakashi Iwai2017-04-121-2/+2
|\|
| * ALSA: oxfw: fix regression to handle Stanton SCS.1m/1dTakashi Sakamoto2017-04-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At a commit 6c29230e2a5f ("ALSA: oxfw: delayed registration of sound card"), ALSA oxfw driver fails to handle SCS.1m/1d, due to -EBUSY at a call of snd_card_register(). The cause is that the driver manages to register two rawmidi instances with the same device number 0. This is a regression introduced since kernel 4.7. This commit fixes the regression, by fixing up device property after discovering stream formats. Fixes: 6c29230e2a5f ("ALSA: oxfw: delayed registration of sound card") Cc: <stable@vger.kernel.org> # 4.7+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-motu: add tracepoints for messages for unique protocolTakashi Sakamoto2017-04-112-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MOTU units transfer/receive messages in each data block of their isochronous packet payload. A part of content in the message is cleard for MIDI message transmission, while the rest is unknown yet. Additional features are required to assist users and developers to reveal the details. This commit adds tracepoints for the purpose. The tracepoints are designed for MOTU's protocol version 2 and 3 (Protocol version 1 is not upstreamed yet). In the tracepoints, events are probed to gather first two 24 bit data chunks of each data block. The chunks are formatted into elements of 64 bit array with padding in MSB. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-motu: add tracepoints for SPH in IEC 61883-1 fashionTakashi Sakamoto2017-04-113-0/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unique protocol is used for MOTU FireWire series. In this protocol, data block format is not compliant to AM824 in IEC 61883-1/6. Each of the data block consists of 24 bit data chunks, except for a first quadlet. The quadlet is used for source packet header (SPH) described in IEC 61883-1. The sequence of SPH seems to represent presentation timestamp corresponding to included data. Developers have experienced that invalid sequence brings disorder of units in the series. Unfortunately, current implementation of ALSA IEC 61883-1/6 engine and firewire-motu driver brings periodical noises to the units at sampling transmission frequency based on 44.1 kHz. The engine generates the SPH with even interval and this mechanism seems not to be suitable to the units. Further work is required for this issue and infrastructure is preferable to assist the work. This commit adds tracepoints for the purpose. In the tracepoints, events are probed to gather the SPHs from each data blocks. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire_lib: add tracepoints for packets without CIP headersTakashi Sakamoto2017-04-112-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unique protocol is used for RME Fireface series. In this protocol, payload format for isochronous packet is not compliant to CIP in IEC 61883-1/6. The packet includes data blocks just with data channels, without headers and any metadata. In previous commits, ALSA IEC 61883-1/6 engine supports this protocol. However, tracepoints are not supported yet, unlike implementation for IEC 61883-1/6 protocol. This commit adds support of tracepoints for the protocol. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-lib/bebob/oxfw: improve response evaluation for AV/C commandsTakashi Sakamoto2017-04-053-14/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In ALSA firewire stack, some AV/C commands are supported, including vendor's extensions. Drivers includes response parser of each command, according to its requirements, while the parser is written with loose fashion in two points; error check and length check. This doesn't cause any issues such as kernel corruption, but should be improved. This commit modifies evaluations of return value on each parsers. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-motu: remove invalid bitshift for register valueTakashi Sakamoto2017-04-051-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In protocol version 3, drivers can read current sampling clock status from register 0x'ffff'f000'0b14. 8 bits of LSB of this register represents type of signal as source of clock. Current driver code includes invalid bitshift to handle the parameter. This commit fixes the bug. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 5992e30034c4 ("ALSA: firewire-motu: add support for MOTU 828mk3 (FireWire/Hybrid) as a model with protocol version 3") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-digi00x: remove transaction handler for unknown purposeTakashi Sakamoto2017-04-052-77/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | For digi00x series, asynchronous transaction is not used to transfer MIDI messages to/from control surface. One of transction handlers in my previous work loses its practical meaning. This commit removes the handler. I note that unit of console type transfers 0x00001000 to registered address of host space when switching to 'standalone' mode. Then the unit generates bus reset. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-digi00x: allow user space applications to read/write MIDI ↵Takashi Sakamoto2017-04-051-129/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | messages for all ports At a commit c5fcee0373b3 ("ALSA: firewire-digi00x: add MIDI operations for MIDI control port"), I described that MIDI messages for control surface is transferred by a different way from the messages for physical ports. However, this is wrong. MIDI messages to/from all of MIDI ports are transferred by isochronous packets. This commit removes codes to transfer MIDI messages via asynchronous transaction, from MIDI handling layer. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-digi00x: handle all MIDI messages on streaming packetsTakashi Sakamoto2017-04-051-18/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At a commit 9dc5d31cdceb ("ALSA: firewire-digi00x: handle MIDI messages in isochronous packets"), a functionality to handle MIDI messages on isochronous packet was supported. But this includes some of my misunderstanding. This commit is to fix them. For digi00x series, first data channel of data blocks in rx/tx packet includes MIDI messages. The data channel has 0x80 in 8 bit of its MSB, however it's against IEC 61883-6. Unique data format is applied: - Upper 4 bits of LSB represent port number. - 0x0: port 1. - 0x2: port 2. - 0xe: console port. - Lower 4 bits of LSB represent the number of included MIDI message bytes; 0x0/0x1/0x2. - Two bytes of middle of this data channel have MIDI bytes. Especially, MIDI messages from/to console surface are also transferred by isochronous packets, as well as physical MIDI ports. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: firewire-digi00x: add support for console models of Digi00x seriesTakashi Sakamoto2017-04-052-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Digi00x series includes two types of unit; rack and console. As long as reading information on config rom of Digi 002 console, 'MODEL_ID' field has a different value from the one on Digi 002 rack. We've already got a test report from users with Digi 003 rack. We can assume that console type and rack type has different value in the field. This commit adds a device entry for console type. For following commits, this commit also adds a member to 'struct snd_digi00x' to identify console type. $ cd linux-firewire-utils/src $ python2 ./crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 0404f9d0 bus_info_length 4, crc_length 4, crc 63952 404 31333934 bus_name "1394" 408 60647002 irmc 0, cmc 1, isc 1, bmc 0, cyc_clk_acc 100, max_rec 7 (256) 40c 00a07e00 company_id 00a07e | 410 00a30000 device_id 0000a30000 | EUI-64 00a07e0000a30000 root directory ----------------------------------------------------------------- 414 00058a39 directory_length 5, crc 35385 418 0c0043a0 node capabilities 41c 04000001 hardware version 420 0300a07e vendor 424 81000007 --> descriptor leaf at 440 428 d1000001 --> unit directory at 42c unit directory at 42c ----------------------------------------------------------------- 42c 00046674 directory_length 4, crc 26228 430 120000a3 specifier id 434 13000001 version 438 17000001 model 43c 81000007 --> descriptor leaf at 458 descriptor leaf at 440 ----------------------------------------------------------------- 440 00055913 leaf_length 5, crc 22803 444 000050f2 descriptor_type 00, specifier_ID 50f2 448 80000000 44c 44696769 450 64657369 454 676e0000 descriptor leaf at 458 ----------------------------------------------------------------- 458 0004a6fd leaf_length 4, crc 42749 45c 00000000 textual descriptor 460 00000000 minimal ASCII 464 44696769 "Digi" 468 20303032 " 002" Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-14 21:01:46 +0000