1. 25 5月, 2014 1 次提交
  2. 14 5月, 2014 1 次提交
  3. 24 3月, 2014 1 次提交
  4. 17 4月, 2013 1 次提交
  5. 09 4月, 2013 2 次提交
  6. 08 4月, 2013 1 次提交
  7. 30 3月, 2013 1 次提交
  8. 30 1月, 2013 1 次提交
  9. 04 1月, 2013 1 次提交
  10. 04 12月, 2012 1 次提交
  11. 17 7月, 2012 1 次提交
  12. 12 5月, 2012 1 次提交
  13. 22 4月, 2012 2 次提交
    • M
      ks8851: Fix request_irq/free_irq mismatch · e8195b24
      Matt Renzelmann 提交于
      The dev_id parameter passed to free_irq needs to match the one passed
      to the corresponding request_irq.
      Signed-off-by: NMatt Renzelmann <mjr@cs.wisc.edu>
      Acked-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8195b24
    • S
      ks8851: Fix mutex deadlock in ks8851_net_stop() · c5a99937
      Stephen Boyd 提交于
      There is a potential deadlock scenario when the ks8851 driver
      is removed. The interrupt handler schedules a workqueue which
      acquires a mutex that ks8851_net_stop() also acquires before
      flushing the workqueue. Previously lockdep wouldn't be able
      to find this problem but now that it has the support we can
      trigger this lockdep warning by rmmoding the driver after
      an ifconfig up.
      
      Fix the possible deadlock by disabling the interrupts in
      the chip and then release the lock across the workqueue
      flushing. The mutex is only there to proect the registers
      anyway so this should be ok.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      3.0.21-00021-g8b33780-dirty #2911
      -------------------------------------------------------
      rmmod/125 is trying to acquire lock:
       ((&ks->irq_work)){+.+...}, at: [<c019e0b8>] flush_work+0x0/0xac
      
      but task is already holding lock:
       (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&ks->lock){+.+...}:
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c083dbec>] mutex_lock_nested+0x68/0x3dc
             [<bf00bd48>] ks8851_irq_work+0x24/0x46c [ks8851]
             [<c019c580>] process_one_work+0x2d8/0x518
             [<c019cb98>] worker_thread+0x220/0x3a0
             [<c01a2ad4>] kthread+0x88/0x94
             [<c0107008>] kernel_thread_exit+0x0/0x8
      
      -> #0 ((&ks->irq_work)){+.+...}:
             [<c01b7984>] validate_chain+0x914/0x1018
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c019e104>] flush_work+0x4c/0xac
             [<bf00b858>] ks8851_net_stop+0x6c/0x138 [ks8851]
             [<c06b209c>] __dev_close_many+0x98/0xcc
             [<c06b2174>] dev_close_many+0x68/0xd0
             [<c06b22ec>] rollback_registered_many+0xcc/0x2b8
             [<c06b2554>] rollback_registered+0x28/0x34
             [<c06b25b8>] unregister_netdevice_queue+0x58/0x7c
             [<c06b25f4>] unregister_netdev+0x18/0x20
             [<bf00c1f4>] ks8851_remove+0x64/0xb4 [ks8851]
             [<c049ddf0>] spi_drv_remove+0x18/0x1c
             [<c0468e98>] __device_release_driver+0x7c/0xbc
             [<c0468f64>] driver_detach+0x8c/0xb4
             [<c0467f00>] bus_remove_driver+0xb8/0xe8
             [<c01c1d20>] sys_delete_module+0x1e8/0x27c
             [<c0105ec0>] ret_fast_syscall+0x0/0x3c
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&ks->lock);
                                     lock((&ks->irq_work));
                                     lock(&ks->lock);
        lock((&ks->irq_work));
      
       *** DEADLOCK ***
      
      4 locks held by rmmod/125:
       #0:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f44>] driver_detach+0x6c/0xb4
       #1:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f50>] driver_detach+0x78/0xb4
       #2:  (rtnl_mutex){+.+.+.}, at: [<c06b25e8>] unregister_netdev+0xc/0x20
       #3:  (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      Cc: Ben Dooks <ben-linux@fluff.org>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5a99937
  14. 14 4月, 2012 1 次提交
  15. 16 2月, 2012 1 次提交
  16. 14 2月, 2012 1 次提交
  17. 13 2月, 2012 1 次提交
  18. 01 2月, 2012 1 次提交
  19. 31 1月, 2012 1 次提交
  20. 27 11月, 2011 3 次提交
  21. 12 8月, 2011 1 次提交
  22. 07 6月, 2011 1 次提交
  23. 31 3月, 2011 1 次提交
  24. 09 11月, 2010 1 次提交
  25. 09 9月, 2010 1 次提交
  26. 06 5月, 2010 3 次提交
  27. 22 4月, 2010 1 次提交
  28. 04 4月, 2010 1 次提交
    • J
      net: convert multicast list to list_head · 22bedad3
      Jiri Pirko 提交于
      Converts the list and the core manipulating with it to be the same as uc_list.
      
      +uses two functions for adding/removing mc address (normal and "global"
       variant) instead of a function parameter.
      +removes dev_mcast.c completely.
      +exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
       manipulation with lists on a sandbox (used in bonding and 80211 drivers)
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22bedad3
  29. 19 3月, 2010 1 次提交
    • A
      KS8851: Avoid NULL pointer in set rx mode · 658cc524
      Abraham Arce 提交于
      Kernel NULL pointer dereference when setting mode for IFF_MULTICAST.
      Tested on SDP OMAP4430 board.
      
      ks8851 spi1.0: message enable is 0
      ks8851 spi1.0: revision 0, MAC f2:f4:2f:56:37:de, IRQ 194
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP
      last sysfs file:
      Modules linked in:
      CPU: 0    Not tainted  (2.6.34-rc1-01039-g38d7ed1-dirty #3)
      PC is at ks8851_set_rx_mode+0x88/0x124
      LR is at bitrev32+0x24/0x2c
      
      <snip>
      
      Backtrace:
      [<c01bfbd8>] ? (ks8851_set_rx_mode+0x0/0x124)
      [<c01d4164>] (__dev_set_rx_mode+0x0/0x90)
      [<c01dc460>] (dev_mc_add+0x0/0x78)
      [<c021f0bc>] (igmp_group_added+0x0/0x64)
      [<c021f174>] (ip_mc_inc_group+0x0/0x150)
      [<c021f3b8>] (ip_mc_up+0x0/0x64)
      [<c0219eb0>] (inetdev_event+0x0/0x3d4)
      [<c0066818>] (notifier_call_chain+0x0/0x78)
      [<c00668b8>] (__raw_notifier_call_chain+0x0/0x24)
      [<c00668dc>] (raw_notifier_call_chain+0x0/0x28)
      [<c01d7484>] (call_netdevice_notifiers+0x0/0x24)
      [<c01d7780>] (__dev_notify_flags+0x0/0x68)
      [<c01d77e8>] (dev_change_flags+0x0/0x4c)
      [<c001f0bc>] (ip_auto_config+0x0/0xf1c)
      [<c0028490>] (do_one_initcall+0x0/0x1bc)
       [<c00084dc>] (kernel_init+0x0/0x234)
      Code: e15130bc e1833012 e14130bc e5943000 (e5934000)
      ---[ end trace ed0fb00a94142792 ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NAbraham Arce <x0066660@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      658cc524
  30. 17 3月, 2010 1 次提交
    • J
      drivers/net/ks*: Use netdev_<level>, netif_<level> and pr_<level> · 0dc7d2b3
      Joe Perches 提交于
      I'm not sure this is correct.
      
      It changes logging macros from:
      	dev_<level>(&ks->spidev->dev,
      to
      	netdev_<level>(ks->netdev,
      
      Comments?
      
      Use netdev_<level>
      Use netif_<level>
      Use pr_<level>
      Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
      Add missing line to message in ks8851_remove
      Change kmalloc/memset(,0) to kzalloc
      Remove ks_<level> macros
      Consolidation code into set_media_state
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0dc7d2b3
  31. 26 2月, 2010 1 次提交
  32. 13 2月, 2010 1 次提交
  33. 05 2月, 2010 1 次提交
  34. 04 12月, 2009 1 次提交