[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250214153432.00005bbb@huawei.com>
Date: Fri, 14 Feb 2025 15:34:32 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Dan Williams <dan.j.williams@...el.com>
CC: Terry Bowman <terry.bowman@....com>, <linux-cxl@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>,
<nifan.cxl@...il.com>, <dave@...olabs.net>, <dave.jiang@...el.com>,
<alison.schofield@...el.com>, <vishal.l.verma@...el.com>,
<bhelgaas@...gle.com>, <mahesh@...ux.ibm.com>, <ira.weiny@...el.com>,
<oohall@...il.com>, <Benjamin.Cheatham@....com>, <rrichter@....com>,
<nathan.fontenot@....com>, <Smita.KoralahalliChannabasappa@....com>,
<lukas@...ner.de>, <ming.li@...omail.com>,
<PradeepVineshReddy.Kodamati@....com>
Subject: Re: [PATCH v7 13/17] cxl/pci: Add trace logging for CXL PCIe Port
RAS errors
On Thu, 13 Feb 2025 18:21:11 -0800
Dan Williams <dan.j.williams@...el.com> wrote:
> Terry Bowman wrote:
> > The CXL drivers use kernel trace functions for logging Endpoint and
> > Restricted CXL host (RCH) Downstream Port RAS errors. Similar functionality
> > is required for CXL Root Ports, CXL Downstream Switch Ports, and CXL
> > Upstream Switch Ports.
> >
> > Introduce trace logging functions for both RAS correctable and
> > uncorrectable errors specific to CXL PCIe Ports. Additionally, update
> > the CXL Port Protocol Error handlers to invoke these new trace functions.
> >
> > Examples of the output from these changes is below.
> >
> > Correctable error:
> > cxl_port_aer_correctable_error: device=port1 parent=root0 status='Received Error From Physical Layer'
> >
> > Uncorrectable error:
> > cxl_port_aer_uncorrectable_error: device=port1 parent=root0 status: 'Memory Byte Enable Parity Error' first_error: 'Memory Byte Enable Parity Erro'
>
> Oh, so this solves the problem I was worried about earlier where it
> looked like protocol errors only got notified if the event was a memdev.
> I still think it would be worthwhile to make this one unified
> trace-event rather than multiple.
I'd go with a 'maybe'. Absolutely would have made sense if this
had been the intent from the start. Now we are going to end
up with at least some tracepoint fields that are mutually exclusive.
E.g. Switch ports aren't going to want to set memdev.
Might be easier to just keep them separate. However this will get
messier anyway when type 2 devices come along.
Jonathan
>
Powered by blists - more mailing lists