Re: [PATCH] EDAC/dmc520: Don't print an error for each unconfigured interrupt line

From: Tyler Hicks <tyhicks@linux.microsoft.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Lei Wang <lewan@microsoft.com>, Tony Luck <tony.luck@intel.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Sinan Kaya <okaya@kernel.org>,
	Shiping Ji <shiping.linux@gmail.com>,
	James Morse <james.morse@arm.com>,
	Robert Richter <rric@kernel.org>,
	linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] EDAC/dmc520: Don't print an error for each unconfigured interrupt line
Date: Tue, 18 Jan 2022 09:28:16 -0600	[thread overview]
Message-ID: <20220118152816.GA89184@sequoia> (raw)
In-Reply-To: <YeRkGvestiloCAUV@zn.tnic>

On 2022-01-16 19:29:46, Borislav Petkov wrote:
> On Tue, Jan 11, 2022 at 10:38:00AM -0600, Tyler Hicks wrote:
> > The dmc520 driver requires that at least one interrupt line, out of the ten
> > possible, is configured. The driver prints an error and returns -EINVAL
> > from its .probe function if there are no interrupt lines configured.
> > 
> > Don't print a KERN_ERR level message for each interrupt line that's
> > unconfigured as that can confuse users into thinking that there is an
> > error condition.
> > 
> > Before this change, the following KERN_ERR level messages would be
> > reported if only dram_ecc_errc and dram_ecc_errd were configured in the
> > device tree:
> > 
> >  dmc520 68000000.dmc: IRQ ram_ecc_errc not found
> >  dmc520 68000000.dmc: IRQ ram_ecc_errd not found
> >  dmc520 68000000.dmc: IRQ failed_access not found
> >  dmc520 68000000.dmc: IRQ failed_prog not found
> >  dmc520 68000000.dmc: IRQ link_err not
> >  dmc520 68000000.dmc: IRQ temperature_event not found
> >  dmc520 68000000.dmc: IRQ arch_fsm not found
> >  dmc520 68000000.dmc: IRQ phy_request not found
> > 
> > Fixes: 1088750d7839 ("EDAC: Add EDAC driver for DMC520")
> > Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
> > Cc: <stable@vger.kernel.org>
> 
> Why stable? AFAICT, this is fixing only the spew of some error messages
> but the driver is still functional.

KERN_ERR messages trip log scanners and cause concern that the
kernel/hardware is not configured or working correctly. They also add a
little big of ongoing stress into kernel maintainer's lives, as we
prepare and test kernel updates, since they show up as red text in
journalctl output that we have to think about regularly. Multiple
KERN_ERR messages, 8 in this case, can also be considered a little worse
than a single error message.

I feel like this trivial fix is worth taking into stable rather than
suppressing these errors (mentally and in log scanners) for years.

Tyler

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette
> 