Re: [PATCH] wifi: rtw88: usb: silence log flooding error message

[Simon Horman <simon.horman@corigine.com>]

On Fri, May 26, 2023 at 12:17:36PM +0200, Sascha Hauer wrote:
> On Wed, May 24, 2023 at 01:34:52PM +0200, Simon Horman wrote:
> > On Wed, May 24, 2023 at 12:39:34PM +0200, Sascha Hauer wrote:
> > > When receiving more rx packets than the kernel can handle the driver
> > > drops the packets and issues an error message. This is bad for two
> > > reasons. The logs are flooded with myriads of messages, but then time
> > > consumed for printing messages in that critical code path brings down
> > > the device. After some time of excessive rx load the driver responds
> > > with:
> > > 
> > > rtw_8822cu 1-1:1.2: failed to get tx report from firmware
> > > rtw_8822cu 1-1:1.2: firmware failed to report density after scan
> > > rtw_8822cu 1-1:1.2: firmware failed to report density after scan
> > > 
> > > The device stops working until being replugged.
> > > 
> > > Fix this by lowering the priority to debug level and also by
> > > ratelimiting it.
> > > 
> > > Fixes: a82dfd33d1237 ("wifi: rtw88: Add common USB chip support")
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > ---
> > >  drivers/net/wireless/realtek/rtw88/usb.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c
> > > index 44a5fafb99055..976eafa739a2d 100644
> > > --- a/drivers/net/wireless/realtek/rtw88/usb.c
> > > +++ b/drivers/net/wireless/realtek/rtw88/usb.c
> > > @@ -535,7 +535,7 @@ static void rtw_usb_rx_handler(struct work_struct *work)
> > >  		}
> > >  
> > >  		if (skb_queue_len(&rtwusb->rx_queue) >= RTW_USB_MAX_RXQ_LEN) {
> > > -			rtw_err(rtwdev, "failed to get rx_queue, overflow\n");
> > > +			dev_dbg_ratelimited(rtwdev->dev, "failed to get rx_queue, overflow\n");
> > 
> > This is certainly an improvement. But as I understand things
> > it is still somewhat verbose if the condition persists.
> > Did you consider dev_dbg_once()?
> 
> My rationale was that dev_dbg() is normally disabled anyway. With
> CONFIG_DYNAMIC_PRINTK you would still have fine grained control if you
> want to see this message or not.
> 
> Personally I don't care that much, I would switch to dev_dbg_once() if
> that's preferred.

No strong preference from my side.