mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH v2] usb: storage: retry for up to 10s on lengthy HDD spin up
Date: Fri, 16 Apr 2021 19:26:46 +0200	[thread overview]
Message-ID: <20210416172646.26834-1-a.fatoum@pengutronix.de> (raw)

Some USB disks take notoriously long to spin up. They are seen by a bus
scan, but they report ready only after a few seconds have passed. This
is not a problem if vbus is enabled early on, so devices have had a
chance to spin up. If vbus is first enabled as part of the usb scan,
not enough time might have passed for the USB disk to be usable.

This issue was observed on an i.MX6QP with following topology:

  usb: USB: scanning bus for devices...
  usb: 5 USB Device(s) found
    1 ID 0000:0000
    |  u-boot EHCI Host Controller
    |
    +-2 ID 0424:2517
    |
    +-5 ID 1058:2621
    |    Western Digital Elements 2621
    ...

Unplugging and replugging the USB disk and doing a second usb scan
made the unit ready test succeed. Increasing the retry count
during initialization has negative consequences for other cases,
like when a device is unplugged while being probed (which already
takes way too long).

Instead, just for the case of a detected USB mass storage device that
couldn't get ready initially: retry for 10s at initialization time
before giving up.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
v1 -> v2:
  - don't increase retry count, instead just check time and don't
    loop longer than 10s at init time.
---
 drivers/usb/storage/usb.c | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index b417640186a2..b0f789b42a9f 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -141,20 +141,23 @@ exit:
 	return ret;
 }
 
-static int usb_stor_test_unit_ready(struct us_blk_dev *usb_blkdev)
+static int usb_stor_test_unit_ready(struct us_blk_dev *usb_blkdev, u64 timeout_ns)
 {
+	u64 start;
 	u8 cmd[6];
 	int ret;
 
 	memset(cmd, 0, sizeof(cmd));
 	cmd[0] = SCSI_TST_U_RDY;
 
-	ret = usb_stor_transport(usb_blkdev, cmd, sizeof(cmd), NULL, 0,
-				 10, 100);
-	if (ret < 0)
-		return -ENODEV;
+	start = get_time_ns();
 
-	return 0;
+	do {
+		ret = usb_stor_transport(usb_blkdev, cmd, sizeof(cmd), NULL, 0,
+					 10, 100);
+	} while (ret < 0 && !is_timeout(start, timeout_ns));
+
+	return ret ? -ENODEV : 0;
 }
 
 static int read_capacity_16(struct us_blk_dev *usb_blkdev)
@@ -282,7 +285,7 @@ static int usb_stor_blk_io(struct block_device *disk_dev,
 
 	/* ensure unit ready */
 	dev_dbg(dev, "Testing for unit ready\n");
-	if (usb_stor_test_unit_ready(pblk_dev)) {
+	if (usb_stor_test_unit_ready(pblk_dev, 0)) {
 		dev_dbg(dev, "Device NOT ready\n");
 		return -EIO;
 	}
@@ -365,7 +368,8 @@ static int usb_stor_init_blkdev(struct us_blk_dev *pblk_dev)
 	/* ensure unit ready */
 	dev_dbg(dev, "Testing for unit ready\n");
 
-	result = usb_stor_test_unit_ready(pblk_dev);
+	/* retry a bit longer than usual as some HDDs take longer to spin up */
+	result = usb_stor_test_unit_ready(pblk_dev, 10ULL * NSEC_PER_SEC);
 	if (result) {
 		dev_dbg(dev, "Device NOT ready\n");
 		return result;
-- 
2.29.2


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


             reply	other threads:[~2021-04-16 17:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 17:26 Ahmad Fatoum [this message]
2021-05-07  8:09 ` Sascha Hauer

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=20210416172646.26834-1-a.fatoum@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.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