Re: [PATCH v3] PCI/TPH: treat reserved 0b10 completer encoding as unsupported
fengchengwen <[email protected]> Fri, 31 Jul 2026 14:09:39 +0800
| Newsgroups | org.kernel.vger.linux-rdma,org.kernel.vger.linux-pci |
|---|---|
| Message-ID | <[email protected]> |
On 7/31/2026 7:11 AM, Zhiping Zhang wrote: > Thanks Fengcheng and all! > > Alex pointed out in the vfio/dma-buf TPH thread that keeping this as a > separate dependency makes the main series harder for review tooling to > apply, while this patch is a self-contained hardening change with no > known affected hardware. That makes sense to me. > > Unless you prefer this to remain a standalone PCI patch, I plan to > include it as the first patch in the next respin of the vfio/dma-buf > TPH series. That works perfectly for me, folding this hardening patch as the first commit in your next respin is fine. Thanks > > Thanks, > Zhiping > > On Mon, Jul 20, 2026 at 4:42 PM fengchengwen <[email protected]> wrote: >> >>> >> Acked-by: Chengwen Feng <[email protected]> >> >> On 7/21/2026 1:22 AM, Zhiping Zhang wrote: >>> get_rp_completer_type() returns the Root Port's "TPH Completer >>> Supported" field (bits 13:12 of Device Capabilities 2) verbatim. The >>> 0b10 encoding is reserved, but pcie_enable_tph() feeds the raw value >>> into the requester type: >>> >>> pdev->tph_req_type = min(pdev->tph_req_type, rp_req_type); >>> >>> and later writes tph_req_type to the TPH Requester Enable field, which >>> only defines 0b00 (disable), 0b01 (TPH only) and 0b11 (extended TPH). >>> >>> No known hardware presents the reserved 0b10 in this field, so this is >>> defensive hardening rather than a fix for observed silicon: fold the >>> reserved encoding into "not supported" so only the three architected >>> values can ever reach the Requester Enable field. >>> >>> Fixes: f69767a1ada3 ("PCI: Add TLP Processing Hints (TPH) support") >>> Signed-off-by: Zhiping Zhang <[email protected]> >> >