1. 04 9月, 2016 1 次提交
  2. 14 8月, 2016 1 次提交
  3. 04 5月, 2016 1 次提交
  4. 14 4月, 2016 1 次提交
  5. 07 3月, 2016 1 次提交
  6. 08 1月, 2016 1 次提交
  7. 11 12月, 2015 2 次提交
    • A
      brcmfmac: add 43242 device id for LG dongle · 540313d8
      Arend van Spriel 提交于
      Got a hint on IRC that a 43242 dongle for LG smart TV's works with
      brcmfmac:
      
      > Hello - I recently got a LG AN-WF500 wireless dongle for LG's SmartTVs.
      > From the information I gathered it uses a Broadcom chipset BCM43242.
      > The device should have been supported by brcmfmac kernel driver if it used
      > USB IDs 0a5c:bd1f.
      > My device however identifies itself as "ID 043e:3101 LG Electronics USA, Inc.".
      > I then tried adding the USB ID to the driver with
      > "echo "043e 3101" > /sys/bus/usb/drivers/brcmfmac/new_id" and it just works.
      > The kernel provides the following information.
      > [15958.851291] usb 3-1.1.3: new high-speed USB device number 53 using ehci-pci
      > [15958.946723] usb 3-1.1.3: New USB device found, idVendor=043e, idProduct=3101
      > [15958.946728] usb 3-1.1.3: New USB device strings: Mfr=1, Product=4, SerialNumber=3
      > [15958.946731] usb 3-1.1.3: Product: Composite Wireless Adapter
      > [15958.946733] usb 3-1.1.3: Manufacturer: Broadcom
      > [15958.946735] usb 3-1.1.3: SerialNumber: 28458
      Reported-by: NJohannes Berg <johannes@sipsolutions.net>
      Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
      Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      540313d8
    • K
      brcmfmac: fix waitqueue_active without memory barrier in brcmfmac driver · a7decc44
      Kosuke Tatsukawa 提交于
      brcmf_msgbuf_ioctl_resp_wake() seems to be missing a memory barrier
      which might cause the waker to not notice the waiter and miss sending a
      wake_up as in the following figure.
      
        brcmf_msgbuf_ioctl_resp_wake		    brcmf_msgbuf_ioctl_resp_wait
      ------------------------------------------------------------------------
      if (waitqueue_active(&msgbuf->ioctl_resp_wait))
      /* The CPU might reorder the test for
         the waitqueue up here, before
         prior writes complete */
         	   	     	 	       /* wait_event_timeout */
      				        /* __wait_event_timeout */
      					 /* ___wait_event */
      					 prepare_to_wait_event(&wq, &__wait,
      					   state);
      					 if (msgbuf->ctl_completed)
      					 ...
      msgbuf->ctl_completed = true;
      					 schedule_timeout(__ret))
      ------------------------------------------------------------------------
      
      There are three other place in drivers/net/wireless/brcm80211/brcmfmac/
      which have similar code.  The attached patch removes the call to
      waitqueue_active() leaving just wake_up() behind.  This fixes the
      problem because the call to spin_lock_irqsave() in wake_up() will be an
      ACQUIRE operation.
      
      I found this issue when I was looking through the linux source code
      for places calling waitqueue_active() before wake_up*(), but without
      preceding memory barriers, after sending a patch to fix a similar
      issue in drivers/tty/n_tty.c  (Details about the original issue can be
      found here: https://lkml.org/lkml/2015/9/28/849).
      Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
      Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
      Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
      Signed-off-by: NKosuke Tatsukawa <tatsu@ab.jp.nec.com>
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      a7decc44
  8. 30 11月, 2015 1 次提交
  9. 26 11月, 2015 2 次提交
  10. 18 11月, 2015 1 次提交
  11. 21 10月, 2015 1 次提交
  12. 09 5月, 2015 1 次提交
  13. 06 2月, 2015 1 次提交
  14. 29 1月, 2015 2 次提交
  15. 18 11月, 2014 1 次提交
  16. 31 10月, 2014 4 次提交
  17. 16 7月, 2014 1 次提交
  18. 26 6月, 2014 4 次提交
  19. 30 5月, 2014 6 次提交
  20. 14 5月, 2014 1 次提交
  21. 17 1月, 2014 1 次提交
  22. 19 12月, 2013 1 次提交
  23. 03 12月, 2013 1 次提交
  24. 04 10月, 2013 1 次提交
  25. 27 9月, 2013 1 次提交
    • A
      brcmfmac: obtain platform data upon module initialization · db4efbbe
      Arend van Spriel 提交于
      The driver uses platform_driver_probe() to obtain platform data
      if any. However, that function is placed in the .init section so
      it must be called upon driver module initialization.
      
      The problem was reported by Fenguang Wu resulting in a kernel
      oops because the .init section was already freed.
      
      [   48.966342] Switched to clocksource tsc
      [   48.970002] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
      [   48.970851] BUG: unable to handle kernel paging request at ffffffff82196446
      [   48.970957] IP: [<ffffffff82196446>] classes_init+0x26/0x26
      [   48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE 8000000002196163
      [   48.970957] Oops: 0011 [#1]
      [   48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 3.11.0-rc7-00444-gc52dd7f #23
      [   48.970957] Workqueue: events brcmf_driver_init
      [   48.970957] task: ffff8800001d2000 ti: ffff8800001d4000 task.ti: ffff8800001d4000
      [   48.970957] RIP: 0010:[<ffffffff82196446>]  [<ffffffff82196446>] classes_init+0x26/0x26
      [   48.970957] RSP: 0000:ffff8800001d5d40  EFLAGS: 00000286
      [   48.970957] RAX: 0000000000000001 RBX: ffffffff820c5620 RCX: 0000000000000000
      [   48.970957] RDX: 0000000000000001 RSI: ffffffff816f7380 RDI: ffffffff820c56c0
      [   48.970957] RBP: ffff8800001d5d50 R08: ffff8800001d2508 R09: 0000000000000002
      [   48.970957] R10: 0000000000000000 R11: 0001f7ce298c5620 R12: ffff8800001c76b0
      [   48.970957] R13: ffffffff81e91d40 R14: 0000000000000000 R15: ffff88000e0ce300
      [   48.970957] FS:  0000000000000000(0000) GS:ffffffff81e84000(0000) knlGS:0000000000000000
      [   48.970957] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [   48.970957] CR2: ffffffff82196446 CR3: 0000000001e75000 CR4: 00000000000006b0
      [   48.970957] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   48.970957] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
      [   48.970957] Stack:
      [   48.970957]  ffffffff816f7df8 ffffffff820c5620 ffff8800001d5d60 ffffffff816eeec9
      [   48.970957]  ffff8800001d5de0 ffffffff81073dc5 ffffffff81073d68 ffff8800001d5db8
      [   48.970957]  0000000000000086 ffffffff820c5620 ffffffff824f7fd0 0000000000000000
      [   48.970957] Call Trace:
      [   48.970957]  [<ffffffff816f7df8>] ? brcmf_sdio_init+0x18/0x70
      [   48.970957]  [<ffffffff816eeec9>] brcmf_driver_init+0x9/0x10
      [   48.970957]  [<ffffffff81073dc5>] process_one_work+0x1d5/0x480
      [   48.970957]  [<ffffffff81073d68>] ? process_one_work+0x178/0x480
      [   48.970957]  [<ffffffff81074188>] worker_thread+0x118/0x3a0
      [   48.970957]  [<ffffffff81074070>] ? process_one_work+0x480/0x480
      [   48.970957]  [<ffffffff8107aa17>] kthread+0xe7/0xf0
      [   48.970957]  [<ffffffff810829f7>] ? finish_task_switch.constprop.57+0x37/0xd0
      [   48.970957]  [<ffffffff8107a930>] ? __kthread_parkme+0x80/0x80
      [   48.970957]  [<ffffffff81a6923a>] ret_from_fork+0x7a/0xb0
      [   48.970957]  [<ffffffff8107a930>] ? __kthread_parkme+0x80/0x80
      [   48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
      cc cc cc cc cc cc <cc> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
      [   48.970957] RIP  [<ffffffff82196446>] classes_init+0x26/0x26
      [   48.970957]  RSP <ffff8800001d5d40>
      [   48.970957] CR2: ffffffff82196446
      [   48.970957] ---[ end trace 62980817cd525f14 ]---
      
      Cc: <stable@vger.kernel.org> # 3.10.x, 3.11.x
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
      Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
      Tested-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      db4efbbe
  26. 16 8月, 2013 1 次提交