From: Dave Jiang <dave.jiang@intel.com>
To: "Cheatham, Benjamin" <benjamin.cheatham@amd.com>,
Richard Cheng <icheng@nvidia.com>,
dave@stgolabs.net, jic23@kernel.org, alison.schofield@intel.com,
vishal.l.verma@intel.com
Cc: iweiny@kernel.org, ming.li@zohomail.com,
linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,
kaihengf@nvidia.com, kobak@nvidia.com, newtonl@nvidia.com,
kristinc@nvidia.com
Subject: Re: [PATCH v2] cxl/port: Fix endpoint RAS error unmasking
Date: Tue, 3 Nov 2026 16:15:05 -0700 [thread overview]
Message-ID: <f1e51d7f-645b-490e-b67c-36732b6db644@intel.com> (raw)
In-Reply-To: <aaa772ba-554a-4bef-8910-e271580c2a5b@amd.com>
On 11/3/26 11:35 AM, Cheatham, Benjamin wrote:
> On 11/3/2026 12:34 AM, Richard Cheng wrote:
>> Moving endpoint RAS handling from cxl_pci to cxl_port left
>> cxl_ras_unmask() checking whether port->uport_dev is a PCI device.
>> Endpoint ports always use a cxl_memdev as uport_dev, so this check
>> returns early and leaves the CXL RAS error masks unchanged.
>>
>> Resolve the PCI device directly through the memdev's parent. Rename
>> helper to cxl_endpoint_ras_unmask() and its param to endpoint to make
>> its endpoint-only scope explicit.
>>
>> Fixes: dab7162d0ae7 ("cxl/port: Move endpoint component register management to cxl_port")
>> Signed-off-by: Richard Cheng <icheng@nvidia.com>
>> ---
>
> ...
>
>> -static int cxl_ras_unmask(struct cxl_port *port)
>> +static int cxl_endpoint_ras_unmask(struct cxl_port *endpoint)
>> {
>> + struct cxl_memdev *cxlmd = to_cxl_memdev(endpoint->uport_dev);
>> + struct device *parent = cxlmd->dev.parent;
>
> Two small nits:
>
> 1. Maybe just use endpoint->uport_dev.parent directly and drop the cxlmd part? It's less
> readable, but it's future proofing for when/if CXL.cache devices come along.
>
> 2. I don't think you need to rename the port parameter if you change the name to endpoint. It's
> self-explanatory at that point and cuts down on the diff.
I asked for that change. Since we are making changes on that line already, may as well make it explicit for readability. Or at least satisfies my OCD :)
DJ
>
> Both are really up to you on whether you think they're worthwhile, and the change makes sense as-is,
> so regardless of whether you implement the above:
>
> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
>
> Thanks,
> Ben
prev parent reply other threads:[~2026-11-03 23:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 6:34 Richard Cheng
2026-11-03 18:35 ` Cheatham, Benjamin
2026-11-03 23:15 ` Dave Jiang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f1e51d7f-645b-490e-b67c-36732b6db644@intel.com \
--to=dave.jiang@intel.com \
--cc=alison.schofield@intel.com \
--cc=benjamin.cheatham@amd.com \
--cc=dave@stgolabs.net \
--cc=icheng@nvidia.com \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=kaihengf@nvidia.com \
--cc=kobak@nvidia.com \
--cc=kristinc@nvidia.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.li@zohomail.com \
--cc=newtonl@nvidia.com \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®