The checkpatch tool warns that msleep(10) can sleep for up to 20ms.
According to Documentation/timers/timers-howto.rst, usleep_range()
should be used for delays between 1ms and 20ms to provide better
timing accuracy.

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

Signed-off-by: Mayur Kumar <kmayur809@gmail.com>
---
 drivers/thermal/armada_thermal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index c2fbdb534f6..96965f393b4 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -178,7 +178,7 @@ static void armada370_init(struct platform_device *pdev,
 
 	regmap_write(priv->syscon, data->syscon_control1_off, reg);
 
-	msleep(10);
+	usleep_range(10000, 11000);
 }
 
 static void armada375_init(struct platform_device *pdev,
-- 
2.34.1

On 5/11/26 17:37, Mayur Kumar wrote:
> The checkpatch tool warns that msleep(10) can sleep for up to 20ms.
> According to Documentation/timers/timers-howto.rst, usleep_range()
> should be used for delays between 1ms and 20ms to provide better
> timing accuracy.
> 
> Replace the 10ms msleep with a 10ms-11ms usleep_range.
> 
> Signed-off-by: Mayur Kumar <kmayur809@gmail.com>
> ---

Miquel,

if you are not against this change, I'll pick it up

Thanks


>   drivers/thermal/armada_thermal.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index c2fbdb534f6..96965f393b4 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -178,7 +178,7 @@ static void armada370_init(struct platform_device *pdev,
>   
>   	regmap_write(priv->syscon, data->syscon_control1_off, reg);
>   
> -	msleep(10);
> +	usleep_range(10000, 11000);
>   }
>   
>   static void armada375_init(struct platform_device *pdev,

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