linux-kernel - Re: [PATCH v2] schemas: pci: Document PCIe T_POWER

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 for Android: free password hash cracker in your pocket

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

Message-ID: <epqkkezjnkwznh4minlvhh7vbnwh3isqeofqamgupj7rjnhjv2@wtrx4ecjgvob>
Date: Thu, 13 Nov 2025 22:11:47 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Lukas Wunner <lukas@...ner.de>
Cc: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>, 
	andersson@...nel.org, robh@...nel.org, manivannan.sadhasivam@...aro.org, 
	krzk@...nel.org, helgaas@...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 v2] schemas: pci: Document PCIe T_POWER_ON

On Thu, Nov 13, 2025 at 09:36:48AM +0100, Lukas Wunner wrote:
> On Thu, Nov 13, 2025 at 09:33:54AM +0530, Krishna Chaitanya Chundru wrote:
> > On 11/10/2025 6:11 PM, Lukas Wunner wrote:
> > > On Mon, Nov 10, 2025 at 04:59:47PM +0530, Krishna Chaitanya Chundru wrote:
> > > >  From PCIe r6, sec 5.5.4 & Table 5-11 in sec 5.5.5 T_POWER_ON is the
> > > Please use the latest spec version as reference, i.e. PCIe r7.0.
> > ack.
> > > > minimum amount of time(in us) that each component must wait in L1.2.Exit
> > > > after sampling CLKREQ# asserted before actively driving the interface to
> > > > ensure no device is ever actively driving into an unpowered component and
> > > > these values are based on the components and AC coupling capacitors used
> > > > in the connection linking the two components.
> > > > 
> > > > This property should be used to indicate the T_POWER_ON for each Root Port.
> > > What's the difference between this property and the Port T_POWER_ON_Scale
> > > and T_POWER_ON_Value in the L1 PM Substates Capabilities Register?
> > > 
> > > Why do you need this in the device tree even though it's available
> > > in the register?
> > 
> > This value is same as L1 PM substates value, some controllers needs to
> > update this
> > value before enumeration as hardware might now program this value
> > correctly[1].
> > 
> > [1]: [PATCH] PCI: qcom: Program correct T_POWER_ON value for L1.2 exit
> > timing
> > 
> > <https://lore.kernel.org/all/20251104-t_power_on_fux-v1-1-eb5916e47fd7@oss.qualcomm.com/>
> 
> Per PCIe r7.0 sec 7.8.3.2, all fields in the L1 PM Substates Capabilities
> Register are of type "HwInit", which sec 7.4 defines as:
> 
>    "Register bits are permitted, as an implementation option, to be
>     hard-coded, initialized by system/device firmware, or initialized
>     by hardware mechanisms such as pin strapping or nonvolatile storage.
>     Initialization by system firmware is permitted only for
>     system-integrated devices.
>     Bits must be fixed in value and read-only after initialization."
>                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> These bits are not supposed to be writable by the operating system,
> so what you're doing in that patch is not spec-compliant.
> 

I interpret 'initialized by system/device firmware', same as 'initialized by
OS', as both are mostly same for the devicetree platforms. So it is fine IMO.
Ofc, if the initialization was carried out by the firmware, then OS has no
business in changing it, but it is not the case.

> I think it needs to be made explicit in the devicetree schema that
> the property is only intended for non-compliant hardware which allows
> (and requires) the operating system to initialize the register.
> 

Sorry, I disagree. The hardware is spec compliant, just that the firmware missed
initializing the fields.

> Maybe it makes more sense to have a property which specifies the raw
> 32-bit register contents, instead of having a property for each
> individual field.  Otherwise you'll have to amend the schema
> whenever the PCIe spec extends the register with additional fields.
> 

DT properties do not specify a register value, but instead they specify hardware
configuration value and that's what this property is doing. The OS/other DT
consumers should interpret this value as per the spec and program the relevant
registers.

- Mani

-- 
மணிவண்ணன் சதாசிவம்