1. 09 2月, 2022 3 次提交
  2. 31 1月, 2022 1 次提交
  3. 28 1月, 2022 1 次提交
  4. 27 1月, 2022 5 次提交
  5. 25 1月, 2022 3 次提交
  6. 20 1月, 2022 2 次提交
  7. 10 1月, 2022 1 次提交
  8. 07 1月, 2022 3 次提交
  9. 06 1月, 2022 1 次提交
  10. 03 1月, 2022 3 次提交
  11. 30 12月, 2021 1 次提交
  12. 27 12月, 2021 1 次提交
  13. 19 12月, 2021 1 次提交
  14. 17 12月, 2021 1 次提交
  15. 16 12月, 2021 1 次提交
  16. 15 12月, 2021 1 次提交
    • J
      net: fec: fix system hang during suspend/resume · 0b6f65c7
      Joakim Zhang 提交于
      1. During normal suspend (WoL not enabled) process, system has posibility
      to hang. The root cause is TXF interrupt coming after clocks disabled,
      system hang when accessing registers from interrupt handler. To fix this
      issue, disable all interrupts when system suspend.
      
      2. System also has posibility to hang with WoL enabled during suspend,
      after entering stop mode, then magic pattern coming after clocks
      disabled, system will be waked up, and interrupt handler will be called,
      system hang when access registers. To fix this issue, disable wakeup
      irq in .suspend(), and enable it in .resume().
      Signed-off-by: NJoakim Zhang <qiangqing.zhang@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b6f65c7
  17. 14 12月, 2021 2 次提交
  18. 08 12月, 2021 1 次提交
    • J
      net: fec: only clear interrupt of handling queue in fec_enet_rx_queue() · b5bd95d1
      Joakim Zhang 提交于
      Background:
      We have a customer is running a Profinet stack on the 8MM which receives and
      responds PNIO packets every 4ms and PNIO-CM packets every 40ms. However, from
      time to time the received PNIO-CM package is "stock" and is only handled when
      receiving a new PNIO-CM or DCERPC-Ping packet (tcpdump shows the PNIO-CM and
      the DCERPC-Ping packet at the same time but the PNIO-CM HW timestamp is from
      the expected 40 ms and not the 2s delay of the DCERPC-Ping).
      
      After debugging, we noticed PNIO, PNIO-CM and DCERPC-Ping packets would
      be handled by different RX queues.
      
      The root cause should be driver ack all queues' interrupt when handle a
      specific queue in fec_enet_rx_queue(). The blamed patch is introduced to
      receive as much packets as possible once to avoid interrupt flooding.
      But it's unreasonable to clear other queues'interrupt when handling one
      queue, this patch tries to fix it.
      
      Fixes: ed63f1dc (net: fec: clear receive interrupts before processing a packet)
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Reported-by: NNicolas Diaz <nicolas.diaz@nxp.com>
      Signed-off-by: NJoakim Zhang <qiangqing.zhang@nxp.com>
      Link: https://lore.kernel.org/r/20211206135457.15946-1-qiangqing.zhang@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      b5bd95d1
  19. 30 11月, 2021 1 次提交
  20. 22 11月, 2021 2 次提交
  21. 18 11月, 2021 3 次提交
  22. 17 11月, 2021 2 次提交