[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <989ba8b4-19b4-4053-bb00-ccced42a8829@stanley.mountain>
Date: Mon, 12 Aug 2024 09:52:21 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: Dave Airlie <airlied@...hat.com>, Jocelyn Falempe <jfalempe@...hat.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
kernel-janitors@...r.kernel.org,
Jani Nikula <jani.nikula@...ux.intel.com>
Subject: Re: [PATCH v2] drm/ast: astdp: fix loop timeout check
On Mon, Aug 12, 2024 at 09:42:53AM +0300, Dan Carpenter wrote:
> This code has an issue because it loops until "i" is set to UINT_MAX but
> the test for failure assumes that "i" is set to zero. The result is that
> it will only print an error message if we succeed on the very last try.
> Reformat the loop to count forwards instead of backwards.
>
> Fixes: 2281475168d2 ("drm/ast: astdp: Perform link training during atomic_enable")
> Signed-off-by: Dan Carpenter <dan.carpenter@...aro.org>
> ---
> v2: In version one, I introduced a bug where it would msleep(100) after failure
> and that is a pointless thing to do. Also change the loop to a for loop.
I mean this version also sleeps on the last failed iteration but at least there
isn't always true if statement to try prevent optimize away the last sleep.
I'm okay with a sleep on the slow path but not with pointless if statements. ;)
regards,
dan carpenter
Powered by blists - more mailing lists