Re: [PATCH 1/3] usb: dwc3: gadget: Prevent losing events in event cache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux