Re: [PATCH] thermal: armada: replace msleep with usleep_range for short durations

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hello Mayur, Daniel,

Actually I have a couple of comments :-)

On 18/05/2026 at 19:57:46 +02, Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> wrote:

> On 5/11/26 17:37, Mayur Kumar wrote:
>> The checkpatch tool warns that msleep(10) can sleep for up to 20ms.

This is a tool that gives you raw advices. Is sleeping 20ms a problem in
an init function, clearly outside of any hotpath? Honestly that does not
look like a big issue to me.

>> According to Documentation/timers/timers-howto.rst, usleep_range()

This file has been dropped in favour of a more up-to-date
Documentation/timers/delay_sleep_functions.rst in:

1f455f601e20 ("timers/Documentation: Cleanup delay/sleep documentation")

>> should be used for delays between 1ms and 20ms to provide better
>> timing accuracy.

Again, I don't see the point here, we do not need accuracy, do we?

>> Replace the 10ms msleep with a 10ms-11ms usleep_range.

10 to 11ms feels very arbitrary and has been selected just for getting
the tool happy. The above file states:
#. Use `fsleep()` whenever unsure (as it combines all the advantages of the
   others)
#. Use `*sleep()` whenever possible
#. Use `usleep_range*()` whenever accuracy of `*sleep()` is not sufficient
#. Use `*delay()` for very, very short delays

Accuracy not being a concern here, fsleep() could be the way to go, and
the actual implementation would end up being usleep_range(10000, 20000),
which is exactly what the tool complains about.

In general I would be in favour of avoiding this kind of change that is
not motivated by hardware concerns, but if you really want to fix this
checkpatch.pl warning I believe in such case you should go for an
fsleep().

Thanks,
Miquèl