[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YXk6z9xWvS4B7eRP@zn.tnic>
Date: Wed, 27 Oct 2021 13:41:03 +0200
From: Borislav Petkov <bp@...en8.de>
To: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
Cc: x86@...nel.org, linux-edac@...r.kernel.org,
linux-kernel@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
"H . Peter Anvin" <hpa@...or.com>, yazen.ghannam@....com
Subject: Re: [PATCH v2 3/5] x86/mce: Use mca_msr_reg() in prepare_msrs()
On Tue, Oct 19, 2021 at 06:36:39PM -0500, Smita Koralahalli wrote:
> Replace MCx_{STATUS, ADDR, MISC} macros with mca_msr_reg().
And this is where your commit message and patch should end. It is a bad
idea to do textual replacements *and* functional changes in a single
patch: it is hard to review and debug if there are possible issues. So
you do the textual replacements in the first one and then the functional
changes in subsequent patches.
> Also, restructure the code to avoid multiple initializations for MCA
> registers.
What multiple initializations?
> SMCA machines define a different set of MSRs for MCA registers
> and mca_msr_reg() returns the proper MSR address for SMCA and legacy
> processors.
>
> Initialize MCA_MISC and MCA_SYND registers at the end after initializing
> MCx_{STATUS, DESTAT} which is further explained in the next patch.
And this should be *in* the next patch.
Also, there's no concept of "next patch" when you do git log on the
upstream tree and use different sorting etc. So a patch should be
self-contained and do one change only.
There's very good documentation in Documentation/process/, expecially
Documentation/process/submitting-patches.rst, which explains how a patch
should look like.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists