linux-kernel - Re: [PATCH V1] schemas: pci: bridge: Document PCI L0s & L1 entry delay and nfts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f71ad2e5-684a-3444-14ba-794238ef48d1@quicinc.com>
Date: Wed, 8 Jan 2025 08:12:46 +0530
From: Krishna Chaitanya Chundru <quic_krichai@...cinc.com>
To: Bjorn Helgaas <helgaas@...nel.org>
CC: Rob Herring <robh@...nel.org>,
        Krishna Chaitanya Chundru
	<krishna.chundru@....qualcomm.com>,
        <andersson@...nel.org>, <dmitry.baryshkov@...aro.org>,
        <manivannan.sadhasivam@...aro.org>, <krzk@...nel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <lpieralisi@...nel.org>, <kw@...ux.com>, <conor+dt@...nel.org>,
        <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree-spec@...r.kernel.org>, <quic_vbadigan@...cinc.com>
Subject: Re: [PATCH V1] schemas: pci: bridge: Document PCI L0s & L1 entry
 delay and nfts



On 1/8/2025 2:12 AM, Bjorn Helgaas wrote:
> On Tue, Jan 07, 2025 at 07:49:00PM +0530, Krishna Chaitanya Chundru wrote:
>> On 1/6/2025 8:37 PM, Rob Herring wrote:
>>> On Mon, Jan 6, 2025 at 3:33 AM Krishna Chaitanya Chundru
>>> <krishna.chundru@....qualcomm.com> wrote:
>>>>
>>>> Some controllers and endpoints provide provision to program the entry
>>>> delays of L0s & L1 which will allow the link to enter L0s & L1 more
>>>> aggressively to save power.
>>>>
>>>> As per PCIe spec 6 sec 4.2.5.6, the number of Fast Training Sequence (FTS)
>>>> can be programmed by the controllers or endpoints that is used for bit and
>>>> Symbol lock when transitioning from L0s to L0 based upon the PCIe data rate
>>>> FTS value can vary. So define a array for each data rate for nfts.
>>>>
>>>> These values needs to be programmed before link training.
> 
>>> Do these properties apply to any link like downstream ports on a
>>> PCIe switch?
>>>
>> These applies to downstream ports also on a switch.
> 
> IIUC every PCIe component with a Link, i.e., Upstream Ports (on a
> Switch or Endpoint) and Downstream Ports (a Root Port or Switch), has
> an N_FTS value that it advertises during Link training.
> 
> I suppose N_FTS depends on the component electrical design and maybe
> the Link, and it only makes sense to have this n-fts property for
> specific devices that support this kind of configuration, right?  I
> don't think we would know what to do with n-fts for random plug-in
> Switches or Endpoints because there's no generic way to configure
> N_FTS, and we *couldn't* do it before the Link is trained anyway
> unless there's some sideband mechanism.
yes I agree with it, we have one such type of PCIe switch which has i2c
sideband mechanism = to program it before enabling link training. This
properties can be used for the switches which has side band mechanism.
> 
>>>> +    description:
>>>> +      Number of Fast Training Sequence (FTS) used during L0s to L0 exit for bit
>>>> +      and Symbol lock.
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>> +    minItems: 1
>>>> +    maxItems: 5
>>>
>>> Need to define what is each entry? Gen 1 to 5?
>>>
>> yes there are from Gen1 to Gen 5, I will update this in next patch these
>> details.
> 
> Components are permitted to advertise different N_FTS values at
> different *speeds*, not "GenX" (PCIe r6.0, sec 4.2.5.6)
> 
> The spec discourages use of Gen1, etc because they are ambiguous (sec
> 1.2):
> 
>    Terms like "PCIe Gen3" are ambiguous and should be avoided. For
>    example, "gen3" could mean (1) compliant with Base 3.0, (2)
>    compliant with Base 3.1 (last revision of 3.x), (3) compliant with
>    Base 3.0 and supporting 8.0 GT/s, (4) compliant with Base 3.0 or
>    later and supporting 8.0 GT/s, ....
> 
> We're stuck with the use of genX for max-link-speed, but we should use
> speeds when we can for clarity, e.g., in the description here.
Ack, that's why I tried to mention data rates instead of gen in the
commit text.

- Krishna Chaitanya.