Received-SPF: pass (google.com: domain of linux-kernel+bounces-58336-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 9 Feb 2024 00:16:23 +0800
From: "Wang, Qingshun" <qingshun.wang@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, 
	linux-acpi@vger.kernel.org, chao.p.peng@linux.intel.com, erwin.tsaur@intel.com, 
	feiting.wanyan@intel.com, qingshun.wang@intel.com, "Rafael J. Wysocki" <rafael@kernel.org>, 
	Len Brown <lenb@kernel.org>, James Morse <james.morse@arm.com>, 
	Tony Luck <tony.luck@intel.com>, Borislav Petkov <bp@alien8.de>, 
	Davidlohr Bueso <dave@stgolabs.net>, Jonathan Cameron <jonathan.cameron@huawei.com>, 
	Dave Jiang <dave.jiang@intel.com>, Alison Schofield <alison.schofield@intel.com>, 
	Vishal Verma <vishal.l.verma@intel.com>, Ira Weiny <ira.weiny@intel.com>, 
	Dan Williams <dan.j.williams@intel.com>, Bjorn Helgaas <bhelgaas@google.com>, 
	Mahesh J Salgaonkar <mahesh@linux.ibm.com>, Oliver O'Halloran <oohall@gmail.com>, 
	Miaohe Lin <linmiaohe@huawei.com>, Shiju Jose <shiju.jose@huawei.com>, 
	Adam Preble <adam.c.preble@intel.com>, Li Yang <leoyang.li@nxp.com>, Lukas Wunner <lukas@wunner.de>, 
	Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>, 
	Robert Richter <rrichter@amd.com>, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, 
	linux-edac@vger.kernel.org
Subject: Re: [PATCH v2 1/4] PCI/AER: Store more information in aer_err_info
Message-ID: <vc67zlmqs46fx2iqjqlpvju5dzpdvqkmydpebecgcaxjivlmu5@ksu4c2g7qqig>
References: <2rfnevhnhylik4r6smr56uunsxweo7s5elo65sjhiztvxnr6bq@5fcyv22zxyyp>
 <20240206172335.GA872811@bhelgaas>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240206172335.GA872811@bhelgaas>

On Tue, Feb 06, 2024 at 11:23:35AM -0600, Bjorn Helgaas wrote:
> On Wed, Feb 07, 2024 at 12:41:41AM +0800, Wang, Qingshun wrote:
> > On Mon, Feb 05, 2024 at 05:12:31PM -0600, Bjorn Helgaas wrote:
> > > On Thu, Jan 25, 2024 at 02:27:59PM +0800, Wang, Qingshun wrote:
> > > > When Advisory Non-Fatal errors are raised, both correctable and
> > > > uncorrectable error statuses will be set. The current kernel code cannot
> > > > store both statuses at the same time, thus failing to handle ANFE properly.
> > > > In addition, to avoid clearing UEs that are not ANFE by accident, UE
> > > > severity and Device Status also need to be recorded: any fatal UE cannot
> > > > be ANFE, and if Fatal/Non-Fatal Error Detected is set in Device Status, do
> > > > not take any assumption and let UE handler to clear UE status.
> > > > 
> > > > Store status and mask of both correctable and uncorrectable errors in
> > > > aer_err_info. The severity of UEs and the values of the Device Status
> > > > register are also recorded, which will be used to determine UEs that should
> > > > be handled by the ANFE handler. Refactor the rest of the code to use
> > > > cor/uncor_status and cor/uncor_mask fields instead of status and mask
> > > > fields.
> > > 
> > > There's a lot going on in this patch.  Could it possibly be split up a
> > > bit, e.g., first tease apart aer_err_info.status/.mask into
> > > .cor_status/mask and .uncor_status/mask, then add .uncor_severity,
> > > then add the device_status bit separately?  If it could be split up, I
> > > think the ANFE case would be easier to see.
> > 
> > Thanks for the feedback! Will split it up into two pacthes in the next
> > version.
> 
> Or even three:
> 
>   1) tease apart aer_err_info.status/.mask into .cor_status/mask and
>      .uncor_status/mask
> 
>   2) add .uncor_severity
> 
>   3) add device_status
> 
> Looking at this again, I'm a little confused about 2) and 3).  I see
> the new read of PCI_ERR_UNCOR_SEVER into .uncor_severity, but there's
> no actual *use* of it.
> 
> Same for 3), I see the new read of PCI_EXP_DEVSTA, but AFAICS there's
> no use of that value.
> 

Both 2) and 3) are used in PATCH 2 and traced in PATCH 4. I can separate
the logic for reading these values from PATCH 1 and merge it with PATCH
2.

--
Best regards,
Wang, Qingshun