1. 08 1月, 2010 8 次提交
  2. 07 1月, 2010 14 次提交
  3. 05 1月, 2010 1 次提交
  4. 04 1月, 2010 16 次提交
  5. 31 12月, 2009 1 次提交
    • A
      fsl_pq_mdio: Fix iomem unmapping for non-eTSEC2.0 controllers · b3319b10
      Anton Vorontsov 提交于
      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: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3319b10