Intel-Wired-Lan Archive on 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox