1. 28 Apr, 2015 2 commits
    • Anantha Krishnan's avatar
      Bluetooth: Add support for Acer [0489:e078] · 6a64bf94
      Anantha Krishnan authored
      [ Upstream commit 4b552bc9 ]
      
      Add support for the QCA6174 chip.
      
          T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
          D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
          P:  Vendor=0489 ProdID=e078 Rev=00.01
          C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
          I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
          I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Signed-off-by: default avatarAnantha Krishnan <ananthk@codeaurora.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6a64bf94
    • Marcel Holtmann's avatar
      Bluetooth: Add support for Broadcom device of Asus Z97-DELUXE motherboard · d94e38ae
      Marcel Holtmann authored
      [ Upstream commit c2aef6e8 ]
      
      The Asus Z97-DELUXE motherboard contains a Broadcom based Bluetooth
      controller on the USB bus. However vendor and product ID are listed
      as ASUSTek Computer.
      
      T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
      D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0b05 ProdID=17cf Rev= 1.12
      S:  Manufacturer=Broadcom Corp
      S:  Product=BCM20702A0
      S:  SerialNumber=54271E910064
      C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=  0mA
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      Reported-by: default avatarJerome Leclanche <jerome@leclan.ch>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d94e38ae
  2. 27 Apr, 2015 33 commits
  3. 24 Apr, 2015 5 commits
    • Igor Mammedov's avatar
      kvm: avoid page allocation failure in kvm_set_memory_region() · b94e91cc
      Igor Mammedov authored
      [ Upstream commit 74496134 ]
      
      KVM guest can fail to startup with following trace on host:
      
      qemu-system-x86: page allocation failure: order:4, mode:0x40d0
      Call Trace:
        dump_stack+0x47/0x67
        warn_alloc_failed+0xee/0x150
        __alloc_pages_direct_compact+0x14a/0x150
        __alloc_pages_nodemask+0x776/0xb80
        alloc_kmem_pages+0x3a/0x110
        kmalloc_order+0x13/0x50
        kmemdup+0x1b/0x40
        __kvm_set_memory_region+0x24a/0x9f0 [kvm]
        kvm_set_ioapic+0x130/0x130 [kvm]
        kvm_set_memory_region+0x21/0x40 [kvm]
        kvm_vm_ioctl+0x43f/0x750 [kvm]
      
      Failure happens when attempting to allocate pages for
      'struct kvm_memslots', however it doesn't have to be
      present in physically contiguous (kmalloc-ed) address
      space, change allocation to kvm_kvzalloc() so that
      it will be vmalloc-ed when its size is more then a page.
      Signed-off-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b94e91cc
    • Dave Chinner's avatar
      xfs: ensure truncate forces zeroed blocks to disk · 48ca7d78
      Dave Chinner authored
      [ Upstream commit 5885ebda ]
      
      A new fsync vs power fail test in xfstests indicated that XFS can
      have unreliable data consistency when doing extending truncates that
      require block zeroing. The blocks beyond EOF get zeroed in memory,
      but we never force those changes to disk before we run the
      transaction that extends the file size and exposes those blocks to
      userspace. This can result in the blocks not being correctly zeroed
      after a crash.
      
      Because in-memory behaviour is correct, tools like fsx don't pick up
      any coherency problems - it's not until the filesystem is shutdown
      or the system crashes after writing the truncate transaction to the
      journal but before the zeroed data in the page cache is flushed that
      the issue is exposed.
      
      Fix this by also flushing the dirty data in memory region between
      the old size and new size when we've found blocks that need zeroing
      in the truncate process.
      Reported-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      48ca7d78
    • Omar Sandoval's avatar
      ext4: fix indirect punch hole corruption · a6995736
      Omar Sandoval authored
      [ Upstream commit 6f30b7e3 ]
      
      Commit 4f579ae7 (ext4: fix punch hole on files with indirect
      mapping) rewrote FALLOC_FL_PUNCH_HOLE for ext4 files with indirect
      mapping. However, there are bugs in several corner cases. This fixes 5
      distinct bugs:
      
      1. When there is at least one entire level of indirection between the
      start and end of the punch range and the end of the punch range is the
      first block of its level, we can't return early; we have to free the
      intervening levels.
      
      2. When the end is at a higher level of indirection than the start and
      ext4_find_shared returns a top branch for the end, we still need to free
      the rest of the shared branch it returns; we can't decrement partial2.
      
      3. When a punch happens within one level of indirection, we need to
      converge on an indirect block that contains the start and end. However,
      because the branches returned from ext4_find_shared do not necessarily
      start at the same level (e.g., the partial2 chain will be shallower if
      the last block occurs at the beginning of an indirect group), the walk
      of the two chains can end up "missing" each other and freeing a bunch of
      extra blocks in the process. This mismatch can be handled by first
      making sure that the chains are at the same level, then walking them
      together until they converge.
      
      4. When the punch happens within one level of indirection and
      ext4_find_shared returns a top branch for the start, we must free it,
      but only if the end does not occur within that branch.
      
      5. When the punch happens within one level of indirection and
      ext4_find_shared returns a top branch for the end, then we shouldn't
      free the block referenced by the end of the returned chain (this mirrors
      the different levels case).
      Signed-off-by: default avatarOmar Sandoval <osandov@osandov.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a6995736
    • Preeti U Murthy's avatar
      timers/tick/broadcast-hrtimer: Fix suspicious RCU usage in idle loop · b27b4b79
      Preeti U Murthy authored
      [ Upstream commit a127d2bc ]
      
      The hrtimer mode of broadcast queues hrtimers in the idle entry
      path so as to wakeup cpus in deep idle states. The associated
      call graph is :
      
      	cpuidle_idle_call()
      	|____ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, ....))
      	     |_____tick_broadcast_set_event()
      		   |____clockevents_program_event()
      			|____bc_set_next()
      
      The hrtimer_{start/cancel} functions call into tracing which uses RCU.
      But it is not legal to call into RCU in cpuidle because it is one of the
      quiescent states. Hence protect this region with RCU_NONIDLE which informs
      RCU that the cpu is momentarily non-idle.
      
      As an aside it is helpful to point out that the clock event device that is
      programmed here is not a per-cpu clock device; it is a
      pseudo clock device, used by the broadcast framework alone.
      The per-cpu clock device programming never goes through bc_set_next().
      Signed-off-by: default avatarPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: linuxppc-dev@ozlabs.org
      Cc: mpe@ellerman.id.au
      Cc: tglx@linutronix.de
      Link: http://lkml.kernel.org/r/20150318104705.17763.56668.stgit@preeti.in.ibm.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b27b4b79
    • Majd Dibbiny's avatar
      IB/mlx4: Saturate RoCE port PMA counters in case of overflow · 02d51afc
      Majd Dibbiny authored
      [ Upstream commit 61a3855b ]
      
      For RoCE ports, we set the u32 PMA values based on u64 HCA counters. In case of
      overflow, according to the IB spec, we have to saturate a counter to its
      max value, do that.
      
      Fixes: c3779134 ('IB/mlx4: Support PMA counters for IBoE')
      Signed-off-by: default avatarMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: default avatarHadar Hen Zion <hadarh@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      02d51afc