Re: [PATCH v3] PCI/TPH: treat reserved 0b10 completer encoding as unsupported

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.

Thanks,
Zhiping

On Mon, Jul 20, 2026 at 4:42=E2=80=AFPM fengchengwen <[email protected]=
om> 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 =3D 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]>
>