Hi, Douglas Anderson <dianders@xxxxxxxxxxxx> writes: > In general it is wise to clear interrupts before processing them. If > you don't do that, you can get: > 1. Interrupt happens > 2. You look at system state and process interrupt > 3. A new interrupt happens > 4. You clear interrupt without processing it. > > This patch was actually a first attempt to fix missing device insertions > as described in (usb: dwc2: host: Fix missing device insertions) and it > did solve some of the signal bouncing problems but not all of > them (which is why I submitted the other patch). Specifically, this > patch itself would sometimes change: > 1. hardware sees connect > 2. hardware sees disconnect > 3. hardware sees connect > 4. dwc2_port_intr() - clears connect interrupt > 5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect() > > ...to: > 1. hardware sees connect > 2. hardware sees disconnect > 3. dwc2_port_intr() - clears connect interrupt > 4. hardware sees connect > 5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect() > > ...but with different timing then sometimes we'd still miss cable > insertions. > > In any case, though this patch doesn't fix any (known) problems, it > still seems wise as a general policy to clear interrupt before handling > them. > > Note that for dwc2_handle_usb_port_intr(), instead of moving the clear > of PRTINT to the beginning of the function we remove it completely. The > only way to clear PRTINT is to clear the sources that set it in the > first place. > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > Acked-by: John Youn <johnyoun@xxxxxxxxxxxx> > Tested-by: John Youn <johnyoun@xxxxxxxxxxxx> $ patch -p1 --dry-run < patch.diff checking file drivers/usb/dwc2/core_intr.c checking file drivers/usb/dwc2/hcd_intr.c Hunk #4 FAILED at 365. Hunk #5 succeeded at 388 (offset 11 lines). 1 out of 5 hunks FAILED Care to rebase on top of my testing/next ? -- balbi
Attachment:
signature.asc
Description: PGP signature