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] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 9 Jan 2018 10:07:22 +0100
From:   Arend van Spriel <arend.vanspriel@...adcom.com>
To:     Jia-Ju Bai <baijiaju1990@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     Larry.Finger@...inger.net, kvalo@...eaurora.org,
        kstewart@...uxfoundation.org, johannes.berg@...el.com,
        tiwai@...e.de, colin.king@...onical.com,
        andrew.zaborowski@...el.com, linux-kernel@...r.kernel.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        b43-dev@...ts.infradead.org
Subject: Re: [PATCH v2] b43: Replace mdelay with usleep_range in
 b43_radio_2057_init_post

On 1/9/2018 9:39 AM, Jia-Ju Bai wrote:
>
>
> On 2018/1/9 16:35, Greg KH wrote:
>> On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai 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 usleep_range,
>>> to reduce busy wait.
>>>
>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@...il.com>
>>> ---
>>> v2:
>>> * Replace mdelay with usleep_range, instead of msleep in v1.
>>>    Thank Larry for good advice.
>>> ---
>>>   drivers/net/wireless/broadcom/b43/phy_n.c |    2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
>>> b/drivers/net/wireless/broadcom/b43/phy_n.c
>>> index a5557d7..f2a2f41 100644
>>> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
>>> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
>>> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct
>>> b43_wldev *dev)
>>>       b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
>>>       b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
>>> -    mdelay(2);
>>> +    usleep_range(2000, 3000);
>> Where did 3000 come from?  Are you sure about that?
>
> I am not very sure, and I use it according to Larry's message:

Hi Jia-Ju Bai,

The duration here is for settling the registers so hardware can pick it 
up. Right after this they are written again. Now this is during 
initialization of the radio so not time critical, but probably anything 
in the range of 2000..3000 would also have been fine.

Regards,
Arend

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ