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

[Maxwell Doose]

On Tue, May 5, 2026 at 4:26 PM Joshua Crofts <joshua.crofts1@xxxxxxxxx> wrote:
>
> Hi Max,
>
> > 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.
>
> > 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.
>

Sorry if there was any confusion, I just double checked the docs
myself, I was saying if we do fsleep(100); wouldn't that mean the
allowable range is 100-125us? Might put some extra strain vs. the
400us we had before. If I'm incorrect on that you can call me out on
that.

>
> 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.
>

Probably true, but like above my only concern is timing.

best regards,
max



>
> --
> Kind regards
>
> CJD