Linux-mediatek Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH nf-next 0/4] Add IPv4 over IPv6 flowtable SW acceleration
From: Lorenzo Bianconi @ 2026-05-06 17:27 UTC (permalink / raw)
  To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Felix Fietkau, Matthias Brugger,
	AngeloGioacchino Del Regno, Simon Horman, David Ahern,
	Ido Schimmel, Pablo Neira Ayuso, Florian Westphal, Phil Sutter,
	Shuah Khan
  Cc: linux-arm-kernel, linux-mediatek, netdev, netfilter-devel,
	coreteam, linux-kselftest
In-Reply-To: <20260505-b4-flowtable-sw-accel-ip6ip-v1-0-9ac39ccc9ea9@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

> Similar to IPIP and IP6I6 tunnels, introduce sw acceleration for IPv4 over
> IPv6 tunnels in the netfilter flowtable infrastructure.

Please drop this revision, I spotted a bug in MTU configuration in
nf_flow_offload_forward(). I will post v2 fixing the issue and adding
SIT support.

Regards,
Lorenzo

> 
> ---
> Lorenzo Bianconi (4):
>       net: netfilter: Add ether_type to net_device_path_ctx
>       net: netfilter: Add encap_proto to flow_offload_tunnel
>       net: netfilter: Add IPv4 over IPv6 tunnel flowtable acceleration
>       selftests: netfilter: nft_flowtable.sh: Add IPv4 over IPv6 flowtable selftest
> 
>  drivers/net/ethernet/airoha/airoha_ppe.c           |  14 ++-
>  drivers/net/ethernet/mediatek/mtk_ppe_offload.c    |  13 ++-
>  include/linux/netdevice.h                          |   5 +-
>  include/net/netfilter/nf_flow_table.h              |   1 +
>  net/core/dev.c                                     |   6 +-
>  net/ipv4/ipip.c                                    |   1 +
>  net/ipv6/ip6_tunnel.c                              |   6 +-
>  net/netfilter/nf_flow_table_core.c                 |  14 ++-
>  net/netfilter/nf_flow_table_ip.c                   | 129 ++++++++++++++++-----
>  net/netfilter/nf_flow_table_path.c                 |  16 +--
>  .../selftests/net/netfilter/nft_flowtable.sh       |  26 +++++
>  11 files changed, 174 insertions(+), 57 deletions(-)
> ---
> base-commit: c1e5127b577c6b88fa48e532616932ae978528d5
> change-id: 20260505-b4-flowtable-sw-accel-ip6ip-7101034cd147
> 
> Best regards,
> -- 
> Lorenzo Bianconi <lorenzo@kernel.org>
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply

* Re: [PATCH v2 8/8] PCI: rzg3s-host: Add 100 ms delay after link training
From: Claudiu Beznea @ 2026-05-06 16:52 UTC (permalink / raw)
  To: Hans Zhang, bhelgaas, lpieralisi, kwilczynski, mani, vigneshr,
	jingoohan1, thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai
  Cc: robh, s-vadapalli, linux-omap, linux-arm-kernel, linux-mediatek,
	linux-renesas-soc, linux-pci, linux-kernel
In-Reply-To: <20260506152346.166056-9-18255117159@163.com>

Hi, Hans,

On 5/6/26 18:23, Hans Zhang wrote:
> The Renesas RZ/G3S PCIe host driver currently does not enforce the
> mandatory 100 ms delay after link training completes for speeds > 5.0 GT/s,
> required by PCIe r6.0 sec 6.6.1.
> 
> The driver already has a 'max_link_speed' field (derived from the device
> tree). Add a call to pcie_wait_after_link_train() in
> rzg3s_pcie_host_init() after reading the link status, ensuring that the
> delay is applied before any Configuration Request is sent downstream.
> 
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
>   drivers/pci/controller/pcie-rzg3s-host.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-rzg3s-host.c b/drivers/pci/controller/pcie-rzg3s-host.c
> index d86e7516dcc2..6ab59c5464cf 100644
> --- a/drivers/pci/controller/pcie-rzg3s-host.c
> +++ b/drivers/pci/controller/pcie-rzg3s-host.c
> @@ -1390,6 +1390,8 @@ static int rzg3s_pcie_host_init(struct rzg3s_pcie_host *host)
>   	val = readl_relaxed(host->axi + RZG3S_PCI_PCSTAT2);
>   	dev_info(host->dev, "PCIe link status [0x%x]\n", val);
>   
> +	pcie_wait_after_link_train(host->max_link_speed);

There is an msleep(PCIE_RESET_CONFIG_WAIT_MS) after 
rzg3s_pcie_set_max_link_speed() call. Shouldn't that msleep() call be replaced 
with your pcie_wait_after_link_train() ?

Thank you,
Claudiu


^ permalink raw reply

* Re: [PATCH v2 4/8] PCI: j721e: Set max_link_speed to enable 100 ms delay after link up
From: Manivannan Sadhasivam @ 2026-05-06 16:51 UTC (permalink / raw)
  To: Hans Zhang
  Cc: bhelgaas, lpieralisi, kwilczynski, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai, robh, s-vadapalli, linux-omap,
	linux-arm-kernel, linux-mediatek, linux-renesas-soc, linux-pci,
	linux-kernel
In-Reply-To: <53e37127-975b-42cd-a1a2-35dd3018c45c@163.com>

On Thu, May 07, 2026 at 12:11:22AM +0800, Hans Zhang wrote:
> 
> 
> On 5/7/26 00:04, Manivannan Sadhasivam wrote:
> > On Wed, May 06, 2026 at 11:23:42PM +0800, Hans Zhang wrote:
> > > Set cdns_pcie.max_link_speed to the maximum supported link speed
> > > (obtained from the device tree property "max-link-speed") in
> > > j721e_pcie_set_link_speed(). This activates the post-link delay logic
> > > added in cdns_pcie_host_start_link() when the controller supports
> > > speeds greater than 5 GT/s.
> > > 
> > > As required by PCIe r6.0 sec 6.6.1, and following the same approach as
> > > commit 80dc18a0cba8d ("PCI: dwc: Ensure that dw_pcie_wait_for_link()
> > > waits 100 ms after link up"), this ensures a 100 ms delay after link
> > > training completes before any Configuration Request is sent.
> > > 
> > > Signed-off-by: Hans Zhang <18255117159@163.com>
> > > ---
> > >   drivers/pci/controller/cadence/pci-j721e.c | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> > > index bfdfe98d5aba..ee85b8e04f5b 100644
> > > --- a/drivers/pci/controller/cadence/pci-j721e.c
> > > +++ b/drivers/pci/controller/cadence/pci-j721e.c
> > > @@ -206,6 +206,7 @@ static int j721e_pcie_set_link_speed(struct j721e_pcie *pcie,
> > >   	    (pcie_get_link_speed(link_speed) == PCI_SPEED_UNKNOWN))
> > >   		link_speed = 2;
> > > +	pcie->cdns_pcie.max_link_speed = link_speed;
> > 
> > What about other glue drivers?
> 
> Hi Mani,
> 
> pci-sky1.c:
> There is no time to handle the corresponding DTS yet, and the attribute
> "max-link-speed" has not been parsed either. There will be a plan for the
> subsequent upstream.
> 
> pcie-sg2042.c:
> I'm not familiar with this product.
> 

Since this helper gets called unconditionally for all glue drivers, not setting
'max_link_speed' would cause 100ms delay for all link speeds.

So either set 'max_link_speed' for all drivers, or call the helper directly from
glue drivers.

- Mani

-- 
மணிவண்ணன் சதாசிவம்


^ permalink raw reply

* Re: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link training
From: Hans Zhang @ 2026-05-06 16:31 UTC (permalink / raw)
  To: Biju Das, bhelgaas@google.com, lpieralisi@kernel.org,
	kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
	jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
	pali@kernel.org, ryder.lee@mediatek.com,
	jianjun.wang@mediatek.com, Claudiu Beznea, mpillai@cadence.com
  Cc: 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
In-Reply-To: <TY3PR01MB11346E35A6CFDE8460FAF107F863F2@TY3PR01MB11346.jpnprd01.prod.outlook.com>



On 5/7/26 00:27, Biju Das wrote:
> Hi Hans,
> 
>> -----Original Message-----
>> From: Hans Zhang <18255117159@163.com>
>> Sent: 06 May 2026 17:21
>> Subject: Re: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link
>> training
>>
>>
>>
>> On 5/6/26 23:31, Biju Das wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: linux-arm-kernel <linux-arm-kernel-bounces@lists.infradead.org>
>>>> On Behalf Of Hans Zhang
>>>> Sent: 06 May 2026 16:24
>>>> Subject: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field
>>>> and 100 ms delay after link training
>>>>
>>>> The Cadence LGA (Legacy Architecture IP) PCIe host controller
>>>> currently lacks the mandatory 100 ms delay after link training
>>>> completes for speeds
>>>>> 5.0 GT/s, as required by PCIe r6.0 sec 6.6.1.
>>>>
>>>> Add a 'max_link_speed' field to struct cdns_pcie to record the
>>>> maximum supported link speed (or the currently configured speed). In
>>>> the common host layer function cdns_pcie_host_start_link(), after the
>>>> link has been successfully established, call pcie_wait_after_link_train() to insert the required
>> delay if max_link_speed > 2.
>>>>
>>>> Glue drivers must set max_link_speed appropriately (e.g., from the
>>>> device tree property "max-link-
>>>> speed") to enable the delay.
>>>>
>>>> Signed-off-by: Hans Zhang <18255117159@163.com>
>>>> ---
>>>>    drivers/pci/controller/cadence/pcie-cadence-host-common.c | 4 ++++
>>>>    drivers/pci/controller/cadence/pcie-cadence.h             | 2 ++
>>>>    2 files changed, 6 insertions(+)
>>>>
>>>> diff --git
>>>> a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> index 2b0211870f02..51376f69d007 100644
>>>> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>>>> @@ -14,6 +14,7 @@
>>>>
>>>>    #include "pcie-cadence.h"
>>>>    #include "pcie-cadence-host-common.h"
>>>> +#include "../../pci.h"
>>>>
>>>>    #define LINK_RETRAIN_TIMEOUT HZ
>>>>
>>>> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc *rc,
>>>>    	if (!ret && rc->quirk_retrain_flag)
>>>>    		ret = cdns_pcie_retrain(pcie, pcie_link_up);
>>>>
>>>> +	if (!ret)
>>>> +		pcie_wait_after_link_train(pcie->max_link_speed);
>>>> +
>>>>    	return ret;
>>>>    }
>>>>    EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
>>>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h
>>>> b/drivers/pci/controller/cadence/pcie-
>>>> cadence.h
>>>> index 574e9cf4d003..e222b095d2b6 100644
>>>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>>>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>>>> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>>>>     * @ops: Platform-specific ops to control various inputs from Cadence PCIe
>>>>     *       wrapper
>>>>     * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
>>>> + * @max_link_speed: maximum supported link speed
>>>
>>> Maximum to make consistent with other comments?
>>
>> Hi Biju,
>>
>> The reference I used is:
>>
>> drivers/pci/controller/pcie-rzg3s-host.c
> 
> * @ops: Platform-specific ops to control various inputs from Cadence PCIe
> *       wrapper
> * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
> 
> Bute here drivers/pci/controller/cadence/pcie-cadence.h, all start with Capital letter.
> 

Hi Biju,

Thanks, will change.

> 
>>
>> drivers/pci/controller/pcie-rzg3s-host.c
>> /**
>>    ......
>>    * @max_link_speed: maximum supported link speed
>>    */
>> struct rzg3s_pcie_host {
>> ......
>>
>>
>>>
>>>
>>>>     */
>>>>    struct cdns_pcie {
>>>>    	void __iomem		             *reg_base;
>>>> @@ -98,6 +99,7 @@ struct cdns_pcie {
>>>>    	struct device_link	             **link;
>>>>    	const  struct cdns_pcie_ops          *ops;
>>>>    	const  struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
>>>> +	int				     max_link_speed;
>>>
>>> unsigned int as speed cannot be negative??
>>
>> The following file referred to:
>>
>> drivers/pci/controller/dwc/pcie-designware.h
>> struct dw_pcie {
>>       ......
>>       int			max_link_speed;
> 
> Maybe that driver is using negative values.
> Is this driver using negative values for speed?

For speed, there are no negative values.

Best regards,
Hans

> 
> Cheers,
> Biju
> 
>>       ......
>> };
>>
>>
>> Best regards,
>> Hans
>>>
>>> Cheers,
>>> Biju
>>>
>>>>    };
>>>>
>>>>    /**
>>>> --
>>>> 2.34.1
>>>>
> 



^ permalink raw reply

* RE: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link training
From: Biju Das @ 2026-05-06 16:27 UTC (permalink / raw)
  To: Hans Zhang, bhelgaas@google.com, lpieralisi@kernel.org,
	kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
	jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
	pali@kernel.org, ryder.lee@mediatek.com,
	jianjun.wang@mediatek.com, Claudiu Beznea, mpillai@cadence.com
  Cc: 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
In-Reply-To: <8932a3a4-ede9-464e-985b-f9b0ab90c830@163.com>

Hi Hans,

> -----Original Message-----
> From: Hans Zhang <18255117159@163.com>
> Sent: 06 May 2026 17:21
> Subject: Re: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link
> training
> 
> 
> 
> On 5/6/26 23:31, Biju Das wrote:
> >
> >
> >> -----Original Message-----
> >> From: linux-arm-kernel <linux-arm-kernel-bounces@lists.infradead.org>
> >> On Behalf Of Hans Zhang
> >> Sent: 06 May 2026 16:24
> >> Subject: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field
> >> and 100 ms delay after link training
> >>
> >> The Cadence LGA (Legacy Architecture IP) PCIe host controller
> >> currently lacks the mandatory 100 ms delay after link training
> >> completes for speeds
> >>> 5.0 GT/s, as required by PCIe r6.0 sec 6.6.1.
> >>
> >> Add a 'max_link_speed' field to struct cdns_pcie to record the
> >> maximum supported link speed (or the currently configured speed). In
> >> the common host layer function cdns_pcie_host_start_link(), after the
> >> link has been successfully established, call pcie_wait_after_link_train() to insert the required
> delay if max_link_speed > 2.
> >>
> >> Glue drivers must set max_link_speed appropriately (e.g., from the
> >> device tree property "max-link-
> >> speed") to enable the delay.
> >>
> >> Signed-off-by: Hans Zhang <18255117159@163.com>
> >> ---
> >>   drivers/pci/controller/cadence/pcie-cadence-host-common.c | 4 ++++
> >>   drivers/pci/controller/cadence/pcie-cadence.h             | 2 ++
> >>   2 files changed, 6 insertions(+)
> >>
> >> diff --git
> >> a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> >> b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> >> index 2b0211870f02..51376f69d007 100644
> >> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> >> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> >> @@ -14,6 +14,7 @@
> >>
> >>   #include "pcie-cadence.h"
> >>   #include "pcie-cadence-host-common.h"
> >> +#include "../../pci.h"
> >>
> >>   #define LINK_RETRAIN_TIMEOUT HZ
> >>
> >> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc *rc,
> >>   	if (!ret && rc->quirk_retrain_flag)
> >>   		ret = cdns_pcie_retrain(pcie, pcie_link_up);
> >>
> >> +	if (!ret)
> >> +		pcie_wait_after_link_train(pcie->max_link_speed);
> >> +
> >>   	return ret;
> >>   }
> >>   EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
> >> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h
> >> b/drivers/pci/controller/cadence/pcie-
> >> cadence.h
> >> index 574e9cf4d003..e222b095d2b6 100644
> >> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> >> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> >> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
> >>    * @ops: Platform-specific ops to control various inputs from Cadence PCIe
> >>    *       wrapper
> >>    * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
> >> + * @max_link_speed: maximum supported link speed
> >
> > Maximum to make consistent with other comments?
> 
> Hi Biju,
> 
> The reference I used is:
> 
> drivers/pci/controller/pcie-rzg3s-host.c

* @ops: Platform-specific ops to control various inputs from Cadence PCIe
*       wrapper
* @cdns_pcie_reg_offsets: Register bank offsets for different SoC

Bute here drivers/pci/controller/cadence/pcie-cadence.h, all start with Capital letter.


> 
> drivers/pci/controller/pcie-rzg3s-host.c
> /**
>   ......
>   * @max_link_speed: maximum supported link speed
>   */
> struct rzg3s_pcie_host {
> ......
> 
> 
> >
> >
> >>    */
> >>   struct cdns_pcie {
> >>   	void __iomem		             *reg_base;
> >> @@ -98,6 +99,7 @@ struct cdns_pcie {
> >>   	struct device_link	             **link;
> >>   	const  struct cdns_pcie_ops          *ops;
> >>   	const  struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
> >> +	int				     max_link_speed;
> >
> > unsigned int as speed cannot be negative??
> 
> The following file referred to:
> 
> drivers/pci/controller/dwc/pcie-designware.h
> struct dw_pcie {
>      ......
>      int			max_link_speed;

Maybe that driver is using negative values.
Is this driver using negative values for speed?

Cheers,
Biju

>      ......
> };
> 
> 
> Best regards,
> Hans
> >
> > Cheers,
> > Biju
> >
> >>   };
> >>
> >>   /**
> >> --
> >> 2.34.1
> >>


^ permalink raw reply

* Re: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link training
From: Hans Zhang @ 2026-05-06 16:21 UTC (permalink / raw)
  To: Biju Das, bhelgaas@google.com, lpieralisi@kernel.org,
	kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
	jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
	pali@kernel.org, ryder.lee@mediatek.com,
	jianjun.wang@mediatek.com, Claudiu Beznea, mpillai@cadence.com
  Cc: 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
In-Reply-To: <TY3PR01MB11346620B7637A16120FDED26863F2@TY3PR01MB11346.jpnprd01.prod.outlook.com>



On 5/6/26 23:31, Biju Das wrote:
> 
> 
>> -----Original Message-----
>> From: linux-arm-kernel <linux-arm-kernel-bounces@lists.infradead.org> On Behalf Of Hans Zhang
>> Sent: 06 May 2026 16:24
>> Subject: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link
>> training
>>
>> The Cadence LGA (Legacy Architecture IP) PCIe host controller currently lacks the mandatory 100 ms
>> delay after link training completes for speeds
>>> 5.0 GT/s, as required by PCIe r6.0 sec 6.6.1.
>>
>> Add a 'max_link_speed' field to struct cdns_pcie to record the maximum supported link speed (or the
>> currently configured speed). In the common host layer function cdns_pcie_host_start_link(), after the
>> link has been successfully established, call pcie_wait_after_link_train() to insert the required delay
>> if max_link_speed > 2.
>>
>> Glue drivers must set max_link_speed appropriately (e.g., from the device tree property "max-link-
>> speed") to enable the delay.
>>
>> Signed-off-by: Hans Zhang <18255117159@163.com>
>> ---
>>   drivers/pci/controller/cadence/pcie-cadence-host-common.c | 4 ++++
>>   drivers/pci/controller/cadence/pcie-cadence.h             | 2 ++
>>   2 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>> b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>> index 2b0211870f02..51376f69d007 100644
>> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>> @@ -14,6 +14,7 @@
>>
>>   #include "pcie-cadence.h"
>>   #include "pcie-cadence-host-common.h"
>> +#include "../../pci.h"
>>
>>   #define LINK_RETRAIN_TIMEOUT HZ
>>
>> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc *rc,
>>   	if (!ret && rc->quirk_retrain_flag)
>>   		ret = cdns_pcie_retrain(pcie, pcie_link_up);
>>
>> +	if (!ret)
>> +		pcie_wait_after_link_train(pcie->max_link_speed);
>> +
>>   	return ret;
>>   }
>>   EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-
>> cadence.h
>> index 574e9cf4d003..e222b095d2b6 100644
>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>>    * @ops: Platform-specific ops to control various inputs from Cadence PCIe
>>    *       wrapper
>>    * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
>> + * @max_link_speed: maximum supported link speed
> 
> Maximum to make consistent with other comments?

Hi Biju,

The reference I used is:

drivers/pci/controller/pcie-rzg3s-host.c
/**
  ......
  * @max_link_speed: maximum supported link speed
  */
struct rzg3s_pcie_host {
......


> 
> 
>>    */
>>   struct cdns_pcie {
>>   	void __iomem		             *reg_base;
>> @@ -98,6 +99,7 @@ struct cdns_pcie {
>>   	struct device_link	             **link;
>>   	const  struct cdns_pcie_ops          *ops;
>>   	const  struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
>> +	int				     max_link_speed;
> 
> unsigned int as speed cannot be negative??

The following file referred to:

drivers/pci/controller/dwc/pcie-designware.h
struct dw_pcie {
     ......
     int			max_link_speed;
     ......
};


Best regards,
Hans
> 
> Cheers,
> Biju
> 
>>   };
>>
>>   /**
>> --
>> 2.34.1
>>



^ permalink raw reply

* Re: [PATCH v2 1/8] PCI: Add pcie_wait_after_link_train() helper
From: Hans Zhang @ 2026-05-06 16:16 UTC (permalink / raw)
  To: Biju Das, bhelgaas@google.com, lpieralisi@kernel.org,
	kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
	jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
	pali@kernel.org, ryder.lee@mediatek.com,
	jianjun.wang@mediatek.com, Claudiu Beznea, mpillai@cadence.com
  Cc: 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
In-Reply-To: <TY3PR01MB1134694C0F3D14E4A69EFB8CA863F2@TY3PR01MB11346.jpnprd01.prod.outlook.com>



On 5/6/26 23:34, Biju Das wrote:
> 
> 
>> -----Original Message-----
>> From: Hans Zhang <18255117159@163.com>
>> Sent: 06 May 2026 16:24
>> Subject: [PATCH v2 1/8] PCI: Add pcie_wait_after_link_train() helper
>>
>> PCIe r6.0, sec 6.6.1 (Conventional Reset) requires that for a Downstream Port supporting Link speeds
>> greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before
>> sending any Configuration Request.
>>
>> Introduce a static inline helper pcie_wait_after_link_train() that checks the given max_link_speed (2 =
>> 5.0 GT/s, 3 = 8.0 GT/s, etc.) and calls
>> msleep(100) only when the speed is greater than 5.0 GT/s. The helper uses the existing
>> PCIE_RESET_CONFIG_WAIT_MS macro defined in pci.h.
>>
>> This allows multiple host controller drivers to share the same mandatory delay without duplicating the
>> logic.
>>
>> Signed-off-by: Hans Zhang <18255117159@163.com>
>> ---
>>   drivers/pci/pci.h | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 4a14f88e543a..a8705a2a2d85 100644
>> --- a/drivers/pci/pci.h
>> +++ b/drivers/pci/pci.h
>> @@ -60,6 +60,19 @@ struct pcie_tlp_log;
>>    */
>>   #define PCIE_RESET_CONFIG_WAIT_MS	100
>>
>> +/**
>> + * pcie_wait_after_link_train - 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 pcie_wait_after_link_train(int max_link_speed) {
>> +	if (max_link_speed > 2)
>> +		msleep(PCIE_RESET_CONFIG_WAIT_MS);
>> +}
> 
> Maybe move this patch to the user??

Hi Biju,

Just as Mani's reply stated, I am more inclined to place it in the 
common header file.

Best regards,
Hans

> 
> Cheers,
> Biju
> 
>> +
>>   /* Parameters for the waiting for link up routine */
>>   #define PCIE_LINK_WAIT_MAX_RETRIES	10
>>   #define PCIE_LINK_WAIT_SLEEP_MS		90
>> --
>> 2.34.1
>>



^ permalink raw reply

* Re: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link training
From: Hans Zhang @ 2026-05-06 16:14 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: bhelgaas, lpieralisi, kwilczynski, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai, robh, s-vadapalli, linux-omap,
	linux-arm-kernel, linux-mediatek, linux-renesas-soc, linux-pci,
	linux-kernel
In-Reply-To: <jmqw5tmgbpou5lanjcnolrpmipgnny6chm53wqybtqg4epfuql@cxqryplrmylk>



On 5/7/26 00:03, Manivannan Sadhasivam wrote:
> On Wed, May 06, 2026 at 11:23:40PM +0800, Hans Zhang wrote:
>> The Cadence LGA (Legacy Architecture IP) PCIe host controller currently
>> lacks the mandatory 100 ms delay after link training completes for speeds
>>> 5.0 GT/s, as required by PCIe r6.0 sec 6.6.1.
>>
>> Add a 'max_link_speed' field to struct cdns_pcie to record the maximum
>> supported link speed (or the currently configured speed). In the common
>> host layer function cdns_pcie_host_start_link(), after the link has been
>> successfully established, call pcie_wait_after_link_train() to insert the
>> required delay if max_link_speed > 2.
>>
>> Glue drivers must set max_link_speed appropriately (e.g., from the device
>> tree property "max-link-speed") to enable the delay.
>>
> 
> You need to club those glue driver patches into this one. Otherwise, you'll end
> up breaking bisectability.

Hi Mani,

Will change.

Best regards,
Hans

> 
> - Mani
> 
>> Signed-off-by: Hans Zhang <18255117159@163.com>
>> ---
>>   drivers/pci/controller/cadence/pcie-cadence-host-common.c | 4 ++++
>>   drivers/pci/controller/cadence/pcie-cadence.h             | 2 ++
>>   2 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>> index 2b0211870f02..51376f69d007 100644
>> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
>> @@ -14,6 +14,7 @@
>>   
>>   #include "pcie-cadence.h"
>>   #include "pcie-cadence-host-common.h"
>> +#include "../../pci.h"
>>   
>>   #define LINK_RETRAIN_TIMEOUT HZ
>>   
>> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc *rc,
>>   	if (!ret && rc->quirk_retrain_flag)
>>   		ret = cdns_pcie_retrain(pcie, pcie_link_up);
>>   
>> +	if (!ret)
>> +		pcie_wait_after_link_train(pcie->max_link_speed);
>> +
>>   	return ret;
>>   }
>>   EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
>> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
>> index 574e9cf4d003..e222b095d2b6 100644
>> --- a/drivers/pci/controller/cadence/pcie-cadence.h
>> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
>> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>>    * @ops: Platform-specific ops to control various inputs from Cadence PCIe
>>    *       wrapper
>>    * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
>> + * @max_link_speed: maximum supported link speed
>>    */
>>   struct cdns_pcie {
>>   	void __iomem		             *reg_base;
>> @@ -98,6 +99,7 @@ struct cdns_pcie {
>>   	struct device_link	             **link;
>>   	const  struct cdns_pcie_ops          *ops;
>>   	const  struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
>> +	int				     max_link_speed;
>>   };
>>   
>>   /**
>> -- 
>> 2.34.1
>>
> 



^ permalink raw reply

* Re: [PATCH v2 1/8] PCI: Add pcie_wait_after_link_train() helper
From: Hans Zhang @ 2026-05-06 16:13 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: bhelgaas, lpieralisi, kwilczynski, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai, robh, s-vadapalli, linux-omap,
	linux-arm-kernel, linux-mediatek, linux-renesas-soc, linux-pci,
	linux-kernel
In-Reply-To: <qryvbq7tn7gpkx63ljauddp3qxczgbzlpfkxiula7vq6f23yaz@oi2pal2ynzgv>



On 5/6/26 23:55, Manivannan Sadhasivam wrote:
> On Wed, May 06, 2026 at 11:23:39PM +0800, Hans Zhang wrote:
>> PCIe r6.0, sec 6.6.1 (Conventional Reset) requires that for a Downstream
>> Port supporting Link speeds greater than 5.0 GT/s, software must wait a
>> minimum of 100 ms after Link training completes before sending any
>> Configuration Request.
>>
>> Introduce a static inline helper pcie_wait_after_link_train() that checks
>> the given max_link_speed (2 = 5.0 GT/s, 3 = 8.0 GT/s, etc.) and calls
>> msleep(100) only when the speed is greater than 5.0 GT/s. The helper uses
>> the existing PCIE_RESET_CONFIG_WAIT_MS macro defined in pci.h.
>>
>> This allows multiple host controller drivers to share the same mandatory
>> delay without duplicating the logic.
>>
>> Signed-off-by: Hans Zhang <18255117159@163.com>
>> ---
>>   drivers/pci/pci.h | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
>> index 4a14f88e543a..a8705a2a2d85 100644
>> --- a/drivers/pci/pci.h
>> +++ b/drivers/pci/pci.h
> 
> Since this helper is for host controller drivers, this needs to be defined in
> pci-host-common.h.
> 

Hi Mani,

Thank you very much for your reply and suggestions.

Will change.

>> @@ -60,6 +60,19 @@ struct pcie_tlp_log;
>>    */
>>   #define PCIE_RESET_CONFIG_WAIT_MS	100
>>   
>> +/**
>> + * pcie_wait_after_link_train - 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 pcie_wait_after_link_train(int max_link_speed)
> 
> pci_host_common_link_train_delay()?

I think it's really great. Thanks.

Best regards,
Hans

> 
> - Mani
> 



^ permalink raw reply

* Re: [PATCH v2 4/8] PCI: j721e: Set max_link_speed to enable 100 ms delay after link up
From: Hans Zhang @ 2026-05-06 16:11 UTC (permalink / raw)
  To: Manivannan Sadhasivam
  Cc: bhelgaas, lpieralisi, kwilczynski, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai, robh, s-vadapalli, linux-omap,
	linux-arm-kernel, linux-mediatek, linux-renesas-soc, linux-pci,
	linux-kernel
In-Reply-To: <rlsvpbo4gcix3mmbfsxvmfebnnn4bqm3cv34x4qkxuv3zwydnm@ehi3el63z664>



On 5/7/26 00:04, Manivannan Sadhasivam wrote:
> On Wed, May 06, 2026 at 11:23:42PM +0800, Hans Zhang wrote:
>> Set cdns_pcie.max_link_speed to the maximum supported link speed
>> (obtained from the device tree property "max-link-speed") in
>> j721e_pcie_set_link_speed(). This activates the post-link delay logic
>> added in cdns_pcie_host_start_link() when the controller supports
>> speeds greater than 5 GT/s.
>>
>> As required by PCIe r6.0 sec 6.6.1, and following the same approach as
>> commit 80dc18a0cba8d ("PCI: dwc: Ensure that dw_pcie_wait_for_link()
>> waits 100 ms after link up"), this ensures a 100 ms delay after link
>> training completes before any Configuration Request is sent.
>>
>> Signed-off-by: Hans Zhang <18255117159@163.com>
>> ---
>>   drivers/pci/controller/cadence/pci-j721e.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
>> index bfdfe98d5aba..ee85b8e04f5b 100644
>> --- a/drivers/pci/controller/cadence/pci-j721e.c
>> +++ b/drivers/pci/controller/cadence/pci-j721e.c
>> @@ -206,6 +206,7 @@ static int j721e_pcie_set_link_speed(struct j721e_pcie *pcie,
>>   	    (pcie_get_link_speed(link_speed) == PCI_SPEED_UNKNOWN))
>>   		link_speed = 2;
>>   
>> +	pcie->cdns_pcie.max_link_speed = link_speed;
> 
> What about other glue drivers?

Hi Mani,

pci-sky1.c:
There is no time to handle the corresponding DTS yet, and the attribute 
"max-link-speed" has not been parsed either. There will be a plan for 
the subsequent upstream.

pcie-sg2042.c:
I'm not familiar with this product.


Do you mean something like a dwc driver, similar to being placed in the 
file drivers/pci/controller/dwc/pcie-designware.c?
pci->max_link_speed = of_pci_get_max_link_speed(np);

For the Cadence driver, it is located in 
drivers/pci/controller/cadence/pcie-cadence-host-common.c.


Best regards,
Hans

> 
> - Mani
> 



^ permalink raw reply

* Re: [PATCH v2 4/8] PCI: j721e: Set max_link_speed to enable 100 ms delay after link up
From: Manivannan Sadhasivam @ 2026-05-06 16:04 UTC (permalink / raw)
  To: Hans Zhang
  Cc: bhelgaas, lpieralisi, kwilczynski, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai, robh, s-vadapalli, linux-omap,
	linux-arm-kernel, linux-mediatek, linux-renesas-soc, linux-pci,
	linux-kernel
In-Reply-To: <20260506152346.166056-5-18255117159@163.com>

On Wed, May 06, 2026 at 11:23:42PM +0800, Hans Zhang wrote:
> Set cdns_pcie.max_link_speed to the maximum supported link speed
> (obtained from the device tree property "max-link-speed") in
> j721e_pcie_set_link_speed(). This activates the post-link delay logic
> added in cdns_pcie_host_start_link() when the controller supports
> speeds greater than 5 GT/s.
> 
> As required by PCIe r6.0 sec 6.6.1, and following the same approach as
> commit 80dc18a0cba8d ("PCI: dwc: Ensure that dw_pcie_wait_for_link()
> waits 100 ms after link up"), this ensures a 100 ms delay after link
> training completes before any Configuration Request is sent.
> 
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
>  drivers/pci/controller/cadence/pci-j721e.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index bfdfe98d5aba..ee85b8e04f5b 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -206,6 +206,7 @@ static int j721e_pcie_set_link_speed(struct j721e_pcie *pcie,
>  	    (pcie_get_link_speed(link_speed) == PCI_SPEED_UNKNOWN))
>  		link_speed = 2;
>  
> +	pcie->cdns_pcie.max_link_speed = link_speed;

What about other glue drivers?

- Mani

-- 
மணிவண்ணன் சதாசிவம்


^ permalink raw reply

* Re: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link training
From: Manivannan Sadhasivam @ 2026-05-06 16:03 UTC (permalink / raw)
  To: Hans Zhang
  Cc: bhelgaas, lpieralisi, kwilczynski, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai, robh, s-vadapalli, linux-omap,
	linux-arm-kernel, linux-mediatek, linux-renesas-soc, linux-pci,
	linux-kernel
In-Reply-To: <20260506152346.166056-3-18255117159@163.com>

On Wed, May 06, 2026 at 11:23:40PM +0800, Hans Zhang wrote:
> The Cadence LGA (Legacy Architecture IP) PCIe host controller currently
> lacks the mandatory 100 ms delay after link training completes for speeds
> > 5.0 GT/s, as required by PCIe r6.0 sec 6.6.1.
> 
> Add a 'max_link_speed' field to struct cdns_pcie to record the maximum
> supported link speed (or the currently configured speed). In the common
> host layer function cdns_pcie_host_start_link(), after the link has been
> successfully established, call pcie_wait_after_link_train() to insert the
> required delay if max_link_speed > 2.
> 
> Glue drivers must set max_link_speed appropriately (e.g., from the device
> tree property "max-link-speed") to enable the delay.
> 

You need to club those glue driver patches into this one. Otherwise, you'll end
up breaking bisectability.

- Mani

> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
>  drivers/pci/controller/cadence/pcie-cadence-host-common.c | 4 ++++
>  drivers/pci/controller/cadence/pcie-cadence.h             | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> index 2b0211870f02..51376f69d007 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> @@ -14,6 +14,7 @@
>  
>  #include "pcie-cadence.h"
>  #include "pcie-cadence-host-common.h"
> +#include "../../pci.h"
>  
>  #define LINK_RETRAIN_TIMEOUT HZ
>  
> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc *rc,
>  	if (!ret && rc->quirk_retrain_flag)
>  		ret = cdns_pcie_retrain(pcie, pcie_link_up);
>  
> +	if (!ret)
> +		pcie_wait_after_link_train(pcie->max_link_speed);
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
> index 574e9cf4d003..e222b095d2b6 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>   * @ops: Platform-specific ops to control various inputs from Cadence PCIe
>   *       wrapper
>   * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
> + * @max_link_speed: maximum supported link speed
>   */
>  struct cdns_pcie {
>  	void __iomem		             *reg_base;
> @@ -98,6 +99,7 @@ struct cdns_pcie {
>  	struct device_link	             **link;
>  	const  struct cdns_pcie_ops          *ops;
>  	const  struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
> +	int				     max_link_speed;
>  };
>  
>  /**
> -- 
> 2.34.1
> 

-- 
மணிவண்ணன் சதாசிவம்


^ permalink raw reply

* Re: [PATCH v2 1/8] PCI: Add pcie_wait_after_link_train() helper
From: Manivannan Sadhasivam @ 2026-05-06 15:55 UTC (permalink / raw)
  To: Hans Zhang
  Cc: bhelgaas, lpieralisi, kwilczynski, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai, robh, s-vadapalli, linux-omap,
	linux-arm-kernel, linux-mediatek, linux-renesas-soc, linux-pci,
	linux-kernel
In-Reply-To: <20260506152346.166056-2-18255117159@163.com>

On Wed, May 06, 2026 at 11:23:39PM +0800, Hans Zhang wrote:
> PCIe r6.0, sec 6.6.1 (Conventional Reset) requires that for a Downstream
> Port supporting Link speeds greater than 5.0 GT/s, software must wait a
> minimum of 100 ms after Link training completes before sending any
> Configuration Request.
> 
> Introduce a static inline helper pcie_wait_after_link_train() that checks
> the given max_link_speed (2 = 5.0 GT/s, 3 = 8.0 GT/s, etc.) and calls
> msleep(100) only when the speed is greater than 5.0 GT/s. The helper uses
> the existing PCIE_RESET_CONFIG_WAIT_MS macro defined in pci.h.
> 
> This allows multiple host controller drivers to share the same mandatory
> delay without duplicating the logic.
> 
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
>  drivers/pci/pci.h | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 4a14f88e543a..a8705a2a2d85 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h

Since this helper is for host controller drivers, this needs to be defined in
pci-host-common.h.

> @@ -60,6 +60,19 @@ struct pcie_tlp_log;
>   */
>  #define PCIE_RESET_CONFIG_WAIT_MS	100
>  
> +/**
> + * pcie_wait_after_link_train - 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 pcie_wait_after_link_train(int max_link_speed)

pci_host_common_link_train_delay()?

- Mani

-- 
மணிவண்ணன் சதாசிவம்


^ permalink raw reply

* Re: [PATCH 04/13] iio: adc: mediatek: add mt6323 PMIC AUXADC driver
From: Jonathan Cameron @ 2026-05-06 15:46 UTC (permalink / raw)
  To: Roman Vivchar via B4 Relay
  Cc: rva333, David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
	AngeloGioacchino Del Regno, Srinivas Kandagatla,
	Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
	Lee Jones, linux-iio, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260504-mt6323-v1-4-799b58b355ff@protonmail.com>

On Mon, 04 May 2026 21:24:56 +0300
Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:

> From: Roman Vivchar <rva333@protonmail.com>
> 
> The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
> provides support for reading various channels including battery and
> charger voltages, battery and chip temperature, current sensing and
> accessory detection.
> 
> Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
> 
> Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>

A few things inline that might not entirely overlap with other reviews

Also make sure to check:
https://sashiko.dev/#/patchset/20260504-mt6323-v1-0-799b58b355ff%40protonmail.com
It may well have made some stuff up, but in general it does find stuff
humans have missed. I've called out a few more interesting ones inline
(I looked after doing my initial review)


Thanks,

Jonathan

> diff --git a/drivers/iio/adc/mt6323-auxadc.c b/drivers/iio/adc/mt6323-auxadc.c
> new file mode 100644
> index 000000000000..97b4ad4e7b47
> --- /dev/null
> +++ b/drivers/iio/adc/mt6323-auxadc.c

> +/**
> + * struct mt6323_auxadc - Main driver structure
> + * @dev:           Device pointer
> + * @regmap:        Regmap from PWRAP
> + * @lock:          Mutex to serialize AUXADC reading vs configuration
> + */
> +struct mt6323_auxadc {
> +	struct device *dev;
> +	struct regmap *regmap;
> +	struct mutex lock;
> +};

> +static int mt6323_auxadc_check_if_stuck(struct mt6323_auxadc *auxadc)
> +{
> +	int i, ret;
> +	u32 val;
> +
> +	for (i = 0; i < 50; i++) {
> +		ret = regmap_read(auxadc->regmap, MT6323_AUXADC_CON19, &val);
> +		if (ret)
> +			return ret;
> +
> +		if (FIELD_GET(AUXADC_DECI_GDLY_MASK, val)) {
Flip to reduce indent.
		if (!FIELD_GET(AUXADC_DECI_GDLY_MASK, val))
			return 0;

		ret = regmap_read(auxadc->regmap, MT6323_AUXADC_ADC19, &val);
		if (ret)
			return ret;

		if (!FIELD_GET(AUXADC_ADC19_BUSY_MASK, val)) {
			ret = regmap_update_bits(auxadc->regmap,
						 MT6323_AUXADC_CON19,
						 FIELD_PREP(AUXADC_DECI_GDLY_MASK, 3),
// no idea what the magic 3 is. Might need a define to make that clear.
// fine to go a bit long on code like this for readability.  Also rather
// odd for a regmap mask to be made up of some bits of a larger mask.
// rather implies that a field needs breaking up into two.

						 0x0);
			if (ret)
				return ret;
		}
		fsleep(10);
	}

> +			ret = regmap_read(auxadc->regmap, MT6323_AUXADC_ADC19,
> +					  &val);
> +			if (ret)
> +				return ret;
> +
> +			if (!FIELD_GET(AUXADC_ADC19_BUSY_MASK, val)) {
> +				ret = regmap_update_bits(
> +					auxadc->regmap, MT6323_AUXADC_CON19,
> +					FIELD_PREP(AUXADC_DECI_GDLY_MASK, 3),
> +					0x0);
> +				if (ret)
> +					return ret;
> +			}
> +		} else {
> +			return 0;
> +		}
> +
> +		fsleep(10);
> +	}
> +
> +	return -ETIMEDOUT;
> +}
> +
> +static int mt6323_auxadc_request(struct mt6323_auxadc *auxadc,
> +				 unsigned long channel)
> +{
> +	int ret;
> +	u32 pmic_val, adc_val;
> +
> +	if (channel < 9) {
> +		ret = regmap_update_bits(auxadc->regmap, MT6323_AUXADC_CON11,
> +					 AUXADC_VBUF_EN, AUXADC_VBUF_EN);
> +		if (ret)
> +			return ret;
> +
> +		ret = regmap_read(auxadc->regmap, MT6323_AUXADC_CON22,
> +				  &pmic_val);
> +		if (ret)
> +			return ret;
> +
> +		adc_val = FIELD_GET(AUXADC_LOW_CHANNEL_MASK, pmic_val);
> +		adc_val &= ~BIT(channel);
> +
> +		ret = regmap_update_bits(auxadc->regmap, MT6323_AUXADC_CON22,
> +					 AUXADC_LOW_CHANNEL_MASK, adc_val);

Given you have the full register value I'd do regmap_write() rather than
update_bits() that may trigger another read. Matters less if you having
caching enabled.

> +		if (ret)
> +			return ret;
> +
> +		ret = regmap_read(auxadc->regmap, MT6323_AUXADC_CON22,
> +				  &pmic_val);
> +		if (ret)
> +			return ret;
> +
> +		adc_val = FIELD_GET(AUXADC_LOW_CHANNEL_MASK, pmic_val);
> +		adc_val |= BIT(channel);
> +
> +		ret = regmap_update_bits(auxadc->regmap, MT6323_AUXADC_CON22,
> +					 AUXADC_LOW_CHANNEL_MASK, adc_val);

as above for a full write.

		return regmap_update_bits() so we don't have to read on
to see what else happens.  You could drop the else but I think it
does have some value in showing they are of 'equal' likelihood.

> +
> +	} else {
Sashiko points out that we only have channels 0-9 defined, so how do
we get here?

> +		ret = regmap_read(auxadc->regmap, MT6323_AUXADC_CON23,
> +				  &pmic_val);
> +		if (ret)
> +			return ret;
> +
> +		adc_val = FIELD_GET(AUXADC_AUDIO_CHANNEL_MASK, pmic_val);
> +		adc_val &= ~BIT(channel - 9);
> +
> +		ret = regmap_update_bits(auxadc->regmap, MT6323_AUXADC_CON23,
> +					 AUXADC_AUDIO_CHANNEL_MASK, adc_val);
> +		if (ret)
> +			return ret;
> +
> +		ret = regmap_read(auxadc->regmap, MT6323_AUXADC_CON23,
> +				  &pmic_val);
> +		if (ret)
> +			return ret;
> +
> +		adc_val = FIELD_GET(AUXADC_AUDIO_CHANNEL_MASK, pmic_val);
> +		adc_val |= BIT(channel - 9);
> +
> +		ret = regmap_update_bits(auxadc->regmap, MT6323_AUXADC_CON23,
> +					 AUXADC_AUDIO_CHANNEL_MASK, adc_val);
return regmap_update_bits() here as well because we might as well.

> +	}
> +
> +	return ret;
> +}

> +static int mt6323_auxadc_read_raw(struct iio_dev *indio_dev,
> +				  const struct iio_chan_spec *chan, int *val,
> +				  int *val2, long mask)
> +{
> +	struct mt6323_auxadc *auxadc = iio_priv(indio_dev);
> +	int ret, mult = 1;

Move declaration of mult into the scope where it's used.
That will mean this default is near the point of use. Mind you
I'd probably but the assignment in and else to make it even
more obvious.

> +
> +	if (mask == IIO_CHAN_INFO_RAW) {
> +		scoped_guard(mutex, &auxadc->lock)
> +		{
		guard(mutex)(&auxadc->lock);
preferred where not necessary to use scoped_guard() as it
means we don't end up with large code indents.

Though if you did { on the line above.

As sashiko notes, this will trip up compilers anyway due
to an oddity of how scoped_guard() is implemented. You have
to have a return after it.

> +			ret = mt6323_auxadc_check_if_stuck(auxadc);
> +			if (ret)
> +				return ret;
> +
> +			ret = mt6323_auxadc_request(auxadc, chan->address);
> +			if (ret)
> +				return ret;
> +
> +			usleep_range(300, 500);

Smells like fsleep() is appropriate.

> +
> +			ret = mt6323_auxadc_read(auxadc, chan, val);
> +			if (ret)
> +				return ret;
> +			return IIO_VAL_INT;
> +		}
> +	} else if (mask == IIO_CHAN_INFO_SCALE) {
> +		if (chan->channel == MT6323_AUXADC_ISENSE ||
> +		    chan->address == MT6323_AUXADC_BATSNS)
Probably pick channel or address.  Mind you not much point in
setting them both to the same thing (another one sashiko got
that I missed)

> +			mult = 4;
> +
> +		*val = mult * 1800;
> +		*val2 = 32768;
> +
> +		return IIO_VAL_FRACTIONAL;
> +	} else 

{} for all legs if any need it.

> +		return -EINVAL;
> +}
> +
> +static int mt6323_auxadc_init(struct mt6323_auxadc *auxadc)
> +{

> +
> +	ret = regmap_update_bits(auxadc->regmap, MT6323_AUXADC_CON9,
> +				 AUXADC_OSR_MASK,
> +				 FIELD_PREP(AUXADC_OSR_MASK, 3));

I'm going to guess something to do with sampling rate?  That 3 is non
obvious so I'd suggest defines for the values AUXADC_OSR can take.

> +	return ret;
> +}


^ permalink raw reply

* RE: [PATCH v2 1/8] PCI: Add pcie_wait_after_link_train() helper
From: Biju Das @ 2026-05-06 15:34 UTC (permalink / raw)
  To: Hans Zhang, bhelgaas@google.com, lpieralisi@kernel.org,
	kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
	jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
	pali@kernel.org, ryder.lee@mediatek.com,
	jianjun.wang@mediatek.com, Claudiu Beznea, mpillai@cadence.com
  Cc: 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
In-Reply-To: <20260506152346.166056-2-18255117159@163.com>



> -----Original Message-----
> From: Hans Zhang <18255117159@163.com>
> Sent: 06 May 2026 16:24
> Subject: [PATCH v2 1/8] PCI: Add pcie_wait_after_link_train() helper
> 
> PCIe r6.0, sec 6.6.1 (Conventional Reset) requires that for a Downstream Port supporting Link speeds
> greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before
> sending any Configuration Request.
> 
> Introduce a static inline helper pcie_wait_after_link_train() that checks the given max_link_speed (2 =
> 5.0 GT/s, 3 = 8.0 GT/s, etc.) and calls
> msleep(100) only when the speed is greater than 5.0 GT/s. The helper uses the existing
> PCIE_RESET_CONFIG_WAIT_MS macro defined in pci.h.
> 
> This allows multiple host controller drivers to share the same mandatory delay without duplicating the
> logic.
> 
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
>  drivers/pci/pci.h | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 4a14f88e543a..a8705a2a2d85 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -60,6 +60,19 @@ struct pcie_tlp_log;
>   */
>  #define PCIE_RESET_CONFIG_WAIT_MS	100
> 
> +/**
> + * pcie_wait_after_link_train - 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 pcie_wait_after_link_train(int max_link_speed) {
> +	if (max_link_speed > 2)
> +		msleep(PCIE_RESET_CONFIG_WAIT_MS);
> +}

Maybe move this patch to the user??

Cheers,
Biju

> +
>  /* Parameters for the waiting for link up routine */
>  #define PCIE_LINK_WAIT_MAX_RETRIES	10
>  #define PCIE_LINK_WAIT_SLEEP_MS		90
> --
> 2.34.1
> 



^ permalink raw reply

* Re: [PATCH 4/9] dt-bindings: iio: adc: mt6359: Add MT6365 PMIC AuxADC
From: Rob Herring (Arm) @ 2026-05-06 15:32 UTC (permalink / raw)
  To: Louis-Alexis Eyraud
  Cc: AngeloGioacchino Del Regno, Dmitry Torokhov, Nuno Sá, kernel,
	linux-kernel, devicetree, Chen Zhong, Krzysztof Kozlowski,
	linux-arm-kernel, Sen Chu, David Lechner, Jonathan Cameron,
	Matthias Brugger, linux-iio, linux-input, Lee Jones,
	linux-mediatek, Sean Wang, Andy Shevchenko, linux-pm,
	Conor Dooley, Macpaul Lin
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-4-6f43838be92f@collabora.com>


On Wed, 29 Apr 2026 11:44:17 +0200, Louis-Alexis Eyraud wrote:
> Add compatible string for the AuxADC block found on the MT6365 PMIC,
> that is compatible with the one found in MT6359.
> 
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
>  .../bindings/iio/adc/mediatek,mt6359-auxadc.yaml        | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>



^ permalink raw reply

* Re: [PATCH 3/9] dt-bindings: input: mediatek,pmic-keys: Add MT6365 support
From: Rob Herring (Arm) @ 2026-05-06 15:32 UTC (permalink / raw)
  To: Louis-Alexis Eyraud
  Cc: linux-iio, Macpaul Lin, Sean Wang, Jonathan Cameron, kernel,
	Lee Jones, Dmitry Torokhov, Conor Dooley, linux-kernel,
	linux-input, devicetree, Krzysztof Kozlowski, linux-pm,
	Nuno Sá, David Lechner, Matthias Brugger,
	AngeloGioacchino Del Regno, linux-arm-kernel, Sen Chu,
	linux-mediatek, Andy Shevchenko, Chen Zhong
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-3-6f43838be92f@collabora.com>


On Wed, 29 Apr 2026 11:44:16 +0200, Louis-Alexis Eyraud wrote:
> Add compatible string for the pmic keys block found on the MT6365 PMIC,
> that is compatible with the one found in MT6359.
> 
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
>  .../bindings/input/mediatek,pmic-keys.yaml          | 21 +++++++++++++--------
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>



^ permalink raw reply

* Re: [PATCH 2/9] dt-bindings: mfd: mediatek: mt6397: Add MT6365 PMIC support
From: Rob Herring (Arm) @ 2026-05-06 15:32 UTC (permalink / raw)
  To: Louis-Alexis Eyraud
  Cc: AngeloGioacchino Del Regno, Dmitry Torokhov, Krzysztof Kozlowski,
	kernel, Andy Shevchenko, Conor Dooley, linux-kernel,
	Matthias Brugger, Nuno Sá, David Lechner, Macpaul Lin,
	linux-iio, linux-pm, Jonathan Cameron, Sean Wang, Sen Chu,
	linux-mediatek, linux-arm-kernel, Lee Jones, linux-input,
	Chen Zhong, devicetree
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-2-6f43838be92f@collabora.com>


On Wed, 29 Apr 2026 11:44:15 +0200, Louis-Alexis Eyraud wrote:
> MT6365 PMIC is compatible with MT6359, so add the compatible strings
> for the main and sub devices (regulator, rtc, audio codec).
> 
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
>  Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>



^ permalink raw reply

* RE: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link training
From: Biju Das @ 2026-05-06 15:31 UTC (permalink / raw)
  To: Hans Zhang, bhelgaas@google.com, lpieralisi@kernel.org,
	kwilczynski@kernel.org, mani@kernel.org, vigneshr@ti.com,
	jingoohan1@gmail.com, thomas.petazzoni@bootlin.com,
	pali@kernel.org, ryder.lee@mediatek.com,
	jianjun.wang@mediatek.com, Claudiu Beznea, mpillai@cadence.com
  Cc: 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
In-Reply-To: <20260506152346.166056-3-18255117159@163.com>



> -----Original Message-----
> From: linux-arm-kernel <linux-arm-kernel-bounces@lists.infradead.org> On Behalf Of Hans Zhang
> Sent: 06 May 2026 16:24
> Subject: [PATCH v2 2/8] PCI: cadence: LGA: Add max_link_speed field and 100 ms delay after link
> training
> 
> The Cadence LGA (Legacy Architecture IP) PCIe host controller currently lacks the mandatory 100 ms
> delay after link training completes for speeds
> > 5.0 GT/s, as required by PCIe r6.0 sec 6.6.1.
> 
> Add a 'max_link_speed' field to struct cdns_pcie to record the maximum supported link speed (or the
> currently configured speed). In the common host layer function cdns_pcie_host_start_link(), after the
> link has been successfully established, call pcie_wait_after_link_train() to insert the required delay
> if max_link_speed > 2.
> 
> Glue drivers must set max_link_speed appropriately (e.g., from the device tree property "max-link-
> speed") to enable the delay.
> 
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
>  drivers/pci/controller/cadence/pcie-cadence-host-common.c | 4 ++++
>  drivers/pci/controller/cadence/pcie-cadence.h             | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> index 2b0211870f02..51376f69d007 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
> @@ -14,6 +14,7 @@
> 
>  #include "pcie-cadence.h"
>  #include "pcie-cadence-host-common.h"
> +#include "../../pci.h"
> 
>  #define LINK_RETRAIN_TIMEOUT HZ
> 
> @@ -115,6 +116,9 @@ int cdns_pcie_host_start_link(struct cdns_pcie_rc *rc,
>  	if (!ret && rc->quirk_retrain_flag)
>  		ret = cdns_pcie_retrain(pcie, pcie_link_up);
> 
> +	if (!ret)
> +		pcie_wait_after_link_train(pcie->max_link_speed);
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(cdns_pcie_host_start_link);
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-
> cadence.h
> index 574e9cf4d003..e222b095d2b6 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -86,6 +86,7 @@ struct cdns_plat_pcie_of_data {
>   * @ops: Platform-specific ops to control various inputs from Cadence PCIe
>   *       wrapper
>   * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
> + * @max_link_speed: maximum supported link speed

Maximum to make consistent with other comments?


>   */
>  struct cdns_pcie {
>  	void __iomem		             *reg_base;
> @@ -98,6 +99,7 @@ struct cdns_pcie {
>  	struct device_link	             **link;
>  	const  struct cdns_pcie_ops          *ops;
>  	const  struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
> +	int				     max_link_speed;

unsigned int as speed cannot be negative??

Cheers,
Biju

>  };
> 
>  /**
> --
> 2.34.1
> 



^ permalink raw reply

* Re: [PATCH 1/9] dt-bindings: mfd: mediatek: mt6397: Add rtc for MT6359
From: Rob Herring (Arm) @ 2026-05-06 15:31 UTC (permalink / raw)
  To: Louis-Alexis Eyraud
  Cc: Sen Chu, Macpaul Lin, Sean Wang, Lee Jones, linux-mediatek,
	Jonathan Cameron, devicetree, kernel, Nuno Sá, linux-input,
	Conor Dooley, David Lechner, AngeloGioacchino Del Regno,
	linux-arm-kernel, Chen Zhong, linux-pm, Matthias Brugger,
	Dmitry Torokhov, linux-iio, Krzysztof Kozlowski, Andy Shevchenko,
	linux-kernel
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-1-6f43838be92f@collabora.com>


On Wed, 29 Apr 2026 11:44:14 +0200, Louis-Alexis Eyraud wrote:
> The rtc block of MT6359 PMIC is compatible with the one found in MT6358
> but this compatibility was never expressed in the dt-bindings, so add
> the missing compatible string for the rtc subnode.
> 
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
>  Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>



^ permalink raw reply

* [PATCH v2 3/8] PCI: cadence: HPA: Add 100 ms delay after link training
From: Hans Zhang @ 2026-05-06 15:23 UTC (permalink / raw)
  To: bhelgaas, lpieralisi, kwilczynski, mani, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai
  Cc: robh, s-vadapalli, linux-omap, linux-arm-kernel, linux-mediatek,
	linux-renesas-soc, linux-pci, linux-kernel, Hans Zhang
In-Reply-To: <20260506152346.166056-1-18255117159@163.com>

The Cadence HPA (High Performance Architecture IP) specific link setup
function cdns_pcie_hpa_host_link_setup() waits for the link to come up
but does not implement the required 100 ms delay after link training
completes for speeds > 5.0 GT/s (PCIe r6.0 sec 6.6.1).

Add a call to pcie_wait_after_link_train() immediately after the link is
confirmed to be up, using the max_link_speed previously stored in struct
cdns_pcie. This ensures compliance with the specification regardless of
whether the HPA or LGA path is used.

Signed-off-by: Hans Zhang <18255117159@163.com>
---
 drivers/pci/controller/cadence/pcie-cadence-host-hpa.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c
index 0f540bed58e8..62e939906785 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c
@@ -15,6 +15,7 @@
 
 #include "pcie-cadence.h"
 #include "pcie-cadence-host-common.h"
+#include "../../pci.h"
 
 static u8 bar_aperture_mask[] = {
 	[RP_BAR0] = 0x3F,
@@ -304,6 +305,8 @@ int cdns_pcie_hpa_host_link_setup(struct cdns_pcie_rc *rc)
 	ret = cdns_pcie_host_wait_for_link(pcie, cdns_pcie_hpa_link_up);
 	if (ret)
 		dev_dbg(dev, "PCIe link never came up\n");
+	else
+		pcie_wait_after_link_train(pcie->max_link_speed);
 
 	return ret;
 }
-- 
2.34.1



^ permalink raw reply related

* [PATCH v2 5/8] PCI: dwc: Use common pcie_wait_after_link_train() helper
From: Hans Zhang @ 2026-05-06 15:23 UTC (permalink / raw)
  To: bhelgaas, lpieralisi, kwilczynski, mani, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai
  Cc: robh, s-vadapalli, linux-omap, linux-arm-kernel, linux-mediatek,
	linux-renesas-soc, linux-pci, linux-kernel, Hans Zhang
In-Reply-To: <20260506152346.166056-1-18255117159@163.com>

The DWC driver already implements the 100 ms delay required by PCIe
r6.0 sec 6.6.1 by checking pci->max_link_speed and calling msleep(100).

Replace the open-coded msleep() with the new common helper
pcie_wait_after_link_train() to reduce code duplication and improve
maintainability. No functional change intended.

Signed-off-by: Hans Zhang <18255117159@163.com>
---
 drivers/pci/controller/dwc/pcie-designware.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index c11cf61b8319..e5808d4b3867 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -799,13 +799,7 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
 		return -ETIMEDOUT;
 	}
 
-	/*
-	 * As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link
-	 * speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms
-	 * after Link training completes before sending a Configuration Request.
-	 */
-	if (pci->max_link_speed > 2)
-		msleep(PCIE_RESET_CONFIG_WAIT_MS);
+	pcie_wait_after_link_train(pci->max_link_speed);
 
 	offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
 	val = dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKSTA);
-- 
2.34.1



^ permalink raw reply related

* [PATCH v2 8/8] PCI: rzg3s-host: Add 100 ms delay after link training
From: Hans Zhang @ 2026-05-06 15:23 UTC (permalink / raw)
  To: bhelgaas, lpieralisi, kwilczynski, mani, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai
  Cc: robh, s-vadapalli, linux-omap, linux-arm-kernel, linux-mediatek,
	linux-renesas-soc, linux-pci, linux-kernel, Hans Zhang
In-Reply-To: <20260506152346.166056-1-18255117159@163.com>

The Renesas RZ/G3S PCIe host driver currently does not enforce the
mandatory 100 ms delay after link training completes for speeds > 5.0 GT/s,
required by PCIe r6.0 sec 6.6.1.

The driver already has a 'max_link_speed' field (derived from the device
tree). Add a call to pcie_wait_after_link_train() in
rzg3s_pcie_host_init() after reading the link status, ensuring that the
delay is applied before any Configuration Request is sent downstream.

Signed-off-by: Hans Zhang <18255117159@163.com>
---
 drivers/pci/controller/pcie-rzg3s-host.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/pcie-rzg3s-host.c b/drivers/pci/controller/pcie-rzg3s-host.c
index d86e7516dcc2..6ab59c5464cf 100644
--- a/drivers/pci/controller/pcie-rzg3s-host.c
+++ b/drivers/pci/controller/pcie-rzg3s-host.c
@@ -1390,6 +1390,8 @@ static int rzg3s_pcie_host_init(struct rzg3s_pcie_host *host)
 	val = readl_relaxed(host->axi + RZG3S_PCI_PCSTAT2);
 	dev_info(host->dev, "PCIe link status [0x%x]\n", val);
 
+	pcie_wait_after_link_train(host->max_link_speed);
+
 	return 0;
 
 config_deinit_post:
-- 
2.34.1



^ permalink raw reply related

* [PATCH v2 7/8] PCI: mediatek-gen3: Add 100 ms delay after link training
From: Hans Zhang @ 2026-05-06 15:23 UTC (permalink / raw)
  To: bhelgaas, lpieralisi, kwilczynski, mani, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai
  Cc: robh, s-vadapalli, linux-omap, linux-arm-kernel, linux-mediatek,
	linux-renesas-soc, linux-pci, linux-kernel, Hans Zhang
In-Reply-To: <20260506152346.166056-1-18255117159@163.com>

The MediaTek Gen3 PCIe host driver lacks the required 100 ms delay after
link training completes for speeds > 5.0 GT/s, as specified in PCIe r6.0
sec 6.6.1.

The driver already stores max_link_speed (from the device tree). After
mtk_pcie_startup_port() successfully brings up the link, call
pcie_wait_after_link_train() to comply with the specification.

Signed-off-by: Hans Zhang <18255117159@163.com>
---
 drivers/pci/controller/pcie-mediatek-gen3.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index b0accd828589..7c5f2ba7157b 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -570,6 +570,8 @@ static int mtk_pcie_startup_port(struct mtk_gen3_pcie *pcie)
 		goto err_power_down_device;
 	}
 
+	pcie_wait_after_link_train(pcie->max_link_speed);
+
 	return 0;
 
 err_power_down_device:
-- 
2.34.1



^ permalink raw reply related

* [PATCH v2 6/8] PCI: aardvark: Add 100 ms delay after link training
From: Hans Zhang @ 2026-05-06 15:23 UTC (permalink / raw)
  To: bhelgaas, lpieralisi, kwilczynski, mani, vigneshr, jingoohan1,
	thomas.petazzoni, pali, ryder.lee, jianjun.wang,
	claudiu.beznea.uj, mpillai
  Cc: robh, s-vadapalli, linux-omap, linux-arm-kernel, linux-mediatek,
	linux-renesas-soc, linux-pci, linux-kernel, Hans Zhang
In-Reply-To: <20260506152346.166056-1-18255117159@163.com>

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



^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox