1. 29 Apr, 2009 3 commits
  2. 28 Apr, 2009 4 commits
    • Marcel Holtmann's avatar
      Bluetooth: Fix connection establishment with low security requirement · 3fdca1e1
      Marcel Holtmann authored
      The Bluetooth 2.1 specification introduced four different security modes
      that can be mapped using Legacy Pairing and Simple Pairing. With the
      usage of Simple Pairing it is required that all connections (except
      the ones for SDP) are encrypted. So even the low security requirement
      mandates an encrypted connection when using Simple Pairing. When using
      Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
      since it causes interoperability issues.
      
      To support this properly the low security requirement translates into
      different host controller transactions depending if Simple Pairing is
      supported or not. However in case of Simple Pairing the command to
      switch on encryption after a successful authentication is not triggered
      for the low security mode. This patch fixes this and actually makes
      the logic to differentiate between Simple Pairing and Legacy Pairing
      a lot simpler.
      
      Based on a report by Ville Tervo <ville.tervo@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3fdca1e1
    • Marcel Holtmann's avatar
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann authored
      The Bluetooth stack uses a reference counting for all established ACL
      links and if no user (L2CAP connection) is present, the link will be
      terminated to save power. The problem part is the dedicated pairing
      when using Legacy Pairing (Bluetooth 2.0 and before). At that point
      no user is present and pairing attempts will be disconnected within
      10 seconds or less. In previous kernel version this was not a problem
      since the disconnect timeout wasn't triggered on incoming connections
      for the first time. However this caused issues with broken host stacks
      that kept the connections around after dedicated pairing. When the
      support for Simple Pairing got added, the link establishment procedure
      needed to be changed and now causes issues when using Legacy Pairing
      
      When using Simple Pairing it is possible to do a proper reference
      counting of ACL link users. With Legacy Pairing this is not possible
      since the specification is unclear in some areas and too many broken
      Bluetooth devices have already been deployed. So instead of trying to
      deal with all the broken devices, a special pairing timeout will be
      introduced that increases the timeout to 60 seconds when pairing is
      triggered.
      
      If a broken devices now puts the stack into an unforeseen state, the
      worst that happens is the disconnect timeout triggers after 120 seconds
      instead of 4 seconds. This allows successful pairings with legacy and
      broken devices now.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      052b30b0
    • Roger Quadros's avatar
      Bluetooth: Ensure that HCI sysfs add/del is preempt safe · f3784d83
      Roger Quadros authored
      Use a different work_struct variables for add_conn() and del_conn() and
      use single work queue instead of two for adding and deleting connections.
      
      It eliminates the following error on a preemptible kernel:
      
      [  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
      [  204.370697] pgd = c0004000
      [  204.373443] [0000000c] *pgd=00000000
      [  204.378601] Internal error: Oops: 17 [#1] PREEMPT
      [  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
      [  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
      [  204.443664] PC is at klist_put+0x2c/0xb4
      [  204.447601] LR is at klist_put+0x18/0xb4
      [  204.451568] pc : [<c0270f08>]    lr : [<c0270ef4>]    psr: a0000113
      [  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
      [  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
      [  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
      [  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
      [  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
      [  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
      [  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)
      Signed-off-by: default avatarRoger Quadros <ext-roger.quadros@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f3784d83
    • Eric Dumazet's avatar
      net: Avoid extra wakeups of threads blocked in wait_for_packet() · bf368e4e
      Eric Dumazet authored
      In 2.6.25 we added UDP mem accounting.
      
      This unfortunatly added a penalty when a frame is transmitted, since
      we have at TX completion time to call sock_wfree() to perform necessary
      memory accounting. This calls sock_def_write_space() and utimately
      scheduler if any thread is waiting on the socket.
      Thread(s) waiting for an incoming frame was scheduled, then had to sleep
      again as event was meaningless.
      
      (All threads waiting on a socket are using same sk_sleep anchor)
      
      This adds lot of extra wakeups and increases latencies, as noted
      by Christoph Lameter, and slows down softirq handler.
      
      Reference : http://marc.info/?l=linux-netdev&m=124060437012283&w=2 
      
      Fortunatly, Davide Libenzi recently added concept of keyed wakeups
      into kernel, and particularly for sockets (see commit
      37e5540b 
      epoll keyed wakeups: make sockets use keyed wakeups)
      
      Davide goal was to optimize epoll, but this new wakeup infrastructure
      can help non epoll users as well, if they care to setup an appropriate
      handler.
      
      This patch introduces new DEFINE_WAIT_FUNC() helper and uses it
      in wait_for_packet(), so that only relevant event can wakeup a thread
      blocked in this function.
      
      Trace of function calls from bnx2 TX completion bnx2_poll_work() is :
      __kfree_skb()
       skb_release_head_state()
        sock_wfree()
         sock_def_write_space()
          __wake_up_sync_key()
           __wake_up_common()
            receiver_wake_function() : Stops here since thread is waiting for an INPUT
      Reported-by: default avatarChristoph Lameter <cl@linux.com>
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf368e4e
  3. 27 Apr, 2009 12 commits
  4. 26 Apr, 2009 2 commits
  5. 24 Apr, 2009 4 commits
  6. 22 Apr, 2009 10 commits
  7. 21 Apr, 2009 5 commits
    • Reinette Chatre's avatar
      iwlwifi: DMA fixes · df833b1d
      Reinette Chatre authored
      A few issues wrt DMA were uncovered when using the driver with swiotlb.
      - driver should not use memory after it has been mapped
      - iwl3945's RX queue management cannot use all of iwlagn because
        the size of the RX buffer is different. Revert back to using
        iwl3945 specific routines that map/unmap memory.
      - no need to "dma_syn_single_range_for_cpu" followed by pci_unmap_single,
        we can just call pci_unmap_single initially
      - only map the memory area that will be used by device. this is especially
        relevant to the mapping of iwl_cmd. we should not map the entire
        structure because the meta data at the beginning of structure contains
        the address to be used later for unmapping. If the address to be used for
        unmapping is stored in mapped data it creates a problem.
      - ensure that _if_ memory needs to be modified after it is mapped that we
        call _sync_single_for_cpu first, and then release it back to device with
        _sync_single_for_device
      - we mapped the wrong length of data for host commands, with mapped length
        differing with length provided to device, fix that.
      
      Thanks to Jason Andryuk <jandryuk@gmail.com> for significant bisecting
      help to find these issues.
      
      This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1964Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Tested-by: default avatarJason Andryuk <jandryuk@gmail.com>
      Tested-by: default avatarBen Gamari <bgamari@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      df833b1d
    • Reinette Chatre's avatar
      iwlwifi: add debugging for TX path · d2ee9cd2
      Reinette Chatre authored
      When debugging TX issues it is helpful to know the seq nr of the
      frame being transmitted. The seq nr is printed as part of ucode's
      log informing us which frame is being processed. Having this information
      printed in driver log makes it easy to match activities between driver
      and firmware.
      
      Also make possible to print TX flags directly. These are already printed
      as part of entire TX command, but having it printed directly in cpu format
      makes it easier to look at.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d2ee9cd2
    • Rami Rosen's avatar
      mwl8: fix build warning. · c491bf12
      Rami Rosen authored
      This patch fixes a build warning in mwl8.c.
      (Marvell TOPDOG wireless driver)
      
      The warning it fixes is: "large integer implicitly truncated to unsigned type."
      
      The rx_ctrl member of the mwl8k_rx_desc struct is 8 bit (__u8 ), whereas trying
      to assign it a 32 bit value (which is returned from  cpu_to_le32())
      causes the compiler to issue
      a truncation warning.
      Signed-off-by: default avatarRami Rosen <ramirose@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c491bf12
    • Johannes Berg's avatar
      mac80211: fix alignment calculation bug · d1bcb9f1
      Johannes Berg authored
      When checking whether or not a given frame needs to be
      moved to be properly aligned to a 4-byte boundary, we
      use & 4 which wasn't intended, this code should check
      the lowest two bits.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d1bcb9f1
    • Reinette Chatre's avatar
      mac80211: do not print WARN if config interface · 7d42081a
      Reinette Chatre authored
      It is expected that config interface will always succeed as mac80211
      will only request what driver supports. The exception here is when a
      device has rfkill enabled. At this time the rfkill state is unknown to
      mac80211 and config interface can fail. When this happens we deal with
      this error instead of printing a WARN.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      7d42081a