Linux-mediatek Archive on lore.kernel.org
 help / color / mirror / Atom feed
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:00:04 +0800	[thread overview]
Message-ID: <581e91fb-2e57-43ed-b79d-19dbf384b955@163.com> (raw)
In-Reply-To: <20260512212531.jupoocz7acv22qyg@pali>



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.


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.

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:

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




  reply	other threads:[~2026-05-13  7:01 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 [this message]
2026-05-13  7:20       ` Pali Rohár
2026-05-13  7:34         ` Hans Zhang
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=581e91fb-2e57-43ed-b79d-19dbf384b955@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