[PATCH] iio: pressure: bm1390: replace short msleeps with usleep_range

[PATCH] iio: pressure: bm1390: replace short msleeps with usleep_range

[Hungyu Lin]

Replace msleep(1) with usleep_range(1000, 2000) for the
driver's short delays.

The BM1390 datasheet specifies a 1 ms reset cancel wait time
(tSC1) during the power-on sequence. Use usleep_range() for
these short delays, as it is more appropriate than msleep()
and avoids unnecessarily long sleeps.

Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
---
 drivers/iio/pressure/rohm-bm1390.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/pressure/rohm-bm1390.c b/drivers/iio/pressure/rohm-bm1390.c
index 08146ca0f91d..35b9abc25a8a 100644
--- a/drivers/iio/pressure/rohm-bm1390.c
+++ b/drivers/iio/pressure/rohm-bm1390.c
@@ -486,21 +486,21 @@ static int bm1390_chip_init(struct bm1390_data *data)
 	if (ret)
 		return ret;
 
-	msleep(1);
+	usleep_range(1000, 2000);
 
 	ret = regmap_write_bits(data->regmap, BM1390_REG_RESET,
 				BM1390_MASK_RESET, BM1390_RESET);
 	if (ret)
 		return ret;
 
-	msleep(1);
+	usleep_range(1000, 2000);
 
 	ret = regmap_write_bits(data->regmap, BM1390_REG_RESET,
 				BM1390_MASK_RESET, BM1390_RESET_RELEASE);
 	if (ret)
 		return ret;
 
-	msleep(1);
+	usleep_range(1000, 2000);
 
 	ret = regmap_reinit_cache(data->regmap, &bm1390_regmap);
 	if (ret) {
@@ -575,7 +575,7 @@ static int bm1390_fifo_disable(struct iio_dev *idev)
 	struct bm1390_data *data = iio_priv(idev);
 	int ret;
 
-	msleep(1);
+	usleep_range(1000, 2000);
 
 	guard(mutex)(&data->mutex);
 	ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP);
-- 
2.34.1

Re: [PATCH] iio: pressure: bm1390: replace short msleeps with usleep_range

[Jonathan Cameron]

On Sun,  7 Jun 2026 14:00:18 +0000
Hungyu Lin <dennylin0707@gmail.com> wrote:

> Replace msleep(1) with usleep_range(1000, 2000) for the
> driver's short delays.
> 
> The BM1390 datasheet specifies a 1 ms reset cancel wait time
> (tSC1) during the power-on sequence. Use usleep_range() for
> these short delays, as it is more appropriate than msleep()
> and avoids unnecessarily long sleeps.

Hi Hungyu,

Use fsleep() which has the added advantage of standardizing the
'slack' so we don't have to thing about the values chosen

Thanks,

Jonathan

> 
> Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
> ---
>  drivers/iio/pressure/rohm-bm1390.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/pressure/rohm-bm1390.c b/drivers/iio/pressure/rohm-bm1390.c
> index 08146ca0f91d..35b9abc25a8a 100644
> --- a/drivers/iio/pressure/rohm-bm1390.c
> +++ b/drivers/iio/pressure/rohm-bm1390.c
> @@ -486,21 +486,21 @@ static int bm1390_chip_init(struct bm1390_data *data)
>  	if (ret)
>  		return ret;
>  
> -	msleep(1);
> +	usleep_range(1000, 2000);
>  
>  	ret = regmap_write_bits(data->regmap, BM1390_REG_RESET,
>  				BM1390_MASK_RESET, BM1390_RESET);
>  	if (ret)
>  		return ret;
>  
> -	msleep(1);
> +	usleep_range(1000, 2000);
>  
>  	ret = regmap_write_bits(data->regmap, BM1390_REG_RESET,
>  				BM1390_MASK_RESET, BM1390_RESET_RELEASE);
>  	if (ret)
>  		return ret;
>  
> -	msleep(1);
> +	usleep_range(1000, 2000);
>  
>  	ret = regmap_reinit_cache(data->regmap, &bm1390_regmap);
>  	if (ret) {
> @@ -575,7 +575,7 @@ static int bm1390_fifo_disable(struct iio_dev *idev)
>  	struct bm1390_data *data = iio_priv(idev);
>  	int ret;
>  
> -	msleep(1);
> +	usleep_range(1000, 2000);
>  
>  	guard(mutex)(&data->mutex);
>  	ret = bm1390_meas_set(data, BM1390_MEAS_MODE_STOP);

Re: [PATCH] iio: pressure: bm1390: replace short msleeps with usleep_range

[Andy Shevchenko]

On Mon, Jun 08, 2026 at 06:41:54PM +0100, Jonathan Cameron wrote:
> On Sun,  7 Jun 2026 14:00:18 +0000
> Hungyu Lin <dennylin0707@gmail.com> wrote:
> 
> > Replace msleep(1) with usleep_range(1000, 2000) for the
> > driver's short delays.
> > 
> > The BM1390 datasheet specifies a 1 ms reset cancel wait time
> > (tSC1) during the power-on sequence. Use usleep_range() for
> > these short delays, as it is more appropriate than msleep()
> > and avoids unnecessarily long sleeps.
> 
> Use fsleep() which has the added advantage of standardizing the
> 'slack' so we don't have to thing about the values chosen

While true, msleep(1) is kinda idiomatic, we don't need to hunt subtle timing
issues in case of switching to stricter fsleep(), which will most likely choose
usleep_range() beneath. TL;DR: I do not see a value in this change.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] iio: pressure: bm1390: replace short msleeps with usleep_range

[Matti Vaittinen]

On 09/06/2026 09:13, Andy Shevchenko wrote:
> On Mon, Jun 08, 2026 at 06:41:54PM +0100, Jonathan Cameron wrote:
>> On Sun,  7 Jun 2026 14:00:18 +0000
>> Hungyu Lin <dennylin0707@gmail.com> wrote:
>>
>>> Replace msleep(1) with usleep_range(1000, 2000) for the
>>> driver's short delays.
>>>
>>> The BM1390 datasheet specifies a 1 ms reset cancel wait time
>>> (tSC1) during the power-on sequence. Use usleep_range() for
>>> these short delays, as it is more appropriate than msleep()
>>> and avoids unnecessarily long sleeps.
>>
>> Use fsleep() which has the added advantage of standardizing the
>> 'slack' so we don't have to thing about the values chosen
> 
> While true, msleep(1) is kinda idiomatic, we don't need to hunt subtle timing
> issues in case of switching to stricter fsleep(), which will most likely choose
> usleep_range() beneath. TL;DR: I do not see a value in this change.
> 

I don't see the value either, unless there is a real problem the patch 
author has encountered. If there is a real world problem this is solving 
- please state it. My stance on fsleep() Vs. msleep() in ASYNC probes 
can be read from discussion (bikeshedding) between me and Nuno ;)

https://lore.kernel.org/all/14a23df0e1828b72b8b03c358980fe08a12bb216.camel@gmail.com/

Yours,
	-- Matti


-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

Re: [PATCH] iio: pressure: bm1390: replace short msleeps with usleep_range

[Hungyu Lin]

> I don't see the value either, unless there is a real problem the patch
> author has encountered. If there is a real world problem this is solving
> - please state it. My stance on fsleep() Vs. msleep() in ASYNC probes
> can be read from discussion (bikeshedding) between me and Nuno ;)
>
> https://lore.kernel.org/all/14a23df0e1828b72b8b03c358980fe08a12bb216.camel@gmail.com/
>

Hi Jonathan, Andy, Matti,

Thanks for the review.

My motivation was based on the BM1390 datasheet specifying a 1 ms
reset cancel wait time (tSC1).

For additional context, I contacted ROHM regarding the timing
requirement and received the following response from their sales
representative after consulting with their engineering team:

"The engineer confirmed that setting a delay longer than 1 ms does not
have any significant impact on subsequent operation."

Given this feedback and the comments in this thread, I agree that I do
not have evidence of any real-world issue caused by the existing
msleep(1) usage, nor a clear functional benefit from this change.

Thanks for the feedback.

Best regards,
Hungyu

Re: [PATCH] iio: pressure: bm1390: replace short msleeps with usleep_range

[Andy Shevchenko]

On Mon, Jun 15, 2026 at 01:51:55PM -0700, Hungyu Lin wrote:

,,,

> > I don't see the value either, unless there is a real problem the patch
> > author has encountered. If there is a real world problem this is solving
> > - please state it. My stance on fsleep() Vs. msleep() in ASYNC probes
> > can be read from discussion (bikeshedding) between me and Nuno ;)
> >
> > https://lore.kernel.org/all/14a23df0e1828b72b8b03c358980fe08a12bb216.camel@gmail.com/
> 
> My motivation was based on the BM1390 datasheet specifying a 1 ms
> reset cancel wait time (tSC1).
> 
> For additional context, I contacted ROHM regarding the timing
> requirement and received the following response from their sales
> representative after consulting with their engineering team:

Wow! Thanks for doing that. I would appreciate the contributors will do like
you have done in this case and consult with a vendor in case of doubt.
(Yeah, some vendors are unresponsive, but it's not our issue.)

> "The engineer confirmed that setting a delay longer than 1 ms does not
> have any significant impact on subsequent operation."
> 
> Given this feedback and the comments in this thread, I agree that I do
> not have evidence of any real-world issue caused by the existing
> msleep(1) usage, nor a clear functional benefit from this change.

-- 
With Best Regards,
Andy Shevchenko