1. 04 Jan, 2017 2 commits
    • Takashi Iwai's avatar
      ALSA: hda - Fix deadlock of controller device lock at unbinding · ab949d51
      Takashi Iwai authored
      Imre Deak reported a deadlock of HD-audio driver at unbinding while
      it's still in probing.  Since we probe the codecs asynchronously in a
      work, the codec driver probe may still be kicked off while the
      controller itself is being unbound.  And, azx_remove() tries to
      process all pending tasks via cancel_work_sync() for fixing the other
      races (see commit [0b8c8219: ALSA: hda - Cancel probe work instead
      of flush at remove]), now we may meet a bizarre deadlock:
      
      Unbind snd_hda_intel via sysfs:
        device_release_driver() ->
          device_lock(snd_hda_intel) ->
            azx_remove() ->
              cancel_work_sync(azx_probe_work)
      
      azx_probe_work():
        codec driver probe() ->
           __driver_attach() ->
             device_lock(snd_hda_intel)
      
      This deadlock is caused by the fact that both device_release_driver()
      and driver_probe_device() take both the device and its parent locks at
      the same time.  The codec device sets the controller device as its
      parent, and this lock is taken before the probe() callback is called,
      while the controller remove() callback gets called also with the same
      lock.
      
      In this patch, as an ugly workaround, we unlock the controller device
      temporarily during cancel_work_sync() call.  The race against another
      bind call should be still suppressed by the parent's device lock.
      Reported-by: default avatarImre Deak <imre.deak@intel.com>
      Fixes: 0b8c8219 ("ALSA: hda - Cancel probe work instead of flush at remove")
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ab949d51
    • Kailang Yang's avatar
      ALSA: hda/realtek - Add new codec ID ALC299 · 28f1f9b2
      Kailang Yang authored
      ALC299 was similar as ALC225.
      Add headset support for ALC299.
      ALC3271 was for Dell rename.
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      28f1f9b2
  2. 03 Jan, 2017 6 commits
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 337ccfce
      Takashi Iwai authored
      337ccfce
    • Takashi Sakamoto's avatar
      ALSA: dice: ensure transmission speed for transmitted packets · b0e159fe
      Takashi Sakamoto authored
      As of kernel 4.10, ALSA dice driver is expected to be used in default
      speed. In most cases, it's S400. While, IEEE 1394 specification describes
      the other speed such as S800.
      
      According to 'TCD30XX User Guide', its link layer controller supports
      several transmission speed up to S800[0]. In Dice software interface,
      transmission speed in output direction can be configured by asynchronous
      transaction to 'TX_SPEED' offset in its address space. S800 may be
      available.
      
      This commit improves configuration of transmission unit before starting
      packet streaming for this purpose. The value of 'max_speed' in 'fw_device'
      data structure has available maximum speed decided in bus arbitration,
      thus it's within capacity of the unit.
      
      [0] TCD3xx User Guide - TCAT 1394 LLC, Revision 0.9.0-41360 (TC Applied Technologies, May 6 2015)
      http://www.tctechnologies.tc/index.php/support/support-hardware/dice-iii-detailed-documentationSigned-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b0e159fe
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: change structure member with proper type · 6b7e95d1
      Takashi Sakamoto authored
      The 'amdtp_stream' structure is initialized by a call of
      'amdtp_stream_init()'. Although a parameter of this function is for bit
      flags of packet attributes, its type is enumerator.
      
      This commit changes the type so that it's proper for a bit flags.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6b7e95d1
    • Takashi Sakamoto's avatar
      ALSA: firewire-tascam: Fix to handle error from initialization of stream data · 6a2a2f45
      Takashi Sakamoto authored
      This module has a bug not to return error code in a case that data
      structure for transmitted packets fails to be initialized.
      
      This commit fixes the bug.
      
      Fixes: 35efa5c4 ("ALSA: firewire-tascam: add streaming functionality")
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6a2a2f45
    • Takashi Sakamoto's avatar
      ALSA: fireworks: fix asymmetric API call at unit removal · e2eb31d7
      Takashi Sakamoto authored
      ALSA fireworks driver has a bug not to call an API to destroy
      'cmp_connection' structure for input direction. Currently this causes no
      issues because it just destroys 'mutex' structure, while it's better to
      fix it for future work.
      
      Fix: d23c2cc4 ("ALSA: fireworks/bebob/dice/oxfw: allow stream destructor after releasing runtime")
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e2eb31d7
    • Takashi Sakamoto's avatar
      ALSA: oxfw: add support for Mackie Onyx 1640i · 03abd33a
      Takashi Sakamoto authored
      As of kernel 4.10,  ALSA OXFW driver has no entry for Onyx 1640i produced
      by Mackie (Loud Technologies). This commit supplement it.
      
      I note that there're two models produced by Mackie (Loud Technologies),
      which have the same name 'Onyx 1640i'. The former model based on OXFW970,
      the latter model based on Dice. This is probably due to low quality of
      communication of OXFW series.
      
      Additionally, the tester reports his or her experiences to get unexpected
      result at higher sampling transmission frequency as 88.2/96.0 kHz. We
      didn't have further investigation yet[0].
      
      $ ./linux-firewire-utils/src/crpp < config_rom
                     ROM header and bus information block
                     -----------------------------------------------------------------
      400  042525ce  bus_info_length 4, crc_length 37, crc 9678
      404  31333934  bus_name "1394"
      408  20ff5003  irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 5 (64)
      40c  000ff205  company_id 000ff2     |
      410  00000fcf  device_id 0500000fcf  | EUI-64 000ff20500000fcf
      
                     root directory
                     -----------------------------------------------------------------
      414  0006c1b7  directory_length 6, crc 49591
      418  03000ff2  vendor
      41c  8100000a  --> descriptor leaf at 444
      420  17001640  model
      424  81000011  --> descriptor leaf at 468
      428  0c0083c0  node capabilities per IEEE 1394
      42c  d1000001  --> unit directory at 430
      
                     unit directory at 430
                     -----------------------------------------------------------------
      430  00040b97  directory_length 4, crc 2967
      434  1200a02d  specifier id: 1394 TA
      438  13010001  version: AV/C
      43c  17001640  model
      440  81000010  --> descriptor leaf at 480
      
                     descriptor leaf at 444
                     -----------------------------------------------------------------
      444  0008a886  leaf_length 8, crc 43142
      448  00000000  textual descriptor
      44c  00000000  minimal ASCII
      450  4c6f7564  "Loud"
      454  20546563  " Tec"
      458  686e6f6c  "hnol"
      45c  6f676965  "ogie"
      460  7320496e  "s In"
      464  632e0000  "c."
      
                     descriptor leaf at 468
                     -----------------------------------------------------------------
      468  00059fcf  leaf_length 5, crc 40911
      46c  00000000  textual descriptor
      470  00000000  minimal ASCII
      474  4f6e7978  "Onyx"
      478  20313634  " 164"
      47c  30690000  "0i"
      
                     descriptor leaf at 480
                     -----------------------------------------------------------------
      480  00059fcf  leaf_length 5, crc 40911
      484  00000000  textual descriptor
      488  00000000  minimal ASCII
      48c  4f6e7978  "Onyx"
      490  20313634  " 164"
      494  30690000  "0i"
      
      [0]: [FFADO-user] Mackie 1640i issues (finer details)
      https://sourceforge.net/p/ffado/mailman/message/35229260/Tested-by: default avatarSeth O'Bannion <saobannion@gmail.com>
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      03abd33a
  3. 01 Jan, 2017 2 commits
    • Linus Torvalds's avatar
      Linux 4.10-rc2 · 0c744ea4
      Linus Torvalds authored
      0c744ea4
    • Linus Torvalds's avatar
      Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · 4759d386
      Linus Torvalds authored
      Pull DAX updates from Dan Williams:
       "The completion of Jan's DAX work for 4.10.
      
        As I mentioned in the libnvdimm-for-4.10 pull request, these are some
        final fixes for the DAX dirty-cacheline-tracking invalidation work
        that was merged through the -mm, ext4, and xfs trees in -rc1. These
        patches were prepared prior to the merge window, but we waited for
        4.10-rc1 to have a stable merge base after all the prerequisites were
        merged.
      
        Quoting Jan on the overall changes in these patches:
      
           "So I'd like all these 6 patches to go for rc2. The first three
            patches fix invalidation of exceptional DAX entries (a bug which
            is there for a long time) - without these patches data loss can
            occur on power failure even though user called fsync(2). The other
            three patches change locking of DAX faults so that ->iomap_begin()
            is called in a more relaxed locking context and we are safe to
            start a transaction there for ext4"
      
        These have received a build success notification from the kbuild
        robot, and pass the latest libnvdimm unit tests. There have not been
        any -next releases since -rc1, so they have not appeared there"
      
      * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
        ext4: Simplify DAX fault path
        dax: Call ->iomap_begin without entry lock during dax fault
        dax: Finish fault completely when loading holes
        dax: Avoid page invalidation races and unnecessary radix tree traversals
        mm: Invalidate DAX radix tree entries only if appropriate
        ext2: Return BH_New buffers for zeroed blocks
      4759d386
  4. 30 Dec, 2016 2 commits
  5. 29 Dec, 2016 2 commits
    • Olof Johansson's avatar
      mm/filemap: fix parameters to test_bit() · 98473f9f
      Olof Johansson authored
       mm/filemap.c: In function 'clear_bit_unlock_is_negative_byte':
        mm/filemap.c:933:9: error: too few arguments to function 'test_bit'
          return test_bit(PG_waiters);
               ^~~~~~~~
      
      Fixes: b91e1302 ('mm: optimize PageWaiters bit use for unlock_page()')
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Brown-paper-bag-by: default avatarLinus Torvalds <dummy@duh.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      98473f9f
    • Linus Torvalds's avatar
      mm: optimize PageWaiters bit use for unlock_page() · b91e1302
      Linus Torvalds authored
      In commit 62906027 ("mm: add PageWaiters indicating tasks are
      waiting for a page bit") Nick Piggin made our page locking no longer
      unconditionally touch the hashed page waitqueue, which not only helps
      performance in general, but is particularly helpful on NUMA machines
      where the hashed wait queues can bounce around a lot.
      
      However, the "clear lock bit atomically and then test the waiters bit"
      sequence turns out to be much more expensive than it needs to be,
      because you get a nasty stall when trying to access the same word that
      just got updated atomically.
      
      On architectures where locking is done with LL/SC, this would be trivial
      to fix with a new primitive that clears one bit and tests another
      atomically, but that ends up not working on x86, where the only atomic
      operations that return the result end up being cmpxchg and xadd.  The
      atomic bit operations return the old value of the same bit we changed,
      not the value of an unrelated bit.
      
      On x86, we could put the lock bit in the high bit of the byte, and use
      "xadd" with that bit (where the overflow ends up not touching other
      bits), and look at the other bits of the result.  However, an even
      simpler model is to just use a regular atomic "and" to clear the lock
      bit, and then the sign bit in eflags will indicate the resulting state
      of the unrelated bit #7.
      
      So by moving the PageWaiters bit up to bit #7, we can atomically clear
      the lock bit and test the waiters bit on x86 too.  And architectures
      with LL/SC (which is all the usual RISC suspects), the particular bit
      doesn't matter, so they are fine with this approach too.
      
      This avoids the extra access to the same atomic word, and thus avoids
      the costly stall at page unlock time.
      
      The only downside is that the interface ends up being a bit odd and
      specialized: clear a bit in a byte, and test the sign bit.  Nick doesn't
      love the resulting name of the new primitive, but I'd rather make the
      name be descriptive and very clear about the limitation imposed by
      trying to work across all relevant architectures than make it be some
      generic thing that doesn't make the odd semantics explicit.
      
      So this introduces the new architecture primitive
      
          clear_bit_unlock_is_negative_byte();
      
      and adds the trivial implementation for x86.  We have a generic
      non-optimized fallback (that just does a "clear_bit()"+"test_bit(7)"
      combination) which can be overridden by any architecture that can do
      better.  According to Nick, Power has the same hickup x86 has, for
      example, but some other architectures may not even care.
      
      All these optimizations mean that my page locking stress-test (which is
      just executing a lot of small short-lived shell scripts: "make test" in
      the git source tree) no longer makes our page locking look horribly bad.
      Before all these optimizations, just the unlock_page() costs were just
      over 3% of all CPU overhead on "make test".  After this, it's down to
      0.66%, so just a quarter of the cost it used to be.
      
      (The difference on NUMA is bigger, but there this micro-optimization is
      likely less noticeable, since the big issue on NUMA was not the accesses
      to 'struct page', but the waitqueue accesses that were already removed
      by Nick's earlier commit).
      Acked-by: default avatarNick Piggin <npiggin@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Bob Peterson <rpeterso@redhat.com>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Andrew Lutomirski <luto@kernel.org>
      Cc: Andreas Gruenbacher <agruenba@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b91e1302
  6. 28 Dec, 2016 8 commits
  7. 27 Dec, 2016 17 commits
  8. 26 Dec, 2016 1 commit