[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251208184250.GA3299436@bhelgaas>
Date: Mon, 8 Dec 2025 12:42:50 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: "Bowman, Terry" <terry.bowman@....com>
Cc: dave@...olabs.net, jonathan.cameron@...wei.com, dave.jiang@...el.com,
alison.schofield@...el.com, dan.j.williams@...el.com,
bhelgaas@...gle.com, shiju.jose@...wei.com, ming.li@...omail.com,
Smita.KoralahalliChannabasappa@....com, rrichter@....com,
dan.carpenter@...aro.org, PradeepVineshReddy.Kodamati@....com,
lukas@...ner.de, Benjamin.Cheatham@....com,
sathyanarayanan.kuppuswamy@...ux.intel.com,
linux-cxl@...r.kernel.org, alucerop@....com, ira.weiny@...el.com,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [RESEND v13 00/25] Enable CXL PCIe Port Protocol Error handling
and logging
On Thu, Dec 04, 2025 at 11:30:45AM -0600, Bowman, Terry wrote:
> On 11/4/2025 4:12 PM, Bjorn Helgaas wrote:
> > On Tue, Nov 04, 2025 at 03:54:21PM -0600, Bowman, Terry wrote:
> >>
> >>
> >> On 11/4/2025 1:11 PM, Bjorn Helgaas wrote:
> >>> On Tue, Nov 04, 2025 at 11:02:40AM -0600, Terry Bowman wrote:
> >>>> This patchset updates CXL Protocol Error handling for CXL Ports and CXL
> >>>> Endpoints (EP). Previous versions of this series can be found here:
> >>>> https://lore.kernel.org/linux-cxl/20250925223440.3539069-1-terry.bowman@amd.com/
> >>>> ...
> >>>> Terry Bowman (24):
> >>>> CXL/PCI: Move CXL DVSEC definitions into uapi/linux/pci_regs.h
> >>>> PCI/CXL: Introduce pcie_is_cxl()
> >>>> cxl/pci: Remove unnecessary CXL Endpoint handling helper functions
> >>>> cxl/pci: Remove unnecessary CXL RCH handling helper functions
> >>>> cxl: Move CXL driver's RCH error handling into core/ras_rch.c
> >>>> CXL/AER: Replace device_lock() in cxl_rch_handle_error_iter() with
> >>>> guard() lock
> >>>> CXL/AER: Move AER drivers RCH error handling into pcie/aer_cxl_rch.c
> >>>> PCI/AER: Report CXL or PCIe bus error type in trace logging
> >>>> cxl/pci: Update RAS handler interfaces to also support CXL Ports
> >>>> cxl/pci: Log message if RAS registers are unmapped
> >>>> cxl/pci: Unify CXL trace logging for CXL Endpoints and CXL Ports
> >>>> cxl/pci: Update cxl_handle_cor_ras() to return early if no RAS errors
> >>>> cxl/pci: Map CXL Endpoint Port and CXL Switch Port RAS registers
> >>>> CXL/PCI: Introduce PCI_ERS_RESULT_PANIC
> >>>> CXL/AER: Introduce pcie/aer_cxl_vh.c in AER driver for forwarding CXL
> >>>> errors
> >>>> cxl: Introduce cxl_pci_drv_bound() to check for bound driver
> >>>> cxl: Change CXL handlers to use guard() instead of scoped_guard()
> >>>> cxl/pci: Introduce CXL protocol error handlers for Endpoints
> >>>> CXL/PCI: Introduce CXL Port protocol error handlers
> >>>> PCI/AER: Dequeue forwarded CXL error
> >>>> CXL/PCI: Export and rename merge_result() to pci_ers_merge_result()
> >>>> CXL/PCI: Introduce CXL uncorrectable protocol error recovery
> >>>> CXL/PCI: Enable CXL protocol errors during CXL Port probe
> >>>> CXL/PCI: Disable CXL protocol error interrupts during CXL Port cleanup
> >>> Is the mix of "CXL/PCI" vs "cxl/pci" in the above telling me
> >>> something, or should they all match?
> >>>
> >>> As a rule of thumb, I'm going to look at things that start with "PCI"
> >>> and skip most of the rest on the assumption that the rest only have
> >>> incidental effects on PCI.
> >>
> >> I think there was logic behind the (un)capitalized but I forget the
> >> reasoning. It's better to keep it simple. I'll change to use
> >> PCI/CXL and AER/CXL.
> >
> > I don't know what "AER/CXL" means. I think "PCI" and "CXL" are the
> > big chunks here and one of them should be first in the prefix.
> >
> > I do think there's value in using "PCI/AER" for things specific to AER
> > and "PCI/ERR" for more generic PCI error handling, and maybe "PCI/CXL"
> > for significant CXL-related things in drivers/pci/.
>
> I was informed any patch touching PCI files requires a PCI maintainer
> review or acknowledgment. I misunderstood how to communicate this.
>
> In my workflow, I used uppercase tags like PCI or AER to indicate that
> a patch needed PCI review or ack. For example, when I wrote CXL/PCI, I
> intended to signal that the patch was primarily CXL-related but in a
> PCI context, and therefore might need PCI review.
>
> To avoid confusion in the future, can you advise on the best way to
> indicate a patch needs your PCI review—even if the PCI changes are
> minor and don’t warrant leading with the PCI label?
>
> Also, can you review the following patches?
> [RESEND v13 01/25] CXL-PCI-Move-CXL-DVSEC-definitions-into-uapi-lin
> [RESEND v13 02/25] PCI-CXL-Introduce-pcie_is_cxl
> [RESEND v13 07/25] CXL-AER-Replace-device_lock-in-cxl_rch_handle_er
> [RESEND v13 08/25] CXL-AER-Move-AER-drivers-RCH-error-handling-into
> [RESEND v13 16/25] CXL-AER-Introduce-pcie-aer_cxl_vh.c-in-AER-drive
> [RESEND v13 20/25] CXL-PCI-Introduce-CXL-Port-protocol-error-handle
> [RESEND v13 22/25] CXL-PCI-Export-and-rename-merge_result-to-pci_er
> [RESEND v13 23/25] CXL-PCI-Introduce-CXL-uncorrectable-protocol-err
> [RESEND v13 25/25] CXL-PCI-Disable-CXL-protocol-error-interrupts-du
Sorry, I responded to most of the first v13 series because I didn't
notice the resend, so this got a little fragmented. Let me know if
there's more I should look at.
Bjorn
Powered by blists - more mailing lists