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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <050fa2c3-0ead-66c9-085a-e8c4578512eb@gmail.com>
Date:   Tue, 9 Jan 2018 09:36:38 +0800
From:   Jia-Ju Bai <baijiaju1990@...il.com>
To:     Larry Finger <Larry.Finger@...inger.net>,
        Kalle Valo <kvalo@...eaurora.org>
Cc:     kstewart@...uxfoundation.org, johannes.berg@...el.com,
        tiwai@...e.de, gregkh@...uxfoundation.org,
        linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
        andrew.zaborowski@...el.com, b43-dev@...ts.infradead.org,
        netdev@...r.kernel.org, colin.king@...onical.com
Subject: Re: b43: Replace mdelay with msleep in b43_radio_2057_init_post



On 2018/1/9 0:31, Larry Finger wrote:
> On 01/08/2018 10:21 AM, Kalle Valo wrote:
>> Jia-Ju Bai <baijiaju1990@...il.com> wrote:
>>
>>> b43_radio_2057_init_post is not called in an interrupt handler
>>> nor holding a spinlock.
>>> The function mdelay in it can be replaced with msleep, to reduce 
>>> busy wait.
>>>
>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@...il.com>
>>
>> You submitted an identical patch a week earlier:
>>
>> https://patchwork.kernel.org/patch/10137671/
>>
>> How is this different? Also always add version number to the patch so 
>> that the
>> maintainers can follow the changes easily:
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#patch_version_missing 
>>
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing 
>>
>
> I had negative comments on one of those due to the possibility of 
> msleep(2) extending as long as 20 msec. Until the author, or someone 
> else, can test that this is OK, then the mdelay(2) can only be 
> replaced with usleep_range(2000, 3000).
>
> NACK for both.
>
> Larry
>

Sorry for my mistake.
I have sent a patch v2 using usleep_range(2000, 3000), and you can have 
a look :)


Thanks,
Jia-Ju Bai

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ