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]>
>>
>