Ack: [Trusty][SRU][PATCH 1/1] ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined

[Brad Figg]

On 06/18/2014 08:49 AM, Joseph Salisbury wrote:
> From: Sander Eikelenboom <linux at eikelenboom.it>
> 
> BugLink: http://bugs.launchpad.net/bugs/1319457
> 
> This (widely used) construction:
> 
> if(printk_ratelimit())
> 	dev_dbg()
> 
> Causes the ratelimiting to spam the kernel log with the "callbacks suppressed"
> message below, even while the dev_dbg it is supposed to rate limit wouldn't
> print anything because DEBUG is not defined for this device.
> 
> [  533.803964] retire_playback_urb: 852 callbacks suppressed
> [  538.807930] retire_playback_urb: 852 callbacks suppressed
> [  543.811897] retire_playback_urb: 852 callbacks suppressed
> [  548.815745] retire_playback_urb: 852 callbacks suppressed
> [  553.819826] retire_playback_urb: 852 callbacks suppressed
> 
> So use dev_dbg_ratelimited() instead of this construction.
> 
> Signed-off-by: Sander Eikelenboom <linux at eikelenboom.it>
> Signed-off-by: Takashi Iwai <tiwai at suse.de>
> (backported from commit b7a7723513dc89f83d6df13206df55d4dc26e825)
> Signed-off-by: Joseph Salisbury <joseph.salisbury at canonical.com>
> ---
>  sound/usb/pcm.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> index 7bfa7a1..ede4b92 100644
> --- a/sound/usb/pcm.c
> +++ b/sound/usb/pcm.c
> @@ -1487,9 +1487,9 @@ static void retire_playback_urb(struct snd_usb_substream *subs,
>  	 * The error should be lower than 2ms since the estimate relies
>  	 * on two reads of a counter updated every ms.
>  	 */
> -	if (printk_ratelimit() &&
> -	    abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2)
> -		snd_printk(KERN_DEBUG "delay: estimated %d, actual %d\n",
> +	if (abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2)
> +		dev_dbg_ratelimited(&subs->dev->dev,
> +			"delay: estimated %d, actual %d\n",
>  			est_delay, subs->last_delay);
>  
>  	if (!subs->running) {
> 

Seems like this should be coming in via stable upstream.

-- 
Brad Figg brad.figg at canonical.com http://www.canonical.com