This patch replaces timeval with timespec64 as 32 bit 'struct timeval' will not give current time beyond 2038.
The patch changes the code to use ktime_get_real_ts64() which returns a 'struct timespec64' instead of do_gettimeofday() which returns a 'struct timeval'
This patch also alters the format strings in pr_info() for now.tv_sec and now.tv_nsec to incorporate 'long long' on 32 bit architectures and leading zeroes respectively.
Signed-off-by: Amitoj Kaur Chawla amitoj1606@gmail.com --- drivers/char/ipmi/ipmi_ssif.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c index 877205d..926add4 100644 --- a/drivers/char/ipmi/ipmi_ssif.c +++ b/drivers/char/ipmi/ipmi_ssif.c @@ -52,6 +52,7 @@ #include <linux/kthread.h> #include <linux/acpi.h> #include <linux/ctype.h> +#include <linux/time64.h>
#define PFX "ipmi_ssif: " #define DEVICE_NAME "ipmi_ssif" @@ -1041,12 +1042,12 @@ static void sender(void *send_info, start_next_msg(ssif_info, flags);
if (ssif_info->ssif_debug & SSIF_DEBUG_TIMING) { - struct timeval t; + struct timespec64 t;
- do_gettimeofday(&t); - pr_info("**Enqueue %02x %02x: %ld.%6.6ld\n", + ktime_get_real_ts64(&t); + pr_info("**Enqueue %02x %02x: %lld.%6.06ld\n", msg->data[0], msg->data[1], - (long) t.tv_sec, (long) t.tv_usec); + (long long) t.tv_sec, (long) t.tv_nsec / NSEC_PER_USEC); } }
On Saturday 24 October 2015 00:39:22 Amitoj Kaur Chawla wrote:
This patch replaces timeval with timespec64 as 32 bit 'struct timeval' will not give current time beyond 2038.
The patch changes the code to use ktime_get_real_ts64() which returns a 'struct timespec64' instead of do_gettimeofday() which returns a 'struct timeval'
This patch also alters the format strings in pr_info() for now.tv_sec and now.tv_nsec to incorporate 'long long' on 32 bit architectures and leading zeroes respectively.
Signed-off-by: Amitoj Kaur Chawla amitoj1606@gmail.com
The patch looks correct, but I think that this time the format string was actually ok already for the microsecond value. Just leave it at "%6.6ld" and send it again with the maintainers on Cc.
drivers/char/ipmi/ipmi_ssif.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c index 877205d..926add4 100644 --- a/drivers/char/ipmi/ipmi_ssif.c +++ b/drivers/char/ipmi/ipmi_ssif.c @@ -52,6 +52,7 @@ #include <linux/kthread.h> #include <linux/acpi.h> #include <linux/ctype.h> +#include <linux/time64.h> #define PFX "ipmi_ssif: " #define DEVICE_NAME "ipmi_ssif" @@ -1041,12 +1042,12 @@ static void sender(void *send_info, start_next_msg(ssif_info, flags); if (ssif_info->ssif_debug & SSIF_DEBUG_TIMING) {
struct timeval t;
struct timespec64 t;
do_gettimeofday(&t);pr_info("**Enqueue %02x %02x: %ld.%6.6ld\n",
ktime_get_real_ts64(&t);pr_info("**Enqueue %02x %02x: %lld.%6.06ld\n", msg->data[0], msg->data[1],
(long) t.tv_sec, (long) t.tv_usec);
(long long) t.tv_sec, (long) t.tv_nsec / NSEC_PER_USEC);}
On Sat, Oct 24, 2015 at 12:53 AM, Arnd Bergmann arnd@arndb.de wrote:
On Saturday 24 October 2015 00:39:22 Amitoj Kaur Chawla wrote:
This patch replaces timeval with timespec64 as 32 bit 'struct timeval' will not give current time beyond 2038.
The patch changes the code to use ktime_get_real_ts64() which returns a 'struct timespec64' instead of do_gettimeofday() which returns a 'struct timeval'
This patch also alters the format strings in pr_info() for now.tv_sec and now.tv_nsec to incorporate 'long long' on 32 bit architectures and leading zeroes respectively.
Signed-off-by: Amitoj Kaur Chawla amitoj1606@gmail.com
The patch looks correct, but I think that this time the format string was actually ok already for the microsecond value. Just leave it at "%6.6ld" and send it again with the maintainers on Cc.
Oh okay can I ask the reason that the change was required there but not here?
On Saturday 24 October 2015 00:58:12 Amitoj Kaur Chawla wrote:
On Sat, Oct 24, 2015 at 12:53 AM, Arnd Bergmann arnd@arndb.de wrote:
On Saturday 24 October 2015 00:39:22 Amitoj Kaur Chawla wrote:
This patch replaces timeval with timespec64 as 32 bit 'struct timeval' will not give current time beyond 2038.
The patch changes the code to use ktime_get_real_ts64() which returns a 'struct timespec64' instead of do_gettimeofday() which returns a 'struct timeval'
This patch also alters the format strings in pr_info() for now.tv_sec and now.tv_nsec to incorporate 'long long' on 32 bit architectures and leading zeroes respectively.
Signed-off-by: Amitoj Kaur Chawla amitoj1606@gmail.com
The patch looks correct, but I think that this time the format string was actually ok already for the microsecond value. Just leave it at "%6.6ld" and send it again with the maintainers on Cc.
Oh okay can I ask the reason that the change was required there but not here?
The other one was "%lu", which has no leading zeroes, while this one was "%6.6ld", which does.
I keep getting confused by printf format strings and sometimes have to try these out myself, but my understanding is that these all behave the same way:
"%06ld" "%.6ld" "%6.6ld" "%6.06ld"
Arnd
On Sat, Oct 24, 2015 at 1:04 AM, Arnd Bergmann arnd@arndb.de wrote:
On Saturday 24 October 2015 00:58:12 Amitoj Kaur Chawla wrote:
On Sat, Oct 24, 2015 at 12:53 AM, Arnd Bergmann arnd@arndb.de wrote:
On Saturday 24 October 2015 00:39:22 Amitoj Kaur Chawla wrote:
This patch replaces timeval with timespec64 as 32 bit 'struct timeval' will not give current time beyond 2038.
The patch changes the code to use ktime_get_real_ts64() which returns a 'struct timespec64' instead of do_gettimeofday() which returns a 'struct timeval'
This patch also alters the format strings in pr_info() for now.tv_sec and now.tv_nsec to incorporate 'long long' on 32 bit architectures and leading zeroes respectively.
Signed-off-by: Amitoj Kaur Chawla amitoj1606@gmail.com
The patch looks correct, but I think that this time the format string was actually ok already for the microsecond value. Just leave it at "%6.6ld" and send it again with the maintainers on Cc.
Oh okay can I ask the reason that the change was required there but not here?
The other one was "%lu", which has no leading zeroes, while this one was "%6.6ld", which does.
I keep getting confused by printf format strings and sometimes have to try these out myself, but my understanding is that these all behave the same way:
"%06ld" "%.6ld" "%6.6ld" "%6.06ld"
Arnd
Oh, yes in the previous change I had tried for "%lu" myself, with several examples. This time I didn't, not paying attention to the change. My bad.
-
Amitoj Kaur Chawla -
Arnd Bergmann