Re: [PATCH] thunderbolt: Reduce retry timeout to speed up boot for some devices

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Wed, Dec 20, 2023 at 06:30:53PM +0100, Greg KH wrote:
> On Wed, Dec 20, 2023 at 05:41:01PM +0100, Werner Sembach wrote:
> > 
> > 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?
> > 
> > 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.
> 
> Remember, the next kernel will be a stable kernel tree, just like the
> one after that.  If it's good enough for Linus's tree, why wouldn't it
> be good enough for all stable trees?  Either it works or it doesn't,
> none of this "we will break things when you move to a new kernel" stuff
> please.

Since this is kind of "improvement" over already functioning code, I
would put it to v6.8 and not to stable trees. This way it gets more some
more exposure before landing to distro kernels.

It would be nice to get Tested-by from the folks involved on that
bugzilla as well, if that's possible. I can try this on my side on a
Maple Ridge based system (that does not have the original issue) so that
we know that it does not cause any issues on them.