[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CY8PR11MB71341040D7F7989091FB16EC89BE2@CY8PR11MB7134.namprd11.prod.outlook.com>
Date: Sat, 19 Apr 2025 02:32:09 +0000
From: "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>
CC: "Xu, Feng F" <feng.f.xu@...el.com>, Borislav Petkov <bp@...en8.de>, "James
Morse" <james.morse@....com>, Mauro Carvalho Chehab <mchehab@...nel.org>,
Robert Richter <rric@...nel.org>, "Lai, Yi1" <yi1.lai@...el.com>, "Fan,
Shawn" <shawn.fan@...el.com>, "linux-edac@...r.kernel.org"
<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 6/7] EDAC/{skx_common,i10nm}: Refactor
show_retry_rd_err_log()
> From: Luck, Tony <tony.luck@...el.com>
> [...]
> > Do you suggest not using the "cecnt_widths" field for now (since it
> > currently only has the value 4 and the code appears somewhat
> > redundant) until we add the EDAC support for Diamond Rapids in the
> future? Or we can keep the "cecnt_widths" field?
>
> The general process is to avoid adding code/infrastructure for future use (as
> sometimes that future never comes). But I have high hopes that Diamond
> Rapids will appear on time. So I'll leave the cecnt_widths code in place. It's
> not much code.
>
OK, got it. Thanks for reminding me of the process.
-Qiuxu
Powered by blists - more mailing lists