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

[Joshua Crofts]

On Tue, 5 May 2026 at 23:42, Maxwell Doose <m32285159@xxxxxxxxx> wrote:
>
> 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.

Okay, now I understand. From a scheduling perspective you're right,
it would be less strain. At the same time I don't think that was the original
intention - the author probably just slipped a random value relatively in
range to satisfy the max parameter.

Either way, we should perhaps take this up with the reviewers, as Jonathan
and Andy (and Sashiko) didn't have any issue with this.

-- 
Kind regards

CJD