Received-SPF: pass (google.com: domain of linux-kernel+bounces-8323-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <4aa4b757-13eb-4653-99eb-16aec7c8a3d9@tuxedocomputers.com>
Date: Thu, 21 Dec 2023 13:20:59 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Werner Sembach <wse@tuxedocomputers.com>
Subject: Re: [PATCH] thunderbolt: Reduce retry timeout to speed up boot for
 some devices
To: Greg KH <greg@kroah.com>
Cc: Andreas Noever <andreas.noever@gmail.com>,
 Michael Jamet <michael.jamet@intel.com>,
 Mika Westerberg <mika.westerberg@linux.intel.com>,
 Yehezkel Bernat <YehezkelShB@gmail.com>, linux-usb@vger.kernel.org,
 linux-kernel@vger.kernel.org
References: <20231220150956.230227-1-wse@tuxedocomputers.com>
 <2e00a0dc-5911-44ee-8c50-a8482eb44197@tuxedocomputers.com>
 <2023122012-spruce-unsteady-e187@gregkh>
Content-Language: de-DE, en-US
In-Reply-To: <2023122012-spruce-unsteady-e187@gregkh>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Am 20.12.23 um 17:04 schrieb Greg KH:
> On Wed, Dec 20, 2023 at 04:23:15PM +0100, Werner Sembach wrote:
>> Am 20.12.23 um 16:09 schrieb Werner Sembach:
>>> This is a followup to "thunderbolt: Workaround an IOMMU fault on certain
>>> systems with Intel Maple Ridge".
>>>
>>> It seems like the timeout can be reduced to 250ms. This reduces the overall
>>> delay caused by the retires to ~1s. This is about the time other things
>>> being initialized in parallel need anyway*, so like this the effective boot
>>> time is no longer compromised.
>>>
>>> *I only had a single device available for my measurements: A Clevo X170KM-G
>>> desktop replacement notebook.
>>>
>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>> I wonder if this could also land in stable? Or would it be to risky?
> If it's really a bugfix now, why would it _not_ be relevant for stable?

edit: Sorry if this is the 3rd time I send this, I got mail server 
errors (hopefully fixed now) and am not sure if it reached out

Because it changes a timeout that could cause issues if set to low: This 
Patch sets to to 250ms. Set to 50ms it causes issues, currently it's 
2000ms, 2 people tested that 250ms is enough, but i don't know if this 
is a big enough sample size for stable.

The advantage is significantly faster boot time on affected devices 
(~12s down to ~3s), however they do already work fine without it.

Kind regards,

Werner

>
> thanks,
>
> greg k-h