net: adaptec: remove dead code in set_vlan_mode

From: Kaixu Xia <kaixuxia@tencent.com>

The body of the if statement can be executed only when the variable
vlan_count equals to 32, so the condition of the while statement can
not be true and the while statement is dead code. Remove it.

Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
---
 drivers/net/ethernet/adaptec/starfire.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

On Fri, 20 Nov 2020 15:50:00 +0800 xiakaixu1987@gmail.com wrote:
> From: Kaixu Xia <kaixuxia@tencent.com>
> 
> The body of the if statement can be executed only when the variable
> vlan_count equals to 32, so the condition of the while statement can
> not be true and the while statement is dead code. Remove it.
> 
> Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
> Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
> ---
>  drivers/net/ethernet/adaptec/starfire.c | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ethernet/adaptec/starfire.c b/drivers/net/ethernet/adaptec/starfire.c
> index 555299737b51..ad27a9fa5e95 100644
> --- a/drivers/net/ethernet/adaptec/starfire.c
> +++ b/drivers/net/ethernet/adaptec/starfire.c
> @@ -1754,14 +1754,9 @@ static u32 set_vlan_mode(struct netdev_private *np)
>  		filter_addr += 16;
>  		vlan_count++;
>  	}
> -	if (vlan_count == 32) {
> +	if (vlan_count == 32)
>  		ret |= PerfectFilterVlan;
> -		while (vlan_count < 32) {
> -			writew(0, filter_addr);
> -			filter_addr += 16;
> -			vlan_count++;
> -		}
> -	}
> +
>  	return ret;
>  }
>  #endif /* VLAN_SUPPORT */

This got broken back in 2011:

commit 5da96be53a16a62488316810d0c7c5d58ce3ee4f
Author: Jiri Pirko <jpirko@redhat.com>
Date:   Wed Jul 20 04:54:31 2011 +0000

    starfire: do vlan cleanup
    
    - unify vlan and nonvlan rx path
    - kill np->vlgrp and netdev_vlan_rx_register
    
    Signed-off-by: Jiri Pirko <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

The comparison to 32 was on a different variable before that change.

Ion, do you think anyone is still using this driver?

Maybe it's time we put it in the history book (by which I mean remove
from the kernel).

On 11/20/20 6:17 PM, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 15:50:00 +0800 xiakaixu1987@gmail.com wrote:
>> From: Kaixu Xia <kaixuxia@tencent.com>
>>
>> The body of the if statement can be executed only when the variable
>> vlan_count equals to 32, so the condition of the while statement can
>> not be true and the while statement is dead code. Remove it.
>>
>> Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
>> Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
>> ---
>>   drivers/net/ethernet/adaptec/starfire.c | 9 ++-------
>>   1 file changed, 2 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/adaptec/starfire.c b/drivers/net/ethernet/adaptec/starfire.c
>> index 555299737b51..ad27a9fa5e95 100644
>> --- a/drivers/net/ethernet/adaptec/starfire.c
>> +++ b/drivers/net/ethernet/adaptec/starfire.c
>> @@ -1754,14 +1754,9 @@ static u32 set_vlan_mode(struct netdev_private *np)
>>   		filter_addr += 16;
>>   		vlan_count++;
>>   	}
>> -	if (vlan_count == 32) {
>> +	if (vlan_count == 32)
>>   		ret |= PerfectFilterVlan;
>> -		while (vlan_count < 32) {
>> -			writew(0, filter_addr);
>> -			filter_addr += 16;
>> -			vlan_count++;
>> -		}
>> -	}
>> +
>>   	return ret;
>>   }
>>   #endif /* VLAN_SUPPORT */
> 
> This got broken back in 2011:
> 
> commit 5da96be53a16a62488316810d0c7c5d58ce3ee4f
> Author: Jiri Pirko <jpirko@redhat.com>
> Date:   Wed Jul 20 04:54:31 2011 +0000
> 
>      starfire: do vlan cleanup
>      
>      - unify vlan and nonvlan rx path
>      - kill np->vlgrp and netdev_vlan_rx_register
>      
>      Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>      Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> The comparison to 32 was on a different variable before that change.
> 
> Ion, do you think anyone is still using this driver?
> 
> Maybe it's time we put it in the history book (by which I mean remove
> from the kernel).

Frankly, no, I don't know of any users, and that unfortunately includes 
myself. I still have two cards in my stash, but they're 64-bit PCI-X, so 
plugging them in would likely require taking a dremel to a 32-bit PCI 
slot to make it open-ended. (They do work in a 32-bit slot.)

Anyway, that filter code could use some fixing in other regards. So 
either we fix it properly (which I can submit a patch for), or clean it 
out for good.

-Ion

On Fri, 20 Nov 2020 18:41:03 -0500 Ion Badulescu wrote:
> Frankly, no, I don't know of any users, and that unfortunately includes 
> myself. I still have two cards in my stash, but they're 64-bit PCI-X, so 
> plugging them in would likely require taking a dremel to a 32-bit PCI 
> slot to make it open-ended. (They do work in a 32-bit slot.)
> 
> Anyway, that filter code could use some fixing in other regards. So 
> either we fix it properly (which I can submit a patch for), or clean it 
> out for good.

Entirely up to you.

On 11/20/20 6:56 PM, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 18:41:03 -0500 Ion Badulescu wrote:
>> Frankly, no, I don't know of any users, and that unfortunately includes
>> myself. I still have two cards in my stash, but they're 64-bit PCI-X, so
>> plugging them in would likely require taking a dremel to a 32-bit PCI
>> slot to make it open-ended. (They do work in a 32-bit slot.)
>>
>> Anyway, that filter code could use some fixing in other regards. So
>> either we fix it properly (which I can submit a patch for), or clean it
>> out for good.
> 
> Entirely up to you.

All right then. I'll whip out the Dremel this weekend and hopefully get 
a test rig going... :)

-Ion