1. 10 7月, 2015 1 次提交
  2. 31 5月, 2015 3 次提交
  3. 13 5月, 2015 2 次提交
  4. 02 3月, 2015 1 次提交
    • F
      net: systemport: fix software maintained statistics · 55ff4ea9
      Florian Fainelli 提交于
      Commit 60b4ea17 ("net: systemport: log RX buffer allocation and RX/TX DMA
      failures") added a few software maintained statistics using
      BCM_SYSPORT_STAT_MIB_RX and BCM_SYSPORT_STAT_MIB_TX. These statistics are read
      from the hardware MIB counters, such that bcm_sysport_update_mib_counters() was
      trying to read from a non-existing MIB offset for these counters.
      
      Fix this by introducing a special type: BCM_SYSPORT_STAT_SOFT, similar to
      BCM_SYSPORT_STAT_NETDEV, such that bcm_sysport_get_ethtool_stats will read from
      the software mib.
      
      Fixes: 60b4ea17 ("net: systemport: log RX buffer allocation and RX/TX DMA failures")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55ff4ea9
  5. 10 12月, 2014 1 次提交
  6. 22 11月, 2014 1 次提交
  7. 13 11月, 2014 1 次提交
  8. 02 11月, 2014 2 次提交
  9. 29 10月, 2014 2 次提交
    • F
      net: systemport: reset UniMAC coming out of a suspend cycle · 704d33e7
      Florian Fainelli 提交于
      bcm_sysport_resume() was missing an UniMAC reset which can lead to
      various receive FIFO corruptions coming out of a suspend cycle. If the
      RX FIFO is stuck, it will deliver corrupted/duplicate packets towards
      the host CPU interface.
      
      This could be reproduced on crowded network and when Wake-on-LAN is
      enabled for this particular interface because the switch still forwards
      packets towards the host CPU interface (SYSTEMPORT), and we had to leave
      the UniMAC RX enable bit on to allow matching MagicPackets.
      
      Once we re-enter the resume function, there is a small window during
      which the UniMAC receive is still enabled, and we start queueing
      packets, but the RDMA and RBUF engines are not ready, which leads to
      having packets stuck in the UniMAC RX FIFO, ultimately delivered towards
      the host CPU as corrupted.
      
      Fixes: 40755a0f ("net: systemport: add suspend and resume support")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      704d33e7
    • F
      net: systemport: enable RX interrupts after NAPI · 8edf0047
      Florian Fainelli 提交于
      There is currently a small window during which the SYSTEMPORT adapter
      enables its RX interrupts without having enabled its NAPI handler, which
      can result in packets to be discarded during interface bringup.
      
      A similar but more serious window exists in bcm_sysport_resume() during
      which we can have the RDMA engine not fully prepared to receive packets
      and yet having RX interrupts enabled.
      
      Fix this my moving the RX interrupt enable down to
      bcm_sysport_netif_start() after napi_enable() for the RX path is called,
      which fixes both call sites: bcm_sysport_open() and
      bcm_sysport_resume().
      
      Fixes: b02e6d9b ("net: systemport: add bcm_sysport_netif_{enable,stop}")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8edf0047
  10. 20 10月, 2014 1 次提交
  11. 11 10月, 2014 1 次提交
    • F
      net: systemport: avoid unbalanced enable_irq_wake calls · 61b423a8
      Florian Fainelli 提交于
      Multiple enable_irq_wake() calls will keep increasing the IRQ
      wake_depth, which ultimately leads to the following types of
      situation:
      
      1) enable Wake-on-LAN interrupt w/o password
      2) enable Wake-on-LAN interrupt w/ password
      3) enable Wake-on-LAN interrupt w/o password
      4) disable Wake-on-LAN interrupt
      
      After step 4), SYSTEMPORT would always wake-up the system no matter what
      wake-up device we use, which is not what we want. Fix this by making
      sure there are no unbalanced enable_irq_wake() calls.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61b423a8
  12. 05 10月, 2014 1 次提交
  13. 09 9月, 2014 1 次提交
    • F
      net: systemport: check harder for out of memory conditions · fe24ba08
      Florian Fainelli 提交于
      There is a potential case where we might be failing to refill a
      control block, leaving it with both a NULL skb pointer *and* a NULL
      dma_unmap_addr.
      
      The way we process incoming packets, by first calling
      dma_unmap_single(), and then only checking for a potential NULL skb can
      lead to situations where do pass a NULL dma_unmap_addr() to
      dma_unmap_single(), resulting in an oops.
      
      Fix this my moving the NULL skb check earlier, since no backing skb
      also means no corresponding DMA mapping for this packet.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe24ba08
  14. 05 9月, 2014 1 次提交
    • F
      net: systemport: update UMAC_CMD only when link is detected · 4a804c01
      Florian Fainelli 提交于
      When we bring the interface down, phy_stop() will schedule the PHY
      state machine to call our link adjustment callback. By the time we do so,
      we may have clock gated off the SYSTEMPORT hardware block, and this will
      cause bus errors to happen in bcm_sysport_adj_link():
      
      Make sure that we only touch the UMAC_CMD register when there is an
      actual link. This is safe to do for two reasons:
      
      - updating the Ethernet MAC registers only make sense when a physical
        link is present
      - the PHY library state machine first set phydev->link = 0 before
        invoking phydev->adjust_link in the PHY_HALTED case
      
      This is a similar fix to the GENET one:
      c677ba8b ("net: bcmgenet: update
      UMAC_CMD only when link is detected").
      
      Fixes: 80105bef ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a804c01
  15. 02 9月, 2014 1 次提交
  16. 10 7月, 2014 2 次提交
  17. 08 7月, 2014 5 次提交
  18. 02 7月, 2014 3 次提交
  19. 06 6月, 2014 4 次提交
  20. 03 6月, 2014 1 次提交
  21. 23 5月, 2014 1 次提交
  22. 17 5月, 2014 2 次提交
  23. 16 5月, 2014 2 次提交