Re: [PATCH AUTOSEL 6.13 13/15] PCI: Store number of supported End-End TLP Prefixes

[Sasha Levin <sashal@kernel.org>]

On Tue, Jan 28, 2025 at 08:00:39PM +0200, Ilpo Järvinen wrote:
>On Tue, 28 Jan 2025, Sasha Levin wrote:
>
>> From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>>
>> [ Upstream commit e5321ae10e1323359a5067a26dfe98b5f44cc5e6 ]
>>
>> eetlp_prefix_path in the struct pci_dev tells if End-End TLP Prefixes
>> are supported by the path or not, and the value is only calculated if
>> CONFIG_PCI_PASID is set.
>>
>> The Max End-End TLP Prefixes field in the Device Capabilities Register 2
>> also tells how many (1-4) End-End TLP Prefixes are supported (PCIe r6.2 sec
>> 7.5.3.15). The number of supported End-End Prefixes is useful for reading
>> correct number of DWORDs from TLP Prefix Log register in AER capability
>> (PCIe r6.2 sec 7.8.4.12).
>>
>> Replace eetlp_prefix_path with eetlp_prefix_max and determine the number of
>> supported End-End Prefixes regardless of CONFIG_PCI_PASID so that an
>> upcoming commit generalizing TLP Prefix Log register reading does not have
>> to read extra DWORDs for End-End Prefixes that never will be there.
>>
>> The value stored into eetlp_prefix_max is directly derived from device's
>> Max End-End TLP Prefixes and does not consider limitations imposed by
>> bridges or the Root Port beyond supported/not supported flags. This is
>> intentional for two reasons:
>>
>>   1) PCIe r6.2 spec sections 2.2.10.4 & 6.2.4.4 indicate that a TLP is
>>      malformed only if the number of prefixes exceed the number of Max
>>      End-End TLP Prefixes, which seems to be the case even if the device
>>      could never receive that many prefixes due to smaller maximum imposed
>>      by a bridge or the Root Port. If TLP parsing is later added, this
>>      distinction is significant in interpreting what is logged by the TLP
>>      Prefix Log registers and the value matching to the Malformed TLP
>>      threshold is going to be more useful.
>>
>>   2) TLP Prefix handling happens autonomously on a low layer and the value
>>      in eetlp_prefix_max is not programmed anywhere by the kernel (i.e.,
>>      there is no limiter OS can control to prevent sending more than N TLP
>>      Prefixes).
>>
>> Link: https://lore.kernel.org/r/20250114170840.1633-7-ilpo.jarvinen@linux.intel.com
>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>Hi,
>
>Why is this being auto selected? It's not a fix nor do I see any
>dependency related tags. Unless the entire TLP consolidation would be
>going into stable, I don't see much value for this change in stable
>kernels.

I wasn't too sure about it either. My thinking was that there is a spec
compatibility issue here, but looks like I was wrong.

I'll drop it, thanks!

-- 
Thanks,
Sasha