1. 25 Jul, 2013 2 commits
  2. 24 Jun, 2013 2 commits
  3. 19 Jun, 2013 2 commits
  4. 13 Jun, 2013 4 commits
    • Arend van Spriel's avatar
      brcmfmac: free primary net_device when brcmf_bus_start() fails · fcb37018
      Arend van Spriel authored
      When initialization within brcmf_bus_start() fails on steps
      before the brcmf_net_attach() the net_device for the primary
      interface needs to be freed.
      
      This patch resolves a panic during kernel boot as reported
      by Stephen Warren.
      
      ref.: http://mid.gmane.org/51AD1F22.2080004@wwwdotorg.orgTested-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarHante Meuleman <meuleman@broadcom.com>
      Reviewed-by: default avatarPieter-Paul Giesberts <pieterpg@broadcom.com>
      Signed-off-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      fcb37018
    • Daniel Drake's avatar
      Bluetooth: btmrvl: fix thread stopping race · ea05fea9
      Daniel Drake authored
      There is currently a race condition in the btmrvl_remove_card() which
      is causing hangs on suspend for OLPC. When the race occurs,
      kthread_stop() never returns.
      
      The problem is that btmrvl_service_main_thread() calls kthread_should_stop()
      and then does a fair number of things before restarting the loop and
      sleeping.
      
      If the thread gets stopped after kthread_should_stop() is checked, but
      before the sleep happens, the thread will go to sleep and won't necessarily
      be woken up.
      
      Move the kthread_should_stop() check into a race-free place.
      Signed-off-by: default avatarDaniel Drake <dsd@laptop.org>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ea05fea9
    • Johan Hedberg's avatar
      Bluetooth: Fix conditions for HCI_Delete_Stored_Link_Key · 59f45d57
      Johan Hedberg authored
      Even though the HCI_Delete_Stored_Link_Key command is mandatory for 1.1
      and later controllers some controllers do not seem to support it
      properly as was witnessed by one Broadcom based controller:
      
      < HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7
          bdaddr 00:00:00:00:00:00 all 1
      > HCI Event: Command Complete (0x0e) plen 4
          Delete Stored Link Key (0x03|0x0012) ncmd 1
          status 0x11 deleted 0
          Error: Unsupported Feature or Parameter Value
      
      Luckily this same controller also doesn't list the command in its
      supported commands bit mask (counting from 0 bit 7 of octet 6):
      
      < HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
      > HCI Event: Command Complete (0x0e) plen 68
          Read Local Supported Commands (0x04|0x0002) ncmd 1
          status 0x00
          Commands: ffffffffffff1ffffffffffff30fffff3f
      
      Therefore, it makes sense to move sending of HCI_Delete_Stored_Link_Key
      to after receiving the supported commands response and to only send it
      if its respective bit in the mask is set. The downside of this is that
      we no longer send the HCI_Delete_Stored_Link_Key command for Bluetooth
      1.1 controllers since HCI_Read_Local_Supported_Command was introduced in
      version 1.2, but this is an acceptable penalty as the command in
      question shouldn't affect critical behavior.
      Reported-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Tested-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      59f45d57
    • Anderson Lizardo's avatar
      Bluetooth: Fix crash in l2cap_build_cmd() with small MTU · 300b962e
      Anderson Lizardo authored
      If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus
      controller, memory corruption happens due to a memcpy() call with
      negative length.
      
      Fix this crash on either incoming or outgoing connections with a MTU
      smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE:
      
      [   46.885433] BUG: unable to handle kernel paging request at f56ad000
      [   46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40
      [   46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060
      [   46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
      [   46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common
      [   46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12
      [   46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [   46.888037] Workqueue: hci0 hci_rx_work [bluetooth]
      [   46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000
      [   46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0
      [   46.888037] EIP is at memcpy+0x1d/0x40
      [   46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2
      [   46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c
      [   46.888037]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [   46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0
      [   46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [   46.888037] DR6: ffff0ff0 DR7: 00000400
      [   46.888037] Stack:
      [   46.888037]  fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000
      [   46.888037]  f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560
      [   46.888037]  f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2
      [   46.888037] Call Trace:
      [   46.888037]  [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth]
      [   46.888037]  [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth]
      [   46.888037]  [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth]
      [   46.888037]  [<c019b37b>] ? trace_hardirqs_off+0xb/0x10
      [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
      [   46.888037]  [<c064ad20>] ? mutex_lock_nested+0x280/0x360
      [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
      [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
      [   46.888037]  [<c064ad08>] ? mutex_lock_nested+0x268/0x360
      [   46.888037]  [<c01a125b>] ? trace_hardirqs_on+0xb/0x10
      [   46.888037]  [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth]
      [   46.888037]  [<c01a0ff8>] ? mark_held_locks+0x68/0x110
      [   46.888037]  [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150
      [   46.888037]  [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0
      [   46.888037]  [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth]
      [   46.888037]  [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth]
      [   46.888037]  [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth]
      [   46.888037]  [<c0158979>] process_one_work+0x1a9/0x600
      [   46.888037]  [<c01588fb>] ? process_one_work+0x12b/0x600
      [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
      [   46.888037]  [<c015922e>] ? worker_thread+0x19e/0x320
      [   46.888037]  [<c0159187>] worker_thread+0xf7/0x320
      [   46.888037]  [<c0159090>] ? rescuer_thread+0x290/0x290
      [   46.888037]  [<c01602f8>] kthread+0xa8/0xb0
      [   46.888037]  [<c0656777>] ret_from_kernel_thread+0x1b/0x28
      [   46.888037]  [<c0160250>] ? flush_kthread_worker+0x120/0x120
      [   46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89
      [   46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c
      [   46.888037] CR2: 00000000f56ad000
      [   46.888037] ---[ end trace 0217c1f4d78714a9 ]---
      Signed-off-by: default avatarAnderson Lizardo <anderson.lizardo@openbossa.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      300b962e
  5. 12 Jun, 2013 24 commits
  6. 04 Jun, 2013 3 commits
  7. 28 May, 2013 3 commits
    • Gabor Juhos's avatar
      ath9k: use correct OTP register offsets for AR9550 · add295a4
      Gabor Juhos authored
      Accessing the OTP memory on AR9950 causes a data bus
      like this:
      
        Data bus error, epc == 801f7774, ra == 801f7774
        Oops[#1]:
        CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-rc3 #592
        task: 87c28000 ti: 87c22000 task.ti: 87c22000
        $ 0   : 00000000 00000061 deadc0de 00000000
        $ 4   : b8115f18 00015f18 00000007 00000004
        $ 8   : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c
        $12   : 7c7c3c7c 80320a68 00000000 7c7c7c3c
        $16   : 87cd8010 00015f18 00000007 00000000
        $20   : 00000064 00000004 87c23c7c 8035210c
        $24   : 00000000 801f3674
        $28   : 87c22000 87c23b48 00000001 801f7774
        Hi    : 00000000
        Lo    : 00000064
        epc   : 801f7774 ath9k_hw_wait+0x58/0xb0
            Not tainted
        ra    : 801f7774 ath9k_hw_wait+0x58/0xb0
        Status: 1000cc03 KERNEL EXL IE
        Cause : 4080801c
        PrId  : 00019750 (MIPS 74Kc)
        Modules linked in:
        Process swapper (pid: 1, threadinfo=87c22000, task=87c28000, ts=00000000)
        Stack : 0000000f 00000061 00002710 8006240c 00000001 87cd8010 87c23bb0 87cd8010
                00000000 00000004 00000003 80210c7c 000000b3 67fa8000 0000032a 000006fe
                000003e8 00000002 00000028 87c23bf0 000003ff 80210d24 803e5630 80210e28
                00000000 00000007 87cd8010 00007044 00000004 00000061 000003ff 000001ff
                87c26000 87cd8010 00000220 87cd8bb8 80210000 8020fcf4 87c22000 87c23c08
                ...
        Call Trace:
        [<801f7774>] ath9k_hw_wait+0x58/0xb0
        [<80210c7c>] ar9300_otp_read_word+0x80/0xd4
        [<80210d24>] ar9300_read_otp+0x54/0xb0
        [<8020fcf4>] ar9300_check_eeprom_header+0x1c/0x40
        [<80210fe4>] ath9k_hw_ar9300_fill_eeprom+0x118/0x39c
        [<80206650>] ath9k_hw_eeprom_init+0x74/0xb4
        [<801f96d0>] ath9k_hw_init+0x7ec/0x96c
        [<801e65ec>] ath9k_init_device+0x340/0x758
        [<801f35d0>] ath_ahb_probe+0x21c/0x2c0
        [<801c041c>] driver_probe_device+0xc0/0x1e4
        [<801c05ac>] __driver_attach+0x6c/0xa4
        [<801bea08>] bus_for_each_dev+0x64/0xa8
        [<801bfa40>] bus_add_driver+0xcc/0x24c
        [<801c0954>] driver_register+0xbc/0x17c
        [<803f8fc0>] ath9k_init+0x5c/0x88
        [<800608fc>] do_one_initcall+0xec/0x1a0
        [<803e6a68>] kernel_init_freeable+0x13c/0x200
        [<80309cdc>] kernel_init+0x1c/0xe4
        [<80062450>] ret_from_kernel_thread+0x10/0x18
      
      On the AR9550, the OTP registers are located at
      the same address as on the AR9340. Use the correct
      values to avoid the error.
      
      Cc: stable@vger.kernel.org  # 3.6+
      Signed-off-by: default avatarGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      add295a4
    • Hante Meuleman's avatar
      brcmfmac: Disable powersave mode for P2P link. · 102fd0d6
      Hante Meuleman authored
      For p2p client mode powersave mode should be kept disabled. It is
      working but inefficient. In general p2p links do no benefit from this
      mode, because these links are setup temporarily to transfer data.
      Reviewed-by: default avatarArend Van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarHante Meuleman <meuleman@broadcom.com>
      Signed-off-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      102fd0d6
    • Hante Meuleman's avatar
      brcmfmac: Add multi channel support for P2P. · 1c9d30cf
      Hante Meuleman authored
      Multi channel support was disabled. This patch will enable it and
      configure the P2P GO on the correct frequency when multi channel
      is used.
      Reviewed-by: default avatarArend Van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarHante Meuleman <meuleman@broadcom.com>
      Signed-off-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1c9d30cf