[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200908192400.GL25236@zn.tnic>
Date: Tue, 8 Sep 2020 21:24:00 +0200
From: Borislav Petkov <bp@...en8.de>
To: Gregor Herburger <gregor.herburger@...tq-group.com>
Cc: "york.sun@....com" <york.sun@....com>,
"mchehab@...nel.org" <mchehab@...nel.org>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"james.morse@....com" <james.morse@....com>,
"rrichter@...vell.com" <rrichter@...vell.com>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/1] edac: fsl_ddr_edac: fix expected data message
On Fri, Sep 04, 2020 at 03:32:58PM +0200, Gregor Herburger wrote:
> That shouldn't happen. The whole if-block is only executed when a single
> bit correctable error has occured (DDR_EDE_SBE). So we always should have
> bad_data_bit or bad_ecc_bit (exclusively).
Ooh, that sbe_ecc_decode() function would give you either the data bit
- if that one is in error - and if not the data bit, then the ECC bit.
Aha.
Ok, so what the driver should do, IMO, is this:
if (bad_data_bit != -1) {
...
fsl_mc_printk("Single-bit data error, ... ", bad_data_bit);
fsl_mc_printk("Expected Data/Captured Data, ... ", exp_high, exp_low, cap_high, cap_low);
}
if (bad_ecc_bit != -1) {
...
fsl_mc_printk("Single-bit ECC error, ... ", bad_ecc_bit);
fsl_mc_printk("Expected ECC/Captured ECC, ... ", exp_syndrome, syndrome);
}
This way you only print either the data or the ECC value which was in
error but not both.
Makes sense?
> Also i just noticed in the kernel log is no hint that this is an
> single bit error. Maybe we should add this too?
Yap, see above.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists