1. 03 4月, 2010 1 次提交
  2. 17 3月, 2010 1 次提交
    • J
      NET: Support clause 45 MDIO commands at the MDIO bus level · abf35df2
      Jason Gunthorpe 提交于
      IEEE 802.3ae clause 45 specifies a somewhat modified MDIO protocol
      for use by 10GIGE phys. The main change is a 21 bit address split into
      a 5 bit device ID and a 16 bit register offset. The definition is designed
      so that normal and extended devices can run on the same MDIO bus.
      
      Extend mdio-bitbang to do the new protocol. At the MDIO bus level the
      protocol is requested by or'ing MII_ADDR_C45 into the register offset.
      
      Make phy_read/phy_write/etc pass a full 32 bit register offset.
      
      This does not attempt to make the phy layer support C45 style PHYs, just
      to provide the MDIO bus support.
      
      Tested against a Broadcom 10GE phy with ID 0x206034, and several
      Broadcom 10/100/1000 Phys in normal mode.
      Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      abf35df2
  3. 18 2月, 2010 1 次提交
  4. 05 2月, 2010 1 次提交
  5. 21 1月, 2010 1 次提交
  6. 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
  7. 07 1月, 2010 1 次提交
  8. 04 1月, 2010 1 次提交
  9. 31 12月, 2009 2 次提交
    • A
      phylib: Properly reinitialize PHYs after hibernation · 2f5cb434
      Anton Vorontsov 提交于
      Since hibernation assumes power loss, we should fully reinitialize
      PHYs (including platform fixups), as if PHYs were just attached.
      
      This patch factors phy_init_hw() out of phy_attach_direct(), then
      converts mdio_bus to dev_pm_ops and adds an appropriate restore()
      callback.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2f5cb434
    • A
      phylib: Fix deadlock on resume · 541cd3ee
      Anton Vorontsov 提交于
      Sometimes kernel hangs on resume with the following trace:
      
       ucc_geth e0102000.ucc: resume
       INFO: task bash:1764 blocked for more than 120 seconds.
       "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
       bash          D 0fecf43c     0  1764   1763 0x00000000
       Call Trace:
       [cf9a7c10] [c0012868] ret_from_except+0x0/0x14 (unreliable)
       --- Exception: cf9a7ce0 at __switch_to+0x4c/0x6c
           LR = 0xcf9a7cc0
       [cf9a7cd0] [c0008c14] __switch_to+0x4c/0x6c (unreliable)
       [cf9a7ce0] [c028bcfc] schedule+0x158/0x260
       [cf9a7d10] [c028c720] __mutex_lock_slowpath+0x80/0xd8
       [cf9a7d40] [c01cf388] phy_stop+0x20/0x70
       [cf9a7d50] [c01d514c] ugeth_resume+0x6c/0x13c
       [...]
      
      Here is why.
      
      On suspend:
      
      - PM core starts suspending devices, ucc_geth_suspend gets called;
      
      - ucc_geth calls phy_stop() on suspend. Note that phy_stop() is
        mostly asynchronous so it doesn't block ucc_geth's suspend routine,
        it just sets PHY_HALTED state and disables PHY's interrupts;
      
      - Suddenly the state machine gets scheduled, it grabs the phydev->lock
        mutex and tries to process the PHY_HALTED state, so it calls
        phydev->adjust_link(phydev->attached_dev). In ucc_geth case
        adjust_link() calls msleep(), which reschedules the code flow back to
        PM core, which now finishes suspend and so we end up sleeping with
        phydev->lock mutex held.
      
      On resume:
      
      - PM core starts resuming devices (notice that nobody rescheduled
        the state machine yet, so the mutex is still held), the core calls
        ucc_geth's resume routine;
      
      - ucc_geth_resume restarts the PHY with phy_stop()/phy_start()
        sequence, and the phy_*() calls are trying to grab the phydev->lock
        mutex. Here comes the deadlock.
      
      This patch fixes the issue by stopping the state machine on suspend
      and starting it again on resume.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      541cd3ee
  10. 19 12月, 2009 1 次提交
  11. 17 12月, 2009 1 次提交
    • D
      NET: Add driver for Octeon MDIO buses. · 25d967b7
      David Daney 提交于
      The Octeon SOC has two types of Ethernet ports, each type with its own
      driver.  However, the PHYs for all the ports are controlled by a
      common MDIO bus.  Because the mdio driver is not associated with a
      particular driver, but is instead a system level resource, we create s
      stand-alone driver for it.
      
      As for the driver, we put the register definitions in
      arch/mips/include/asm/octeon where most of the other Octeon register
      definitions live.  This is a platform driver with the platform device
      for "mdio-octeon" being registered in the platform startup code.
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      25d967b7
  12. 04 12月, 2009 1 次提交
  13. 17 11月, 2009 1 次提交
    • S
      net: fix mdio section mismatch warning · f99b4a02
      Stephen Rothwell 提交于
      This fixes the following warning:
      
      WARNING: drivers/net/phy/built-in.o(.devexit.text+0x70): Section mismatch in reference from the function .mdio_gpio_bus_destroy() to the function .devinit.text:.mdio_gpio_bus_deinit()
      The function __devexit .mdio_gpio_bus_destroy() references
      a function __devinit .mdio_gpio_bus_deinit().
      This is often seen when error handling in the exit function
      uses functionality in the init path.
      The fix is often to remove the __devinit annotation of
      .mdio_gpio_bus_deinit() so it may be used outside an init section.
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f99b4a02
  14. 03 11月, 2009 8 次提交
  15. 15 10月, 2009 1 次提交
  16. 12 9月, 2009 2 次提交
  17. 04 9月, 2009 1 次提交
  18. 27 8月, 2009 3 次提交
  19. 24 7月, 2009 1 次提交
  20. 15 7月, 2009 1 次提交
  21. 08 7月, 2009 1 次提交
  22. 03 7月, 2009 1 次提交
  23. 17 6月, 2009 1 次提交
  24. 03 6月, 2009 1 次提交
  25. 27 4月, 2009 2 次提交
  26. 16 4月, 2009 1 次提交
  27. 14 4月, 2009 2 次提交