From a5b85a431ef7ba701a309aed1a4ea763922b42cd Mon Sep 17 00:00:00 2001
From: Dima Zavin <dmitriyz@waymo.com>
Date: Thu, 28 Feb 2019 14:50:25 -0800
Subject: [PATCH 1/2] fastboot: switch the timeout clock source to steady_clock

Previously, system_clock was used for remote command timeouts
which can get disturbed by NTP adjustments (jumps).

Change-Id: I0ffc159bf34d12e8d3713044524114d60a6a45ca
Signed-off-by: Dima Zavin <dmitriyz@waymo.com>
---
 fastboot/fastboot_driver.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fastboot/fastboot_driver.cpp b/fastboot/fastboot_driver.cpp
index 65a52475d..4deed94a0 100644
--- a/fastboot/fastboot_driver.cpp
+++ b/fastboot/fastboot_driver.cpp
@@ -403,7 +403,7 @@ RetCode FastBootDriver::DownloadCommand(uint32_t size, std::string* response,
 RetCode FastBootDriver::HandleResponse(std::string* response, std::vector<std::string>* info,
                                        int* dsize) {
     char status[FB_RESPONSE_SZ + 1];
-    auto start = std::chrono::system_clock::now();
+    auto start = std::chrono::steady_clock::now();
 
     auto set_response = [response](std::string s) {
         if (response) *response = std::move(s);
@@ -414,7 +414,7 @@ RetCode FastBootDriver::HandleResponse(std::string* response, std::vector<std::s
 
     // erase response
     set_response("");
-    while ((std::chrono::system_clock::now() - start) < std::chrono::seconds(RESP_TIMEOUT)) {
+    while ((std::chrono::steady_clock::now() - start) < std::chrono::seconds(RESP_TIMEOUT)) {
         int r = transport_->Read(status, FB_RESPONSE_SZ);
         if (r < 0) {
             error_ = ErrnoStr("Status read failed");

From 6d46a4975e7b57094c7ecacbc35d34295ab4b40a Mon Sep 17 00:00:00 2001
From: Dima Zavin <dmitriyz@waymo.com>
Date: Sat, 23 Feb 2019 21:14:38 -0800
Subject: [PATCH 2/2] fastboot: reset timeout if INFO is received during long
 commands

As part of a refactor, commit db511207ed3b2bb4fc422ef83868009b03692e61
added a timeout for receving responses for commands. Unfortunately,
the timeout is optimistic as to how quickly target devices can complete
such operations. Flash and erase commands can be quite slow on devices
with traditional flash chips. The fastboot protocol is already adept
at handling such cases because it allows for sending INFO packets during
these periods. We may receive one or more INFO packets during tehse long
operations. Every time we receive an INFO packet, it proves the remote
end is alive, but busy, which should reset our timeout timer.

Change-Id: Ia3bba21c497b22639b626d89711ecd4eb02504ed
Signed-off-by: Dima Zavin <dmitriyz@waymo.com>
---
 fastboot/fastboot_driver.cpp | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fastboot/fastboot_driver.cpp b/fastboot/fastboot_driver.cpp
index 4deed94a0..fea0a77e5 100644
--- a/fastboot/fastboot_driver.cpp
+++ b/fastboot/fastboot_driver.cpp
@@ -427,6 +427,11 @@ RetCode FastBootDriver::HandleResponse(std::string* response, std::vector<std::s
             std::string tmp = input.substr(strlen("INFO"));
             info_(tmp);
             add_info(std::move(tmp));
+            // We may receive one or more INFO packets during long operations,
+            // e.g. flash/erase if they are back by slow media like NAND/NOR
+            // flash. In that case, reset the timer since it's not a real
+            // timeout.
+            start = std::chrono::steady_clock::now();
         } else if (android::base::StartsWith(input, "OKAY")) {
             set_response(input.substr(strlen("OKAY")));
             return SUCCESS;