mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans Zhang <18255117159@163.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/7] PCI: Replace short msleep() calls with more precise delay functions
Date: Mon, 25 Aug 2025 00:05:26 +0800	[thread overview]
Message-ID: <155f9f4f-45e4-45ea-85c2-de67115bd12c@163.com> (raw)
In-Reply-To: <20250822164638.GA687302@bhelgaas>



On 2025/8/23 00:46, Bjorn Helgaas wrote:
> On Fri, Aug 22, 2025 at 11:59:01PM +0800, Hans Zhang wrote:
>> This series replaces short msleep() calls (less than 20ms) with more
>> precise delay functions (fsleep() and usleep_range()) throughout the
>> PCI subsystem.
>>
>> The msleep() function with small values can sleep longer than intended
>> due to timer granularity, which can cause unnecessary delays in PCI
>> operations such as link status checking, reset handling, and hotplug
>> operations.
>>
>> These changes:
>> - Use fsleep() for delays that require precise timing (1-2ms).
>> - Use usleep_range() for delays that can benefit from a small range.
>> - Add #defines for all delay values with references to PCIe specifications.
>> - Update comments to reference the latest PCIe r7.0 specification.
>>
>> This improves the responsiveness of PCI operations while maintaining
>> compliance with PCIe specifications.
> 

Dear Bjron,

Thank you very much for your reply.


> I would split this a little differently:
> 
>    - Add #defines for values from PCIe base spec.  Make the #define
>      value match the spec value.  If there's adjustment, e.g.,

Ok. For patch 0001, I will modify it again.

>      doubling, do it at the sleep site.  Adjustment like this seems a
>      little paranoid since the spec should already have some margin
>      built into it.

Can I understand that it's enough to just use fsleep(1000) here?

patch 0001 I intend to modify it as follows:

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b0f4d98036cd..fb4aff520f64 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4963,11 +4963,8 @@ void pci_reset_secondary_bus(struct pci_dev *dev)
         ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
         pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);

-       /*
-        * PCI spec v3.0 7.6.4.2 requires minimum Trst of 1ms.  Double
-        * this to 2ms to ensure that we meet the minimum requirement.
-        */
-       msleep(2);
+       /* Wait for the reset to take effect */
+       fsleep(PCI_T_RST_SEC_BUS_DELAY_US);

         ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
         pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 34f65d69662e..9d38ef26c6a9 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -60,6 +60,9 @@ struct pcie_tlp_log;
  #define PCIE_LINK_WAIT_MAX_RETRIES     10
  #define PCIE_LINK_WAIT_SLEEP_MS                90

+/* PCIe r7.0, sec 7.5.1.3.13, requires minimum Trst of 1ms */
+#define PCI_T_RST_SEC_BUS_DELAY_US     1000
+
  /* Message Routing (r[2:0]); PCIe r6.0, sec 2.2.8 */
  #define PCIE_MSG_TYPE_R_RC     0
  #define PCIE_MSG_TYPE_R_ADDR   1



> 
>    - Change to fsleep() (or usleep_range()) in separate patch.  There
>      might be discussion about these changes, but the #defines are
>      desirable regardless.
> 
> I'm personally dubious about the places you used usleep_range().
> These are low-frequency paths (rcar PHY ready, brcmstb link up,
> hotplug command completion, DPC recover) that don't seem critical.  I
> think they're all using made-up delays that don't come from any spec
> or hardware requirement anyway.  I think it's hard to make an argument
> for precision here.

My initial understanding was the same. There was no need for such 
precision here. Then msleep will be retained, but only modified to #defines?

If you think it's unnecessary, I will discard the remaining patches.

Best regards,
Hans



  reply	other threads:[~2025-08-24 16:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22 15:59 Hans Zhang
2025-08-22 15:59 ` [PATCH v2 1/7] PCI: Replace msleep(2) with fsleep() for precise delay Hans Zhang
2025-08-22 15:59 ` [PATCH v2 2/7] PCI: Replace msleep(1) with fsleep() for precise link status checking Hans Zhang
2025-08-22 15:59 ` [PATCH v2 3/7] PCI: rcar-host: Replace msleep(1) with fsleep() for precise speed change monitoring Hans Zhang
2025-08-22 15:59 ` [PATCH v2 4/7] PCI: brcmstb: Replace msleep(5) with usleep_range() for precise link up checking Hans Zhang
2025-08-22 15:59 ` [PATCH v2 5/7] PCI: rcar: Replace msleep(5) with usleep_range() for precise PHY ready checking Hans Zhang
2025-08-22 15:59 ` [PATCH v2 6/7] PCI: pciehp: Replace msleep(10) with usleep_range() for precise delays Hans Zhang
2025-08-22 15:59 ` [PATCH v2 7/7] PCI/DPC: Replace msleep(10) with usleep_range() for precise RP busy checking Hans Zhang
2025-08-22 16:46 ` [PATCH v2 0/7] PCI: Replace short msleep() calls with more precise delay functions Bjorn Helgaas
2025-08-24 16:05   ` Hans Zhang [this message]
2025-08-25 20:30     ` Bjorn Helgaas
2025-08-26 17:07   ` 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=155f9f4f-45e4-45ea-85c2-de67115bd12c@163.com \
    --to=18255117159@163.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®