public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [patch 1/2] fix USB initialisation procedure
Date: Thu, 09 Oct 2008 11:22:48 -0400	[thread overview]
Message-ID: <48EE21C8.6000403@ge.com> (raw)
In-Reply-To: <200810091659.55186.sr@denx.de>

Stefan Roese wrote:
> On Thursday 09 October 2008, Markus Klotzb?cher wrote:
>> On Thu, Oct 09, 2008 at 03:19:22PM +0200, Wolfgang Denk wrote:
>>> Dear Jean-Christophe PLAGNIOL-VILLARD,
>>>
>>> In message <20081009121044.GA25278@game.jcrosoft.org> you wrote:
>>>>>  	if (dev->status == 0)
>>>>>  		return dev->act_len;
>>>> please add {} to if too or remove the else
>>>>
>>>>> -	else
>>>>> +	else {
>>>>> +		/* Let's wait a while for the timeout to elaps.
>>>>> +		 * it has no real use, but it keeps the interface happy. */
>>>>> +		wait_ms(timeout);
>>>>>  		return -1;
>>>>> +	}
>>> Good catch.
>> Quite honest, I think this is *way* to pedantic. I'd really prefer to
>> let people who are contributing significantly do their work instead of
>> bugging them with such rare coding style violations.
> 
> ACK from me here. "Minor" coding style violations like these braces issue or 
> too long lines should not delay patches.
> 
>>> Actually the "else" should be removed.
>> How so?
> 
> Because of the "return dev->act_len;" above. :)
> 
> Best regards,
> Stefan

Also agreed.

While we are painting the bike shed, I would suggest a better structure 
would be to flip the conditional so that the normal flow goes out the 
end of the module and the abnormal flow returns early.  (The comment is 
also a coding standards violation for multiline comments and has two 
typos in it.)

	if (dev->status != 0) {
		/*
		 * Let's wait a while for the timeout to elapse.
		 * It has no real use, but it keeps the interface happy.
		 */
		wait_ms(timeout);
		return -1;
	}

	return dev->act_len;
}

Hmmm, looking at the original changeset, my above point has some 
validity.  While we (gcc) can do a flow analysis and recognize that 
something will be returned in all cases due to the if/else, it doesn't 
jump out at a casual observation of the code.  On the surface, the code 
looks like it can fall off the end of the function (e.g. return "void"), 
which would be very wrong.  Making it obvious that the Right Thing[tm] 
is returned: priceless.

> --- u-boot-git-22092008.orig/common/usb.c	2008-10-08 10:51:49.000000000 +0200
> +++ u-boot-git-22092008/common/usb.c	2008-10-08 10:51:50.000000000 +0200
> @@ -196,15 +196,14 @@ int usb_control_msg(struct usb_device *d
>  	if (timeout == 0)
>  		return (int)size;
> 
> -	while (timeout--) {
> -		if (!((volatile unsigned long)dev->status & USB_ST_NOT_PROC))
> -			break;
> -		wait_ms(1);
> -	}
>  	if (dev->status == 0)
>  		return dev->act_len;
> -	else
> +	else {
> +		/* Let's wait a while for the timeout to elaps.
> +		 * it has no real use, but it keeps the interface happy. */
> +		wait_ms(timeout);
>  		return -1;
> +	}
>  }

I like green paint,
gvb

  parent reply	other threads:[~2008-10-09 15:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-08  8:54 [U-Boot] [patch 0/2] Some more USB-OHCI bugfixes Remy Bohmer
2008-10-08  8:54 ` [U-Boot] [patch 1/2] fix USB initialisation procedure Remy Bohmer
2008-10-09 12:10   ` Jean-Christophe PLAGNIOL-VILLARD
2008-10-09 13:19     ` Wolfgang Denk
2008-10-09 14:43       ` Markus Klotzbücher
2008-10-09 14:59         ` Stefan Roese
2008-10-09 15:09           ` Markus Klotzbücher
2008-10-09 15:22           ` Jerry Van Baren [this message]
2008-10-09 18:45           ` Wolfgang Denk
2008-10-09 19:52             ` Markus Klotzbücher
2008-10-10  7:30             ` Remy Bohmer
2008-10-09 18:42         ` Wolfgang Denk
2008-10-08  8:54 ` [U-Boot] [patch 2/2] The PIPE_INTERRUPT flag is used wrong Remy Bohmer
2008-10-08 10:12 ` [U-Boot] [patch 0/2] Some more USB-OHCI bugfixes Markus Klotzbücher
2008-10-08 10:41 ` Stelian Pop
2008-10-09  8:33 ` Stelian Pop
2008-10-09  9:51   ` Remy Bohmer
2008-10-09 15:01     ` Stelian Pop
2008-10-10  7:21       ` Remy Bohmer
2008-10-10  8:25         ` Stelian Pop
2008-10-10  8:33           ` Remy Bohmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48EE21C8.6000403@ge.com \
    --to=gerald.vanbaren@ge.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox