public inbox for cip-dev@lists.cip-project.org
 help / color / mirror / Atom feed
From: Claudiu Beznea <claudiu.beznea@tuxon.dev>
To: Pavel Machek <pavel@nabladev.com>
Cc: nobuhiro.iwamatsu.x90@mail.toshiba, cip-dev@lists.cip-project.org
Subject: Re: [PATCH 5.10.y-cip 09/28] PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value
Date: Wed, 25 Mar 2026 10:36:11 +0200	[thread overview]
Message-ID: <02bf97da-a22e-4849-bd33-5bcd9641372b@tuxon.dev> (raw)
In-Reply-To: <acJabrcQAzuYQzi2@duo.ucw.cz>

Hi, Pavel,

On 3/24/26 11:33, Pavel Machek wrote:
> Hi!
> 
>> commit d5ceb9496c565eb5763c127c6eb2d2b3068ab1df upstream.
>>
>> Add the PCIE_RESET_CONFIG_DEVICE_WAIT_MS macro to define the minimum
>> waiting time between exit from a conventional reset and sending the
>> first configuration request to the device.
>>
>> As described in PCIe r6.0, sec 6.6.1 <Conventional Reset>, there are two
>> different use cases of the value:
>>
>>     - "With a Downstream Port that does not support Link speeds greater
>>       than 5.0 GT/s, software must wait a minimum of 100 ms following exit
>>       from a Conventional Reset before sending a Configuration Request to
>>       the device immediately below that Port."
>>
>>     - "With 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 to the device
>>       immediately below that Port."
>>
>> [kwilczynski: commit log]
>> Link: https://lore.kernel.org/linux-pci/20240328091835.14797-21-minda.chen@starfivetech.com
>> Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com>
>> Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>> Reviewed-by: Mason Huo <mason.huo@starfivetech.com>
>> [claudiu.beznea: fixed conflict by keeping only the definition for
>>   PCIE_RESET_CONFIG_DEVICE_WAIT_MS]
> 
> I don't understand the message here. Upstream patch seems to be
> identical to this one, but context differs.

Yes, the commit d5ceb9496c565eb5763c127c6eb2d2b3068ab1df ("PCI: Add 
PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value") and this patch are 
identical, but, cherry-picking commit d5ceb9496c565eb5763c127c6eb2d2b3068ab1df 
on top of v5.10.249-cip69 give the following conflict:

#define PCI_VSEC_ID_INTEL_TBT   0x1234  /* Thunderbolt */ 

  

<<<<<<< HEAD 

======= 

#define PCIE_LINK_RETRAIN_TIMEOUT_MS    1000 

  

/* Power stable to PERST# inactive from PCIe card Electromechanical Spec */ 

#define PCIE_T_PVPERL_MS                100 

  

/* 

  * PCIe r6.0, sec 5.3.3.2.1 <PME Synchronization> 

  * Recommends 1ms to 10ms timeout to check L2 ready. 

  */ 

#define PCIE_PME_TO_L2_TIMEOUT_US       10000 

  

/* 

  * PCIe r6.0, sec 6.6.1 <Conventional Reset> 

  * 

  * - "With a Downstream Port that does not support Link speeds greater 

  *    than 5.0 GT/s, software must wait a minimum of 100 ms following exit 

  *    from a Conventional Reset before sending a Configuration Request to 

  *    the device immediately below that Port." 

  * 

  * - "With 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 to the device 

  *    immediately below that Port." 

  */ 

#define PCIE_RESET_CONFIG_DEVICE_WAIT_MS        100 

  

 >>>>>>> d5ceb9496c56 (PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time 
value)
extern const unsigned char pcie_link_speed[]; 

extern bool pci_early_dump; 


So, I had to manually adjust it and keep only the 
PCIE_RESET_CONFIG_DEVICE_WAIT_MS define along with its documentation.

Thank you,
Claudiu


  reply	other threads:[~2026-03-25  8:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11 11:03 [PATCH 5.10.y-cip 00/28] Add RZ/G3S PCIe support Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 01/28] soc: renesas: Add SYSC driver for Renesas RZ family Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 02/28] soc: renesas: rz-sysc: Move RZ/G3S SoC detection to the SYSC driver Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 03/28] mfd: syscon: Add of_syscon_register_regmap() API Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 04/28] soc: renesas: rz-sysc: Add syscon/regmap support Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 05/28] soc: renesas: rz-sysc: Populate readable_reg/writeable_reg in regmap config Claudiu
2026-03-24  9:26   ` Pavel Machek
2026-03-25  8:35     ` Claudiu Beznea
2026-03-11 11:03 ` [PATCH 5.10.y-cip 06/28] clk: renesas: r9a08g045: Add PCIe clocks and resets Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 07/28] lib/bitmap: add bitmap_{read,write}() Claudiu
2026-03-24  9:29   ` Pavel Machek
2026-03-25  8:37     ` Claudiu Beznea
2026-03-11 11:03 ` [PATCH 5.10.y-cip 08/28] genirq/msi: Silence 'set affinity failed' warning Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 09/28] PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value Claudiu
2026-03-24  9:33   ` Pavel Machek
2026-03-25  8:36     ` Claudiu Beznea [this message]
2026-03-11 11:03 ` [PATCH 5.10.y-cip 10/28] PCI: Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to PCIE_RESET_CONFIG_WAIT_MS Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 11/28] PCI: Move link up wait time and max retries macros to pci.h Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 12/28] reset: make shared pulsed reset controls re-triggerable Claudiu
2026-03-24  9:37   ` Pavel Machek
2026-03-25  8:35     ` Claudiu Beznea
2026-03-11 11:03 ` [PATCH 5.10.y-cip 13/28] reset: Add reset_control_bulk API Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 14/28] of: Add cleanup.h based auto release via __free(device_node) markings Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 15/28] of/irq: Allow matching of an interrupt-map local to an interrupt controller Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 16/28] of/irq: Update the out_irq->np before returning success Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 17/28] dt-bindings: PCI: Add Renesas RZ/G3S PCIe controller binding Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 18/28] PCI: Add Renesas RZ/G3S host controller driver Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 19/28] PCI: rzg3s-host: Initialize MSI status bitmap before use Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 20/28] PCI: rzg3s-host: Use pci_generic_config_write() for the root bus Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 21/28] PCI: rzg3s-host: Drop the lock on RZG3S_PCI_MSIRS and RZG3S_PCI_PINTRCVIS Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 22/28] PCI: rzg3s-host: Fix device node reference leak in rzg3s_pcie_host_parse_port() Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 23/28] arm64: dts: renesas: r9a08g045: Enable SYS node Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 24/28] arm64: dts: renesas: r9a08g045: Use syscon compatible for the system controller Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 25/28] arm64: dts: renesas: r9a08g045: Add PCIe node Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 26/28] arm64: dts: renesas: rzg3s-smarc-som: Add PCIe reference clock Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 27/28] arm64: dts: renesas: rzg3s-smarc: Enable PCIe Claudiu
2026-03-11 11:03 ` [PATCH 5.10.y-cip 28/28] arm64: defconfig: Enable PCIe for the Renesas RZ/G3S SoC Claudiu

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=02bf97da-a22e-4849-bd33-5bcd9641372b@tuxon.dev \
    --to=claudiu.beznea@tuxon.dev \
    --cc=cip-dev@lists.cip-project.org \
    --cc=nobuhiro.iwamatsu.x90@mail.toshiba \
    --cc=pavel@nabladev.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