[v3] iio: accel: adxl355: replace usleep_range() with fsleep()

[PATCH v3] iio: accel: adxl355: replace usleep_range() with fsleep()

Posted by Stepan Ionichev 2 weeks, 5 days ago

The "at least 5ms" wait after software reset has no specific upper
bound. Use fsleep() with 5 * USEC_PER_MSEC to make the unit
explicit at the call site.

No functional change.

Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
---
v3:
- Add this changelog (was missing in v2)

v2:
- Use 5 * USEC_PER_MSEC instead of raw 5000

 drivers/iio/accel/adxl355_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/accel/adxl355_core.c b/drivers/iio/accel/adxl355_core.c
index 8f90c58f4..9d4421653 100644
--- a/drivers/iio/accel/adxl355_core.c
+++ b/drivers/iio/accel/adxl355_core.c
@@ -351,7 +351,7 @@ static int adxl355_setup(struct adxl355_data *data)
 			return ret;
 
 		/* Wait at least 5ms after software reset */
-		usleep_range(5000, 10000);
+		fsleep(5 * USEC_PER_MSEC);
 
 		/* Read shadow registers for comparison */
 		ret = regmap_bulk_read(data->regmap,
-- 
2.43.0

Re: [PATCH v3] iio: accel: adxl355: replace usleep_range() with fsleep()

Posted by Andy Shevchenko 2 weeks, 5 days ago

On Sun, May 10, 2026 at 04:38:52PM +0500, Stepan Ionichev wrote:
> The "at least 5ms" wait after software reset has no specific upper
> bound. Use fsleep() with 5 * USEC_PER_MSEC to make the unit
> explicit at the call site.

> No functional change.

Strictly speaking the upper limit is not set as 10 milliseconds now,
but defined by the internals of fsleep(), usually +25%.

Perhaps Jonathan can just drop this sentence from the commit message
whilst applying.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3] iio: accel: adxl355: replace usleep_range() with fsleep()

Posted by Jonathan Cameron 2 weeks, 4 days ago

On Mon, 11 May 2026 10:27:40 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Sun, May 10, 2026 at 04:38:52PM +0500, Stepan Ionichev wrote:
> > The "at least 5ms" wait after software reset has no specific upper
> > bound. Use fsleep() with 5 * USEC_PER_MSEC to make the unit
> > explicit at the call site.  
> 
> > No functional change.  
> 
> Strictly speaking the upper limit is not set as 10 milliseconds now,
> but defined by the internals of fsleep(), usually +25%.

I'm not following.  There doesn't seem to be a statement of anything
about the upper limit that is used - just one on it not being specified
for the part.

> 
> Perhaps Jonathan can just drop this sentence from the commit message
> whilst applying.
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> 
Given I didn't really get the comment - applied as is.

J

Re: [PATCH v3] iio: accel: adxl355: replace usleep_range() with fsleep()

Posted by Andy Shevchenko 2 weeks, 4 days ago

On Mon, May 11, 2026 at 05:13:31PM +0100, Jonathan Cameron wrote:
> On Mon, 11 May 2026 10:27:40 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Sun, May 10, 2026 at 04:38:52PM +0500, Stepan Ionichev wrote:

...

> > > No functional change.  
> > 
> > Strictly speaking the upper limit is not set as 10 milliseconds now,
> > but defined by the internals of fsleep(), usually +25%.
> 
> I'm not following.  There doesn't seem to be a statement of anything
> about the upper limit that is used - just one on it not being specified
> for the part.

I meant that switching from usleep_range() with explicit high limit is
different to implicit fsleep(). And that's a (subtle) functional change.
Hence "No functional change" is not fully true. Hope now it's clearer.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3] iio: accel: adxl355: replace usleep_range() with fsleep()

Posted by Jonathan Cameron 2 weeks, 3 days ago

On Tue, 12 May 2026 10:32:23 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Mon, May 11, 2026 at 05:13:31PM +0100, Jonathan Cameron wrote:
> > On Mon, 11 May 2026 10:27:40 +0300
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:  
> > > On Sun, May 10, 2026 at 04:38:52PM +0500, Stepan Ionichev wrote:  
> 
> ...
> 
> > > > No functional change.    
> > > 
> > > Strictly speaking the upper limit is not set as 10 milliseconds now,
> > > but defined by the internals of fsleep(), usually +25%.  
> > 
> > I'm not following.  There doesn't seem to be a statement of anything
> > about the upper limit that is used - just one on it not being specified
> > for the part.  
> 
> I meant that switching from usleep_range() with explicit high limit is
> different to implicit fsleep(). And that's a (subtle) functional change.
> Hence "No functional change" is not fully true. Hope now it's clearer.
Ah. Got you.  Thanks for talking me through it!

Jonathan

>