1. 25 Sep, 2019 1 commit
  2. 28 Aug, 2019 1 commit
  3. 08 Jul, 2019 1 commit
  4. 24 Jun, 2019 3 commits
  5. 19 Jun, 2019 2 commits
  6. 23 May, 2019 1 commit
  7. 14 May, 2019 1 commit
  8. 07 May, 2019 1 commit
  9. 06 May, 2019 1 commit
  10. 03 May, 2019 2 commits
  11. 08 Apr, 2019 1 commit
  12. 21 Mar, 2019 1 commit
  13. 19 Mar, 2019 1 commit
  14. 03 Mar, 2019 4 commits
  15. 14 Feb, 2019 2 commits
  16. 12 Feb, 2019 1 commit
  17. 08 Feb, 2019 1 commit
  18. 29 Jan, 2019 1 commit
  19. 04 Jan, 2019 1 commit
  20. 19 Dec, 2018 3 commits
    • Anssi Hannula's avatar
      net: macb: add missing barriers when reading descriptors · 6e0af298
      Anssi Hannula authored
      When reading buffer descriptors on RX or on TX completion, an
      RX_USED/TX_USED bit is checked first to ensure that the descriptors have
      been populated, i.e. the ownership has been transferred. However, there
      are no memory barriers to ensure that the data protected by the
      RX_USED/TX_USED bit is up-to-date with respect to that bit.
      
      Specifically:
      
      - TX timestamp descriptors may be loaded before ctrl is loaded for the
        TX_USED check, which is racy as the descriptors may be updated between
        the loads, causing old timestamp descriptor data to be used.
      
      - RX ctrl may be loaded before addr is loaded for the RX_USED check,
        which is racy as a new frame may be written between the loads, causing
        old ctrl descriptor data to be used.
        This issue exists for both macb_rx() and gem_rx() variants.
      
      Fix the races by adding DMA read memory barriers on those paths and
      reordering the reads in macb_rx().
      
      I have not observed any actual problems in practice caused by these
      being missing, though.
      
      Tested on a ZynqMP based system.
      
      Fixes: 89e5785f
      
       ("[PATCH] Atmel MACB ethernet driver")
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e0af298
    • Anssi Hannula's avatar
      net: macb: fix dropped RX frames due to a race · 8159ecab
      Anssi Hannula authored
      Bit RX_USED set to 0 in the address field allows the controller to write
      data to the receive buffer descriptor.
      
      The driver does not ensure the ctrl field is ready (cleared) when the
      controller sees the RX_USED=0 written by the driver. The ctrl field might
      only be cleared after the controller has already updated it according to
      a newly received frame, causing the frame to be discarded in gem_rx() due
      to unexpected ctrl field contents.
      
      A message is logged when the above scenario occurs:
      
        macb ff0b0000.ethernet eth0: not whole frame pointed by descriptor
      
      Fix the issue by ensuring that when the controller sees RX_USED=0 the
      ctrl field is already cleared.
      
      This issue was observed on a ZynqMP based system.
      
      Fixes: 4df95131
      
       ("net/macb: change RX path for GEM")
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Tested-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8159ecab
    • Anssi Hannula's avatar
      net: macb: fix random memory corruption on RX with 64-bit DMA · e100a897
      Anssi Hannula authored
      64-bit DMA addresses are split in upper and lower halves that are
      written in separate fields on GEM. For RX, bit 0 of the address is used
      as the ownership bit (RX_USED). When the RX_USED bit is unset the
      controller is allowed to write data to the buffer.
      
      The driver does not guarantee that the controller already sees the upper
      half when the RX_USED bit is cleared, possibly resulting in the
      controller writing an incoming frame to an address with an incorrect
      upper half and therefore possibly corrupting unrelated system memory.
      
      Fix that by adding the necessary DMA memory barrier between the writes.
      
      This corruption was observed on a ZynqMP based system.
      
      Fixes: fff8019a
      
       ("net: macb: Add 64 bit addressing support for GEM")
      Signed-off-by: default avatarAnssi Hannula <anssi.hannula@bitwise.fi>
      Acked-by: default avatarHarini Katakam <harini.katakam@xilinx.com>
      Tested-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e100a897
  21. 18 Dec, 2018 1 commit
    • Claudiu Beznea's avatar
      net: macb: restart tx after tx used bit read · 42983885
      Claudiu Beznea authored
      
      
      On some platforms (currently detected only on SAMA5D4) TX might stuck
      even the pachets are still present in DMA memories and TX start was
      issued for them. This happens due to race condition between MACB driver
      updating next TX buffer descriptor to be used and IP reading the same
      descriptor. In such a case, the "TX USED BIT READ" interrupt is asserted.
      GEM/MACB user guide specifies that if a "TX USED BIT READ" interrupt
      is asserted TX must be restarted. Restart TX if used bit is read and
      packets are present in software TX queue. Packets are removed from software
      TX queue if TX was successful for them (see macb_tx_interrupt()).
      
      Signed-off-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      42983885
  22. 03 Dec, 2018 1 commit
  23. 25 Oct, 2018 1 commit
  24. 22 Oct, 2018 1 commit
  25. 25 Sep, 2018 2 commits
  26. 17 Sep, 2018 1 commit
  27. 13 Sep, 2018 2 commits
  28. 02 Sep, 2018 1 commit
    • Jia-Ju Bai's avatar
      net: cadence: Fix a sleep-in-atomic-context bug in macb_halt_tx() · 16fe10cf
      Jia-Ju Bai authored
      
      
      The kernel module may sleep with holding a spinlock.
      
      The function call paths (from bottom to top) in Linux-4.16 are:
      
      [FUNC] usleep_range
      drivers/net/ethernet/cadence/macb_main.c, 648:
      	usleep_range in macb_halt_tx
      drivers/net/ethernet/cadence/macb_main.c, 730:
      	macb_halt_tx in macb_tx_error_task
      drivers/net/ethernet/cadence/macb_main.c, 721:
      	_raw_spin_lock_irqsave in macb_tx_error_task
      
      To fix this bug, usleep_range() is replaced with udelay().
      
      This bug is found by my static analysis tool DSAC.
      
      Signed-off-by: default avatarJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16fe10cf