Re: [PATCH v6 1/6] PCI/TPH: Fix pcie_tph_get_st_table_loc() field extraction

[Leon Romanovsky <leon@kernel.org>]

On Wed, May 06, 2026 at 10:54:18AM -0500, Bjorn Helgaas wrote:
> On Wed, May 06, 2026 at 05:46:18PM +0800, Chengwen Feng wrote:
> > pcie_tph_get_st_table_loc() incorrectly uses FIELD_GET(), which shifts the
> > field value to bit 0. But the function is designed to return raw
> > PCI_TPH_LOC_* values as defined in the function comment.
> > 
> > This causes incorrect ST table location detection. Fix it by using bitwise
> > AND with PCI_TPH_CAP_LOC_MASK to return the unshifted field value matching
> > the function specification.
> > 
> > While this change appears to be a no-op within tph.c, the external caller
> > mlx5_st_create() relies on the documented function behavior, making this
> > fix necessary.
> 
> Previously, pcie_tph_get_st_table_loc() returned 0x0 (for
> PCI_TPH_LOC_NONE), 0x2 (for PCI_TPH_LOC_CAP), or 0x4 (for
> PCI_TPH_LOC_MSIX).
> 
> mlx5_st_create() is currently the only external caller.  It only
> checks for PCI_TPH_LOC_NONE, which is 0 regardless of the FIELD_GET(),
> so I don't think this actually fixes mlx5_st_create().
> 
> Probably still worth a stable backport because other drivers may call
> pcie_tph_get_st_table_loc() in the future, and if they depend on
> PCI_TPH_LOC_CAP or PCI_TPH_LOC_MSIX, and are backported to stable
> kernels, they will need this.
> 
> I might reword that last paragraph to avoid the implication that this
> actually fixes something in mlx5:
> 
>   This doesn't make a difference to mlx5_st_create(), the lone
>   external caller, because it only checks for PCI_TPH_LOC_NONE (0),
>   but will be needed for callers that check for PCI_TPH_LOC_CAP or
>   PCI_TPH_LOC_MSIX.

Right, we are running TPH in mlx5 regression and it works perfectly
without "the fix".

Thanks