1. 30 Aug, 2017 2 commits
  2. 29 Aug, 2017 1 commit
  3. 24 Aug, 2017 6 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Correct broken procfs set up · e6b4c525
      Takashi Iwai authored
      The commit c8da9be4 ("ALSA: pcm: Adjust nine function calls
      together with a variable assignment") contained a badly incorrect
      conversion, a "status" PCM procfs creation was replaced with the next
      one.  Luckily, this could be spotted easily by the kernel runtime
      warning.
      
      Fixes: c8da9be4 ("ALSA: pcm: Adjust nine function calls together...")
      Reported-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Tested-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e6b4c525
    • Tom Rini's avatar
      ASoC: rt5677: Reintroduce I2C device IDs · 9ce76511
      Tom Rini authored
      Not all devices with ACPI and this combination of sound devices will
      have the required information provided via ACPI.  Reintroduce the I2C
      device ID to restore sound functionality on on the Chromebook 'Samus'
      model.
      
      [ More background note:
       the commit a36afb0a ("ASoC: rt5677: Introduce proper table...")
       moved the i2c ID probed via ACPI ("RT5677CE:00") to a proper
       acpi_device_id table.  Although the action itself is correct per se,
       the overseen issue is the reference id->driver_data at
       rt5677_i2c_probe() for retrieving the corresponding chip model for
       the given id.  Since id=NULL is passed for ACPI matching case, we get
       an Oops now.
      
       We already have queued more fixes for 4.14 and they already address
       the issue, but they are bigger changes that aren't preferable for the
       late 4.13-rc stage.  So, this patch just papers over the bug as a
       once-off quick fix for a particular ACPI matching.  -- tiwai ]
      
      Fixes: a36afb0a ("ASoC: rt5677: Introduce proper table for ACPI enumeration")
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9ce76511
    • Takashi Sakamoto's avatar
      ALSA: control: TLV data is unavailable at initial state of user-defined element set · b8e2204b
      Takashi Sakamoto authored
      For user-defined element set, in its initial state, TLV data is not
      registered. It's firstly available when any application register it by
      an additional operation. However, in current implementation, it's available
      in its initial state. As a result, applications get -ENXIO to read it.
      
      This commit controls its readability to manage info flags properly. In an
      initial state, elements don't have SND_CTL_ELEM_ACCESS_TLV_READ flag. Once
      TLV write operation is executed, they get the flag.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b8e2204b
    • Takashi Sakamoto's avatar
      ALSA: control: queue TLV event for a set of user-defined element · da428828
      Takashi Sakamoto authored
      In a design of user-defined element set, applications allow to change TLV
      data on the set. This operation doesn't only affects to a target element,
      but also to elements in the set.
      
      This commit generates TLV event for all of elements in the set when the TLV
      data is changed.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      da428828
    • Takashi Sakamoto's avatar
      ALSA: control: delegate TLV eventing to each driver · fb8027eb
      Takashi Sakamoto authored
      In a design of ALSA control core, a set of elements is represented by
      'struct snd_kcontrol' to share common attributes. The set of elements
      shares TLV (Type-Length-Value) data, too.
      
      On the other hand, in ALSA control interface/protocol for applications,
      a TLV operation is committed to an element. Totally, the operation can
      have sub-effect to the other elements in the set. For example, TLV_WRITE
      operation is expected to change TLV data, which returns to applications.
      Applications attempt to change the TLV data per element, but in the above
      design, they can effect to elements in the same set.
      
      As a default, ALSA control core has no implementation except for TLV_READ
      operation. Thus, the above design looks to have no issue. However, in
      kernel APIs of ALSA control component, developers can program a handler
      for any request of the TLV operation. Therefore, for elements in a set
      which has the handler, applications can commit TLV_WRITE and TLV_COMMAND
      requests.
      
      For the above scenario, ALSA control core assist notification. When the
      handler returns positive value, the core queueing an event for a requested
      element. However, this includes design defects that the event is not
      queued for the other element in a set. Actually, developers can program
      the handlers to keep per-element TLV data, but it depends on each driver.
      
      As of v4.13-rc6, there's no driver in tree to utilize the notification,
      except for user-defined element set. This commit delegates the notification
      into each driver to prevent developers from the design defects.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fb8027eb
    • Arvind Yadav's avatar
      ALSA: nm256: constify snd_ac97_res_table · 5d3806ee
      Arvind Yadav authored
      snd_ac97_res_table are not supposed to change at runtime. All functions
      working with snd_ac97_res_table provided by <sound/ac97_codec.h> work with
      const snd_ac97_res_table. So mark the non-const structs as const.
      Signed-off-by: default avatarArvind Yadav <arvind.yadav.cs@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5d3806ee
  4. 23 Aug, 2017 12 commits
  5. 22 Aug, 2017 9 commits
  6. 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
  7. 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
  8. 19 Aug, 2017 3 commits