All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "Konrad Dybcio" <konrad.dybcio@linaro.org>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Marijn Suijten" <marijn.suijten@somainline.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Johan Hovold" <johan+linaro@kernel.org>
Subject: Re: [PATCH] PCI: dwc: Use the correct sleep function in wait_for_link
Date: Thu, 15 Feb 2024 11:02:58 -0600	[thread overview]
Message-ID: <20240215170258.GA1292702@bhelgaas> (raw)
In-Reply-To: <7611f6f9-a021-4bbd-bc71-5363af3d9391@intel.com>

On Thu, Feb 15, 2024 at 02:35:13PM +0100, Alexander Lobakin wrote:
> From: Konrad Dybcio <konrad.dybcio@linaro.org>
> Date: Thu, 15 Feb 2024 11:39:31 +0100
> 
> > According to [1], msleep should be used for large sleeps, such as the
> > 100-ish ms one in this function. Comply with the guide and use it.
> > 
> > [1] https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
> > 
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> > ---
> > Tested on Qualcomm SC8280XP CRD
> > ---
> >  drivers/pci/controller/dwc/pcie-designware.c | 2 +-
> >  drivers/pci/controller/dwc/pcie-designware.h | 3 +--
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> > index 250cf7f40b85..abce6afceb91 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -655,7 +655,7 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
> >  		if (dw_pcie_link_up(pci))
> >  			break;
> >  
> > -		usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
> > +		msleep(LINK_WAIT_MSLEEP_MAX);
> 
> Just use fsleep(LINK_WAIT_USLEEP_MAX) and let the kernel decide which
> function to pick.

Odd.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/timers-howto.rst?id=v6.7#n114
mentions fsleep() (with no real guidance about when to use it), but
https://www.kernel.org/doc/Documentation/timers/timers-howto.txt 
seems to be a stale copy from 2017, before fsleep() was added.  I
emailed helpdesk@kernel.org to see if the stale content can be
removed.

I do think fsleep() should be more widely used.

> >  /* Parameters for the waiting for link up routine */
> >  #define LINK_WAIT_MAX_RETRIES		10
> > -#define LINK_WAIT_USLEEP_MIN		90000
> > -#define LINK_WAIT_USLEEP_MAX		100000
> > +#define LINK_WAIT_MSLEEP_MAX		100

Since you're touching this anyway, it would be helpful to include the
units on the timeout.

USLEEP/MSLEEP is definitely a hint, but I think the "SLEEP" part
suggests something about atomic/non-atomic context and isn't relevant
to the time interval itself, and something like "TIMEOUT" would be
better.

I think an explicit "_US" or "_MS" would better indicate the units.

This is turning into a long tangent, but I'm not a huge fan of the
LINK_WAIT_* pattern where I have to look up the code that uses
LINK_WAIT_MAX_RETRIES and LINK_WAIT_USLEEP_MAX and do the math to see
what the actual timeout is.  Obviously not fodder for *this* patch.

Bjorn

  reply	other threads:[~2024-02-15 17:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 10:39 [PATCH] PCI: dwc: Use the correct sleep function in wait_for_link Konrad Dybcio
2024-02-15 13:35 ` Alexander Lobakin
2024-02-15 17:02   ` Bjorn Helgaas [this message]
2024-02-15 17:46     ` Konrad Dybcio
2024-02-20  8:23       ` Johan Hovold
2024-02-20 23:00         ` Bjorn Helgaas
2024-02-21 12:40           ` Johan Hovold
2024-02-15 14:17 ` Serge Semin
2024-02-15 17:47   ` Konrad Dybcio
2024-02-15 14:51 ` Kuppuswamy Sathyanarayanan
2024-02-15 17:48   ` Konrad Dybcio

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=20240215170258.GA1292702@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=bhelgaas@google.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=jingoohan1@gmail.com \
    --cc=johan+linaro@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=marijn.suijten@somainline.org \
    --cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.