From: Hans Zhang <18255117159@163.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: bhelgaas@google.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
ryder.lee@mediatek.com, jianjun.wang@mediatek.com,
claudiu.beznea.uj@bp.renesas.com, mpillai@cadence.com,
robh@kernel.org, s-vadapalli@ti.com, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 6/8] PCI: aardvark: Add 100 ms delay after link training
Date: Wed, 13 May 2026 15:34:46 +0800 [thread overview]
Message-ID: <15532890-ce22-4b20-96d9-e7f7c47050d2@163.com> (raw)
In-Reply-To: <20260513072008.vol4htgbzquly2rb@pali>
On 5/13/26 15:20, Pali Rohár wrote:
> On Wednesday 13 May 2026 15:00:04 Hans Zhang wrote:
>>
>>
>> On 5/13/26 05:25, Pali Rohár wrote:
>>> On Wednesday 06 May 2026 23:23:44 Hans Zhang wrote:
>>>> The Aardvark PCIe controller driver waits for the link to come up but
>>>> does not implement the mandatory 100 ms delay after link training
>>>> completes for speeds greater than 5.0 GT/s (PCIe r6.0 sec 6.6.1).
>>>>
>>>> The driver already maintains a 'link_gen' field that holds the negotiated
>>>> link speed. Use it together with pcie_wait_after_link_train() to insert
>>>> the required delay immediately after confirming that the link is up.
>>>>
>>>> Signed-off-by: Hans Zhang <18255117159@163.com>
>>>> ---
>>>> drivers/pci/controller/pci-aardvark.c | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
>>>> index e34bea1ff0ac..526351c21c49 100644
>>>> --- a/drivers/pci/controller/pci-aardvark.c
>>>> +++ b/drivers/pci/controller/pci-aardvark.c
>>>> @@ -350,8 +350,10 @@ static int advk_pcie_wait_for_link(struct advk_pcie *pcie)
>>>> /* check if the link is up or not */
>>>> for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
>>>> - if (advk_pcie_link_up(pcie))
>>>> + if (advk_pcie_link_up(pcie)) {
>>>> + pcie_wait_after_link_train(pcie->link_gen);
>>>> return 0;
>>>> + }
>>>> usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
>>>> }
>>>> --
>>>> 2.34.1
>>>>
>>>
>>> Are you sure that this is correct to do? Have you checked the A3720
>>> Functional Specification which describes how to bring PCIe link up?
>>>
>>> A3720 PCIe controller is buggy and needs more timing hacks to make it
>>> behave. Playing with random sleeps can break its internal logic.
>>> I'm not sure if it could be safe without proper testing.
>>>
>>> And IIRC A3720 PCIe controller is just PCIe2.0 with 5 GT/s.
>>
>>
>> Hi Pali,
>>
>> 1. This driver does not support A3720.
>>
>> static const struct of_device_id advk_pcie_of_match_table[] = {
>> { .compatible = "marvell,armada-3700-pcie", },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, advk_pcie_of_match_table);
>>
>> If you need support for A3720, please submit the corresponding patch so that
>> Bjorn and Mani can review it.
>
> 3700 (or 37xx) is family and covers both a3710 and a3720. In most cases is the
> a3720 dominant and hence identifiers 3700 and 3720 are begin mixed.
>
>>
>> 2. If A3720 only supports GEN2, you can configure "max-link-speed" to be 2
>> in the DT. This will not affect the functionality of this patch.
>
> Whole A37xx supports only GEN2. And in DT files for 37xx should be
> already there max-link-speed.
>
> Seems that in advk_pcie_of_match_table there is no GEN3 device
> specified.
>
Hi Pali,
However, I saw many GEN3 assignments and conditions in the code.
ret = of_pci_get_max_link_speed(dev->of_node);
if (ret <= 0 || ret > 3)
pcie->link_gen = 3;
else
pcie->link_gen = ret;
static void advk_pcie_train_link(struct advk_pcie *pcie)
{
struct device *dev = &pcie->pdev->dev;
u32 reg;
int ret;
/*
* Setup PCIe rev / gen compliance based on device tree property
* 'max-link-speed' which also forces maximal link speed.
*/
reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG);
reg &= ~PCIE_GEN_SEL_MSK;
if (pcie->link_gen == 3)
reg |= SPEED_GEN_3;
else if (pcie->link_gen == 2)
reg |= SPEED_GEN_2;
else
reg |= SPEED_GEN_1;
advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG);
/*
* Set maximal link speed value also into PCIe Link Control 2 register.
* Armada 3700 Functional Specification says that default value is based
* on SPEED_GEN but tests showed that default value is always 8.0 GT/s.
*/
reg = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL2);
reg &= ~PCI_EXP_LNKCTL2_TLS;
if (pcie->link_gen == 3)
reg |= PCI_EXP_LNKCTL2_TLS_8_0GT;
else if (pcie->link_gen == 2)
reg |= PCI_EXP_LNKCTL2_TLS_5_0GT;
else
reg |= PCI_EXP_LNKCTL2_TLS_2_5GT;
advk_writel(pcie, reg, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL2);
....
If you are certain about the relevant information. Is it understandable
that we need to delete the code related to GEN3?
Best regards,
Hans
>> 3. This patch is a common delay requirement stipulated by the PCIe
>> specification. If it is greater than GEN2, then msleep(100) will be added;
>> otherwise, there will be no such delay.
>>
>> 4. For instance, we often come across the situation where some common APIs
>> are modified, and in many cases, their functionality does not require the
>> actual development board for verification. I believe that many other
>> developers and maintainers have modified different parts of the code. For
>> example, the recent submission:
>
> Switching one API to another is one thing. But changing code which looks
> to be critical, specially when it is known that hw has bugs, can cause
> breaking of existing boards.
>
>> commit 750277048afe7ce8ebfc0b120de7dfbc745058a7
>> Author: Nam Cao <namcao@linutronix.de>
>> Date: Thu Jun 26 16:47:53 2025 +0200
>>
>> PCI: aardvark: Switch to msi_create_parent_irq_domain()
>>
>> Switch to msi_create_parent_irq_domain() from
>> pci_msi_create_irq_domain()
>> which was using legacy MSI domain setup.
>>
>>
>> And many controller drivers have been modified.
>>
>>
>> Best regards,
>> Hans
>>
>>
next prev parent reply other threads:[~2026-05-13 7:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 15:23 [PATCH v2 0/8] PCI: Add common helper for 100 ms delay after link training Hans Zhang
2026-05-06 15:23 ` [PATCH v2 1/8] PCI: Add pcie_wait_after_link_train() helper Hans Zhang
2026-05-06 15:34 ` Biju Das
2026-05-06 16:16 ` Hans Zhang
2026-05-06 15:55 ` Manivannan Sadhasivam
2026-05-06 16:13 ` Hans Zhang
2026-05-06 15:23 ` [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link training Hans Zhang
2026-05-06 15:31 ` Biju Das
2026-05-06 16:21 ` Hans Zhang
2026-05-06 16:27 ` Biju Das
2026-05-06 16:31 ` Hans Zhang
2026-05-06 16:03 ` Manivannan Sadhasivam
2026-05-06 16:14 ` Hans Zhang
2026-05-06 15:23 ` [PATCH v2 3/8] PCI: cadence: HPA: Add " Hans Zhang
2026-05-06 15:23 ` [PATCH v2 4/8] PCI: j721e: Set max_link_speed to enable 100 ms delay after link up Hans Zhang
2026-05-06 16:04 ` Manivannan Sadhasivam
2026-05-06 16:11 ` Hans Zhang
2026-05-06 16:51 ` Manivannan Sadhasivam
2026-05-06 15:23 ` [PATCH v2 5/8] PCI: dwc: Use common pcie_wait_after_link_train() helper Hans Zhang
2026-05-06 15:23 ` [PATCH v2 6/8] PCI: aardvark: Add 100 ms delay after link training Hans Zhang
2026-05-12 21:25 ` Pali Rohár
2026-05-13 7:00 ` Hans Zhang
2026-05-13 7:20 ` Pali Rohár
2026-05-13 7:34 ` Hans Zhang [this message]
2026-05-06 15:23 ` [PATCH v2 7/8] PCI: mediatek-gen3: " Hans Zhang
2026-05-06 15:23 ` [PATCH v2 8/8] PCI: rzg3s-host: " Hans Zhang
2026-05-06 16:52 ` Claudiu Beznea
2026-05-09 16:25 ` Hans Zhang
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=15532890-ce22-4b20-96d9-e7f7c47050d2@163.com \
--to=18255117159@163.com \
--cc=bhelgaas@google.com \
--cc=claudiu.beznea.uj@bp.renesas.com \
--cc=jianjun.wang@mediatek.com \
--cc=jingoohan1@gmail.com \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=mpillai@cadence.com \
--cc=pali@kernel.org \
--cc=robh@kernel.org \
--cc=ryder.lee@mediatek.com \
--cc=s-vadapalli@ti.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vigneshr@ti.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