1. 29 9月, 2015 9 次提交
  2. 25 8月, 2015 7 次提交
  3. 13 8月, 2015 1 次提交
  4. 21 7月, 2015 2 次提交
  5. 16 6月, 2015 2 次提交
  6. 15 6月, 2015 11 次提交
  7. 10 6月, 2015 1 次提交
    • J
      mac80211: convert HW flags to unsigned long bitmap · 30686bf7
      Johannes Berg 提交于
      As we're running out of hardware capability flags pretty quickly,
      convert them to use the regular test_bit() style unsigned long
      bitmaps.
      
      This introduces a number of helper functions/macros to set and to
      test the bits, along with new debugfs code.
      
      The occurrences of an explicit __clear_bit() are intentional, the
      drivers were never supposed to change their supported bits on the
      fly. We should investigate changing this to be a per-frame flag.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      30686bf7
  8. 08 6月, 2015 3 次提交
  9. 28 5月, 2015 4 次提交
    • A
      brcmfmac: avoid null pointer access when brcmf_msgbuf_get_pktid() fails · 7d072b40
      Arend van Spriel 提交于
      The function brcmf_msgbuf_get_pktid() may return a NULL pointer so
      the callers should check the return pointer before accessing it to
      avoid the crash below (see [1]):
      
      brcmfmac: brcmf_msgbuf_get_pktid: Invalid packet id 273 (not in use)
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
      IP: [<ffffffff8145b225>] skb_pull+0x5/0x50
      PGD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: pci_stub vboxpci(O) vboxnetflt(O) vboxnetadp(O) vboxdrv(O)
       snd_hda_codec_hdmi bnep mousedev hid_generic ushwmon msr ext4 crc16 mbcache
       jbd2 sd_mod uas usb_storage ahci libahci libata scsi_mod xhci_pci xhci_hcd
       usbcore usb_common
      CPU: 0 PID: 1661 Comm: irq/61-brcmf_pc Tainted: G O    4.0.1-MacbookPro-ARCH #1
      Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6,
       BIOS MBP121.88Z.0167.B02.1503241251 03/24/2015
      task: ffff880264203cc0 ti: ffff88025ffe4000 task.ti: ffff88025ffe4000
      RIP: 0010:[<ffffffff8145b225>]  [<ffffffff8145b225>] skb_pull+0x5/0x50
      RSP: 0018:ffff88025ffe7d40  EFLAGS: 00010202
      RAX: 0000000000000000 RBX: ffff88008a33c000 RCX: 0000000000000044
      RDX: 0000000000000000 RSI: 000000000000004a RDI: 0000000000000000
      RBP: ffff88025ffe7da8 R08: 0000000000000096 R09: 000000000000004a
      R10: 0000000000000000 R11: 000000000000048e R12: ffff88025ff14f00
      R13: 0000000000000000 R14: ffff880263b48200 R15: ffff88008a33c000
      FS:  0000000000000000(0000) GS:ffff88026ec00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000080 CR3: 000000000180b000 CR4: 00000000003407f0
      Stack:
       ffffffffa06aed74 ffff88025ffe7dc8 ffff880263b48270 ffff880263b48278
       05ea88020000004a 0002ffff81014635 000000001720b2f6 ffff88026ec116c0
       ffff880263b48200 0000000000010000 ffff880263b4ae00 ffff880264203cc0
      Call Trace:
       [<ffffffffa06aed74>] ? brcmf_msgbuf_process_rx+0x404/0x480 [brcmfmac]
       [<ffffffff810cea60>] ? irq_finalize_oneshot.part.30+0xf0/0xf0
       [<ffffffffa06afb55>] brcmf_proto_msgbuf_rx_trigger+0x35/0xf0 [brcmfmac]
       [<ffffffffa06baf2a>] brcmf_pcie_isr_thread_v2+0x8a/0x130 [brcmfmac]
       [<ffffffff810cea80>] irq_thread_fn+0x20/0x50
       [<ffffffff810ceddf>] irq_thread+0x13f/0x170
       [<ffffffff810cebf0>] ? wake_threads_waitq+0x30/0x30
       [<ffffffff810ceca0>] ? irq_thread_dtor+0xb0/0xb0
       [<ffffffff81092a08>] kthread+0xd8/0xf0
       [<ffffffff81092930>] ? kthread_create_on_node+0x1c0/0x1c0
       [<ffffffff8156d898>] ret_from_fork+0x58/0x90
       [<ffffffff81092930>] ? kthread_create_on_node+0x1c0/0x1c0
      Code: 01 83 e2 f7 88 50 01 48 83 c4 08 5b 5d f3 c3 0f 1f 80 00 00 00 00 83 e2
       f7 88 50 01 c3 66 0f 1f 84 00 00 00 00 00 0f 1f
      RIP  [<ffffffff8145b225>] skb_pull+0x5/0x50
       RSP <ffff88025ffe7d40>
      CR2: 0000000000000080
      ---[ end trace b074c0f90e7c997d ]---
      
      [1] http://mid.gmane.org/20150430193259.GA5630@googlemail.com
      
      Cc: <stable@vger.kernel.org> # v3.18, v3.19, v4.0, v4.1
      Reported-by: NMichael Hornung <mhornung.linux@gmail.com>
      Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
      Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      7d072b40
    • R
      brcmfmac: allow NVRAM values to contain spaces · fc23e81e
      Rafał Miłecki 提交于
      Platform NVRAMs often contain values with spaces. Even if right now most
      firmware-supported entries are simple values, we shouldn't reject these
      with spaces. It was semi-confirmed by Broadcom in the early patch adding
      support for platform NVRAMs.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Acked-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      fc23e81e
    • R
      brcmfmac: treat \0 as end of comment when parsing NVRAM · 279b4cb7
      Rafał Miłecki 提交于
      This fixes brcmfmac dealing with NVRAM coming from platform e.g. from a
      flash MTD partition. In such cases entries are separated by \0 instead
      of \n which caused ignoring whole content after the first "comment".
      While platform NVRAM doesn't usually contain comments, we switch to
      COMMENT state after e.g. finding an unexpected char in key name.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      279b4cb7
    • R
      brcmfmac: simplify check finding NVRAM v1 device path · 5d08408b
      Rafał Miłecki 提交于
      With a simple use of snprintf and small buffer we can compare NVRAM
      entry value with a full string. This way we avoid checking random chars
      at magic offsets.
      Tested on BCM43602 with NVRAM hacked to use v1 format.
      Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      5d08408b