Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 30 4月, 2013 4 次提交
  3. 27 4月, 2013 3 次提交
  5. 25 4月, 2013 3 次提交
  7. 23 4月, 2013 5 次提交
  9. 20 4月, 2013 3 次提交
  11. 13 4月, 2013 1 次提交
  13. 12 4月, 2013 1 次提交
  15. 18 3月, 2013 1 次提交
  17. 15 3月, 2013 3 次提交
  19. 08 3月, 2013 1 次提交
  21. 07 3月, 2013 1 次提交
  23. 06 3月, 2013 1 次提交
    • G
      benet: Wait f/w POST until timeout · 66d29cbc
      由 Gavin Shan 提交于 
      While PCI card faces EEH errors, reset (usually hot reset) is
expected to recover from the EEH errors. After EEH core finishes
the reset, the driver callback (be_eeh_reset) is called and wait
the firmware to complete POST successfully. The original code would
return with error once detecting failure during POST stage. That
seems not enough.

The patch forces the driver (be_eeh_reset) to wait the firmware
completes POST until timeout, instead of returning error upon
detection POST failure immediately. Also, it would improve the
reliability of the EEH funtionality of the driver.
Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
Acked-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66d29cbc
  25. 14 2月, 2013 1 次提交
  27. 05 2月, 2013 2 次提交
  29. 30 1月, 2013 1 次提交
  31. 13 1月, 2013 1 次提交
    • S
      be2net: fix unconditionally returning IRQ_HANDLED in INTx · d0b9cec3
      由 Sathya Perla 提交于 
      commit e49cc34f introduced an unconditional IRQ_HANDLED return in be_intx()
to workaround Lancer and BE2 HW issues. This is bad as it prevents the kernel
from detecting interrupt storms due to broken HW.

The BE2/Lancer HW issues are:
1) In Lancer, there is no means for the driver to detect if the interrupt
belonged to device, other than counting and notifying events.
2) In Lancer de-asserting INTx takes a while, causing the INTx irq handler
to be called multiple times till the de-assert happens.
3) In BE2, we see an occasional interrupt even when EQs are unarmed.

Issue (1) can cause the notified events to be orphaned, if NAPI was already
running.
This patch fixes this issue by scheduling NAPI only if it is not scheduled
already. Doing this also takes care of possible events_get() race that may be
caused due to issue (2) and (3). Also, IRQ_HANDLED is returned only the first
time zero events are detected.
(Thanks Ben H. for the feedback and suggestions.)
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0b9cec3
  33. 07 1月, 2013 1 次提交
  35. 19 12月, 2012 2 次提交
    • S
      be2net: fix wrong frag_idx reported by RX CQ · d23e946c
      由 Sathya Perla 提交于 
      The RX CQ can report completions with invalid frag_idx when the RXQ that
was *previously* using it, was not cleaned up properly. This hits
a BUG_ON() in be2net.

When completion coalescing is enabled on a CQ, an explicit CQ-notify
(with rearm) is needed for each compl, to flush partially coalesced CQ
entries that are pending DMA.

In be_close(), this fix now notifies CQ for each compl, waits explicitly
for the flush compl to arrive and complains if it doesn't arrive.

Also renaming be_crit_error() to be_hw_error() as it's the more
appropriate name and to convey that we don't wait for the flush compl
only when a HW error has occurred.
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d23e946c
    • S
      be2net: fix be_close() to ensure all events are ack'ed · a323d9bf
      由 Sathya Perla 提交于 
      In be_close(), be_eq_clean() must be called after all RX/TX/MCC queues
have been cleaned to ensure that any events caused while cleaning up
completions are notified/acked. Not clearing all events can cause
upredictable behaviour when RX rings are re-created in the subsequent
be_open().
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a323d9bf
  37. 08 12月, 2012 1 次提交
  39. 04 12月, 2012 1 次提交
  41. 29 11月, 2012 1 次提交
  43. 24 11月, 2012 1 次提交
    • S
      be2net: fix a possible events_get() race on BE2 · 0b545a62
      由 Sathya Perla 提交于 
      On BE2 chip, an interrupt being raised even when EQ is in un-armed state has
been observed a few times.  This is not expected and has never been
observed on BE3/Lancer chips.

As a consequence, be_msix()::events_get() and be_poll()::events_get()
can race and notify an EQ wrongly causing a CEV UE. The other possible
side-effect would be traffic stalling because after notifying EQ,
napi_schedule() is ignored as NAPI is already running.

This patch fixes this issue by counting events only in be_poll().
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b545a62
  45. 20 11月, 2012 1 次提交