1. 20 12月, 2008 33 次提交
  2. 19 12月, 2008 7 次提交
    • A
      ucc_geth: Remove UGETH_FILTERING dead code · 221b3d60
      Anton Vorontsov 提交于
      The code appears to be dead: nobody call these functions, plus build
      breaks when UGETH_FILTERING is enabled:
      
      ucc_geth.c:1848: warning: 'struct enet_addr' declared inside parameter list
      ucc_geth.c:1848: warning: its scope is only this definition or declaration, which is probably not what you want
      ucc_geth.c: In function 'ugeth_82xx_filtering_get_match_addr_in_hash':
      ucc_geth.c:1856: error: dereferencing pointer to incomplete type
      ucc_geth.c:1874: error: dereferencing pointer to incomplete type
      ucc_geth.c:1877: warning: return from incompatible pointer type
      ucc_geth.c: At top level:
      ucc_geth.c:1885: warning: 'struct enet_addr' declared inside parameter list
      ucc_geth.c: In function 'ugeth_82xx_filtering_add_addr_in_hash':
      ucc_geth.c:1894: error: dereferencing pointer to incomplete type
      ucc_geth.c:1909: warning: passing argument 2 of 'ugeth_82xx_filtering_get_match_addr_in_hash' from incompatible pointer type
      ucc_geth.c:1909: warning: assignment from incompatible pointer type
      ucc_geth.c:1918: error: dereferencing pointer to incomplete type
      ucc_geth.c: At top level:
      ucc_geth.c:1928: warning: 'struct enet_addr' declared inside parameter list
      ucc_geth.c: In function 'ugeth_82xx_filtering_clear_addr_in_hash':
      ucc_geth.c:1947: warning: passing argument 2 of 'ugeth_82xx_filtering_get_match_addr_in_hash' from incompatible pointer type
      ucc_geth.c:1947: warning: assignment from incompatible pointer type
      ucc_geth.c:1954: error: dereferencing pointer to incomplete type
      ucc_geth.c: At top level:
      ucc_geth.c:2060: warning: 'struct enet_addr' declared inside parameter list
      ucc_geth.c: In function 'ugeth_82xx_filtering_add_addr_in_paddr':
      ucc_geth.c:2064: error: dereferencing pointer to incomplete type
      ucc_geth.c:2073: error: dereferencing pointer to incomplete type
      ucc_geth.c:2075: warning: passing argument 2 of 'hw_add_addr_in_paddr' from incompatible pointer type
      make[2]: *** [ucc_geth.o] Error 1
      
      The code is there since the driver was merged, and nobody seem to be
      interested in fixing or actually using it. If we ever want the
      filtering support, we can always revert the patch and fix it, but so
      far it just draws reader's attention.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      221b3d60
    • A
      ucc_geth: Fix IO memory (un)mapping code · 3e73fc9a
      Anton Vorontsov 提交于
      The driver doesn't check ioremap() return value, and doesn't free the
      remapped memory.
      
      This patch fixes it.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e73fc9a
    • A
      ucc_geth: Cleanup repetitive ucc_geth_memclean() calls · ba574696
      Anton Vorontsov 提交于
      No need to call ucc_geth_memclean() so many times, just check for
      errors in ucc_geth_open(), and call ucc_geth_stop() in case of errors.
      
      The ucc_geth_stop() may be called anytime and will do the right thing.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba574696
    • A
      ucc_geth: Fix IRQ freeing code in ucc_geth_open() · 67c2fb8f
      Anton Vorontsov 提交于
      open() routine calls stop() in case of errors, the function will try
      to free the requested IRQ. But we don't know if it was actually
      requested, so the code might issue bogus free_irq(0, dev) call.
      
      Fix this by rearranging the code so that now request_irq() is the last
      call in the open() routine, and move free_irq() into the close().
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67c2fb8f
    • A
      ucc_geth: Fix TX watchdog timeout handling · 1762a29a
      Anton Vorontsov 提交于
      The timeout handling code is currently broken in several ways:
      
      - It calls stop() (which frees all the memory and IRQ), and then
        calls startup() (which won't re-request IRQ, neither it will
        re-init the Fast UCC structure).
      - It calls these routines from the softirq context, which is wrong,
        since stop() calls free_irq() (which might sleep) and startup()
        allocates things with GFP_KERNEL.
      - It won't soft-reset the PHY. We need the PHY reset for at least
        MPC8360E-MDS boards with Marvell 88E1111 PHY, the PHY won't recover
        from timeouts w/o the reset.
      
      So the patch fixes these problems by implementing the workqueue for the
      timeout handling, and there we fully re-open the device via close() and
      open() calls. The close/open paths do the right things, and I can see
      that the driver actually survive the timeouts.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1762a29a
    • A
      ucc_geth: Fix endless loop in stop_{tx,rx} routines · b3431c64
      Anton Vorontsov 提交于
      Currently the routines wait for the various bits w/o an assumption that
      bits may never get set. When timeouts happen I see that these bits never
      get set and so the routines hang the kernel.
      
      With this patch we'll wait the graceful stop for 100 ms, and then will
      simply exit. There is nothing* we can do about that, but it's OK since
      we'll do full reset later.
      
      * Well, actually, there is also not-graceful variant for the TX stop,
        but specs says that we never should use it.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3431c64
    • M
      tcp: Stop scaring users with "treason uncloaked!" · 6086ebca
      Matt Mackall 提交于
      The original message was unhelpful and extremely alarming to our poor
      users, despite its charm. Make it less frightening.
      Signed-off-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6086ebca