Return-path: Received: from mail-io0-f195.google.com ([209.85.223.195]:37220 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751802AbeAIIjz (ORCPT ); Tue, 9 Jan 2018 03:39:55 -0500 Subject: Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post To: Greg KH Cc: Larry.Finger@lwfinger.net, kvalo@codeaurora.org, kstewart@linuxfoundation.org, johannes.berg@intel.com, tiwai@suse.de, colin.king@canonical.com, andrew.zaborowski@intel.com, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, b43-dev@lists.infradead.org References: <1515462006-6144-1-git-send-email-baijiaju1990@gmail.com> <20180109083541.GA13460@kroah.com> From: Jia-Ju Bai Message-ID: <4201e8cd-81ba-ab7d-2a0d-af957c5dfed6@gmail.com> (sfid-20180109_094046_347876_9C98CB41) Date: Tue, 9 Jan 2018 16:39:31 +0800 MIME-Version: 1.0 In-Reply-To: <20180109083541.GA13460@kroah.com> Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: 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 >> --- >> 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: > 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). Thanks, Jia-Ju Bai