All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Enrique Hernández Bello" <ehbello@gmail.com>
Cc: devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v5 1/2] dt-bindings: PCI: rockchip,rk3399-pcie: Add PERST# inactive delay properties
Date: Wed, 04 Nov 2026 22:06:05 +0000	[thread overview]
Message-ID: <sashiko-outbox-198198@kernel.org> (raw)
In-Reply-To: <20261104215848.2087944-2-ehbello@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: PCI: rockchip,rk3399-pcie: OS policy and magic 0 in PERST# props
--

commit 9f3338157ea2855233568eb255bd2687fadd36fe
Author: Enrique Hernández Bello <ehbello@gmail.com>

dt-bindings: PCI: rockchip,rk3399-pcie: Add PERST# inactive delay properties

This commit adds the optional rockchip,perst-inactive-ms and
rockchip,s2r-perst-inactive-ms properties to the RK3399 PCIe host controller
binding to configure the reset assertion delay at probe and system resume.

> diff --git a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
> index 720a5f945a4e6..7ac915c267910 100644
> --- a/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/rockchip,rk3399-pcie.yaml
> @@ -40,6 +40,21 @@ properties:
>      maxItems: 1
>      description: pre-reset GPIO
>  
> +  rockchip,perst-inactive-ms:
> +    default: 100
> +    description:
> +      Time PERST# is held asserted before it is released, which is also the
> +      width of the reset pulse. The default meets T_PVPERL for a slot that
> +      is powered at the moment PERST# is asserted. Some endpoints need more
> +      settling time than that, while others stop responding when the pulse
> +      is that long. A value of 0 selects the 100 us minimum the PCI Express
> +      CEM specification sets for the pulse.
> +
> +  rockchip,s2r-perst-inactive-ms:
> +    description:
> +      The same time, applied when resuming from system suspend. Defaults to
> +      the value of rockchip,perst-inactive-ms.

[Severity: Medium]
Are vendor-specific host controller properties split by OS lifecycle state
the right way to model this in Device Tree?

Splitting the reset delay into rockchip,perst-inactive-ms (probe) and
rockchip,s2r-perst-inactive-ms (system suspend-to-ram resume) encodes OS
driver power-management transitions directly into the binding rather than
describing hardware characteristics.

In drivers/pci/controller/pcie-rockchip-host.c, rockchip_pcie_suspend_noirq()
only disables vpcie0v9 while leaving vpcie12v, vpcie3v3, and vpcie1v8
enabled, and does not assert perst_gpio on suspend. Then on both probe and
resume, rockchip_pcie_host_init_port() asserts perst_gpio, enables link
training (PCIE_CLIENT_LINK_TRAIN_ENABLE) while reset is still asserted, and
sleeps for PCIE_T_PVPERL_MS (100 ms) before deasserting perst_gpio.

Holding reset asserted for 100 ms after enabling link training or when slot
power rails are already stable looks like a sequencing issue in
pcie-rockchip-host.c rather than a property of the RK3399 controller.

Also, if an endpoint requires a non-standard reset delay, shouldn't that be
described using generic reset or PCI device properties (such as
reset-assert-ms or reset-delay-us) rather than SoC-specific host properties?
Neither rockchip,perst-inactive-ms nor rockchip,s2r-perst-inactive-ms exists
in mainline Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml.

Finally, rockchip,perst-inactive-ms uses the standard -ms unit suffix, but
defines 0 as a magic value that selects a 100 us pulse width instead of 0 ms,
and names the active-low reset assertion duration "perst-inactive-ms" even
though the signal is held active (asserted) during this window. Could this be
handled by fixing the driver reset sequencing or using standard unit-accurate
properties instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261104215848.2087944-1-ehbello@gmail.com?part=1

  reply	other threads:[~2026-11-04 22:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 21:58 [PATCH v5 0/2] PCI: rockchip-host: Make the PERST# inactive delay configurable Enrique Hernández Bello
2026-11-04 21:58 ` Enrique Hernández Bello
2026-11-04 21:58 ` [PATCH v5 1/2] dt-bindings: PCI: rockchip,rk3399-pcie: Add PERST# inactive delay properties Enrique Hernández Bello
2026-11-04 21:58   ` Enrique Hernández Bello
2026-11-04 22:06   ` sashiko-bot [this message]
2026-11-05 12:23   ` Krzysztof Kozlowski
2026-11-05 12:23     ` Krzysztof Kozlowski
2026-11-05 17:40     ` Enrique Hernández Bello
2026-11-05 17:40       ` Enrique Hernández Bello
2026-11-05 18:24       ` Krzysztof Kozlowski
2026-11-05 18:24         ` Krzysztof Kozlowski
2026-11-04 21:58 ` [PATCH v5 2/2] PCI: rockchip-host: Make the PERST# inactive delay configurable Enrique Hernández Bello
2026-11-04 21:58   ` Enrique Hernández Bello
2026-11-04 22:04   ` sashiko-bot
2026-11-05  1:44 ` [PATCH v5 0/2] " Igor Velkov
2026-11-05  1:44   ` Igor Velkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-198198@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ehbello@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.