From: Hans Zhang <18255117159@163.com>
To: sashiko@lists.linux.dev
Cc: wsa+renesas@sang-engineering.com, linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 1/7] PCI: Add pci_host_common_link_train_delay() helper
Date: Tue, 12 May 2026 08:45:41 +0800 [thread overview]
Message-ID: <982ada81-7f17-47f8-9b23-6e5c59f627eb@163.com> (raw)
In-Reply-To: <20260512000723.2F382C2BCB0@smtp.kernel.org>
On 5/12/26 08:07, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] Negative error codes passed as `max_link_speed` silently bypass the mandatory PCIe delay.
> - [Medium] Architectural modularity violation by placing a generic PCIe helper in an ECAM framework header.
> - [Low] The helper API relies on raw integer values for link speed instead of the typed `enum pci_bus_speed`, creating a brittle interface.
> --
>
> commit 47720e87ef05a9f0115d64b2e2d6eaa190242b88
> Author: Hans Zhang <18255117159@163.com>
>
> PCI: Add pci_host_common_link_train_delay() helper
>
> This commit introduces a static inline helper to wait 100 ms after link
> training completes if the maximum link speed is greater than 5.0 GT/s,
> satisfying the PCIe r6.0 specification.
>
>> diff --git a/drivers/pci/controller/pci-host-common.h b/drivers/pci/controller/pci-host-common.h
>> index b5075d4bd7eb3..d709f7e3e11a3 100644
>> --- a/drivers/pci/controller/pci-host-common.h
>> +++ b/drivers/pci/controller/pci-host-common.h
>
> This isn't a bug, but this places a generic PCIe helper inside an ECAM
> framework header. Unrelated host controller drivers will have to include
> an ECAM-specific header just to use this delay function.
>
> Should this generic helper be placed in a more widely accessible internal
> header like drivers/pci/pci.h?
No, Mani suggested placing it in the pci-host-common.h file.
>
> [ ... ]
>
>> @@ -20,4 +23,18 @@ void pci_host_common_remove(struct platform_device *pdev);
>>
>> struct pci_config_window *pci_host_common_ecam_create(struct device *dev,
>> struct pci_host_bridge *bridge, const struct pci_ecam_ops *ops);
>> +
>> +/**
>> + * pci_host_common_link_train_delay - Wait 100 ms if link speed > 5 GT/s
>> + * @max_link_speed: the maximum link speed (2 = 5.0 GT/s, 3 = 8.0 GT/s, ...)
>> + *
>> + * Must be called after Link training completes and before the first
>> + * Configuration Request is sent.
>> + */
>> +static inline void pci_host_common_link_train_delay(int max_link_speed)
>
> This isn't a bug, but relying on raw integer values for link speed instead
> of enum pci_bus_speed creates a brittle interface.
>
> The PCI subsystem uses enum pci_bus_speed for link speeds, where
> PCIE_SPEED_2_5GT is 20 and PCIE_SPEED_5_0GT is 21. If a driver mistakenly
> passes an enum pci_bus_speed, the condition greater than 2 will evaluate
> to true for all speeds, applying the delay unconditionally.
>
>> +{
>> + if (max_link_speed > 2)
>
> Will negative error codes passed as max_link_speed silently bypass the
> mandatory PCIe delay?
>
> Drivers retrieve the maximum link speed using of_pci_get_max_link_speed(),
> which returns -EINVAL if the max-link-speed property is missing from the
> device tree.
>
> If -EINVAL is passed directly to this helper, the condition evaluates to
> false and the 100 ms delay is skipped. If the hardware supports greater
> than 5.0 GT/s, skipping this delay violates the PCIe r6.0 specification.
>
>> + msleep(PCIE_RESET_CONFIG_WAIT_MS);
>> +}
>> +
>> #endif
>
next prev parent reply other threads:[~2026-05-12 0:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 5:59 [PATCH v3 0/7] PCI: Add common helper for 100 ms delay after link training Hans Zhang
2026-05-11 5:59 ` [PATCH v3 1/7] PCI: Add pci_host_common_link_train_delay() helper Hans Zhang
2026-05-12 0:07 ` sashiko-bot
2026-05-12 0:45 ` Hans Zhang [this message]
2026-05-12 7:05 ` Claudiu Beznea
2026-05-12 10:06 ` Hans Zhang
2026-05-11 5:59 ` [PATCH v3 2/7] PCI: cadence: Add post-link delay for LGA and j721e glue driver Hans Zhang
2026-05-12 0:24 ` sashiko-bot
2026-05-12 0:44 ` Hans Zhang
2026-05-11 5:59 ` [PATCH v3 3/7] PCI: cadence: HPA: Add post-link delay Hans Zhang
2026-05-12 0:44 ` sashiko-bot
2026-05-11 5:59 ` [PATCH v3 4/7] PCI: dwc: Use common pci_host_common_link_train_delay() helper Hans Zhang
2026-05-11 7:02 ` Krzysztof Wilczyński
2026-05-12 0:43 ` Hans Zhang
2026-05-12 7:14 ` Krzysztof Wilczyński
2026-05-12 10:06 ` Hans Zhang
2026-05-12 6:45 ` Manivannan Sadhasivam
2026-05-12 7:14 ` Krzysztof Wilczyński
2026-05-12 1:00 ` sashiko-bot
2026-05-11 5:59 ` [PATCH v3 5/7] PCI: aardvark: Add 100 ms delay after link training Hans Zhang
2026-05-12 1:31 ` sashiko-bot
2026-05-11 5:59 ` [PATCH v3 6/7] PCI: mediatek-gen3: Add 100 ms delay after link up Hans Zhang
2026-05-12 1:59 ` sashiko-bot
2026-05-11 5:59 ` [PATCH v3 7/7] PCI: rzg3s-host: Use common pci_host_common_link_train_delay() helper Hans Zhang
2026-05-12 2:15 ` sashiko-bot
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=982ada81-7f17-47f8-9b23-6e5c59f627eb@163.com \
--to=18255117159@163.com \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko@lists.linux.dev \
--cc=wsa+renesas@sang-engineering.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox