1. 03 5月, 2014 2 次提交
  2. 17 1月, 2014 1 次提交
  3. 31 8月, 2013 1 次提交
  4. 22 8月, 2013 1 次提交
  5. 21 8月, 2013 1 次提交
  6. 26 6月, 2013 1 次提交
  7. 16 6月, 2013 1 次提交
  8. 13 6月, 2013 2 次提交
  9. 11 6月, 2013 1 次提交
    • S
      net/ti davinci_mdio: don't hold a spin lock while calling pm_runtime · 2786aae7
      Sebastian Siewior 提交于
      was playing with suspend and run into this:
      
      |BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:891
      |in_atomic(): 1, irqs_disabled(): 0, pid: 1963, name: bash
      |6 locks held by bash/1963:
      |CPU: 0 PID: 1963 Comm: bash Not tainted 3.10.0-rc4+ #50
      |[<c0014fdc>] (unwind_backtrace+0x0/0xf8) from [<c0011da4>] (show_stack+0x10/0x14)
      |[<c0011da4>] (show_stack+0x10/0x14) from [<c02e8680>] (__pm_runtime_idle+0xa4/0xac)
      |[<c02e8680>] (__pm_runtime_idle+0xa4/0xac) from [<c0341158>] (davinci_mdio_suspend+0x6c/0x9c)
      |[<c0341158>] (davinci_mdio_suspend+0x6c/0x9c) from [<c02e0628>] (platform_pm_suspend+0x2c/0x54)
      |[<c02e0628>] (platform_pm_suspend+0x2c/0x54) from [<c02e52bc>] (dpm_run_callback.isra.3+0x2c/0x64)
      |[<c02e52bc>] (dpm_run_callback.isra.3+0x2c/0x64) from [<c02e57e4>] (__device_suspend+0x100/0x22c)
      |[<c02e57e4>] (__device_suspend+0x100/0x22c) from [<c02e67e8>] (dpm_suspend+0x68/0x230)
      |[<c02e67e8>] (dpm_suspend+0x68/0x230) from [<c0072a20>] (suspend_devices_and_enter+0x68/0x350)
      |[<c0072a20>] (suspend_devices_and_enter+0x68/0x350) from [<c0072f18>] (pm_suspend+0x210/0x24c)
      |[<c0072f18>] (pm_suspend+0x210/0x24c) from [<c0071c74>] (state_store+0x6c/0xbc)
      |[<c0071c74>] (state_store+0x6c/0xbc) from [<c02714dc>] (kobj_attr_store+0x14/0x20)
      |[<c02714dc>] (kobj_attr_store+0x14/0x20) from [<c01341a0>] (sysfs_write_file+0x16c/0x19c)
      |[<c01341a0>] (sysfs_write_file+0x16c/0x19c) from [<c00ddfe4>] (vfs_write+0xb4/0x190)
      |[<c00ddfe4>] (vfs_write+0xb4/0x190) from [<c00de3a4>] (SyS_write+0x3c/0x70)
      |[<c00de3a4>] (SyS_write+0x3c/0x70) from [<c000e2c0>] (ret_fast_syscall+0x0/0x48)
      
      I don't see a reason why the pm_runtime call must be under the lock.
      Further I don't understand why this is a spinlock and not mutex.
      
      Cc: Mugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2786aae7
  10. 25 4月, 2013 1 次提交
  11. 05 2月, 2013 1 次提交
  12. 04 12月, 2012 1 次提交
  13. 15 11月, 2012 1 次提交
  14. 01 9月, 2012 1 次提交
  15. 08 8月, 2012 1 次提交
  16. 19 7月, 2012 1 次提交
  17. 18 4月, 2012 1 次提交
    • C
      davinci_mdio: Fix MDIO timeout check · 5b76d060
      Christian Riesch 提交于
      Under heavy load (flood ping) it is possible for the MDIO timeout to
      expire before the loop checks the GO bit again. This patch adds an
      additional check whether the operation was done before actually
      returning -ETIMEDOUT.
      
      To reproduce this bug, flood ping the device, e.g., ping -f -l 1000
      After some time, a "timed out waiting for user access" warning
      may appear. And even worse, link may go down since the PHY reported a
      timeout.
      Signed-off-by: NChristian Riesch <christian.riesch@omicron.at>
      Cc: <stable@vger.kernel.org>
      Cc: Cyril Chemparathy <cyril@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b76d060
  18. 24 2月, 2012 1 次提交
  19. 03 2月, 2012 1 次提交
  20. 11 1月, 2012 1 次提交
  21. 12 8月, 2011 1 次提交
  22. 24 9月, 2010 1 次提交