linux-kernel - Re: [PATCH 2/3] staging: r8188eu: refactor rtw

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

Date:   Mon, 21 Feb 2022 23:54:50 +0300
From:   Pavel Skripkin <paskripkin@...il.com>
To:     Michael Straube <straube.linux@...il.com>,
        Dan Carpenter <dan.carpenter@...cle.com>
Cc:     gregkh@...uxfoundation.org, Larry.Finger@...inger.net,
        phil@...lpotter.co.uk, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] staging: r8188eu: refactor rtw_ch2freq()

Hi Michael,

On 2/21/22 22:20, Michael Straube wrote:
>> I'm glad that Pavel noticed this change.  This is a risky thing and
>> should have been noted in the commit message.
>> 
>> Just from a review stand point it would be best to leave the original
>> behavior.
>>
> 
> Do you mean to leave the whole original code including the 5 GHz
> frequencies? Or returning a default value if we have a channel value < 1
> or > 14?
> 

IMO, your version is much cleaner than previous one. This table walk 
seems really unreasonable, since 5 GHz support is really redundant (I 
saw it in other thread)

I'd put just sanity check and return the default value from previous 
version. Maybe even wrapped with unlikely() if we sure, that in normal 
state we won't hit it ;)




With regards,
Pavel Skripkin