1. 17 11月, 2014 8 次提交
  2. 15 11月, 2014 9 次提交
  3. 13 11月, 2014 5 次提交
    • J
      Bluetooth: Fix correct nesting for 6lowpan server channel · 2773b024
      Johan Hedberg 提交于
      Server channels in BT_LISTEN state should use L2CAP_NESTING_PARENT. This
      patch fixes the nesting value for the 6lowpan channel.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2773b024
    • J
      Bluetooth: Fix L2CAP nesting level initialization location · ff714119
      Johan Hedberg 提交于
      There's no reason why all users of L2CAP would need to worry about
      initializing chan->nesting to L2CAP_NESTING_NORMAL (which is important
      since 0 is the same as NESTING_SMP). This patch moves the initialization
      to the common place that's used to create all new channels, i.e. the
      l2cap_chan_create() function.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      ff714119
    • J
      Bluetooth: Fix L2CAP socket lock nesting level · 3b2ab39e
      Johan Hedberg 提交于
      The teardown callback for L2CAP channels is problematic in that it is
      explicitly called for all types of channels from l2cap_chan_del(),
      meaning it's not possible to hard-code a nesting level when taking the
      socket lock. The simplest way to have a correct nesting level for the
      socket locking is to use the same value as for the chan. This also means
      that the other places trying to lock parent sockets need to be update to
      use the chan value (since L2CAP_NESTING_PARENT is defined as 2 whereas
      SINGLE_DEPTH_NESTING has the value 1).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      3b2ab39e
    • J
      Bluetooth: Use proper nesting annotation for l2cap_chan lock · abe84903
      Johan Hedberg 提交于
      By default lockdep considers all L2CAP channels equal. This would mean
      that we get warnings if a channel is locked when another one's lock is
      tried to be acquired in the same thread. This kind of inter-channel
      locking dependencies exist in the form of parent-child channels as well
      as any channel wishing to elevate the security by requesting procedures
      on the SMP channel.
      
      To eliminate the chance for these lockdep warnings we introduce a
      nesting level for each channel and use that when acquiring the channel
      lock. For now there exists the earlier mentioned three identified
      categories: SMP, "normal" channels and parent channels (i.e. those in
      BT_LISTEN state). The nesting level is defined as atomic_t since we need
      access to it before the lock is actually acquired.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      abe84903
    • A
      mac802154: add interframe spacing time handling · 61f2dcba
      Alexander Aring 提交于
      This patch adds a new interframe spacing time handling into mac802154
      layer. Interframe spacing time is a time period between each transmit.
      This patch adds a high resolution timer into mac802154 and starts on
      xmit complete with corresponding interframe spacing expire time if
      ifs_handling is true. We make it variable because it depends if
      interframe spacing time is handled by transceiver or mac802154. At the
      timer complete function we wake the netdev queue again. This avoids
      new frame transmit in range of interframe spacing time.
      
      For synced driver we add no handling of interframe spacing time. This
      is currently a lack of support in all synced xmit drivers. I suppose
      it's working because the latency of workqueue which is needed to call
      spi_sync.
      Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      61f2dcba
  4. 12 11月, 2014 15 次提交
  5. 11 11月, 2014 3 次提交
    • J
      Bluetooth: 6lowpan: Remove unnecessary RCU callback · 4e790226
      Johan Hedberg 提交于
      When kfree() is all that's needed to free an object protected by RCU
      there's a kfree_rcu() convenience function that can be used. This patch
      updates the 6lowpan code to use this, thereby eliminating the need for
      the separate peer_free() function.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4e790226
    • J
      Bluetooth: Fix mgmt connected notification · 60cb49d2
      Johan Hedberg 提交于
      This patch fixes a regression that was introduced by commit
      cb77c3ec. In addition to BT_CONFIG,
      BT_CONNECTED is also a state in which we may get a remote name and need
      to indicate over mgmt the connection status. This scenario is
      particularly likely to happen for incoming connections that do not need
      authentication since there the hci_conn state will reach BT_CONNECTED
      before the remote name is received.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      60cb49d2
    • J
      Bluetooth: Fix sparse warning in amp.c · 252670c4
      Johan Hedberg 提交于
      This fixes the following sparse warning:
      
      net/bluetooth/amp.c:152:53: warning: Variable length array is used.
      
      The warning itself is probably harmless since this kind of usage of
      shash_desc is present also in other places in the kernel (there's even a
      convenience macro SHASH_DESC_ON_STACK available for defining such stack
      variables). However, dynamically allocated versions are also used in
      several places of the kernel (e.g. kernel/kexec.c and lib/digsig.c)
      which have the benefit of not exhibiting the sparse warning.
      
      Since there are no more sparse warnings in the Bluetooth subsystem after
      fixing this one it is now easier to spot whenever new ones might get
      introduced by future patches.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      252670c4