Re: [PATCH net-next 3/4] r8152: Add irq mitigation for RTL8157/9

[Michal Pecio]

On Wed, 29 Apr 2026 06:06:30 +0200, Birger Koblitz wrote:
> On 29/04/2026 3:56 am, Andrew Lunn wrote:
> > On Tue, Apr 28, 2026 at 05:47:23AM +0200, Birger Koblitz wrote:  
> >> Add interrupt mitigation code for both RTL8157 and RTL8159 that prevents
> >> USB interrupt callbacks with urb->status ESHUTDOWN being triggered. While the
> >> issue is rarely seen on the RTL8157, without the mitigation, it is
> >> common on the RTL8159:
> >> [273.561863] r8152 7-1:1.0 enx88c9b3b5xxxx: Stop submitting intr, status -108
> >>
> >> Signed-off-by: Birger Koblitz <mail@xxxxxxxxxxxxxxxxx>
> >> ---
> >>   drivers/net/usb/r8152.c | 6 ++++++
> >>   1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> >> index 8255261d73148a7b4dabe0188faf07cb1f356437..08cc3c1dae0facb2400890ba4d093c97ed56d40b 100644
> >> --- a/drivers/net/usb/r8152.c
> >> +++ b/drivers/net/usb/r8152.c
> >> @@ -8444,6 +8444,12 @@ static void r8156_init(struct r8152 *tp)
> >>   	else
> >>   		r8153_u2p3en(tp, false);
> >>   
> >> +	if (tp->version >= RTL_VER_16) {
> >> +		/* Disable Interrupt Mitigation */
> >> +		ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xcf04,
> >> +				  BIT(0) | BIT(1) | BIT(2) | BIT(7));
> >> +	}  
> > 
> > What does interrupt mitigation do?
> > 
> > Is this a different name for interrupt coalescence, where the MAC
> > delays interrupts for a period of time so more packets are in the
> > receive ring when it does interrupt, so reducing the number of
> > interrupts, and bigger bursts of packets are processed at once?
> >   
> 
> I do not understand what the mechanism behind this is, there is no
> more documentation in the original driver. I experimented with this
> for some time and the effect that I see is that it prevents
> interrupts after shutdown.

What do you mean by "after shutdown", driver unbind? You shouldn't be
seeing URB completions then if the disconnect() method unlinks them.
And if it doesn't, completions may be using driver data after free.

Or maybe you have pending URBs while calling set_configuration() or
set_interface(), which is dodgy too but at least not asking for panic.

Other cause of ESHUTDOWN might be serious host controller failure, but
you would likely get other log noise with that, at least with xhci.

What shows up if you repro with this enabled?
echo 'module usbcore +p' >/proc/dynamic_debug/control

Regards,
Michal