From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751455AbeEVOjU (ORCPT ); Tue, 22 May 2018 10:39:20 -0400 Received: from mail-ot0-f195.google.com ([74.125.82.195]:39329 "EHLO mail-ot0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751196AbeEVOjS (ORCPT ); Tue, 22 May 2018 10:39:18 -0400 X-Google-Smtp-Source: AB8JxZr/JmB/fnnQeFApBA8AdADMup7y8AuG3/N2mwrTWfW3rnXhJJ5uQUaqK87L/3OBbMnRjwwceg== Subject: Re: [PATCH v6 1/2] acpi: apei: Rename ghes_severity() to ghes_cper_severity() To: Borislav Petkov Cc: "Rafael J. Wysocki" , alex_gagniuc@dellteam.com, austin_bolen@dell.com, shyam_iyer@dell.com, "Rafael J. Wysocki" , Len Brown , Tony Luck , Tyler Baicar , Will Deacon , James Morse , Shiju Jose , "Jonathan (Zhixiong) Zhang" , Dongjiu Geng , ACPI Devel Maling List , Linux Kernel Mailing List References: <20180521135003.32459-1-mr.nuke.me@gmail.com> <20180521135003.32459-2-mr.nuke.me@gmail.com> <53d0ba88-6929-a7cf-6c3e-4ca389f7249a@gmail.com> <20180522135015.GF5512@pd.tnic> From: "Alex G." Message-ID: <0b758a1c-90e3-6f76-4f83-1e22c8fc9cd6@gmail.com> Date: Tue, 22 May 2018 09:39:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180522135015.GF5512@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/22/2018 08:50 AM, Borislav Petkov wrote: > On Tue, May 22, 2018 at 08:38:39AM -0500, Alex G. wrote: >>> It looks like the *real* reason for this change is that you >>> re-introduce ghes_severity() as a different function in the second >>> patch. >> >> /me holds fist at Borislav > > That was a misunderstanding with Rafael and me - we fixed it on IRC. You mean to say this whole time I've been struggling to write emails, there was an IRC? > But this is not the real problem with your approach - it is the marking > of all PCIe errors as recoverable, regardless of the signature. That's a > no-no, IMO. No, the problem is with the current approach, not with mine. The problem is trying to handle the error outside of the existing handler. That's a no-no, IMO. Alex