1. 07 Jan, 2010 1 commit
  2. 04 Jan, 2010 17 commits
  3. 31 Dec, 2009 4 commits
    • Anton Vorontsov's avatar
      fsl_pq_mdio: Fix iomem unmapping for non-eTSEC2.0 controllers · b3319b10
      Anton Vorontsov authored
      We use a rather complicated logic to support eTSEC and eTSEC2.0
      registers maps in a single driver. Currently, the code tries to
      unmap 'regs', but for non-eTSEC2.0 controllers 'regs' doesn't
      point to a mapping start, and this might cause badness on probe
      failure or module removal:
      
       Freescale PowerQUICC MII Bus: probed
       Trying to vfree() nonexistent vm area (e107f000)
       ------------[ cut here ]------------
       Badness at c00a7754 [verbose debug info unavailable]
       NIP: c00a7754 LR: c00a7754 CTR: c02231ec
       [...]
       NIP [c00a7754] __vunmap+0xec/0xf4
       LR [c00a7754] __vunmap+0xec/0xf4
       Call Trace:
       [df827e50] [c00a7754] __vunmap+0xec/0xf4 (unreliable)
       [df827e70] [c001519c] iounmap+0x44/0x54
       [df827e80] [c028b924] fsl_pq_mdio_probe+0x1cc/0x2fc
       [df827eb0] [c02fb9b4] of_platform_device_probe+0x5c/0x84
       [df827ed0] [c0229928] really_probe+0x78/0x1a8
       [df827ef0] [c0229b20] __driver_attach+0xa4/0xa8
      
      Fix this by introducing a proper priv structure (finally!), which
      now holds 'regs' and 'map' fields separately.
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3319b10
    • Anton Vorontsov's avatar
      ucc_geth: Fix netdev watchdog triggering on suspend · 29fb00e0
      Anton Vorontsov authored
      Sometimes ucc_geth fails to suspend with the following trace:
      
       ucc_geth e0103000.ucc: suspend
       ucc_geth e0102000.ucc: suspend
       NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out
       ------------[ cut here ]------------
       Badness at net/sched/sch_generic.c:255
       NIP: c021cb5c LR: c021cb5c CTR: c01ab4b4
       [...]
       NIP [c021cb5c] dev_watchdog+0x298/0x2a8
       LR [c021cb5c] dev_watchdog+0x298/0x2a8
       Call Trace:
       [c0389da0] [c021cb5c] dev_watchdog+0x298/0x2a8 (unreliable)
       [c0389e00] [c0031ed8] run_timer_softirq+0x16c/0x1dc
       [c0389e50] [c002c638] __do_softirq+0xa4/0x11c
       [...]
      
      This patch fixes the issue by properly detaching the device on
      suspend, and attaching it back on resume.
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29fb00e0
    • Anton Vorontsov's avatar
      phylib: Properly reinitialize PHYs after hibernation · 2f5cb434
      Anton Vorontsov authored
      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: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f5cb434
    • Anton Vorontsov's avatar
      phylib: Fix deadlock on resume · 541cd3ee
      Anton Vorontsov authored
      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: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      541cd3ee
  4. 30 Dec, 2009 1 commit
  5. 29 Dec, 2009 1 commit
  6. 28 Dec, 2009 16 commits