linux-kernel - Re: [Outreachy kernel] [PATCH v4] staging: vt6656: add error code handling to unused variable

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] [day] [month] [year] [list]

Message-ID: <c2e96efe-64d7-61d7-0c4f-58b318b47a68@gmail.com>
Date:   Mon, 30 Mar 2020 19:42:08 +0100
From:   Malcolm Priestley <tvboxspy@...il.com>
To:     Stefano Brivio <sbrivio@...hat.com>,
        "John B. Wyatt IV" <jbwyatt4@...il.com>
Cc:     outreachy-kernel@...glegroups.com,
        Julia Lawall <julia.lawall@...ia.fr>,
        Forest Bond <forest@...ttletooquiet.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Quentin Deslandes <quentin.deslandes@...ev.co.uk>,
        Colin Ian King <colin.king@...onical.com>,
        devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [Outreachy kernel] [PATCH v4] staging: vt6656: add error code
 handling to unused variable

On 30/03/2020 18:14, Stefano Brivio wrote:
> On Mon, 30 Mar 2020 09:45:30 -0700
> "John B. Wyatt IV" <jbwyatt4@...il.com> wrote:
> 
>> Add error code handling to unused 'ret' variable that was never used.
>> Return an error code from functions called within vnt_radio_power_on.
>>
>> Issue reported by coccinelle (coccicheck).
>>
>> Suggested-by: Quentin Deslandes <quentin.deslandes@...ev.co.uk>
>> Suggested-by: Stefano Brivio <sbrivio@...hat.com>
>> Suggested-by: Julia Lawall <julia.lawall@...ia.fr>
>> Reviewed-by: Quentin Deslandes <quentin.deslandes@...ev.co.uk>
>> Signed-off-by: John B. Wyatt IV <jbwyatt4@...il.com>
>> ---
>> v4: Move Suggested-by: Julia Lawall above seperator line.
> 
> Actually, as Julia didn't suggest this patch, the place where you had
> this in v3 was the right one.
---snip
>>   
>>   	switch (priv->rf_type) {
>>   	case RF_AL2230:
>> @@ -734,14 +738,14 @@ int vnt_radio_power_on(struct vnt_private *priv)
>>   	case RF_VT3226:
>>   	case RF_VT3226D0:
>>   	case RF_VT3342A0:
>> -		vnt_mac_reg_bits_on(priv, MAC_REG_SOFTPWRCTL,
>> -				    (SOFTPWRCTL_SWPE2 | SOFTPWRCTL_SWPE3));
>> +		ret = vnt_mac_reg_bits_on(priv, MAC_REG_SOFTPWRCTL,
>> +					 (SOFTPWRCTL_SWPE2 | SOFTPWRCTL_SWPE3));
> 
> 
> Another thing that should be considered in this function is to restore
> the previous hardware state on failures, but I think the way you're
> handling this is possibly the safest, without hardware to test on.
> 
This section of hardware is controlled by mac80211 as is most of the driver.

Users can turn the wireless off then on again to try again but to date 
this is not known to fail with the hardware I have used.

No problems with hardware with this patch.

Tested-by: Malcolm Priestley <tvboxspy@...il.com>