1. 31 May, 2011 6 commits
    • Jussi Kivilinna's avatar
      zd1211rw: fix to work on OHCI · 59342f6a
      Jussi Kivilinna authored
      zd1211 devices register 'EP 4 OUT' endpoint as Interrupt type on USB 2.0:
      
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x04  EP 4 OUT
              bmAttributes            3
                Transfer Type            Interrupt
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0040  1x 64 bytes
              bInterval               1
      
      However on USB 1.1 endpoint becomes Bulk:
      
            Endpoint Descriptor:
              bLength                 7
              bDescriptorType         5
              bEndpointAddress     0x04  EP 4 OUT
              bmAttributes            2
                Transfer Type            Bulk
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0040  1x 64 bytes
              bInterval               0
      
      Commit 37939810
      
       assumed that endpoint is
      always interrupt type and changed usb_bulk_msg() calls to usb_interrupt_msg().
      
      Problem here is that usb_bulk_msg() on interrupt endpoint selfcorrects the
      call and changes requested pipe to interrupt type (see usb_bulk_msg).
      However with usb_interrupt_msg() on bulk endpoint does not correct the
      pipe type to bulk, but instead URB is submitted with interrupt type pipe.
      
      So pre-2.6.39 used usb_bulk_msg() and therefore worked with both endpoint
      types, however in 2.6.39 usb_interrupt_msg() with bulk endpoint causes
      ohci_hcd to fail submitted URB instantly with -ENOSPC and preventing zd1211rw
      from working with OHCI.
      
      Fix this by detecting endpoint type and using correct endpoint/pipe types
      for URB. Also fix asynchronous zd_usb_iowrite16v_async() to use right
      URB type on 'EP 4 OUT'.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      59342f6a
    • Luciano Coelho's avatar
      wl12xx: fix oops in sched_scan when forcing a passive scan · 66870b1c
      Luciano Coelho authored
      
      
      Fix kernel oops when trying to use passive scheduled scans.  The
      reason was that in passive scans there are no SSIDs, so there was a
      NULL pointer dereference.
      
      To solve the problem, we now check the number of SSIDs provided in the
      sched_scan request and only access the list if there's one or more
      (ie. passive scan is not forced).  We also force all the channels to
      be passive by adding the IEEE80211_CHAN_PASSIVE_SCAN flag locally
      before the checks in the wl1271_scan_get_sched_scan_channels()
      function.
      Signed-off-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      66870b1c
    • Luciano Coelho's avatar
      wl12xx: add separate config value for DFS dwell time on sched scan · 50a66d7f
      Luciano Coelho authored
      
      
      Use a different value for DFS dwell time when performing a scheduled
      scan.  Previously we were using the same value as for normal passive
      scans.  This adds some flexibility between these two different types
      of passive scan.
      
      For now we use 150 TUs for DFS channel dwell time.  This may need to
      be fine-tuned in the future.
      Signed-off-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      50a66d7f
    • Luciano Coelho's avatar
      wl12xx: fix DFS channels handling in scheduled scan · 2497a246
      Luciano Coelho authored
      
      
      DFS channels were never getting included in the scheduled scans,
      because they always contain the passive flag as well and the call was
      asking for DFS and active channels.
      
      Fix this by ignoring the passive flag when collecting DFS channels.
      Also, move the DFS channels in the channel list before the 5GHz active
      channels (this was implemented in the FW differently than specified).
      Signed-off-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2497a246
    • Luciano Coelho's avatar
      wl12xx: fix passive and radar channel generation for scheduled scan · dd086821
      Luciano Coelho authored
      
      
      We were comparing bitwise AND results with a boolean, so when the
      boolean was set to true, it was not matching as it should.
      
      Fix this by booleanizing the bitwise AND results with !!.
      Signed-off-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      dd086821
    • Daniel Drake's avatar
      libertas: Set command sequence number later to ensure consistency · 71005be4
      Daniel Drake authored
      
      
      Before this patch, the command sequence number is being set before
      lbs_queue_cmd() adds the command to the queue. However, lbs_queue_cmd()
      sometimes forces commands to queue-jump (e.g. CMD_802_11_WAKEUP_CONFIRM).
      It currently does this without considering that sequence numbers might need
      adjusting to keep things running in order.
      
      Fix this by setting the sequence number at a later stage, just before
      we're actually submitting the command to the hardware. Also fixes a
      possible race where seqnum was being modified outside of the driver
      lock.
      Signed-off-by: default avatarDaniel Drake <dsd@laptop.org>
      Acked-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      71005be4
  2. 27 May, 2011 13 commits
  3. 26 May, 2011 19 commits
  4. 25 May, 2011 2 commits
    • Flavio Leitner's avatar
      bonding: documentation and code cleanup for resend_igmp · 94265cf5
      Flavio Leitner authored
      
      
      Improves the documentation about how IGMP resend parameter
      works, fix two missing checks and coding style issues.
      Signed-off-by: default avatarFlavio Leitner <fbl@redhat.com>
      Acked-by: default avatarRick Jones <rick.jones2@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94265cf5
    • Neil Horman's avatar
      bonding: prevent deadlock on slave store with alb mode (v3) · 9fe0617d
      Neil Horman authored
      
      
      This soft lockup was recently reported:
      
      [root@dell-per715-01 ~]# echo +bond5 > /sys/class/net/bonding_masters
      [root@dell-per715-01 ~]# echo +eth1 > /sys/class/net/bond5/bonding/slaves
      bonding: bond5: doing slave updates when interface is down.
      bonding bond5: master_dev is not up in bond_enslave
      [root@dell-per715-01 ~]# echo -eth1 > /sys/class/net/bond5/bonding/slaves
      bonding: bond5: doing slave updates when interface is down.
      
      BUG: soft lockup - CPU#12 stuck for 60s! [bash:6444]
      CPU 12:
      Modules linked in: bonding autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc
      be2d
      Pid: 6444, comm: bash Not tainted 2.6.18-262.el5 #1
      RIP: 0010:[<ffffffff80064bf0>]  [<ffffffff80064bf0>]
      .text.lock.spinlock+0x26/00
      RSP: 0018:ffff810113167da8  EFLAGS: 00000286
      RAX: ffff810113167fd8 RBX: ffff810123a47800 RCX: 0000000000ff1025
      RDX: 0000000000000000 RSI: ffff810123a47800 RDI: ffff81021b57f6f8
      RBP: ffff81021b57f500 R08: 0000000000000000 R09: 000000000000000c
      R10: 00000000ffffffff R11: ffff81011d41c000 R12: ffff81021b57f000
      R13: 0000000000000000 R14: 0000000000000282 R15: 0000000000000282
      FS:  00002b3b41ef3f50(0000) GS:ffff810123b27940(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00002b3b456dd000 CR3: 000000031fc60000 CR4: 00000000000006e0
      
      Call Trace:
       [<ffffffff80064af9>] _spin_lock_bh+0x9/0x14
       [<ffffffff886937d7>] :bonding:tlb_clear_slave+0x22/0xa1
       [<ffffffff8869423c>] :bonding:bond_alb_deinit_slave+0xba/0xf0
       [<ffffffff8868dda6>] :bonding:bond_release+0x1b4/0x450
       [<ffffffff8006457b>] __down_write_nested+0x12/0x92
       [<ffffffff88696ae4>] :bonding:bonding_store_slaves+0x25c/0x2f7
       [<ffffffff801106f7>] sysfs_write_file+0xb9/0xe8
       [<ffffffff80016b87>] vfs_write+0xce/0x174
       [<ffffffff80017450>] sys_write+0x45/0x6e
       [<ffffffff8005d28d>] tracesys+0xd5/0xe0
      
      It occurs because we are able to change the slave configuarion of a bond while
      the bond interface is down.  The bonding driver initializes some data structures
      only after its ndo_open routine is called.  Among them is the initalization of
      the alb tx and rx hash locks.  So if we add or remove a slave without first
      opening the bond master device, we run the risk of trying to lock/unlock a
      spinlock that has garbage for data in it, which results in our above softlock.
      
      Note that sometimes this works, because in many cases an unlocked spinlock has
      the raw_lock parameter initialized to zero (meaning that the kzalloc of the
      net_device private data is equivalent to calling spin_lock_init), but thats not
      true in all cases, and we aren't guaranteed that condition, so we need to pass
      the relevant spinlocks through the spin_lock_init function.
      
      Fix it by moving the spin_lock_init calls for the tx and rx hashtable locks to
      the ndo_init path, so they are ready for use by the bond_store_slaves path.
      
      Change notes:
      v2) Based on conversation with Jay and Nicolas it seems that the ability to
      enslave devices while the bond master is down should be safe to do.  As such
      this is an outlier bug, and so instead we'll just initalize the errant spinlocks
      in the init path rather than the open path, solving the problem.  We'll also
      remove the warnings about the bond being down during enslave operations, since
      it should be safe
      
      v3) Fix spelling error
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: jtluka@redhat.com
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: nicolas.2p.debian@gmail.com
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9fe0617d