On 19.8.2025 12.08, Neronin, Niklas wrote:
On 19/08/2025 11.56, Mathias Nyman wrote:
On 19.8.2025 9.41, Michał Pecio wrote:
On Mon, 18 Aug 2025 23:11:03 +0200, Michał Pecio wrote:
A bisect effort is ongoing and c0c9379f235d ("Merge tag 'usb-6.16-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb") is bad,
so that's where the bug likely came from.
Looks like the result is in.
e1db856bd28891d70008880d7f1d3b8d1ea948fd is the first bad commit
commit e1db856bd28891d70008880d7f1d3b8d1ea948fd
Author: Niklas Neronin <niklas.neronin@xxxxxxxxxxxxxxx>
Date: Thu May 15 16:56:14 2025 +0300
usb: xhci: remove '0' write to write-1-to-clear register
Thanks for tracking this down, I see the issue now
We may lose interrupts due to this patch, example:
Hardware sets IMAN_IP BIT(0) when in needs attention
Driver later allows xHC interrupt by setting IMAN_IE BIT(1), but
Driver clears IMAN_IP (RW1C) when setting IMAN_IE so no interrupt is triggered.
Apologies for my blunder.
So, there can be an interrupt pending even when the interrupt is not enabled?
So it seems, Interrupt pending (IMAN_IP) is set if:
- event handler busy (EHB) is 0, and
- moderation counter (IMODC) reaches 0, and
- Internal IPE bit is set, meaning:
xHC inserted an event to the event ring (ring not empty), and
"block event interrupt" (BEI) is 0
It does not depend on interrupt enable (IMAN_IE) bit, that only gates the interrupt from being
generated for this interrupter
See xhci section 4.17.5
But there (ideally) should not be an interrupt pending when disabling the interrupt?
Yes, So it would be good to still print the debug message if IP is set.
But we should not clear the IP bit here, it will trigger an interrupt and get handled once
IE is enabled back.
I can submit a fix patch.
Sounds good.
Lets get this fixed as soon as possible.
Thanks
Mathias
