Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 28 May 2019 01:28:50 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Cc:     "Luck, Tony" <tony.luck@intel.com>,
        "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v3 5/6] x86/MCE: Save MCA control bits that get set in
 hardware
Message-ID: <20190527232849.GC8209@cz.tnic>
References: <20190517101006.GA32065@zn.tnic>
 <SN6PR12MB26391A0C3979030082EE38F8F80B0@SN6PR12MB2639.namprd12.prod.outlook.com>
 <20190517163729.GE13482@zn.tnic>
 <20190517172648.GA18164@agluck-desk>
 <20190517174817.GG13482@zn.tnic>
 <20190517180607.GA21710@agluck-desk>
 <20190517193431.GI13482@zn.tnic>
 <SN6PR12MB2639C5427366AC3004C35CC0F80B0@SN6PR12MB2639.namprd12.prod.outlook.com>
 <20190517200225.GK13482@zn.tnic>
 <SN6PR12MB26390759DB43763D3A482918F8010@SN6PR12MB2639.namprd12.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <SN6PR12MB26390759DB43763D3A482918F8010@SN6PR12MB2639.namprd12.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, May 23, 2019 at 08:00:33PM +0000, Ghannam, Yazen wrote:
> I did a bit more testing and I noticed that writing "0" disables a bank with no way to reenable it.
> 
> For example:
> 1) Read bank10.
> 	a) Succeeds; returns "fffffffffffffff".
> 2) Write "0" to bank10.
> 	a) Succeeds; hardware register is set to "0".
> 	b) Hardware register is checked, and b->init=0.
> 3) Read bank10.
> 	a) Fails, because b->init=0.
> 4) Write non-zero value to bank10 to reenable it.
> 	a) Fails, because b->init=0.
> 5) Reboot needed to reset bank.
> 
> Is that okay?

Nope, that doesn't sound correct to me.

I guess the cleanest way to handle his properly would be to have a
function called something like __mcheck_cpu_init_banks() which gets
called in mcheck_cpu_init() after the quirks have run and then does the
final poking of the banks and sets b->init properly.

__mcheck_cpu_init_clear_banks() should then be renamed to
__mcheck_cpu_clear_banks() to denote that it only clears the banks and
would only do:

                if (!b->init)
                        continue;

                wrmsrl(msr_ops.ctl(i), b->ctl);
                wrmsrl(msr_ops.status(i), 0);

And then sprinkle some commenting to not forget the scheme again.

Yeah, this sounds clean to me but you guys might have a better idea...

Thx.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply. Srsly.