Re: [RFC PATCH] PCI: pciehp: Allow more time for link activation after slot power-on

[Lukas Wunner <lukas@wunner.de>]

On Thu, Sep 10, 2026 at 09:51:51AM +0800, Hongbo Yao wrote:
> The OCP NIC 3.0 Specification, version 1.6.0, Figure 132 [1], requires
> an interval greater than one second between Main Power Valid and PERST#
> deassertion.  The diagram labels this interval T_PVPERL.  PCIe link
> activation requires additional time after PERST# is deasserted.

The 1 sec delay implemented by:

  board_added()
    pciehp_power_on_slot()          # turn on the power
    pciehp_check_link_status()
      pcie_wait_for_link()
        pcie_wait_for_link_delay()  # wait 1 sec for DLLLA,
				    # then wait another 100 msec

... is specified by PCIe r7.0 sec 6.7.3.3, which is referenced by
sec 6.7.1.8 ("Power Controller").

In particular, sec 6.7.3.3 says:

 "The Data Link Layer State Changed event must occur within 1 second
  of the event that initiates the hot-insertion. If a power controller
  is supported, the time out interval is measured from when software
  initiated a write to the Slot Control register to turn on the power.
  [...] Software is allowed to time out on a hot add operation if the
  Data Link Layer State Changed event does not occur within 1 second."

So I think the delays observed by pciehp are conforming to the spec.

The PCIe CEM Spec r6.0.1 sec 2.11.2 specifies Tpvperl as "min 100 ms".

I don't know why the OCP NIC Spec says "> 1s" instead, but that number
isn't what the PCIe CEM Spec says and that's the authoritative document.

So I'm inclined to say the number in the OCP NIC Spec is wrong and
needs to be fixed.

> This is observed with an OCP ConnectX-7 (MT2910 family) adapter.  On the
> affected platform, power-on to PERST# deassertion takes about 1.2 seconds,
> followed by a few hundred milliseconds for link activation, exceeding
> the existing polling budget.

Which platform are we talking about?  A chassis from HJ Micro?
Has this already been shipped to customers or is it still in
internal validation?  If it's still in validation, please fix
the hardware to shorten the delays in accordance with the PCIe
Base and CEM Spec, ignoring the bogus value in the OCP NIC spec.

If it's already in customers' hands, can you fix this through
a firmware update or something like that?

I'd like to avoid lengthening the delays in pciehp beyond what
the spec prescribes, only to work around non-conforming platforms.

Thanks,

Lukas