linux-kernel - Re: [RESEND v13 00/25] Enable CXL PCIe Port Protocol Error handling and logging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <00537640-96a1-4476-afd4-c8c4894d7931@amd.com>
Date: Thu, 4 Dec 2025 11:30:45 -0600
From: "Bowman, Terry" <terry.bowman@....com>
To: Bjorn Helgaas <helgaas@...nel.org>
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 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

-Terry