1. 20 10月, 2019 1 次提交
  2. 25 9月, 2019 1 次提交
  3. 29 8月, 2019 1 次提交
  4. 09 7月, 2019 1 次提交
  5. 25 6月, 2019 2 次提交
  6. 24 6月, 2019 1 次提交
  7. 19 6月, 2019 2 次提交
  8. 23 5月, 2019 1 次提交
  9. 15 5月, 2019 1 次提交
  10. 08 5月, 2019 1 次提交
  11. 06 5月, 2019 1 次提交
  12. 03 5月, 2019 2 次提交
  13. 09 4月, 2019 1 次提交
  14. 22 3月, 2019 1 次提交
  15. 20 3月, 2019 1 次提交
  16. 04 3月, 2019 4 次提交
  17. 15 2月, 2019 1 次提交
  18. 14 2月, 2019 1 次提交
  19. 13 2月, 2019 1 次提交
  20. 09 2月, 2019 1 次提交
  21. 30 1月, 2019 1 次提交
  22. 05 1月, 2019 1 次提交
  23. 19 12月, 2018 4 次提交
    • A
      net: macb: add missing barriers when reading descriptors · 6e0af298
      Anssi Hannula 提交于
      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: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e0af298
    • A
      net: macb: fix dropped RX frames due to a race · 8159ecab
      Anssi Hannula 提交于
      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: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Tested-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8159ecab
    • A
      net: macb: fix random memory corruption on RX with 64-bit DMA · e100a897
      Anssi Hannula 提交于
      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: NAnssi Hannula <anssi.hannula@bitwise.fi>
      Acked-by: NHarini Katakam <harini.katakam@xilinx.com>
      Tested-by: NClaudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e100a897
    • C
      net: macb: restart tx after tx used bit read · 42983885
      Claudiu Beznea 提交于
      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: NClaudiu Beznea <claudiu.beznea@microchip.com>
      Acked-by: NNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42983885
  24. 04 12月, 2018 1 次提交
  25. 26 10月, 2018 1 次提交
  26. 22 10月, 2018 1 次提交
  27. 26 9月, 2018 2 次提交
  28. 17 9月, 2018 1 次提交
  29. 13 9月, 2018 2 次提交