On Tue, 2014-02-04 at 14:05 -0800, Sebastian Capella wrote:
Quoting Joe Perches (2014-02-04 13:21:02)
On Tue, 2014-02-04 at 12:43 -0800, Sebastian Capella wrote:
Checkpatch reports several warnings in hibernate.c printk use removed, long lines wrapped, whitespace cleanup, extend short msleeps, while loops on two lines.
[]
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
[]
@@ -765,7 +762,7 @@ static int software_resume(void) if (isdigit(resume_file[0]) && resume_wait) { int partno; while (!get_gendisk(swsusp_resume_device, &partno))
msleep(10);
msleep(20);
What good is changing this from 10 to 20?
@@ -776,8 +773,9 @@ static int software_resume(void) wait_for_device_probe(); if (resume_wait) {
while ((swsusp_resume_device = name_to_dev_t(resume_file)) == 0)
msleep(10);
while ((swsusp_resume_device =
name_to_dev_t(resume_file)) == 0)
msleep(20);
here too.
Thanks Joe!
I'm happy to make whatever change is best. I just ran into one checkpatch warning around a printk I indented and figured I'd try to get them all if I could.
Shutting up checkpatch for the sake of shutting of checkpatch is sometimes not the right thing to do.
The delays in question didn't appear timing critical as both are looping waiting for device discovery to complete. They're only enabled when using the resumewait command line parameter.
Any time it happens faster doesn't hurt and can therefore could resume faster no?
Is this an incorrect checkpatch warning? The message from checkpatch implies using msleep for smaller values can be misleading.
That's true, but it doesn't mean it's required to change the code.
- Why not msleep for (1ms - 20ms)? Explained originally here: http://lkml.org/lkml/2007/8/3/250 msleep(1~20) may not do what the caller intends, and will often sleep longer (~20 ms actual sleep for any value given in the 1~20ms range). In many cases this is not the desired behavior.
When I look at kernel/timers.c in my current kernel, I see msleep is using msecs_to_jiffies + 1, and on my current platform this appears to be ~20msec as the jiffies are 10ms.
And on platforms where HZ is 1000, it's still slightly faster.
I'd just leave it alone.