Message ID | 20240215-topic-pci_sleep-v1-1-7ac79ac9739a@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-66682-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:b825:b0:106:860b:bbdd with SMTP id da37csp330729dyb; Thu, 15 Feb 2024 03:30:56 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUPS8tMXZRin+3SJ7KWfef4uQrkvWmZ7tmFt3sy2O6SeeC9NklDxvAr57Q4T9x5H+V7SqoMGY2TM0/RBdw0rOAl9EXEcw== X-Google-Smtp-Source: AGHT+IHPlv/9H+itxDHtGAbcR+dhIin+4hSLAKMju3/PYP/GshoLuqOtLD4K/NejEQsFcix3kZ4v X-Received: by 2002:a05:6a20:c78e:b0:1a0:762c:7c9f with SMTP id hk14-20020a056a20c78e00b001a0762c7c9fmr1705805pzb.36.1707996655984; Thu, 15 Feb 2024 03:30:55 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707996655; cv=pass; d=google.com; s=arc-20160816; b=svkxprPB9PVS8cN4e+vFGVDfPX9ftaUiT9o5/epHCxqsBGyziPXjnkAURdL42ogsnC 3TTTbDNGsLJ5FAdzcs0H7PCLYE/j6q0pUiO8VBsTOKjAOQeZoSy0KzMOp6WyAZugcVwu RKJb6NY9ssv31WrXdaxr2dLakakNBOe4lN99bnvdtg9gUTI9t2GHrAceIYnHa5gkcb1q 6ueJSb7/eNTL3Au6lp4AWj5p3AiJQcWfVxXN8WYTl9hi3vGGgn9oderBWv5+vcwz3SLI PJymPrQDk2PkovVuhbWh9zLGUpV2Y1KkThiBHjnME3TgAutyYobmSDm7Lpmlg2YdQpQT y7pQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:message-id:content-transfer-encoding:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:subject:date :from:dkim-signature; bh=QD1gYi0qromzk9mvV/EvG6oZSGwvLtBgJUyJlsYq8VE=; fh=2qpjgUBYoEjyiWrGFMerNoPns+7hm4jpox/UGSKOHvk=; b=wwk55NnyzkOl5ZCHKMPoq6YmujrdO4n0F2qXIiMBkOY3zqbq0rpMKA2XcX9tnvWJ7C JyllAD35iM8366WuWBapk9wvF552E6zvOopfVukVGcmY8W4BCrHp4pHivVIXe3+6j/W9 PYU0PZnPr+7MGhiQBZ5VGj54FWEvykJ9hdg8+C91IuHl9Pii/fdBSEXPRyBcATBGKbnu 369EO94Si9ioUCpug1SOqFz8khETvQNsw5nKeWrcjvDxXxjrskui+Tn6rVFFjmzL5YbR RXx7co8eLzWfVNA4Ffim26n8zNVZqF1enWyiwdiQ9WYt/tkmWVjkpH+L+XCc6KErB+Rq rqoQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="P/94mqqZ"; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-66682-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-66682-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id g12-20020a056a0023cc00b006e0f438e98fsi1014039pfc.208.2024.02.15.03.30.55 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 03:30:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-66682-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="P/94mqqZ"; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-66682-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-66682-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 8A585B375DF for <ouuuleilei@gmail.com>; Thu, 15 Feb 2024 10:51:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0B764131733; Thu, 15 Feb 2024 10:39:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="P/94mqqZ" Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 72E6F130E2D for <linux-kernel@vger.kernel.org>; Thu, 15 Feb 2024 10:39:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707993585; cv=none; b=s0D7QySkqLpJLHgbYx4VFlykKuchu9K3At3UNHOpofZ1HKga+kdrvOMJVPNwRtEuQwcztdDjVcyDItQCafYZxuD41xTbeH//gIjduzWKFWjJAu7dqCGD4eS0S3PuW5s4A1+GptjJVIdELNVSCxxR0shrhshgtPFCagD5AP/vK4g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707993585; c=relaxed/simple; bh=gOy17tuDWMpGGIAMdxDlvpGP151b/AW6UzIQXHsI/1s=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=RHKSLqYtJAKQFZnWno4vddKK1dTWzFwbggg+Bt4QOuHHJXk6Dfqn2bN/86r4pIlinEMSoUL9D93+YnLqHLMeqN3nmtyltvhrIMwGA01W5WjoI1dwP81yA4VPPWTIzdY719T+zNInIqsMWoKXySSMUgLZ6ic2VnepPjVqiMN6rSM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=P/94mqqZ; arc=none smtp.client-ip=209.85.218.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a3d0d26182dso71245866b.1 for <linux-kernel@vger.kernel.org>; Thu, 15 Feb 2024 02:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1707993581; x=1708598381; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=QD1gYi0qromzk9mvV/EvG6oZSGwvLtBgJUyJlsYq8VE=; b=P/94mqqZpOlV0S+C/dhlV6Or0Yy9ETQVk9tEGptEEObCaMI5iwwajekpPUjDtaA2RL Ip7XWGE+qmN2D5J2HLQqd72nfAydwhtrHWTsVora5PHe9zzJhMIeryJvec3sdVqJBv+W 4lAJM2gCFqCMWrEHxza45F+eiJQE3Ab/D2IIleN+N5+BwboEQlJDyykY/0/imUdHSnu5 brNnEhFcSik+z4EAiwFALOoyAHWhZ7T5Vr8TZ9im4UPvxDiCRq86QXCeAIswm1cpEwZ8 mzV8QBKT+mnewQiSitSY7rEOkqGaB9icP1gi8c53PwtliqIb6BaQs3hvZdDT49rQ2pVH p4NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707993581; x=1708598381; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QD1gYi0qromzk9mvV/EvG6oZSGwvLtBgJUyJlsYq8VE=; b=A/z6L3xj7sUSUqicBIQUrcfZ0hwcSlM8pXC91//N/ErFCPQvAu1BwrR3mnV6x//5Sa oXVTiyDYE6SgSRCeYlvFQY8ZiS6y8K8fGk2Pze3mPHasyW7Qrp+6kSMxqXwUCbVnQxWx ZIF1lkG43ICIaDvxwyKEuOsgQQ7rcG5YRhsfhQgQAzvxO1vdHACj7DS9qxPrfz9M5cWP KVS523f7cJPWZ1Cicn6aiICWrGu7ZD2az/a8UWRDQ5tYiazhOxKmJ850uDbx+SMFX23Q fZlBZWnC4I13Gd5RP4v/CvFyX+li3+oX0mH6vcHEQfe3ambE0+bxRfXOiX8MQxOaL8WO D2QQ== X-Forwarded-Encrypted: i=1; AJvYcCUATfDWKJtd3WuvSrM00H/xtz5LnEzCOqUxSSIDtsZMOxqF0Qoe0FLBi5n25pdDzFRNnWLn2U+Dzd5rNHKHpt1WNgGjINLUpy+ct6Na X-Gm-Message-State: AOJu0YzUz9VP/lroQ1MCNxI+rVggKgIUaSIr5qoNGpx/MWly5yGTm/u8 4X/XiTHNPwP0zfIfvWHo82MeSI8qerW70yYBDw0RdG3D8vSlrABJq4P7oztYwbQ= X-Received: by 2002:a17:906:d9c8:b0:a3d:4ac5:2012 with SMTP id qk8-20020a170906d9c800b00a3d4ac52012mr874808ejb.25.1707993581699; Thu, 15 Feb 2024 02:39:41 -0800 (PST) Received: from [10.167.154.1] (078088045141.garwolin.vectranet.pl. [78.88.45.141]) by smtp.gmail.com with ESMTPSA id qo3-20020a170907874300b00a3da5bf6aa5sm194070ejc.211.2024.02.15.02.39.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 02:39:40 -0800 (PST) From: Konrad Dybcio <konrad.dybcio@linaro.org> Date: Thu, 15 Feb 2024 11:39:31 +0100 Subject: [PATCH] PCI: dwc: Use the correct sleep function in wait_for_link Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240215-topic-pci_sleep-v1-1-7ac79ac9739a@linaro.org> X-B4-Tracking: v=1; b=H4sIAOLpzWUC/x2N0QqDMAwAf0XyvEBbp4i/ImO0XaqBUkuzDUH89 4U93sFxJwg1JoG5O6HRl4X3omBvHcTNl5WQX8rgjLsbZwd875Uj1shPyUQV+3GyZvI2hTGBVsE LYWi+xE278slZZW2U+Phvlsd1/QAqX4L1dgAAAA== To: Jingoo Han <jingoohan1@gmail.com>, Gustavo Pimentel <gustavo.pimentel@synopsys.com>, Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>, Lorenzo Pieralisi <lpieralisi@kernel.org>, =?utf-8?q?Krzysztof_Wilczy=C5=84?= =?utf-8?q?ski?= <kw@linux.com>, Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com> Cc: Marijn Suijten <marijn.suijten@somainline.org>, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Johan Hovold <johan+linaro@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org> X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1707993579; l=1741; i=konrad.dybcio@linaro.org; s=20230215; h=from:subject:message-id; bh=gOy17tuDWMpGGIAMdxDlvpGP151b/AW6UzIQXHsI/1s=; b=gVAzF0+FSbsq0Gk2mQfYr0dVV9Vx0Uy24zbpDOkYsC02CTjGY54YpNSlrdkowpJL8FbwhfUwX 7Haxlo8bEJdDsDLu3q4WGDsbD/ejzwIYoYQ1k7lPjQH5weiHmIQopYE X-Developer-Key: i=konrad.dybcio@linaro.org; a=ed25519; pk=iclgkYvtl2w05SSXO5EjjSYlhFKsJ+5OSZBjOkQuEms= X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790964301466469474 X-GMAIL-MSGID: 1790964301466469474 |
Series |
PCI: dwc: Use the correct sleep function in wait_for_link
|
|
Commit Message
Konrad Dybcio
Feb. 15, 2024, 10:39 a.m. UTC
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(-)
---
base-commit: 26d7d52b6253574d5b6fec16a93e1110d1489cef
change-id: 20240215-topic-pci_sleep-368108a1fb6f
Best regards,
Comments
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. > } > > if (retries >= LINK_WAIT_MAX_RETRIES) { > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h > index 26dae4837462..3f145d6a8a31 100644 > --- a/drivers/pci/controller/dwc/pcie-designware.h > +++ b/drivers/pci/controller/dwc/pcie-designware.h > @@ -63,8 +63,7 @@ > > /* 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 > > /* Parameters for the waiting for iATU enabled routine */ > #define LINK_WAIT_MAX_IATU_RETRIES 5 > > --- > base-commit: 26d7d52b6253574d5b6fec16a93e1110d1489cef > change-id: 20240215-topic-pci_sleep-368108a1fb6f > > Best regards, Thanks, Olek
On Thu, Feb 15, 2024 at 11:39:31AM +0100, Konrad Dybcio wrote: > 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); > } > > if (retries >= LINK_WAIT_MAX_RETRIES) { > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h > index 26dae4837462..3f145d6a8a31 100644 > --- a/drivers/pci/controller/dwc/pcie-designware.h > +++ b/drivers/pci/controller/dwc/pcie-designware.h > @@ -63,8 +63,7 @@ > > /* 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 Why do you use the _MAX suffix here? AFAICS any the timers normally ensures the lower boundary value of the wait-duration, not the upper one. So the more correct suffix would be _MIN. On the other hand, as Alexander correctly noted, using fsleep() would be more suitable at least from the maintainability point of view. Thus having a macro name like LINK_WAIT_USLEEP_MIN or just LINK_WAIT_SLEEP_US would be more appropriate. The later version is more preferable IMO. -Serge(y) > > /* Parameters for the waiting for iATU enabled routine */ > #define LINK_WAIT_MAX_IATU_RETRIES 5 > > --- > base-commit: 26d7d52b6253574d5b6fec16a93e1110d1489cef > change-id: 20240215-topic-pci_sleep-368108a1fb6f > > Best regards, > -- > Konrad Dybcio <konrad.dybcio@linaro.org> > >
On 2/15/24 2:39 AM, Konrad Dybcio wrote: > 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); > } > > if (retries >= LINK_WAIT_MAX_RETRIES) { > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h > index 26dae4837462..3f145d6a8a31 100644 > --- a/drivers/pci/controller/dwc/pcie-designware.h > +++ b/drivers/pci/controller/dwc/pcie-designware.h > @@ -63,8 +63,7 @@ > > /* 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 90 ms is an acceptable value, why not use it? > > /* Parameters for the waiting for iATU enabled routine */ > #define LINK_WAIT_MAX_IATU_RETRIES 5 > > --- > base-commit: 26d7d52b6253574d5b6fec16a93e1110d1489cef > change-id: 20240215-topic-pci_sleep-368108a1fb6f > > Best regards,
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
On 15.02.2024 18:02, Bjorn Helgaas wrote: > 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. IMO, fsleep only makes sense when the argument is variable.. This way, we can save on bothering the compiler or adding an unnecessary branch > > 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. Might as well do that indeed Konrad
On 15.02.2024 15:17, Serge Semin wrote: > On Thu, Feb 15, 2024 at 11:39:31AM +0100, Konrad Dybcio wrote: >> 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); >> } >> >> if (retries >= LINK_WAIT_MAX_RETRIES) { >> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h >> index 26dae4837462..3f145d6a8a31 100644 >> --- a/drivers/pci/controller/dwc/pcie-designware.h >> +++ b/drivers/pci/controller/dwc/pcie-designware.h >> @@ -63,8 +63,7 @@ >> >> /* 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 > > Why do you use the _MAX suffix here? AFAICS any the timers normally > ensures the lower boundary value of the wait-duration, not the upper > one. So the more correct suffix would be _MIN. On the other hand, as > Alexander correctly noted, using fsleep() would be more suitable at > least from the maintainability point of view. Thus having a macro name > like LINK_WAIT_USLEEP_MIN or just LINK_WAIT_SLEEP_US would be more > appropriate. The later version is more preferable IMO. Agree with SLEEP_US Konrad
On 15.02.2024 15:51, Kuppuswamy Sathyanarayanan wrote: > > On 2/15/24 2:39 AM, Konrad Dybcio wrote: >> 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); >> } >> >> if (retries >= LINK_WAIT_MAX_RETRIES) { >> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h >> index 26dae4837462..3f145d6a8a31 100644 >> --- a/drivers/pci/controller/dwc/pcie-designware.h >> +++ b/drivers/pci/controller/dwc/pcie-designware.h >> @@ -63,8 +63,7 @@ >> >> /* 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 90 ms is an acceptable value, why not use it? I suppose I can do that indeed.. Usually I go for the safer option when cleaning up old code, but you're right, 90 should be ok (unless somebody has some documentation stating otherwise) Konrad
On Thu, Feb 15, 2024 at 06:46:55PM +0100, Konrad Dybcio wrote: > On 15.02.2024 18:02, Bjorn Helgaas wrote: > > 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. > > IMO, fsleep only makes sense when the argument is variable.. This way, we > can save on bothering the compiler or adding an unnecessary branch I fully agree. Using fsleep() with a constant just looks sloppy (e.g. with that hardcoded usleep range) and hides what is really going on for no good reason. Johan
On Tue, Feb 20, 2024 at 09:23:24AM +0100, Johan Hovold wrote: > On Thu, Feb 15, 2024 at 06:46:55PM +0100, Konrad Dybcio wrote: > > On 15.02.2024 18:02, Bjorn Helgaas wrote: > > > 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. > > > > IMO, fsleep only makes sense when the argument is variable.. This way, we > > can save on bothering the compiler or adding an unnecessary branch > > I fully agree. Using fsleep() with a constant just looks sloppy (e.g. > with that hardcoded usleep range) and hides what is really going on for > no good reason. Why does it look sloppy? I'd be surprised if using a constant led to more executable code, given that fsleep() is inline. I'm all for having the compiler choose the right thing instead of having to look up the guidelines myself. Bjorn
On Tue, Feb 20, 2024 at 05:00:48PM -0600, Bjorn Helgaas wrote: > On Tue, Feb 20, 2024 at 09:23:24AM +0100, Johan Hovold wrote: > > On Thu, Feb 15, 2024 at 06:46:55PM +0100, Konrad Dybcio wrote: > > > On 15.02.2024 18:02, Bjorn Helgaas wrote: > > > > On Thu, Feb 15, 2024 at 02:35:13PM +0100, Alexander Lobakin wrote: > > > >> Just use fsleep(LINK_WAIT_USLEEP_MAX) and let the kernel decide which > > > >> function to pick. > > > > > > IMO, fsleep only makes sense when the argument is variable.. This way, we > > > can save on bothering the compiler or adding an unnecessary branch > > > > I fully agree. Using fsleep() with a constant just looks sloppy (e.g. > > with that hardcoded usleep range) and hides what is really going on for > > no good reason. > > Why does it look sloppy? I'd be surprised if using a constant led to > more executable code, given that fsleep() is inline. I'm all for > having the compiler choose the right thing instead of having to look > up the guidelines myself. It's not about the generated code, but about hiding what's really going from kernel developers that should be aware of such things. The fact that you end up with an usleep range of 20 to 40 ms if you want to sleep for 20 ms is not very nice either. Except possibly for a few cases where you'd otherwise end up open-coding fsleep() I don't think there's any reason to use it. Johan
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); } if (retries >= LINK_WAIT_MAX_RETRIES) { diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h index 26dae4837462..3f145d6a8a31 100644 --- a/drivers/pci/controller/dwc/pcie-designware.h +++ b/drivers/pci/controller/dwc/pcie-designware.h @@ -63,8 +63,7 @@ /* 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 /* Parameters for the waiting for iATU enabled routine */ #define LINK_WAIT_MAX_IATU_RETRIES 5