dwc2: irq 66: nobody cared triggered on resume

[Stefan Wahren]

Hello Lukas,

Am 22.06.24 um 20:47 schrieb Lukas Wunner:
> On Sat, Jun 22, 2024 at 02:23:33PM +0200, Stefan Wahren wrote:
>> i currently experiment with suspend to idle on the Raspberry Pi 3 A+.
>> Supend & resume works expected as long as no USB device is connected to
>> the board. If i connect a USB hub to the Pi, the resume phase is
>> significantly delayed and the kernel disabled IRQ 66 which belongs to DWC2.
> [...]
>> [ 1131.109996] PM: noirq resume of devices complete after 1.273 msecs
>> [ 1131.111208] PM: early resume of devices complete after 1.051 msecs
>> [ 1131.230277] brcmfmac: brcmf_fw_alloc_request: using
>> brcm/brcmfmac43455-sdio for chip BCM4345/6
>> [ 1131.458687] irq 66: nobody cared (try booting with the "irqpoll" option)
>> [ 1131.458714] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.10.0-rc3-g7fd4227d1bd5-dirty #49
>> [ 1131.458734] Hardware name: BCM2835
>> [ 1131.458744] Call trace:
> [...]
>> [ 1131.458877] note_interrupt from handle_irq_event+0x88/0x8c
>> [ 1131.458900] handle_irq_event from handle_level_irq+0xb4/0x1ac
>> [ 1131.458923] handle_level_irq from generic_handle_domain_irq+0x24/0x34
>> [ 1131.458957] generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28
>> [ 1131.458992] bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34
>> [ 1131.459024] generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44
>> [ 1131.459056] generic_handle_arch_irq from __irq_svc+0x88/0xb0
>> [ 1131.459079] Exception stack(0xc1b01f20 to 0xc1b01f68)
>> [ 1131.459142] __irq_svc from default_idle_call+0x1c/0xb0
>> [ 1131.459167] default_idle_call from do_idle+0x21c/0x284
>> [ 1131.459202] do_idle from cpu_startup_entry+0x28/0x2c
>> [ 1131.459239] cpu_startup_entry from kernel_init+0x0/0x12c
>> [ 1131.459271] handlers:
>> [ 1131.459279] [<f539e0f4>] dwc2_handle_common_intr
>> [ 1131.459308] [<75cd278b>] usb_hcd_irq
>> [ 1131.459329] Disabling IRQ #66
> [...]
>> An ideas what causing this issue?
> Interrupts are re-enabled after the resume_noirq phase.  Looks like
> the chip signals an interrupt right afterwards but the two hardirq
> handlers do not feel responsible.
>
> The only option might be to add a few printk() in dwc2_handle_common_intr(),
> usb_hcd_irq() and dwc2_handle_hcd_intr() (called from usb_hcd_irq())
> to see why they're all returning IRQ_NONE without clearing the source
> of the interrupt.  The chip just keeps signaling interrupts because
> the driver doesn't handle them, hence the IRQ storm which the IRQ core
> eventually stops by outright disabling the interrupt.
thanks for your suggestion. Unfortunately placing printk in those busy
interrupt handler is futile, so i switched to debugfs. This issue would
be much easier in case the interrupt wouldn't be shared. But first let
me share some outputs before i start to extend debugfs further:

1. No hub connected to Rpi 3 A+

root at raspberrypi:/sys/kernel/debug/usb/3f980000.usb# cat state
DCFG=0x00000000, DCTL=0x00000000, DSTS=0x0007ff02
DIEPMSK=0x00000000, DOEPMASK=0x00000000
GINTMSK=0xf3000806, GINTSTS=0x04000023
DAINTMSK=0x00000000, DAINT=0x00000000
GNPTXSTS=0x00080100, GRXSTSR=3f83bbfe

2. Hub connected before suspend / irq issue

DCFG=0x00000000, DCTL=0x00000000, DSTS=0x0007a202
DIEPMSK=0x00000000, DOEPMASK=0x00000000
GINTMSK=0xf300080e, GINTSTS=0x04000023
DAINTMSK=0x00000000, DAINT=0x00000000
GNPTXSTS=0x08080100, GRXSTSR=789a460a

3. Hub connected after suspend / irq issue

DCFG=0x00000000, DCTL=0x00000000, DSTS=0x0007ff02
DIEPMSK=0x00000000, DOEPMASK=0x00000000
GINTMSK=0xf1000806, GINTSTS=0x0500002b
DAINTMSK=0x000000ff, DAINT=0x00000000
GNPTXSTS=0x29080100, GRXSTSR=befdf595

Based on my limited knowledge and observations the issue seems related
to GINTMSK/GINTSTS and a outstanding GINTSTS_PRTINT.

Regards