1. 05 2月, 2010 1 次提交
  2. 19 1月, 2010 1 次提交
    • A
      phylib: Move workqueue initialization to a proper place · 4f9c85a1
      Anton Vorontsov 提交于
      commit 541cd3ee ("phylib: Fix deadlock
      on resume") caused TI DaVinci EMAC ethernet driver to oops upon resume:
      
       PM: resume of devices complete after 237.098 msecs
       Restarting tasks ... done.
       kernel BUG at kernel/workqueue.c:354!
       Unable to handle kernel NULL pointer dereference at virtual address 00000000
       [...]
       Backtrace:
       [<c002c598>] (__bug+0x0/0x2c) from [<c0052a54>] (queue_delayed_work_on+0x74/0xf8)
       [<c00529e0>] (queue_delayed_work_on+0x0/0xf8) from [<c0052b30>] (queue_delayed_work+0x2c/0x30)
      
      The oops pops up because TI DaVinci EMAC driver detaches PHY on
      suspend and attaches it back on resume. Attaching makes phylib call
      phy_start_machine() that initializes a workqueue. On the other hand,
      PHY's resume routine will call phy_start_machine() again, and that
      will cause the oops since we just destroyed the already scheduled
      workqueue.
      
      This patch fixes the issue by moving workqueue initialization to
      phy_device_create().
      
      p.s. We don't see this oops with ucc_geth and gianfar drivers because
      they perform a fine-grained suspend, i.e. they just stop the PHYs
      without detaching.
      Reported-by: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Tested-by: NSekhar Nori <nsekhar@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f9c85a1
  3. 31 12月, 2009 1 次提交
  4. 27 5月, 2009 1 次提交
  5. 27 4月, 2009 2 次提交
  6. 14 4月, 2009 1 次提交
    • A
      phylib: Allow early-out in phy_change · a8729eb3
      Anatolij Gustschin 提交于
      Marvell 88E1121R Dual PHY device can be hardware-configured
      to use shared interrupt pin for both PHY ports. For such
      PHY configurations using shared PHY interrupt phy_interrupt()
      handler will also schedule a work for PHY port which didn't
      cause an interrupt.
      
      This patch adds a possibility for PHY drivers to provide
      did_interrupt() function which reports if the PHY (or a PHY
      port in a multi-PHY device) generated an interrupt. This
      function is called in phy_change() as phy_change() shouldn't
      proceed if it is invoked for a PHY which didn't cause an
      interrupt. So check for interrupt originator in phy_change()
      to allow early-out.
      Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8729eb3
  7. 14 3月, 2009 1 次提交
  8. 29 11月, 2008 1 次提交
    • G
      phy: power management support · 0f0ca340
      Giuseppe Cavallaro 提交于
      This patch adds the power management support into the physical
      abstraction layer.
      
      Suspend and resume functions respectively turns on/off the bit 11
      into the PHY Basic mode control register.
      Generic PHY device starts supporting PM.
      
      In order to support the wake-on LAN and avoid to put in power down
      the PHY device, the MDIO is aware of what the Ethernet device wants to do.
      
      Voluntary, no CONFIG_PM defines were added into the sources.
      Also generic suspend/resume functions are exported to allow
      other drivers use them (such as genphy_config_aneg etc.).
      
      Within the phy_driver_register function, we need to remove the
      memset. It overrides the device driver owner and it is not good.
      Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f0ca340
  9. 09 10月, 2008 4 次提交
  10. 19 9月, 2008 1 次提交
  11. 07 5月, 2008 1 次提交
  12. 25 4月, 2008 1 次提交
  13. 18 4月, 2008 1 次提交
  14. 17 4月, 2008 2 次提交
  15. 03 2月, 2008 1 次提交
  16. 05 12月, 2007 1 次提交
    • A
      PHY: Add the phy_device_release device method. · 6f4a7f41
      Anton Vorontsov 提交于
      Lately I've got this nice badness on mdio bus removal:
      
      Device 'e0103120:06' does not have a release() function, it is broken and must be fixed.
      ------------[ cut here ]------------
      Badness at drivers/base/core.c:107
      NIP: c015c1a8 LR: c015c1a8 CTR: c0157488
      REGS: c34bdcf0 TRAP: 0700   Not tainted  (2.6.23-rc5-g9ebadfbb-dirty)
      MSR: 00029032 <EE,ME,IR,DR>  CR: 24088422  XER: 00000000
      ...
      [c34bdda0] [c015c1a8] device_release+0x78/0x80 (unreliable)
      [c34bddb0] [c01354cc] kobject_cleanup+0x80/0xbc
      [c34bddd0] [c01365f0] kref_put+0x54/0x6c
      [c34bdde0] [c013543c] kobject_put+0x24/0x34
      [c34bddf0] [c015c384] put_device+0x1c/0x2c
      [c34bde00] [c0180e84] mdiobus_unregister+0x2c/0x58
      ...
      
      Though actually there is nothing broken, it just device
      subsystem core expects another "pattern" of resource managment.
      
      This patch implement phy device's release function, thus
      we're getting rid of this badness.
      
      Also small hidden bug fixed, hope none other introduced. ;-)
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Acked-by: NAndy Fleming <afleming@freescale.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      6f4a7f41
  17. 02 12月, 2007 1 次提交
  18. 11 10月, 2007 1 次提交
    • M
      PHYLIB: IRQ event workqueue handling fixes · 0ac49527
      Maciej W. Rozycki 提交于
      Keep track of disable_irq_nosync() invocations and call enable_irq() the
      right number of times if work has been cancelled that would include them.
      
      Now that the call to flush_work_keventd() (problematic because of
      rtnl_mutex being held) has been replaced by cancel_work_sync() another
      issue has arisen and been left unresolved.  As the MDIO bus cannot be
      accessed from the interrupt context the PHY interrupt handler uses
      disable_irq_nosync() to prevent from looping and schedules some work to be
      done as a softirq, which, apart from handling the state change of the
      originating PHY, is responsible for reenabling the interrupt.  Now if the
      interrupt line is shared by another device and a call to the softirq
      handler has been cancelled, that call to enable_irq() never happens and the
      other device cannot use its interrupt anymore as its stuck disabled.
      
      I decided to use a counter rather than a flag because there may be more
      than one call to phy_change() cancelled in the queue -- a real one and a
      fake one triggered by free_irq() if DEBUG_SHIRQ is used, if nothing else.
      Therefore because of its nesting property enable_irq() has to be called the
      right number of times to match the number disable_irq_nosync() was called
      and restore the original state.  This DEBUG_SHIRQ feature is also the
      reason why free_irq() has to be called before cancel_work_sync().
      
      While at it I updated the comment about phy_stop_interrupts() being called
      from `keventd' -- this is no longer relevant as the use of
      cancel_work_sync() makes such an approach unnecessary.  OTOH a similar
      comment referring to flush_scheduled_work() in phy_stop() still applies as
      using cancel_work_sync() there would be dangerous.
      
      Checked with checkpatch.pl and at the run time (with and without
      DEBUG_SHIRQ).
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: Andy Fleming <afleming@freescale.com>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      0ac49527
  19. 28 4月, 2007 1 次提交
  20. 02 12月, 2006 2 次提交
  21. 13 11月, 2006 1 次提交
  22. 20 8月, 2006 1 次提交
  23. 13 1月, 2006 1 次提交
  24. 06 11月, 2005 1 次提交
  25. 29 8月, 2005 1 次提交
  26. 11 8月, 2005 2 次提交
  27. 31 7月, 2005 1 次提交