1. 13 Nov, 2014 4 commits
    • Johan Hedberg's avatar
      Bluetooth: Fix L2CAP socket lock nesting level · 3b2ab39e
      Johan Hedberg authored
      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: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3b2ab39e
    • Johan Hedberg's avatar
      Bluetooth: Use proper nesting annotation for l2cap_chan lock · abe84903
      Johan Hedberg authored
      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: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      abe84903
    • Alexander Aring's avatar
      at86rf230: remove interframe spacing time workaround · 24ccb9f4
      Alexander Aring authored
      This patch removes the interframe spacing time workaround from at86rf230
      driver and use the mac802154 one. The interframe spacing time differs at
      at86rf212 and channel setting. This patch fix this handling which is also
      a new workaround and should be moved into mac802154 while channel
      setting.
      Signed-off-by: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      24ccb9f4
    • Alexander Aring's avatar
      mac802154: add interframe spacing time handling · 61f2dcba
      Alexander Aring authored
      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: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      61f2dcba
  2. 12 Nov, 2014 20 commits
  3. 11 Nov, 2014 2 commits
  4. 10 Nov, 2014 2 commits
  5. 09 Nov, 2014 12 commits