Re: [PATCH v5 03/18] iio: magnetometer: ak8975: replace usleep_range() with fsleep()

[Andy Shevchenko]

On Tue, May 05, 2026 at 11:26:08PM +0200, Joshua Crofts wrote:
> On Tue, 5 May 2026 at 22:30, Maxwell Doose <m32285159@xxxxxxxxx> wrote:
> > On Tue, May 5, 2026 at 6:53 AM Joshua Crofts via B4 Relay
> > <devnull+joshua.crofts1.gmail.com@xxxxxxxxxx> wrote:
> > >
> > > Replace usleep_range() calls with fsleep(), passing the minimum value
> > > required by the sensor for hardware delays.
> > >
> > > fsleep() automatically selects the optimal sleep mechanism, simplifying
> > > driver code and time management.

[snip]

> > Looks fine overall but has this been tested on actual hardware? Just
> > want to double check since this touches the set_mode and power_on
> > logic.
> 
> Fair enough, this series mostly concerned code cleanup and moving
> away from older driver programming practices, so it shouldn't mess
> with the functioning logic as much - however it would be more than
> welcome if someone had the hardware to test it.

This simple patch doesn't change the minimum time to sleep, assuming the driver
was tested previously (and it had to be), the given change is very unlikely to
introduce regressions. Also note that the similar changes have been done all
around the kernel in the past few month and I haven't heard it brought a
regression to the users (but if you, Maxwell, have some pointers to otherwise,
please share, I would really like to see such a report!).

> > Also I will say it may be better to keep usleep_range() since
> > it's more explicit, which will likely be better for the future to make
> > it obvious. Also, I was taking a look at the docs for fsleep() and it
> > provides "maximum 25% slack", which means we're stripping away almost
> > 375us on one of these calls. And besides, it would eventually just
> > call usleep_range() anyways.
> 
> I disagree here. If you look at the documentation for msleep(), you can see
> that "slack" is actually an addition to the delay time, not a
> subtraction. fsleep()
> will always guarantee a delay of at least what's supplied as the parameter.
> 
> About fsleep() translating to usleep_range() - yes, you're correct about that,
> however not only it's more modern practice, it also doesn't require the
> programmer to add an additional arbitrary max value, fsleep() just
> adds it itself.
> As for explicitness, I think fsleep(500) is explicit enough, as described above.

Yes, fsleep() is recommended way of non-atomic sleeps with a microsecond
granularity.

-- 
With Best Regards,
Andy Shevchenko