lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <359e5aa5-5908-44d3-8359-4605aac3f5d5@stanley.mountain>
Date: Fri, 9 Aug 2024 20:06:53 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Jani Nikula <jani.nikula@...ux.intel.com>
Cc: Thomas Zimmermann <tzimmermann@...e.de>,
	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
Subject: Re: [PATCH] drm/ast: astdp: fix pre-op vs post-op bug

On Fri, Aug 09, 2024 at 04:43:51PM +0300, Jani Nikula wrote:
> On Fri, 09 Aug 2024, Thomas Zimmermann <tzimmermann@...e.de> wrote:
> > Hi,
> >
> > thanks a lot for the bugfix.
> >
> > Am 09.08.24 um 14:33 schrieb Dan Carpenter:
> >> The test for "Link training failed" expect the loop to exit with "i"
> >> set to zero but it exits when "i" is set to -1.  Change this from a
> >> post-op to a pre-op so that it exits with "i" set to zero.  This
> >> changes the number of iterations from 10 to 9 but probably that's
> >> okay.
> >
> > Yes, that's ok.
> >
> >>
> >> Fixes: 2281475168d2 ("drm/ast: astdp: Perform link training during atomic_enable")
> >> Signed-off-by: Dan Carpenter <dan.carpenter@...aro.org>
> >> ---
> >>   drivers/gpu/drm/ast/ast_dp.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/ast/ast_dp.c b/drivers/gpu/drm/ast/ast_dp.c
> >> index 5d07678b502c..4329ab680f62 100644
> >> --- a/drivers/gpu/drm/ast/ast_dp.c
> >> +++ b/drivers/gpu/drm/ast/ast_dp.c
> >> @@ -148,7 +148,7 @@ void ast_dp_link_training(struct ast_device *ast)
> >>   	struct drm_device *dev = &ast->base;
> >>   	unsigned int i = 10;
> >>   
> >> -	while (i--) {
> >> +	while (--i) {
> >
> > If this loop ever starts with i = 0, it would break again. Can we use
> >
> > while (i) {
> >    --i;
> >     ...
> > }
> >
> > instead?
> 
> FWIW, I personally *always* use for loops when there isn't a compelling
> reason to do otherwise. You know at a glance that
> 
> 	for (i = 0; i < N; i++)
> 
> gets run N times and what i is going to be afterwards.
> 
> Sure, you may have to restructure other things, but I think it's almost
> always worth it.

A for statement works here.  I need to resend the patch anyway because
the if (i) msleep() code doesn't make sense now.

regards,
dan carpenter


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ