All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: Guixin Liu <kanie@linux.alibaba.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Jonathan Cameron <jic23@kernel.org>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dan Williams <djbw@kernel.org>, Ira Weiny <iweiny@kernel.org>,
	Li Ming <ming.li@zohomail.com>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v2 0/3] cxl/pci: Fix the GPF DVSEC setup path
Date: Fri, 9 Oct 2026 14:48:07 -0700	[thread overview]
Message-ID: <9ee576b5-c719-4e10-b4ea-b90f9f99529e@intel.com> (raw)
In-Reply-To: <20261008034619.28059-1-kanie@linux.alibaba.com>



On 10/7/26 8:46 PM, Guixin Liu wrote:
> Three small fixes for the GPF setup path in cxl/core/pci.c, found
> while reworking the same area for a downstream backport.
> 
> Patch 1 is the one with user-visible impact: on an RCD the GPF DVSEC
> lookup takes the port path, so dirty shutdown tracking never arms and
> the count stays invalid. The other two deal with error handling and
> a full-register rewrite of the phase control register.
> 
> Testing on a QEMU CXL topology, with the patched cxl_core hot-swapped
> in and the topology re-enumerated. With the phase 1/2 timeout
> registers of all four dports (two root ports, two switch downstream
> ports) zeroed beforehand, every dport came back at 0x0702 — base 2,
> scale 7, the same value the unpatched code writes. So the timeout
> write ran on each of them: the read-modify-write of patch 3, through
> the error-checked setup of patch 2. With the registers left at their
> programmed value instead, the setup takes the "already at max" early
> return and writes nothing. Re-enumeration comes up clean, all three
> memdevs back.
> 
> What QEMU cannot exercise: the topology has no RCD, so the RC_END
> branch of patch 1 never ran — though the emulated type-3 devices do
> expose the Device GPF DVSEC that the fix selects for a restricted
> endpoint. A config write to a live DVSEC does not fail, so the error
> paths of patch 2 stayed cold. And the phase control register defines
> no non-timeout bits today, so patch 3 lands on the same value the old
> full rewrite did.
> 
> Changes since v1 [1]:
> 
> - Collect the Reviewed-by tags from Jonathan Cameron and Dave Jiang
>   for patches 1 and 2 (code unchanged).
> 
> - Rework patch 3 to use a pair of FIELD_MODIFY() calls instead of
>   clearing and setting the timeout masks by hand, as suggested by
>   Jonathan Cameron. The generated code for update_gpf_port_dvsec()
>   is identical to the manual version.
> 
> [1] https://lore.kernel.org/all/20260922100026.3742401-1-kanie@linux.alibaba.com/
> 
> Guixin Liu (3):
>   cxl/pci: Use the Device GPF DVSEC for restricted endpoints
>   cxl/pci: Program the Port GPF timeouts before caching the DVSEC
>   cxl/pci: Update only the Port GPF timeout fields
> 
>  drivers/cxl/core/pci.c | 37 +++++++++++++++++++++++++------------
>  1 file changed, 25 insertions(+), 12 deletions(-)
> 

Applied to cxl/next:
b5d14009bdb1
ec2e30a68294
d2654fa0d841

      parent reply	other threads:[~2026-10-09 21:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08  3:46 [PATCH v2 0/3] cxl/pci: Fix the GPF DVSEC setup path Guixin Liu
2026-10-08  3:46 ` [PATCH v2 1/3] cxl/pci: Use the Device GPF DVSEC for restricted endpoints Guixin Liu
2026-10-09 19:02   ` Alison Schofield
2026-10-08  3:46 ` [PATCH v2 2/3] cxl/pci: Program the Port GPF timeouts before caching the DVSEC Guixin Liu
2026-10-08  3:58   ` sashiko-bot
2026-10-09 19:03   ` Alison Schofield
2026-10-08  3:46 ` [PATCH v2 3/3] cxl/pci: Update only the Port GPF timeout fields Guixin Liu
2026-10-09 17:27   ` Dave Jiang
2026-10-09 19:03   ` Alison Schofield
2026-10-09 21:48 ` 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=9ee576b5-c719-4e10-b4ea-b90f9f99529e@intel.com \
    --to=dave.jiang@intel.com \
    --cc=alison.schofield@intel.com \
    --cc=dave@stgolabs.net \
    --cc=djbw@kernel.org \
    --cc=iweiny@kernel.org \
    --cc=jic23@kernel.org \
    --cc=kanie@linux.alibaba.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=ming.li@zohomail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.