1. 08 1月, 2016 5 次提交
  2. 08 6月, 2015 1 次提交
  3. 01 4月, 2015 1 次提交
  4. 12 2月, 2015 1 次提交
  5. 11 12月, 2014 1 次提交
  6. 05 12月, 2014 1 次提交
    • A
      SSB / B44: fix WOL for BCM4401 · 5580373f
      Andrey Skvortsov 提交于
      Wake On Lan was not working on laptop DELL Vostro 1500.
      If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked.
      But the laptop could not be woken up with the Magic Packet. The reason for
      that was that PCIE was not enabled as a system wakeup source and
      therefore the host PCI bridge was not powered up in suspend mode.
      PCIE was not enabled in suspend by PM because no child devices were
      registered as wakeup source during suspend process.
      On laptop BCM4401 is connected through the SSB bus, that is connected to the
      PCI-Express bus. SSB and B44 did not use standard PM wakeup functions
      and did not forward wakeup settings to their parents.
      To fix that B44 driver enables PM wakeup and registers new wakeup source
      using device_set_wakeup_enable(). Wakeup is automatically reported to the parent SSB
      bus via power.wakeup_path. SSB bus enables wakeup for the parent PCI bridge, if there is any
      child devices with enabled wakeup functionality. All other steps are
      done by PM core code.
      Signed-off-by: NAndrey Skvortsov <Andrej.Skvortzov@gmail.com>
      Signed-off-by: NMichael Buesch <m@bues.ch>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5580373f
  7. 13 9月, 2014 1 次提交
  8. 10 9月, 2014 1 次提交
  9. 13 8月, 2014 1 次提交
  10. 14 5月, 2014 1 次提交
  11. 15 3月, 2014 1 次提交
  12. 03 3月, 2014 2 次提交
  13. 21 12月, 2013 8 次提交
  14. 03 10月, 2013 1 次提交
  15. 01 10月, 2013 1 次提交
  16. 22 9月, 2013 1 次提交
  17. 19 2月, 2013 1 次提交
  18. 16 2月, 2013 1 次提交
  19. 05 2月, 2013 1 次提交
  20. 09 1月, 2013 1 次提交
  21. 08 12月, 2012 1 次提交
  22. 04 12月, 2012 1 次提交
  23. 19 7月, 2012 1 次提交
  24. 09 7月, 2012 1 次提交
  25. 20 2月, 2012 1 次提交
  26. 01 2月, 2012 1 次提交
  27. 24 11月, 2011 1 次提交
    • X
      b44: Use dev_kfree_skb_irq() in b44_tx() · 15ac2b08
      Xander Hover 提交于
      Reported issues when using dev_kfree_skb() on UP systems and
      systems with low numbers of cores.  dev_kfree_skb_irq() will
      properly save IRQ state before freeing the skb.
      
      Tested on 3.1.1 and 3.2_rc2
      
      Example of reproducible trace of kernel 3.1.1
      ------------[ cut here ]------------
         WARNING: at kernel/softirq.c:159 local_bh_enable+0x32/0x79()
         ...
         Pid: 0, comm: swapper Not tainted 3.1.1-gentoo #1
         Call Trace:
          [<c1022970>] warn_slowpath_common+0x65/0x7a
          [<c102699e>] ? local_bh_enable+0x32/0x79
          [<c1022994>] warn_slowpath_null+0xf/0x13
          [<c102699e>] local_bh_enable+0x32/0x79
          [<c134bfd8>] destroy_conntrack+0x7c/0x9b
          [<c134890b>] nf_conntrack_destroy+0x1f/0x26
          [<c132e3a6>] skb_release_head_state+0x74/0x83
          [<c132e286>] __kfree_skb+0xb/0x6b
          [<c132e30a>] consume_skb+0x24/0x26
          [<c127c925>] b44_poll+0xaa/0x449
          [<c1333ca1>] net_rx_action+0x3f/0xea
          [<c1026a44>] __do_softirq+0x5f/0xd5
          [<c10269e5>] ? local_bh_enable+0x79/0x79
          <IRQ>  [<c1026c32>] ? irq_exit+0x34/0x8d
          [<c1003628>] ? do_IRQ+0x74/0x87
          [<c13f5329>] ? common_interrupt+0x29/0x30
          [<c1006e18>] ? default_idle+0x29/0x3e
          [<c10015a7>] ? cpu_idle+0x2f/0x5d
          [<c13e91c5>] ? rest_init+0x79/0x7b
          [<c15c66a9>] ? start_kernel+0x297/0x29c
          [<c15c60b0>] ? i386_start_kernel+0xb0/0xb7
         ---[ end trace 583f33bb1aa207a9 ]---
      Signed-off-by: NXander Hover <LKML@hover.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15ac2b08
  28. 18 8月, 2011 1 次提交