[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z5kduHuaGWQwS9M_@lappy>
Date: Tue, 28 Jan 2025 13:11:04 -0500
From: Sasha Levin <sashal@...nel.org>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
Bjorn Helgaas <bhelgaas@...gle.com>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Yazen Ghannam <yazen.ghannam@....com>, linux-pci@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 6.13 13/15] PCI: Store number of supported
End-End TLP Prefixes
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@...ux.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@...ux.intel.com>
>> Signed-off-by: Bjorn Helgaas <bhelgaas@...gle.com>
>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
>> Reviewed-by: Yazen Ghannam <yazen.ghannam@....com>
>> Signed-off-by: Sasha Levin <sashal@...nel.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
Powered by blists - more mailing lists