On Fri, 04 Aug 2023 17:15:14 +0200, Mark Brown wrote: > > On Fri, Aug 04, 2023 at 04:42:34PM +0200, Takashi Iwai wrote: > > Pierre-Louis Bossart wrote: > > > > > And also changes _soc_pcm_ret() to not log for -EINVAL errors, to fix > > > > the other error. Userspace passing wrong parameters should not lead > > > > to dmesg messages. > > > > Maybe, but it's a questionable flow if pipewire tries to open stuff > > > without the mixer values set-up. Is there something done about this? > > > I think it's an oft-seen problem when user runs the system without > > installing a proper UCM profile. > > Yeah, it's really easy to do. > > > > It really makes no sense for userspace to try and open devices that are > > > known to be problematic. We can push kernel error logs below the rug, it > > > doesn't make the programming flows better. > > > Downgrading the message also hides to show what's wrong there. > > Although the message doesn't indicate how to fix the problem, no > > message would make debug harder. > > > So in general I agree that it's annoying and it should be fixed, but > > hiding all as default can be bad, too. Maybe we can introduce a > > counter and shut out after three strikes? > > Hrm, do systems typically filter out debug logs? Most of the systems I > work on do still log debug logs, they just only include them in dmesg by > default. I thought flipping the dynamic debug flag needed for showing them up with dev_dbg() and co. > There are ratelimited printk APIs which we could use, though > they're not quite ratelimited enough for this I think. Yes, this is printed not too frequently but just repeatedly. IMHO, dev_err_once() would be a good compromise. thanks, Takashi
