- 22 Aug, 2017 3 commits
-
-
Takashi Iwai authored
Conflicts: sound/core/control.c
-
Takashi Iwai authored
When user tries to replace the user-defined control TLV, the kernel checks the change of its content via memcmp(). The problem is that the kernel passes the return value from memcmp() as is. memcmp() gives a non-zero negative value depending on the comparison result, and this shall be recognized as an error code. The patch covers that corner-case, return 1 properly for the changed TLV. Fixes: 8aa9b586 ("[ALSA] Control API - more robust TLV implementation") Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
Joakim Tjernlund authored
These headsets reports a lot of: cannot set freq 44100 to ep 0x81 and need a small delay between sample rate settings, just like Zoom R16/24. Add both headsets to the Zoom R16/24 quirk for a 1 ms delay between control msgs. Signed-off-by:
Joakim Tjernlund <joakim.tjernlund@infinera.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 21 Aug, 2017 2 commits
-
-
Takashi Sakamoto authored
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 Sakamoto authored
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:
-
- 20 Aug, 2017 5 commits
-
-
Takashi Sakamoto authored
When failing sound card registration after initializing stream data, this module leaves allocated data in stream data. This commit fixes the bug. Fixes: 9b2bb4f2 ('ALSA: firewire-motu: add stream management functionality') Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by:
-
Takashi Sakamoto authored
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: 324540c4 ('ALSA: fireface: postpone sound card registration') at v4.12 Fixes: 8865a31e ('ALSA: firewire-motu: postpone sound card registration') at v4.12 Fixes: b610386c ('ALSA: firewire-tascam: deleyed registration of sound card') at v4.7 Fixes: 86c8dd7f ('ALSA: firewire-digi00x: delayed registration of sound card') at v4.7 Fixes: 6c29230e ('ALSA: oxfw: delayed registration of sound card') at v4.7 Fixes: 7d3c1d59 ('ALSA: fireworks: delayed registration of sound card') at v4.7 Fixes: 04a2c73c ('ALSA: bebob: delayed registration of sound card') at v4.7 Fixes: b59fb190 ('ALSA: dice: postpone card registration') at v4.5 Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by:
-
Takashi Sakamoto authored
In ALSA control interface, applications can execute two types of request for value of members on each element; ELEM_READ and ELEM_WRITE. In ALSA control core, these two requests are handled within read lock of a counting semaphore, therefore several processes can run to execute these two requests at the same time. This has an issue because ELEM_WRITE requests have an effect to change state of the target element. Concurrent access should be controlled for each of ELEM_READ/ELEM_WRITE case. This commit uses the counting semaphore as write lock for ELEM_WRITE requests, while use it as read lock for ELEM_READ requests. The state of a target element is maintained exclusively between ELEM_WRITE/ELEM_READ operations. There's a concern. If the counting semaphore is acquired for read lock in implementations of 'struct snd_kcontrol.put()' in each driver, this commit shall cause dead lock. As of v4.13-rc5, 'snd-mixer-oss.ko', 'snd-emu10k1.ko' and 'snd-soc-sst-atom-hifi2-platform.ko' includes codes for read locks, but these are not in a call graph from 'struct snd_kcontrol.put(). Therefore, this commit is safe. In current implementation, the same solution is applied for the other operations to element; e.g. ELEM_LOCK and ELEM_UNLOCK. There's another discussion about an overhead to maintain concurrent access to an element during operating the other elements on the same card instance, because the lock primitive is originally implemented to maintain a list of elements on the card instance. There's a substantial difference between per-element-list lock and per-element lock. Here, let me investigate another idea to add per-element lock to maintain the concurrent accesses with inquiry/change requests to an element. It's not so frequent for applications to operate members on elements, while adding a new lock primitive to structure increases memory footprint for all of element sets somehow. Experimentally, inquiry operation is more frequent than change operation and usage of counting semaphore for the inquiry operation brings no blocking to the other inquiry operations. Thus the overhead is not so critical for usual applications. For the above reasons, in this commit, the per-element lock is not introduced. Signed-off-by:
-
Takashi Sakamoto authored
ALSA control core handles ELEM_READ/ELEM_WRITE requests within lock acquisition of a counting semaphore. The lock is acquired in helper functions in the end of call path before calling implementations of each driver. ioctl(2) with SNDRV_CTL_ELEM_READ ... ->snd_ctl_ioctl() ->snd_ctl_elem_read_user() ->snd_ctl_elem_read() ->down_read(controls_rwsem) ->snd_ctl_find_id() ->struct snd_kcontrol.get() ->up_read(controls_rwsem) ioctl(2) with SNDRV_CTL_ELEM_WRITE ... ->snd_ctl_ioctl() ->snd_ctl_elem_write_user() ->snd_ctl_elem_write() ->down_read(controls_rwsem) ->snd_ctl_find_id() ->struct snd_kcontrol.put() ->up_read(controls_rwsem) This commit moves the lock acquisition to middle of the call graph to simplify the helper functions. As a result: ioctl(2) with SNDRV_CTL_ELEM_READ ... ->snd_ctl_ioctl() ->snd_ctl_elem_read_user() ->down_read(controls_rwsem) ->snd_ctl_elem_read() ->snd_ctl_find_id() ->struct snd_kcontrol.get() ->up_read(controls_rwsem) ioctl(2) with SNDRV_CTL_ELEM_WRITE ... ->snd_ctl_ioctl() ->snd_ctl_elem_write_user() ->down_read(controls_rwsem) ->snd_ctl_elem_write() ->snd_ctl_find_id() ->struct snd_kcontrol.put() ->up_read(controls_rwsem) Signed-off-by: -
Takashi Sakamoto authored
Any control event is queued by a call of snd_ctl_notify(). This function adds the event to each queue of opened file data corresponding to ALSA control character devices. This function acquired two types of lock; a counting semaphore for a list of the opened file data and a spinlock for card data opened by the file. Typically, this function is called after acquiring a counting semaphore for a list of elements in the card data. In current implementation of a handler for ELEM_WRITE request, the function is called after releasing the semaphore for a list of elements in the card data. This release is not necessarily needed. This commit removes the release to call the function within the critical section so that later commits are simple. Signed-off-by:
-
- 19 Aug, 2017 13 commits
-
-
Arvind Yadav authored
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:
-
Arvind Yadav authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
- 18 Aug, 2017 3 commits
-
-
Takashi Iwai authored
The commit d42fe63d ("ALSA: emu10k1: Get rid of set_fs() usage") converted the user-space copy hack with set_fs() to the direct memcpy(), but one place was forgotten. This resulted in the error from snd_emu10k1_init_efx(), eventually failed to load the driver. Fix the missing piece. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196687 Fixes: d42fe63d ("ALSA: emu10k1: Get rid of set_fs() usage") Signed-off-by:
-
Jussi Laako authored
Add DSD support for new Amanero Combo384 firmware version with a new PID. This firmware uses DSD_U32_BE. Fixes: 3eff682d ("ALSA: usb-audio: Support both DSD LE/BE Amanero firmware versions") Signed-off-by:
Jussi Laako <jussi@sonarnerd.net> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Stephen Barber authored
A few calls to snd_usb_ctl_msg wrap the function in a retry loop. In the worst case, the timeout for snd_usb_ctl_msg is 5 seconds, which when retried 10 times (for example, if a device is removed) could cause a probe to hang for ~50 seconds. Example stack trace from 3.14 which triggered a hung task timeout: Call Trace: [<ffffffffa2c1f720>] ? inet6_set_link_af.part.35+0x12/0x12 [<ffffffffa2c20309>] schedule+0x6e/0x70 [<ffffffffa2c1f81c>] schedule_timeout+0xfc/0x13c [<ffffffffa2667bbc>] ? rcu_read_unlock_sched_notrace+0x17/0x17 [<ffffffffa2c20d68>] __wait_for_common+0x153/0x190 [<ffffffffa2c20d68>] ? __wait_for_common+0x153/0x190 [<ffffffffa26890e5>] ? wake_up_state+0x12/0x12 [<ffffffffa2c20e0e>] wait_for_completion_timeout+0x1d/0x1f [<ffffffffa2a07c70>] usb_start_wait_urb+0x93/0xf1 [<ffffffffa2a07daf>] usb_control_msg+0xe1/0x11d [<ffffffffc02cd254>] snd_usb_ctl_msg+0x9c/0xf1 [snd_usb_audio] [<ffffffffc02ce191>] snd_usb_mixer_set_ctl_value+0x124/0xab1 [snd_usb_audio] [<ffffffffc02ce230>] snd_usb_mixer_set_ctl_value+0x1c3/0xab1 [snd_usb_audio] [<ffffffffc02ce58e>] snd_usb_mixer_set_ctl_value+0x521/0xab1 [snd_usb_audio] [<ffffffffc02cee88>] snd_usb_mixer_add_control+0x36a/0x1264 [snd_usb_audio] [<ffffffffc02cf323>] snd_usb_mixer_add_control+0x805/0x1264 [snd_usb_audio] [<ffffffffa2a06e11>] ? usb_free_urb+0x1a/0x1c [<ffffffffc02cfcf7>] snd_usb_mixer_add_control+0x11d9/0x1264 [snd_usb_audio] [<ffffffffc02d000f>] snd_usb_create_mixer+0xbc/0x286 [snd_usb_audio] [<ffffffffc02cac18>] 0xffffffffc02cac17 [<ffffffffa2a0aaf1>] usb_probe_interface+0x17c/0x21c [<ffffffffa29a65bc>] driver_probe_device+0xae/0x1fa [<ffffffffa29a6767>] __device_attach_driver+0x5f/0x66 [<ffffffffa29a6708>] ? driver_probe_device+0x1fa/0x1fa [<ffffffffa29a4a60>] bus_for_each_drv+0x87/0xaa [<ffffffffa29a688a>] __device_attach+0x9d/0x101 [<ffffffffa29a6913>] device_initial_probe+0x13/0x15 [<ffffffffa29a5ae6>] bus_probe_device+0x33/0x96 [<ffffffffa29a3d19>] device_add+0x328/0x547 [<ffffffffa2a09355>] usb_set_configuration+0x624/0x674 [<ffffffffa2a11949>] generic_probe+0x45/0x77 [<ffffffffa2a0a962>] usb_probe_device+0x2d/0x40 [<ffffffffa29a65bc>] driver_probe_device+0xae/0x1fa [<ffffffffa29a6767>] __device_attach_driver+0x5f/0x66 [<ffffffffa29a6708>] ? driver_probe_device+0x1fa/0x1fa [<ffffffffa29a4a60>] bus_for_each_drv+0x87/0xaa [<ffffffffa29a688a>] __device_attach+0x9d/0x101 [<ffffffffa29a6913>] device_initial_probe+0x13/0x15 [<ffffffffa29a5ae6>] bus_probe_device+0x33/0x96 [<ffffffffa29a3d19>] device_add+0x328/0x547 [<ffffffffa29030bc>] ? add_device_randomness+0x111/0x130 [<ffffffffa2a00967>] usb_new_device+0x2a2/0x3c0 [<ffffffffa2a02ddc>] hub_thread+0xa3d/0xeed [<ffffffffa2c2010d>] ? __schedule+0x41e/0x5ac [<ffffffffa26957ce>] ? finish_wait+0x62/0x62 [<ffffffffa2a0239f>] ? usb_reset_device+0x16a/0x16a [<ffffffffa267b255>] kthread+0x108/0x110 [<ffffffffa267b14d>] ? __kthread_parkme+0x67/0x67 [<ffffffffa2c23b2c>] ret_from_fork+0x7c/0xb0 [<ffffffffa267b14d>] ? __kthread_parkme+0x67/0x67 Signed-off-by:
Stephen Barber <smbarber@chromium.org> Signed-off-by:
-
- 17 Aug, 2017 14 commits
-
-
Takashi Iwai authored
C-Media devices (at least some models) mute the playback stream when volumes are set to the minimum value. But this isn't informed via TLV and the user-space, typically PulseAudio, gets confused as if it's still played in a low volume. This patch adds the new flag, min_mute, to struct usb_mixer_elem_info for indicating that the mixer element is with the minimum-mute volume. This flag is set for known C-Media devices in snd_usb_mixer_fu_apply_quirk() in turn. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196669 Cc: <stable@vger.kernel.org> Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Done using Coccinelle Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Signed-off-by:
-
Bhumika Goyal authored
Make this const as it is only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make this const as it is only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Done using Coccinelle Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make this const as it is only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Bhumika Goyal authored
Make this const as it is only used in a copy operation. Done using Coccinelle. Signed-off-by:
-
Arvind Yadav authored
pnp_card_device_id are not supposed to change at runtime. All functions working with pnp_card_device_id provided by <linux/pnp.h> work with const pnp_card_device_id. So mark the non-const structs as const. Signed-off-by:
-
