Skip to contentSkip to conversation

input_event: Provide override for sparc64

PATCH Applied Deepa Dinamani 4 participants 7 messages Dec 29, 2018 – Jan 16, 2019

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 input_event: Provide override for sparc64

The usec part of the timeval is defined as
__kernel_suseconds_t tv_usec; /* microseconds */

Arnd noticed that sparc64 is the only architecture that defines __kernel_suseconds_t as int rather than long.

This breaks the current y2038 fix for kernel as we only access and define the timeval struct for non-kernel use cases. But, this was hidden by an another typo in the use of __KERNEL__ qualifier.

Fix the typo, and provide an override for sparc64.

Fixes 152194fe9c3f ("Input: extend usable life of event timestamps to 2106 on 32 bit systems")
---
 include/uapi/linux/input.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
include/uapi/linux/input.h +5 -1
index fb78f6f500f3..ffab958bc512 100644
@@ -26,13 +26,17 @@
  */
 
 struct input_event {
-#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL)
+#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL__)
 	struct timeval time;
 #define input_event_sec time.tv_sec
 #define input_event_usec time.tv_usec
 #else
 	__kernel_ulong_t __sec;
+#ifdef CONFIG_SPARC64
+	unsigned int __usec;
+#else
 	__kernel_ulong_t __usec;
+#endif
 #define input_event_sec  __sec
 #define input_event_usec __usec
 #endif
Signature · 1 line
2.17.1
#1 lore raw
Quoted 49 lines · Deepa Dinamani

The usec part of the timeval is defined as
__kernel_suseconds_t tv_usec; /* microseconds */

Arnd noticed that sparc64 is the only architecture that defines __kernel_suseconds_t as int rather than long.

This breaks the current y2038 fix for kernel as we only access and define the timeval struct for non-kernel use cases. But, this was hidden by an another typo in the use of __KERNEL__ qualifier.

Fix the typo, and provide an override for sparc64.

Fixes 152194fe9c3f ("Input: extend usable life of event timestamps to 2106 on 32 bit systems")

---
include/uapi/linux/input.h | 6 +++++-

1 file changed, 5 insertions(+), 1 deletion(-)
include/uapi/linux/input.h +5 -1
index fb78f6f500f3..ffab958bc512 100644
@@ -26,13 +26,17 @@
 */
 
 struct input_event {
-#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL)
+#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL__)
   struct timeval time;
 #define input_event_sec time.tv_sec
 #define input_event_usec time.tv_usec
 #else
   __kernel_ulong_t __sec;
+#ifdef CONFIG_SPARC64
+    unsigned int __usec;
+#else
   __kernel_ulong_t __usec;
+#endif
 #define input_event_sec  __sec
 #define input_event_usec __usec
 #endif
Signature · 1 line
2.17.1

Ping.

This is required for the proper functioning of the y2038 additions to input event.

-Deepa
_______________________________________________
Y2038 mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/y2038

maintainer Applied
#2 lore raw
In reply to Deepa Dinamani
Quoted 11 lines · Deepa Dinamani

The usec part of the timeval is defined as
__kernel_suseconds_t tv_usec; /* microseconds */

Arnd noticed that sparc64 is the only architecture that defines __kernel_suseconds_t as int rather than long.

This breaks the current y2038 fix for kernel as we only access and define the timeval struct for non-kernel use cases. But, this was hidden by an another typo in the use of __KERNEL__ qualifier.

Quoted 5 lines

Fix the typo, and provide an override for sparc64.

Fixes 152194fe9c3f ("Input: extend usable life of event timestamps to 2106 on 32 bit systems")

Applied, thank you.

Quoted 30 lines
---
 include/uapi/linux/input.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
include/uapi/linux/input.h +5 -1
index fb78f6f500f3..ffab958bc512 100644
@@ -26,13 +26,17 @@
  */
 
 struct input_event {
-#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL)
+#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL__)
 	struct timeval time;
 #define input_event_sec time.tv_sec
 #define input_event_usec time.tv_usec
 #else
 	__kernel_ulong_t __sec;
+#ifdef CONFIG_SPARC64
+	unsigned int __usec;
+#else
 	__kernel_ulong_t __usec;
+#endif
 #define input_event_sec  __sec
 #define input_event_usec __usec
 #endif
Signature · 1 line
2.17.1
Signature · 1 line
Dmitry
#3 lore raw
In reply to Deepa Dinamani

include/uapi/linux/input.h line 42

Quoted 13 lines · Deepa Dinamani
        struct timeval time;
 #define input_event_sec time.tv_sec
 #define input_event_usec time.tv_usec
 #else
        __kernel_ulong_t __sec;
include/uapi/linux/input.h +4 -0
+#ifdef CONFIG_SPARC64
+       unsigned int __usec;
+#else
        __kernel_ulong_t __usec;
+#endif
 #define input_event_sec  __sec
 #define input_event_usec __usec
 #endif

Sorry for not having looked at this earlier, I just realized that this is a mistake
in user space: uapi headers are not allowed to reference CONFIG_* symbols, since the headers are supposed to be configuration independent and the CONFIG_* namespace might clash with user space identifiers.

The correct check appears to be

#if defined(__sparc__) && defined(__arch64__)

Arnd

maintainer
#5 lore raw
Quoted 9 lines · David Miller

From: Arnd Bergmann <[email protected]>
Date: Tue, 15 Jan 2019 22:19:27 +0100

Quoted 3 lines

The correct check appears to be

#if defined(__sparc__) && defined(__arch64__)

That is correct.

OK. Deepa, could you please send me a fixup as I already pushed out the original patch?

Thanks.

Signature · 5 lines
Dmitry
_______________________________________________
Y2038 mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/y2038
#6 lore raw
Quoted 9 lines · Dmitry Torokhov
Quoted 6 lines · David Miller

From: Arnd Bergmann <[email protected]>
Date: Tue, 15 Jan 2019 22:19:27 +0100

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

The correct check appears to be

#if defined(__sparc__) && defined(__arch64__)

That is correct.

OK. Deepa, could you please send me a fixup as I already pushed out the original patch?

Ok, I’m traveling. I will post an update in a couple of days.

Thanks,
Deepa