1. 23 Aug, 2017 8 commits
  2. 22 Aug, 2017 9 commits
  3. 21 Aug, 2017 2 commits
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: add support for MOTU Audio Express · 3a93d082
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3a93d082
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: add specification flag for position of flag for MIDI messages · 8b460c76
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8b460c76
  4. 20 Aug, 2017 5 commits
    • Takashi Sakamoto's avatar
      ALSA: firewire-motu: destroy stream data surely at failure of card initialization · dbd7396b
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dbd7396b
    • Takashi Sakamoto's avatar
      ALSA: firewire: fix NULL pointer dereference when releasing uninitialized data of iso-resource · 0c264af7
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0c264af7
    • Takashi Sakamoto's avatar
      ALSA: control: use counting semaphore as write lock for ELEM_WRITE operation · 5bbb1ab5
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5bbb1ab5
    • Takashi Sakamoto's avatar
      ALSA: control: code refactoring for ELEM_READ/ELEM_WRITE operations · becf9e5d
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      becf9e5d
    • Takashi Sakamoto's avatar
      ALSA: control: queue events within locking of controls_rwsem for ELEM_WRITE operation · 7b42cfaf
      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: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7b42cfaf
  5. 19 Aug, 2017 13 commits
  6. 18 Aug, 2017 3 commits
    • Takashi Iwai's avatar
      ALSA: emu10k1: Fix forgotten user-copy conversion in init code · 0b36f2bd
      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: default avatarTakashi Iwai <tiwai@suse.de>
      0b36f2bd
    • Jussi Laako's avatar
      ALSA: usb-audio: add DSD support for new Amanero PID · ed993c6f
      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: default avatarJussi Laako <jussi@sonarnerd.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ed993c6f
    • Stephen Barber's avatar
      ALSA: usb-audio: don't retry snd_usb_ctl_msg after timeout · 5a9a8eca
      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: default avatarStephen Barber <smbarber@chromium.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5a9a8eca