Hi, John Youn <John.Youn@xxxxxxxxxxxx> writes: >>>> Do you think we introduce this when adding evt->cache in TH? >>>> Even without evt->cache we still could overwrite evt->count - so, was >>>> that seen before evt->cache? >>> >>> The multiple TH calls could have happened even before we introduced >>> evt->cache, but only with the cache would it have caused a failure due >>> to overwriting the cached events on multiple calls. >> >> Right, multiple TH calls should NEVER happen, because our IRQ line is >> masked. Unless, and this is a long shot, IRQ line is shared and ANOTHER >> device is causing IRQ to be raised. Can you show the output of: > > We thought about this and ensured that there is no sharing of the IRQ. > We still see the dual calls to the top-half. > >> >> # grep dwc3 /proc/interrupts >> >> If another device raises the interrupt, then we will get into our TH, >> however we should just return IRQ_HANDLED in that case because we >> shouldn't be generating events. > > No, we will still be generating events. The masking of the interrupt > just deasserts the interrupt line. Events are still written out as > usual. Yes, events should be written to event buffer, but the IRQ line shouldn't assert which means that our IRQ handler shouldn't get called. If we really _are_ getting called, then we either have shared IRQ line (which we must cope with, anyway) or there's a spurious IRQ triggering. -- balbi
Attachment:
signature.asc
Description: PGP signature