All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.duyck@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next-queue 1/8] e1000: clean up the useless 'continue' statement
Date: Wed, 16 Sep 2015 09:38:51 -0700	[thread overview]
Message-ID: <55F99B1B.1010504@gmail.com> (raw)
In-Reply-To: <20150916153428.GB3881@mail.gmail.com>

On 09/16/2015 08:34 AM, J?an Sacren wrote:
> From: "Rustad, Mark D" <mark.d.rustad@intel.com>
> Date: Tue, 15 Sep 2015 18:24:39 +0000
>>
>>> On Sep 14, 2015, at 10:35 PM, J?an Sacren <sakiwit@gmail.com> wrote:
>
> [...]
>
>>> The goto statement might be executed if and only if at the last loop out
>>> of a total of 32. I think we need to rewrite the checking logic here:
>>>
>>> 			...
>>> 			if (tmp != 0 && tmp != 0xFF)
>>> 				break;
>>>
>>> 			if (i == 31)
>>> 				goto err_eeprom;
>>> 			...
>>>
>>> What do you think?
>>
>> This is ok too, but this makes it look to me like the if and goto
>> should really be outside the loop, so after the loop one would have:
>>
>> 		if (i == 32)
>> 			goto err_eeprom;
>
> I think moving the above check out of the loop is a good idea, yet it
> still retains the same issue as doing the unnecessary checking.
>
> How about the following patch:
>
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
> index 74dc15055971..4c3ca7c9ce49 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> @@ -1199,15 +1199,14 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>   		for (i = 0; i < 32; i++) {
>   			hw->phy_addr = i;
>   			e1000_read_phy_reg(hw, PHY_ID2, &tmp);
> -			if (tmp == 0 || tmp == 0xFF) {
> -				if (i == 31)
> -					goto err_eeprom;
> -				continue;
> -			} else
> -				break;
> +
> +			if (tmp != 0 && tmp != 0xFF)
> +				goto no_err;
>   		}
> -	}
>
> +		goto err_eeprom;
> +	}
> +no_err:
>   	/* reset the hardware with the new settings */
>   	e1000_reset(adapter);
>

I kind of like Mark's idea better, though I would make one change.  I 
would make it so that you pull the check for i outside the loop so you 
have something like:
		for (i = 0; i < 32; i++) {
			hw->phy_addr = i;
			e1000_read_phy_reg(hw, PHY_ID2, &tmp);

			if (tmp != 0 && tmp != 0xFF)
				break;
		}

		if (i >= 32)
			goto no_err;

This way you should only have to ever do a comparison of i once per 
loop, and hopefully the compiler is smart enough to realize that i >= 32 
is the exit condition for the loop and will place the jump to that label 
accordingly.

As a side note I am curious if this code is even correct.  I see tmp is 
a u16, the declaration for which could be moved down into the if 
statement if I am not mistaken, and I am curious as to why we are 
comparing it to 0xFF instead of 0xFFFF.  I suspect that the 0xFF check 
might not be adding any value, but I could be wrong.

- Alex


  reply	other threads:[~2015-09-16 16:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-14  6:27 [Intel-wired-lan] [next-queue 0/8] Trivial fix-ups for Intel wired LAN drivers 09/10/2015 =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-14  6:27 ` [Intel-wired-lan] [next-queue 1/8] e1000: clean up the useless 'continue' statement =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-14 16:48   ` Rustad, Mark D
2015-09-15  5:35     ` =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-15 18:24       ` Rustad, Mark D
2015-09-16 15:34         ` =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-16 16:38           ` Alexander Duyck [this message]
2015-09-16 18:27             ` Rustad, Mark D
2015-09-16 21:09               ` Alexander Duyck
2015-09-16 23:36                 ` Rustad, Mark D
2015-09-14  6:27 ` [Intel-wired-lan] [next-queue 2/8] e1000: fix a typo in the comment =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-14  6:27 ` [Intel-wired-lan] [next-queue 3/8] e1000e: clean up the local variable =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-14  6:27 ` [Intel-wired-lan] [next-queue 4/8] i40e: fix kernel-doc argument name =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-22 21:27   ` Bowers, AndrewX
2015-09-14  6:27 ` [Intel-wired-lan] [next-queue 5/8] ixgbe: fix multiple kernel-doc errors =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-14  6:27 ` [Intel-wired-lan] [next-queue 6/8] i40e: declare rather than initialize int object =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-14  6:27 ` [Intel-wired-lan] [next-queue 7/8] e1000: fix kernel-doc argument being missing =?unknown-8bit?q?J=CE=B5an?= Sacren
2015-09-14  6:27 ` [Intel-wired-lan] [next-queue 8/8] e1000: get rid of duplicate exit path =?unknown-8bit?q?J=CE=B5an?= Sacren

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=55F99B1B.1010504@gmail.com \
    --to=alexander.duyck@gmail.com \
    --cc=intel-wired-lan@osuosl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.