Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Zhiping Zhang" <zhipingz@meta.com>
Cc: dri-devel@lists.freedesktop.org, kvm@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v7 2/5] PCI/TPH: Add requester/completer type helpers
Date: Fri, 12 Jun 2026 16:46:30 +0000	[thread overview]
Message-ID: <20260612164631.C71451F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260611161546.4075580-3-zhipingz@meta.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pcie_tph_completer_type() does not check for PCI_ERROR_RESPONSE (~0U), leading to a false positive Extended TPH capability if the device is disconnected or in a low power state.
--

commit f9aeb32b2542c39fb3d9466efa934427ab4660a5
Author: Zhiping Zhang <zhipingz@meta.com>
PCI/TPH: Add requester/completer type helpers

This commit adds pcie_tph_enabled_req_type() and pcie_tph_completer_type()
helpers to allow drivers to query TPH enabled requester modes and completer
support without accessing pci_dev internals directly.

> diff --git a/drivers/pci/tph.c b/drivers/pci/tph.c
> index 91145e8d9d951..4fe076bba953a 100644
> --- a/drivers/pci/tph.c
> +++ b/drivers/pci/tph.c
[ ... ]
> @@ -174,6 +174,49 @@ u32 pcie_tph_get_st_table_loc(struct pci_dev *pdev)
[ ... ]
> +u8 pcie_tph_completer_type(struct pci_dev *pdev)
> +{
> +	u32 reg;
> +
> +	if (pcie_capability_read_dword(pdev, PCI_EXP_DEVCAP2, &reg))
> +		return PCI_EXP_DEVCAP2_TPH_COMP_NONE;
> +
> +	switch (FIELD_GET(PCI_EXP_DEVCAP2_TPH_COMP_MASK, reg)) {
> +	case PCI_EXP_DEVCAP2_TPH_COMP_TPH_ONLY:
> +		return PCI_EXP_DEVCAP2_TPH_COMP_TPH_ONLY;
> +	case PCI_EXP_DEVCAP2_TPH_COMP_EXT_TPH:
> +		return PCI_EXP_DEVCAP2_TPH_COMP_EXT_TPH;

[Severity: Medium]
Will this return a false positive if the device is disconnected or in a low
power state?

When reading the PCI config space of an unplugged or unresponsive device,
the host bridge typically returns all 1s (0xFFFFFFFF) and the config read
returns 0 (success).

If pcie_capability_read_dword() succeeds but sets reg to 0xFFFFFFFF,
FIELD_GET() will extract 0b11 (3) from bits 13:12. This matches
PCI_EXP_DEVCAP2_TPH_COMP_EXT_TPH, causing the switch statement to
incorrectly return that the device supports Extended TPH.

Could this trick drivers querying capabilities during teardown or error
recovery into believing a removed device supports Extended TPH? Using
PCI_POSSIBLE_ERROR() to check the register value before evaluating the bits
might prevent this.

> +	default:
> +		return PCI_EXP_DEVCAP2_TPH_COMP_NONE;
> +	}
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611161546.4075580-1-zhipingz@meta.com?part=2

  reply	other threads:[~2026-06-12 16:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-11 16:11 [PATCH v7 0/5] vfio/dma-buf: add TPH support for peer-to-peer access Zhiping Zhang
2026-06-11 16:11 ` [PATCH v7 1/5] net/mlx5: free mlx5_st_idx_data on final dealloc Zhiping Zhang
2026-06-12 16:46   ` sashiko-bot
2026-06-11 16:11 ` [PATCH v7 2/5] PCI/TPH: Add requester/completer type helpers Zhiping Zhang
2026-06-12 16:46   ` sashiko-bot [this message]
2026-06-12 16:52   ` Alex Williamson
2026-06-11 16:11 ` [PATCH v7 3/5] dma-buf: add optional get_tph() callback Zhiping Zhang
2026-06-12 16:46   ` sashiko-bot
2026-06-11 16:11 ` [PATCH v7 4/5] vfio/pci: implement get_tph and DMA_BUF_TPH feature Zhiping Zhang
2026-06-12 16:46   ` sashiko-bot
2026-06-12 17:10   ` Alex Williamson
2026-06-11 16:11 ` [PATCH v7 5/5] RDMA/mlx5: get tph for p2p access when registering dma-buf mr Zhiping Zhang
2026-06-12 16:46   ` sashiko-bot
     [not found] <20260610193158.2614209-3-zhipingz@meta.com>
2026-06-11 20:25 ` [PATCH v7 2/5] PCI/TPH: Add requester/completer type helpers sashiko-bot
2026-06-11 23:06   ` Zhiping Zhang

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=20260612164631.C71451F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=zhipingz@meta.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