* Re: [PATCH v2 1/2] HID: use BIT macro instead of plain integers for flags
From: Dmitry Torokhov @ 2017-12-08 19:30 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, Peter Hutterer, linux-input, linux-kernel
In-Reply-To: <20171208142818.15156-2-benjamin.tissoires@redhat.com>
On Fri, Dec 08, 2017 at 03:28:17PM +0100, Benjamin Tissoires wrote:
> This can lead to some hairy situation with the developer losing
> a day or two realizing that 4 should be after 2, not 3.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
Please add
#include <linux/bitops.h>
to make sure we have definition if BIT(), otherwise
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks!
>
> new in v2
>
> include/linux/hid.h | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index a62ee4a609ac..421b62b77c69 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -494,13 +494,13 @@ struct hid_output_fifo {
> char *raw_report;
> };
>
> -#define HID_CLAIMED_INPUT 1
> -#define HID_CLAIMED_HIDDEV 2
> -#define HID_CLAIMED_HIDRAW 4
> -#define HID_CLAIMED_DRIVER 8
> +#define HID_CLAIMED_INPUT BIT(0)
> +#define HID_CLAIMED_HIDDEV BIT(1)
> +#define HID_CLAIMED_HIDRAW BIT(2)
> +#define HID_CLAIMED_DRIVER BIT(3)
>
> -#define HID_STAT_ADDED 1
> -#define HID_STAT_PARSED 2
> +#define HID_STAT_ADDED BIT(0)
> +#define HID_STAT_PARSED BIT(1)
>
> struct hid_input {
> struct list_head list;
> --
> 2.14.3
>
--
Dmitry
^ permalink raw reply
* [PATCH 1/1] HID: core: rewrite the hid-generic automatic unbind
From: Benjamin Tissoires @ 2017-12-08 14:29 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, linux-kernel, Benjamin Tissoires
We actually can have the unbind/rebind logic in hid-core.c, leaving
only the match function in hid-generic.
This makes hid-generic simpler and the whole logic simpler too.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Hi Jiri,
while trying to find out a local bug, I figured out we don't really
need the bus_add_driver and bus_removed_driver callbacks.
This makes the code simpler and also allows other drivers to remove
themself if other conditions are met. They just need to implement a smart
enough .matchcallback and they are done.
Cheers,
Benjamin
drivers/hid/hid-core.c | 35 ++++++++++++++++++++++++-----------
drivers/hid/hid-generic.c | 33 ---------------------------------
include/linux/hid.h | 4 ----
3 files changed, 24 insertions(+), 48 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c2560aae5542..c058bb911ca1 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2197,31 +2197,40 @@ void hid_destroy_device(struct hid_device *hdev)
EXPORT_SYMBOL_GPL(hid_destroy_device);
-static int __bus_add_driver(struct device_driver *drv, void *data)
+static int __hid_bus_reprobe_drivers(struct device *dev, void *data)
{
- struct hid_driver *added_hdrv = data;
- struct hid_driver *hdrv = to_hid_driver(drv);
+ struct hid_driver *hdrv = data;
+ struct hid_device *hdev = to_hid_device(dev);
- if (hdrv->bus_add_driver)
- hdrv->bus_add_driver(added_hdrv);
+ if (hdev->driver == hdrv &&
+ !hdrv->match(hdev, hid_ignore_special_drivers))
+ return device_reprobe(dev);
return 0;
}
-static int __bus_removed_driver(struct device_driver *drv, void *data)
+static int __hid_bus_driver_added(struct device_driver *drv, void *data)
{
- struct hid_driver *removed_hdrv = data;
struct hid_driver *hdrv = to_hid_driver(drv);
- if (hdrv->bus_removed_driver)
- hdrv->bus_removed_driver(removed_hdrv);
+ if (hdrv->match) {
+ bus_for_each_dev(&hid_bus_type, NULL, hdrv,
+ __hid_bus_reprobe_drivers);
+ }
return 0;
}
+static int __bus_removed_driver(struct device_driver *drv, void *data)
+{
+ return bus_rescan_devices(&hid_bus_type);
+}
+
int __hid_register_driver(struct hid_driver *hdrv, struct module *owner,
const char *mod_name)
{
+ int ret;
+
hdrv->driver.name = hdrv->name;
hdrv->driver.bus = &hid_bus_type;
hdrv->driver.owner = owner;
@@ -2230,9 +2239,13 @@ int __hid_register_driver(struct hid_driver *hdrv, struct module *owner,
INIT_LIST_HEAD(&hdrv->dyn_list);
spin_lock_init(&hdrv->dyn_lock);
- bus_for_each_drv(&hid_bus_type, NULL, hdrv, __bus_add_driver);
+ ret = driver_register(&hdrv->driver);
+
+ if (ret == 0)
+ bus_for_each_drv(&hid_bus_type, NULL, NULL,
+ __hid_bus_driver_added);
- return driver_register(&hdrv->driver);
+ return ret;
}
EXPORT_SYMBOL_GPL(__hid_register_driver);
diff --git a/drivers/hid/hid-generic.c b/drivers/hid/hid-generic.c
index 3c0a1bf433d7..c25b4718de44 100644
--- a/drivers/hid/hid-generic.c
+++ b/drivers/hid/hid-generic.c
@@ -26,37 +26,6 @@
static struct hid_driver hid_generic;
-static int __unmap_hid_generic(struct device *dev, void *data)
-{
- struct hid_driver *hdrv = data;
- struct hid_device *hdev = to_hid_device(dev);
-
- /* only unbind matching devices already bound to hid-generic */
- if (hdev->driver != &hid_generic ||
- hid_match_device(hdev, hdrv) == NULL)
- return 0;
-
- if (dev->parent) /* Needed for USB */
- device_lock(dev->parent);
- device_release_driver(dev);
- if (dev->parent)
- device_unlock(dev->parent);
-
- return 0;
-}
-
-static void hid_generic_add_driver(struct hid_driver *hdrv)
-{
- bus_for_each_dev(&hid_bus_type, NULL, hdrv, __unmap_hid_generic);
-}
-
-static void hid_generic_removed_driver(struct hid_driver *hdrv)
-{
- int ret;
-
- ret = driver_attach(&hid_generic.driver);
-}
-
static int __check_hid_generic(struct device_driver *drv, void *data)
{
struct hid_driver *hdrv = to_hid_driver(drv);
@@ -97,8 +66,6 @@ static struct hid_driver hid_generic = {
.name = "hid-generic",
.id_table = hid_table,
.match = hid_generic_match,
- .bus_add_driver = hid_generic_add_driver,
- .bus_removed_driver = hid_generic_removed_driver,
};
module_hid_driver(hid_generic);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 091a81cf330f..a62ee4a609ac 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -686,8 +686,6 @@ struct hid_usage_id {
* @input_mapped: invoked on input registering after mapping an usage
* @input_configured: invoked just before the device is registered
* @feature_mapping: invoked on feature registering
- * @bus_add_driver: invoked when a HID driver is about to be added
- * @bus_removed_driver: invoked when a HID driver has been removed
* @suspend: invoked on suspend (NULL means nop)
* @resume: invoked on resume if device was not reset (NULL means nop)
* @reset_resume: invoked on resume if device was reset (NULL means nop)
@@ -742,8 +740,6 @@ struct hid_driver {
void (*feature_mapping)(struct hid_device *hdev,
struct hid_field *field,
struct hid_usage *usage);
- void (*bus_add_driver)(struct hid_driver *driver);
- void (*bus_removed_driver)(struct hid_driver *driver);
#ifdef CONFIG_PM
int (*suspend)(struct hid_device *hdev, pm_message_t message);
int (*resume)(struct hid_device *hdev);
--
2.14.3
^ permalink raw reply related
* [PATCH v2 0/2] HID: input: do not increment usages when a duplicate is found
From: Benjamin Tissoires @ 2017-12-08 14:28 UTC (permalink / raw)
To: Jiri Kosina, Dmitry Torokhov, Peter Hutterer
Cc: linux-input, linux-kernel, Benjamin Tissoires
Hi Jiri,
slightly modified version (to actually make it working this time).
There is not much to add, the differences are in the commit messages
and in the notes of each patch.
Cheers,
Benjamin
Benjamin Tissoires (2):
HID: use BIT macro instead of plain integers for flags
HID: input: do not increment usages when a duplicate is found
drivers/hid/hid-input.c | 33 +++++++++++++++++++++++++++++++--
include/linux/hid.h | 14 ++++++++------
2 files changed, 39 insertions(+), 8 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH v2 2/2] HID: input: do not increment usages when a duplicate is found
From: Benjamin Tissoires @ 2017-12-08 14:28 UTC (permalink / raw)
To: Jiri Kosina, Dmitry Torokhov, Peter Hutterer
Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20171208142818.15156-1-benjamin.tissoires@redhat.com>
This is something that bothered us from a long time. When hid-input
doesn't know how to map a usage, it uses *_MISC. But there is something
else which increments the usage if the evdev code is already used.
This leads to few issues:
- some devices may have their ABS_X mapped to ABS_Y if they export a bad
set of usages (see the DragonRise joysticks IIRC -> fixed in a specific
HID driver)
- *_MISC + N might (will) conflict with other defined axes (my Logitech
H800 exports some multitouch axes because of that)
- this prevents to freely add some new evdev usages, because "hey, my
headset will now report ABS_COFFEE, and it's not coffee capable".
So let's try to kill this nonsense, and hope we won't break too many
devices.
I my headset case, the ABS_MISC axes are created because of some
proprietary usages, so we might not break that many devices.
For backward compatibility, a quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE
is created and can be applied to any device that needs this behavior.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
changes in v2:
- fixed a bug where the flag was not used properly and prevented to
remove devices
- downgrade the error message from info to debug, given that when
hid-generic binds first, it will output such kernel log for every
multitouch device.
drivers/hid/hid-input.c | 33 +++++++++++++++++++++++++++++++--
include/linux/hid.h | 2 ++
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 04d01b57d94c..31bbeb7019bd 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1100,8 +1100,31 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
set_bit(usage->type, input->evbit);
- while (usage->code <= max && test_and_set_bit(usage->code, bit))
- usage->code = find_next_zero_bit(bit, max + 1, usage->code);
+ /*
+ * This part is *really* controversial:
+ * - HID aims at being generic so we should do our best to export
+ * all incoming events
+ * - HID describes what events are, so there is no reason for ABS_X
+ * to be mapped to ABS_Y
+ * - HID is using *_MISC+N as a default value, but nothing prevents
+ * *_MISC+N to overwrite a legitimate even, which confuses userspace
+ * (for instance ABS_MISC + 7 is ABS_MT_SLOT, which has a different
+ * processing)
+ *
+ * If devices still want to use this (at their own risk), they will
+ * have to use the quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE, but
+ * the default should be a reliable mapping.
+ */
+ while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
+ if (device->quirks & HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE) {
+ usage->code = find_next_zero_bit(bit,
+ max + 1,
+ usage->code);
+ } else {
+ device->status |= HID_STAT_DUP_DETECTED;
+ goto ignore;
+ }
+ }
if (usage->code > max)
goto ignore;
@@ -1610,6 +1633,8 @@ int hidinput_connect(struct hid_device *hid, unsigned int force)
INIT_LIST_HEAD(&hid->inputs);
INIT_WORK(&hid->led_work, hidinput_led_worker);
+ hid->status &= ~HID_STAT_DUP_DETECTED;
+
if (!force) {
for (i = 0; i < hid->maxcollection; i++) {
struct hid_collection *col = &hid->collection[i];
@@ -1676,6 +1701,10 @@ int hidinput_connect(struct hid_device *hid, unsigned int force)
goto out_unwind;
}
+ if (hid->status & HID_STAT_DUP_DETECTED)
+ hid_dbg(hid,
+ "Some usages could not be mapped, please use HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE if this is legitimate.\n");
+
return 0;
out_unwind:
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 421b62b77c69..de3a8700ccf1 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -344,6 +344,7 @@ struct hid_item {
#define HID_QUIRK_SKIP_OUTPUT_REPORT_ID 0x00020000
#define HID_QUIRK_NO_OUTPUT_REPORTS_ON_INTR_EP 0x00040000
#define HID_QUIRK_HAVE_SPECIAL_DRIVER 0x00080000
+#define HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE 0x00100000
#define HID_QUIRK_FULLSPEED_INTERVAL 0x10000000
#define HID_QUIRK_NO_INIT_REPORTS 0x20000000
#define HID_QUIRK_NO_IGNORE 0x40000000
@@ -501,6 +502,7 @@ struct hid_output_fifo {
#define HID_STAT_ADDED BIT(0)
#define HID_STAT_PARSED BIT(1)
+#define HID_STAT_DUP_DETECTED BIT(2)
struct hid_input {
struct list_head list;
--
2.14.3
^ permalink raw reply related
* [PATCH v2 1/2] HID: use BIT macro instead of plain integers for flags
From: Benjamin Tissoires @ 2017-12-08 14:28 UTC (permalink / raw)
To: Jiri Kosina, Dmitry Torokhov, Peter Hutterer
Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20171208142818.15156-1-benjamin.tissoires@redhat.com>
This can lead to some hairy situation with the developer losing
a day or two realizing that 4 should be after 2, not 3.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
new in v2
include/linux/hid.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index a62ee4a609ac..421b62b77c69 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -494,13 +494,13 @@ struct hid_output_fifo {
char *raw_report;
};
-#define HID_CLAIMED_INPUT 1
-#define HID_CLAIMED_HIDDEV 2
-#define HID_CLAIMED_HIDRAW 4
-#define HID_CLAIMED_DRIVER 8
+#define HID_CLAIMED_INPUT BIT(0)
+#define HID_CLAIMED_HIDDEV BIT(1)
+#define HID_CLAIMED_HIDRAW BIT(2)
+#define HID_CLAIMED_DRIVER BIT(3)
-#define HID_STAT_ADDED 1
-#define HID_STAT_PARSED 2
+#define HID_STAT_ADDED BIT(0)
+#define HID_STAT_PARSED BIT(1)
struct hid_input {
struct list_head list;
--
2.14.3
^ permalink raw reply related
* [PATCH] Input: atmel_mxt_ts: Add touchscreen support for Chromebooks with upstream coreboot
From: Jean Lucas @ 2017-12-08 8:06 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov; +Cc: linux-input, linux-kernel
Chromebooks use coreboot for system initialization. coreboot has always
had the default mainboard vendor string for Google machines set to
"Google". Google engineers set this string to "GOOGLE" for the coreboot
copy within their Chromium OS tree. The atmel_mxt_ts driver in its
current state is set to match the latter case; it will only bind to a
Chromebook's touchscreen either if the device uses the vendor coreboot
firmware (providing the matching mainboard vendor string), or if a user
running upstream coreboot has manually set the string to "GOOGLE". Let's
add a match for coreboot's default.
Signed-off-by: Jean Lucas <jean@4ray.co>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 7659bc48f1db..43d1ea4145d7 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -3038,6 +3038,14 @@ static const struct dmi_system_id mxt_dmi_table[] = {
},
.driver_data = chromebook_platform_data,
},
+ {
+ /* Chromebooks with a custom coreboot version */
+ .ident = "Chromebook",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Google"),
+ },
+ .driver_data = chromebook_platform_data,
+ },
{ }
};
--
2.15.1
^ permalink raw reply related
* Re: [PATCH v4 1/4] uinput: Use monotonic times for uinput timestamps.
From: Arnd Bergmann @ 2017-12-07 22:24 UTC (permalink / raw)
To: Deepa Dinamani
Cc: Dmitry Torokhov, open list:HID CORE LAYER,
Linux Kernel Mailing List, Peter Hutterer, y2038 Mailman List
In-Reply-To: <20171207181306.5623-2-deepa.kernel@gmail.com>
On Thu, Dec 7, 2017 at 7:13 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> struct timeval which is part of struct input_event to
> maintain the event times is not y2038 safe.
>
> Real time timestamps are also not ideal for input_event
> as this time can go backwards as noted in the patch
> a80b83b7b8 by John Stultz.
>
> The patch switches the timestamps to use monotonic time
> from realtime time. This is assuming no one is using
> absolute times from these timestamps.
>
> The structure to maintain input events will be changed
> in a different patch.
>
> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] HID: wacom: EKR: ensure devres groups at higher indexes are released
From: Aaron Armstrong Skomra @ 2017-12-07 20:31 UTC (permalink / raw)
To: linux-input, jkosina, pinglinux, killertofu, benjamin.tissoires
Cc: Aaron Armstrong Skomra, stable #4 . 9, Aaron Armstrong Skomra
Background: ExpressKey Remotes communicate their events via usb dongle.
Each dongle can hold up to 5 pairings at one time and one EKR (identified
by its serial number) can unfortunately be paired with its dongle
more than once. The pairing takes place in a round-robin fashion.
Input devices are only created once per EKR, when a new serial number
is seen in the list of pairings. However, if a device is created for
a "higher" paring index and subsequently a second pairing occurs at a
lower pairing index, unpairing the remote with that serial number from
any pairing index will currently cause a driver crash. This occurs
infrequently, as two remotes are necessary to trigger this bug and most
users have only one remote.
As an illustration, to trigger the bug you need to have two remotes,
and pair them in this order:
1. slot 0 -> remote 1 (input device created for remote 1)
2. slot 1 -> remote 1 (duplicate pairing - no device created)
3. slot 2 -> remote 1 (duplicate pairing - no device created)
4. slot 3 -> remote 1 (duplicate pairing - no device created)
5. slot 4 -> remote 2 (input device created for remote 2)
6. slot 0 -> remote 2 (1 destroyed and recreated at slot 1)
7. slot 1 -> remote 2 (1 destroyed and recreated at slot 2)
8. slot 2 -> remote 2 (1 destroyed and recreated at slot 3)
9. slot 3 -> remote 2 (1 destroyed and not recreated)
10. slot 4 -> remote 2 (2 was already in this slot so no changes)
11. slot 0 -> remote 1 (The current code sees remote 2 was paired over in
one of the dongle slots it occupied and attempts
to remove all information about remote 2 [1]. It
calls wacom_remote_destroy_one for remote 2, but
the destroy function assumes the lowest index is
where the remote's input device was created. The
code "cleans up" the other remote 2 pairings
including the one which the input device was based
on, assuming they were were just duplicate
pairings. However, the cleanup doesn't call the
devres release function for the input device that
was created in slot 4).
This issue is fixed by this commit.
[1] Remote 2 should subsequently be re-created on the next packet from the
EKR at the lowest numbered slot that it occupies (here slot 1).
Fixes: f9036bd43602 ("HID: wacom: EKR: use devres groups to manage resources")
Cc: stable <stable@vger.kernel.org> #4.9
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com>
---
drivers/hid/wacom_sys.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index ee71ad9b6cc1..76531796bd3c 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -2347,23 +2347,23 @@ static void wacom_remote_destroy_one(struct wacom *wacom, unsigned int index)
int i;
unsigned long flags;
- spin_lock_irqsave(&remote->remote_lock, flags);
- remote->remotes[index].registered = false;
- spin_unlock_irqrestore(&remote->remote_lock, flags);
+ for (i = 0; i < WACOM_MAX_REMOTES; i++) {
+ if (remote->remotes[i].serial == serial) {
- if (remote->remotes[index].battery.battery)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index].battery.bat_desc);
+ spin_lock_irqsave(&remote->remote_lock, flags);
+ remote->remotes[i].registered = false;
+ spin_unlock_irqrestore(&remote->remote_lock, flags);
- if (remote->remotes[index].group.name)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index]);
+ if (remote->remotes[i].battery.battery)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i].battery.bat_desc);
+
+ if (remote->remotes[i].group.name)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i]);
- for (i = 0; i < WACOM_MAX_REMOTES; i++) {
- if (remote->remotes[i].serial == serial) {
remote->remotes[i].serial = 0;
remote->remotes[i].group.name = NULL;
- remote->remotes[i].registered = false;
remote->remotes[i].battery.battery = NULL;
wacom->led.groups[i].select = WACOM_STATUS_UNKNOWN;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/4] input: evdev: Replace timeval with timespec64
From: Deepa Dinamani @ 2017-12-07 18:13 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038
In-Reply-To: <20171207181306.5623-1-deepa.kernel@gmail.com>
struct timeval is not y2038 safe.
All references to timeval in the kernel will be replaced
by y2038 safe structures.
Replace all references to timeval with y2038 safe
struct timespec64 here.
struct input_event will be changed in a different patch.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/evdev.c | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 925571475005..e5dbfc5ff1b0 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -156,15 +156,22 @@ static void __evdev_flush_queue(struct evdev_client *client, unsigned int type)
static void __evdev_queue_syn_dropped(struct evdev_client *client)
{
struct input_event ev;
- ktime_t time;
+ struct timespec64 ts;
- time = client->clk_type == EV_CLK_REAL ?
- ktime_get_real() :
- client->clk_type == EV_CLK_MONO ?
- ktime_get() :
- ktime_get_boottime();
+ switch (client->clk_type) {
+ case EV_CLK_REAL:
+ ktime_get_real_ts64(&ts);
+ break;
+ case EV_CLK_MONO:
+ ktime_get_ts64(&ts);
+ break;
+ case EV_CLK_BOOT:
+ get_monotonic_boottime64(&ts);
+ break;
+ }
- ev.time = ktime_to_timeval(time);
+ ev.time.tv_sec = ts.tv_sec;
+ ev.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
ev.type = EV_SYN;
ev.code = SYN_DROPPED;
ev.value = 0;
@@ -257,17 +264,20 @@ static void __pass_event(struct evdev_client *client,
static void evdev_pass_values(struct evdev_client *client,
const struct input_value *vals, unsigned int count,
- ktime_t *ev_time)
+ struct timespec64 *ev_time)
{
struct evdev *evdev = client->evdev;
const struct input_value *v;
struct input_event event;
+ struct timespec64 ts;
bool wakeup = false;
if (client->revoked)
return;
- event.time = ktime_to_timeval(ev_time[client->clk_type]);
+ ts = ev_time[client->clk_type];
+ event.time.tv_sec = ts.tv_sec;
+ event.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
/* Interrupts are disabled, just acquire the lock. */
spin_lock(&client->buffer_lock);
@@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle,
{
struct evdev *evdev = handle->private;
struct evdev_client *client;
- ktime_t ev_time[EV_CLK_MAX];
+ struct timespec64 ev_time[EV_CLK_MAX];
- ev_time[EV_CLK_MONO] = ktime_get();
- ev_time[EV_CLK_REAL] = ktime_mono_to_real(ev_time[EV_CLK_MONO]);
- ev_time[EV_CLK_BOOT] = ktime_mono_to_any(ev_time[EV_CLK_MONO],
- TK_OFFS_BOOT);
+ ktime_get_ts64(&ev_time[EV_CLK_MONO]);
+ ktime_get_real_ts64(&ev_time[EV_CLK_REAL]);
+ get_monotonic_boottime64(&ev_time[EV_CLK_BOOT]);
rcu_read_lock();
--
2.14.1
^ permalink raw reply related
* [PATCH v4 1/4] uinput: Use monotonic times for uinput timestamps.
From: Deepa Dinamani @ 2017-12-07 18:13 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038
In-Reply-To: <20171207181306.5623-1-deepa.kernel@gmail.com>
struct timeval which is part of struct input_event to
maintain the event times is not y2038 safe.
Real time timestamps are also not ideal for input_event
as this time can go backwards as noted in the patch
a80b83b7b8 by John Stultz.
The patch switches the timestamps to use monotonic time
from realtime time. This is assuming no one is using
absolute times from these timestamps.
The structure to maintain input events will be changed
in a different patch.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
---
drivers/input/misc/uinput.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 39ddd9a73feb..d521aecbc078 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -84,11 +84,14 @@ static int uinput_dev_event(struct input_dev *dev,
unsigned int type, unsigned int code, int value)
{
struct uinput_device *udev = input_get_drvdata(dev);
+ struct timespec64 ts;
udev->buff[udev->head].type = type;
udev->buff[udev->head].code = code;
udev->buff[udev->head].value = value;
- do_gettimeofday(&udev->buff[udev->head].time);
+ ktime_get_ts64(&ts);
+ udev->buff[udev->head].time.tv_sec = ts.tv_sec;
+ udev->buff[udev->head].time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
udev->head = (udev->head + 1) % UINPUT_BUFFER_SIZE;
wake_up_interruptible(&udev->waitq);
--
2.14.1
^ permalink raw reply related
* [PATCH v4 4/4] input: serio: Replace timeval by timespec64
From: Deepa Dinamani @ 2017-12-07 18:13 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038
In-Reply-To: <20171207181306.5623-1-deepa.kernel@gmail.com>
struct timeval is not y2038 safe.
All references to timeval will be deleted from the
kernel to make it y2038 safe.
Replace its uses by y2038 safe struct timespec64.
The timestamps changed here only keep track of delta
times. These timestamps are also internal to kernel.
Hence, monotonic times are sufficient here.
The unit of the delta times is also changed in certain
cases to nanoseconds rather than microseconds. This is
in line with timespec64 which keeps time in nanoseconds.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/serio/hil_mlc.c | 37 ++++++++++++++++++-------------------
drivers/input/serio/hp_sdc.c | 17 +++++++++--------
drivers/input/serio/hp_sdc_mlc.c | 10 +++++-----
include/linux/hil_mlc.h | 6 +++---
include/linux/hp_sdc.h | 6 +++---
5 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/input/serio/hil_mlc.c b/drivers/input/serio/hil_mlc.c
index d66d01c5373b..b5856b4d3717 100644
--- a/drivers/input/serio/hil_mlc.c
+++ b/drivers/input/serio/hil_mlc.c
@@ -274,14 +274,14 @@ static int hilse_match(hil_mlc *mlc, int unused)
/* An LCV used to prevent runaway loops, forces 5 second sleep when reset. */
static int hilse_init_lcv(hil_mlc *mlc, int unused)
{
- struct timeval tv;
+ time64_t time;
- do_gettimeofday(&tv);
+ time = ktime_get_seconds();
- if (mlc->lcv && (tv.tv_sec - mlc->lcv_tv.tv_sec) < 5)
+ if (mlc->lcv && (time - mlc->lcv_tv.tv_sec) < 5)
return -1;
- mlc->lcv_tv = tv;
+ mlc->lcv_tv.tv_sec = time;
mlc->lcv = 0;
return 0;
@@ -466,7 +466,7 @@ static const struct hilse_node hil_mlc_se[HILSEN_END] = {
FUNC(hilse_init_lcv, 0, HILSEN_NEXT, HILSEN_SLEEP, 0)
/* 1 HILSEN_RESTART */
- FUNC(hilse_inc_lcv, 10, HILSEN_NEXT, HILSEN_START, 0)
+ FUNC(hilse_inc_lcv, 10000, HILSEN_NEXT, HILSEN_START, 0)
OUT(HIL_CTRL_ONLY) /* Disable APE */
CTS
@@ -485,7 +485,7 @@ static const struct hilse_node hil_mlc_se[HILSEN_END] = {
FUNC(hilse_init_lcv, 0, HILSEN_NEXT, HILSEN_SLEEP, 0)
/* 10 HILSEN_DHR2 */
- FUNC(hilse_inc_lcv, 10, HILSEN_NEXT, HILSEN_START, 0)
+ FUNC(hilse_inc_lcv, 10000, HILSEN_NEXT, HILSEN_START, 0)
FUNC(hilse_set_ddi, -1, HILSEN_NEXT, 0, 0)
OUT(HIL_PKT_CMD | HIL_CMD_DHR)
IN(300000, HILSEN_DHR2, HILSEN_DHR2, HILSEN_NEXT)
@@ -515,7 +515,7 @@ static const struct hilse_node hil_mlc_se[HILSEN_END] = {
FUNC(hilse_init_lcv, 0, HILSEN_NEXT, HILSEN_DOZE, 0)
/* 22 HILSEN_ACF2 */
- FUNC(hilse_inc_lcv, 10, HILSEN_NEXT, HILSEN_START, 0)
+ FUNC(hilse_inc_lcv, 10000, HILSEN_NEXT, HILSEN_START, 0)
OUT(HIL_PKT_CMD | HIL_CMD_ACF | 1)
IN(20000, HILSEN_NEXT, HILSEN_DSR, HILSEN_NEXT)
@@ -572,7 +572,7 @@ static const struct hilse_node hil_mlc_se[HILSEN_END] = {
OUT(HIL_PKT_CMD | HIL_CMD_RPL)
EXPECT(HIL_PKT_CMD | HIL_CMD_RPL | HIL_ERR_INT,
20000, HILSEN_NEXT, HILSEN_DSR, HILSEN_NEXT)
- FUNC(hilse_operate, 1, HILSEN_OPERATE, HILSEN_IFC, HILSEN_PROBE)
+ FUNC(hilse_operate, 1000, HILSEN_OPERATE, HILSEN_IFC, HILSEN_PROBE)
/* 58 HILSEN_IFCACF */
OUT(HIL_PKT_CMD | HIL_CMD_IFC)
@@ -584,7 +584,6 @@ static const struct hilse_node hil_mlc_se[HILSEN_END] = {
static inline void hilse_setup_input(hil_mlc *mlc, const struct hilse_node *node)
{
-
switch (node->act) {
case HILSE_EXPECT_DISC:
mlc->imatch = node->object.packet;
@@ -605,7 +604,7 @@ static inline void hilse_setup_input(hil_mlc *mlc, const struct hilse_node *node
}
mlc->istarted = 1;
mlc->intimeout = node->arg;
- do_gettimeofday(&(mlc->instart));
+ ktime_get_ts64(&(mlc->instart));
mlc->icount = 15;
memset(mlc->ipacket, 0, 16 * sizeof(hil_packet));
BUG_ON(down_trylock(&mlc->isem));
@@ -710,7 +709,7 @@ static int hilse_donode(hil_mlc *mlc)
break;
}
mlc->ostarted = 0;
- do_gettimeofday(&(mlc->instart));
+ ktime_get_ts64(&(mlc->instart));
write_unlock_irqrestore(&mlc->lock, flags);
nextidx = HILSEN_NEXT;
break;
@@ -731,18 +730,18 @@ static int hilse_donode(hil_mlc *mlc)
#endif
while (nextidx & HILSEN_SCHED) {
- struct timeval tv;
+ struct timespec64 ts;
if (!sched_long)
goto sched;
- do_gettimeofday(&tv);
- tv.tv_usec += USEC_PER_SEC * (tv.tv_sec - mlc->instart.tv_sec);
- tv.tv_usec -= mlc->instart.tv_usec;
- if (tv.tv_usec >= mlc->intimeout) goto sched;
- tv.tv_usec = (mlc->intimeout - tv.tv_usec) * HZ / USEC_PER_SEC;
- if (!tv.tv_usec) goto sched;
- mod_timer(&hil_mlcs_kicker, jiffies + tv.tv_usec);
+ ktime_get_ts64(&ts);
+ ts.tv_nsec += NSEC_PER_SEC * (ts.tv_sec - mlc->instart.tv_sec);
+ ts.tv_nsec -= mlc->instart.tv_nsec;
+ if (ts.tv_nsec >= mlc->intimeout) goto sched;
+ ts.tv_nsec = (mlc->intimeout - ts.tv_nsec) * HZ / NSEC_PER_SEC;
+ if (!ts.tv_nsec) goto sched;
+ mod_timer(&hil_mlcs_kicker, jiffies + ts.tv_nsec);
break;
sched:
tasklet_schedule(&hil_mlcs_tasklet);
diff --git a/drivers/input/serio/hp_sdc.c b/drivers/input/serio/hp_sdc.c
index 1d7c7d81a5ef..c8e3eb1c98c0 100644
--- a/drivers/input/serio/hp_sdc.c
+++ b/drivers/input/serio/hp_sdc.c
@@ -193,7 +193,7 @@ static void hp_sdc_take(int irq, void *dev_id, uint8_t status, uint8_t data)
curr->seq[curr->idx++] = status;
curr->seq[curr->idx++] = data;
hp_sdc.rqty -= 2;
- do_gettimeofday(&hp_sdc.rtv);
+ ktime_get_ts64(&hp_sdc.rtv);
if (hp_sdc.rqty <= 0) {
/* All data has been gathered. */
@@ -306,13 +306,13 @@ static void hp_sdc_tasklet(unsigned long foo)
write_lock_irq(&hp_sdc.rtq_lock);
if (hp_sdc.rcurr >= 0) {
- struct timeval tv;
+ struct timespec64 ts;
- do_gettimeofday(&tv);
- if (tv.tv_sec > hp_sdc.rtv.tv_sec)
- tv.tv_usec += USEC_PER_SEC;
+ ktime_get_ts64(&ts);
+ if (ts.tv_sec > hp_sdc.rtv.tv_sec)
+ ts.tv_nsec += NSEC_PER_SEC;
- if (tv.tv_usec - hp_sdc.rtv.tv_usec > HP_SDC_MAX_REG_DELAY) {
+ if (ts.tv_nsec - hp_sdc.rtv.tv_nsec > HP_SDC_MAX_REG_DELAY) {
hp_sdc_transaction *curr;
uint8_t tmp;
@@ -322,7 +322,8 @@ static void hp_sdc_tasklet(unsigned long foo)
* it back to the application. and be less verbose.
*/
printk(KERN_WARNING PREFIX "read timeout (%ius)!\n",
- (int)(tv.tv_usec - hp_sdc.rtv.tv_usec));
+ (int)(ts.tv_nsec - hp_sdc.rtv.tv_nsec) /
+ (int)NSEC_PER_USEC);
curr->idx += hp_sdc.rqty;
hp_sdc.rqty = 0;
tmp = curr->seq[curr->actidx];
@@ -551,7 +552,7 @@ unsigned long hp_sdc_put(void)
/* Start a new read */
hp_sdc.rqty = curr->seq[curr->idx];
- do_gettimeofday(&hp_sdc.rtv);
+ ktime_get_ts64(&hp_sdc.rtv);
curr->idx++;
/* Still need to lock here in case of spurious irq. */
write_lock_irq(&hp_sdc.rtq_lock);
diff --git a/drivers/input/serio/hp_sdc_mlc.c b/drivers/input/serio/hp_sdc_mlc.c
index d50f0678bf47..66020cd931be 100644
--- a/drivers/input/serio/hp_sdc_mlc.c
+++ b/drivers/input/serio/hp_sdc_mlc.c
@@ -149,7 +149,7 @@ static int hp_sdc_mlc_in(hil_mlc *mlc, suseconds_t timeout)
/* Try to down the semaphore */
if (down_trylock(&mlc->isem)) {
- struct timeval tv;
+ struct timespec64 ts;
if (priv->emtestmode) {
mlc->ipacket[0] =
HIL_ERR_INT | (mlc->opacket &
@@ -160,11 +160,11 @@ static int hp_sdc_mlc_in(hil_mlc *mlc, suseconds_t timeout)
/* printk(KERN_DEBUG PREFIX ">[%x]\n", mlc->ipacket[0]); */
goto wasup;
}
- do_gettimeofday(&tv);
- tv.tv_usec += USEC_PER_SEC * (tv.tv_sec - mlc->instart.tv_sec);
- if (tv.tv_usec - mlc->instart.tv_usec > mlc->intimeout) {
+ ktime_get_ts64(&ts);
+ ts.tv_nsec += NSEC_PER_SEC * (ts.tv_sec - mlc->instart.tv_sec);
+ if (ts.tv_nsec - mlc->instart.tv_nsec > mlc->intimeout) {
/* printk("!%i %i",
- tv.tv_usec - mlc->instart.tv_usec,
+ tv.tv_nsec - mlc->instart.tv_nsec,
mlc->intimeout);
*/
rc = 1;
diff --git a/include/linux/hil_mlc.h b/include/linux/hil_mlc.h
index 394a8405dd74..f846730d6595 100644
--- a/include/linux/hil_mlc.h
+++ b/include/linux/hil_mlc.h
@@ -32,7 +32,7 @@
*/
#include <linux/hil.h>
-#include <linux/time.h>
+#include <linux/time64.h>
#include <linux/interrupt.h>
#include <linux/semaphore.h>
#include <linux/serio.h>
@@ -144,12 +144,12 @@ struct hil_mlc {
hil_packet ipacket[16];
hil_packet imatch;
int icount;
- struct timeval instart;
+ struct timespec64 instart;
suseconds_t intimeout;
int ddi; /* Last operational device id */
int lcv; /* LCV to throttle loops */
- struct timeval lcv_tv; /* Time loop was started */
+ struct timespec64 lcv_tv; /* Time loop was started */
int di_map[7]; /* Maps below items to live devs */
struct hil_mlc_devinfo di[HIL_MLC_DEVMEM];
diff --git a/include/linux/hp_sdc.h b/include/linux/hp_sdc.h
index d392975d8887..d863944f5c0c 100644
--- a/include/linux/hp_sdc.h
+++ b/include/linux/hp_sdc.h
@@ -47,9 +47,9 @@
#endif
-/* No 4X status reads take longer than this (in usec).
+/* No 4X status reads take longer than this (in nsec).
*/
-#define HP_SDC_MAX_REG_DELAY 20000
+#define HP_SDC_MAX_REG_DELAY 20000000
typedef void (hp_sdc_irqhook) (int irq, void *dev_id,
uint8_t status, uint8_t data);
@@ -281,7 +281,7 @@ typedef struct {
hp_sdc_transaction *tq[HP_SDC_QUEUE_LEN]; /* All pending read/writes */
int rcurr, rqty; /* Current read transact in process */
- struct timeval rtv; /* Time when current read started */
+ struct timespec64 rtv; /* Monotonic time when current read started */
int wcurr; /* Current write transact in process */
int dev_err; /* carries status from registration */
--
2.14.1
^ permalink raw reply related
* [PATCH v4 3/4] input: Deprecate real timestamps beyond year 2106
From: Deepa Dinamani @ 2017-12-07 18:13 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038
In-Reply-To: <20171207181306.5623-1-deepa.kernel@gmail.com>
struct timeval is not y2038 safe.
All usage of timeval in the kernel will be replaced by
y2038 safe structures.
The change is also necessary as glibc is introducing support
for 32 bit applications to use 64 bit time_t. Without this
change, many applications would incorrectly interpret values
in the struct input_event.
More details about glibc at
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign .
struct input_event maintains time for each input event.
Real time timestamps are not ideal for input as this
time can go backwards as noted in the patch a80b83b7b8
by John Stultz. Hence, having the input_event.time fields
only big enough for monotonic and boot times are
sufficient.
The change leaves the representation of struct input_event as is
on 64 bit architectures. But uses 2 unsigned long values on 32 bit
machines to support real timestamps until year 2106.
This intentionally breaks the ABI on 32 bit architectures and
compat handling on 64 bit architectures.
This is as per maintainer's preference to introduce compile time errors
rather than run into runtime incompatibilities.
The change requires any 32 bit userspace utilities reading or writing
from event nodes to update their reading format to match the new
input_event. The changes to the popular libraries will be posted once
we agree on the kernel change.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
---
drivers/input/evdev.c | 14 ++++++++------
drivers/input/input-compat.c | 11 ++++++-----
drivers/input/input-compat.h | 3 ++-
drivers/input/misc/uinput.c | 4 ++--
include/uapi/linux/input.h | 12 +++++++++++-
5 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index e5dbfc5ff1b0..6172af6476c0 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -135,7 +135,8 @@ static void __evdev_flush_queue(struct evdev_client *client, unsigned int type)
continue;
} else if (head != i) {
/* move entry to fill the gap */
- client->buffer[head].time = ev->time;
+ client->buffer[head].input_event_sec = ev->input_event_sec;
+ client->buffer[head].input_event_usec = ev->input_event_usec;
client->buffer[head].type = ev->type;
client->buffer[head].code = ev->code;
client->buffer[head].value = ev->value;
@@ -170,8 +171,8 @@ static void __evdev_queue_syn_dropped(struct evdev_client *client)
break;
}
- ev.time.tv_sec = ts.tv_sec;
- ev.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+ ev.input_event_sec = ts.tv_sec;
+ ev.input_event_usec = ts.tv_nsec / NSEC_PER_USEC;
ev.type = EV_SYN;
ev.code = SYN_DROPPED;
ev.value = 0;
@@ -248,7 +249,8 @@ static void __pass_event(struct evdev_client *client,
*/
client->tail = (client->head - 2) & (client->bufsize - 1);
- client->buffer[client->tail].time = event->time;
+ client->buffer[client->tail].input_event_sec = event->input_event_sec;
+ client->buffer[client->tail].input_event_usec = event->input_event_usec;
client->buffer[client->tail].type = EV_SYN;
client->buffer[client->tail].code = SYN_DROPPED;
client->buffer[client->tail].value = 0;
@@ -276,8 +278,8 @@ static void evdev_pass_values(struct evdev_client *client,
return;
ts = ev_time[client->clk_type];
- event.time.tv_sec = ts.tv_sec;
- event.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+ event.input_event_sec = ts.tv_sec;
+ event.input_event_usec = ts.tv_nsec / NSEC_PER_USEC;
/* Interrupts are disabled, just acquire the lock. */
spin_lock(&client->buffer_lock);
diff --git a/drivers/input/input-compat.c b/drivers/input/input-compat.c
index 2186f71c9fe5..419e40b68486 100644
--- a/drivers/input/input-compat.c
+++ b/drivers/input/input-compat.c
@@ -24,14 +24,15 @@ int input_event_from_user(const char __user *buffer,
sizeof(struct input_event_compat)))
return -EFAULT;
- event->time.tv_sec = compat_event.time.tv_sec;
- event->time.tv_usec = compat_event.time.tv_usec;
+ event->input_event_sec = compat_event.sec;
+ event->input_event_usec = compat_event.usec;
event->type = compat_event.type;
event->code = compat_event.code;
event->value = compat_event.value;
} else {
- if (copy_from_user(event, buffer, sizeof(struct input_event)))
+ if (copy_from_user(event, buffer,
+ sizeof(struct input_event)))
return -EFAULT;
}
@@ -44,8 +45,8 @@ int input_event_to_user(char __user *buffer,
if (in_compat_syscall() && !COMPAT_USE_64BIT_TIME) {
struct input_event_compat compat_event;
- compat_event.time.tv_sec = event->time.tv_sec;
- compat_event.time.tv_usec = event->time.tv_usec;
+ compat_event.sec = event->input_event_sec;
+ compat_event.usec = event->input_event_usec;
compat_event.type = event->type;
compat_event.code = event->code;
compat_event.value = event->value;
diff --git a/drivers/input/input-compat.h b/drivers/input/input-compat.h
index 1563160a7af3..08cd755e73fd 100644
--- a/drivers/input/input-compat.h
+++ b/drivers/input/input-compat.h
@@ -18,7 +18,8 @@
#ifdef CONFIG_COMPAT
struct input_event_compat {
- struct compat_timeval time;
+ compat_ulong_t sec;
+ compat_ulong_t usec;
__u16 type;
__u16 code;
__s32 value;
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index d521aecbc078..cb4bdbd3e9e2 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -90,8 +90,8 @@ static int uinput_dev_event(struct input_dev *dev,
udev->buff[udev->head].code = code;
udev->buff[udev->head].value = value;
ktime_get_ts64(&ts);
- udev->buff[udev->head].time.tv_sec = ts.tv_sec;
- udev->buff[udev->head].time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+ udev->buff[udev->head].input_event_sec = ts.tv_sec;
+ udev->buff[udev->head].input_event_usec = ts.tv_nsec / NSEC_PER_USEC;
udev->head = (udev->head + 1) % UINPUT_BUFFER_SIZE;
wake_up_interruptible(&udev->waitq);
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 8c5a0bf6ee35..9c5105ff5cc6 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -21,10 +21,20 @@
/*
* The event structure itself
+ * Note that __USE_TIME_BITS64 is defined by libc based on
+ * application's request to use 64 bit time_t.
*/
-
struct input_event {
+#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;
+ __kernel_ulong_t __usec;
+#define input_event_sec __sec
+#define input_event_usec __usec
+#endif
__u16 type;
__u16 code;
__s32 value;
--
2.14.1
^ permalink raw reply related
* [PATCH v4 0/4] Make input drivers y2038 safe
From: Deepa Dinamani @ 2017-12-07 18:13 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel; +Cc: peter.hutterer, arnd, y2038
The series is aimed at making input events y2038 safe.
It extends the lifetime of the realtime timestamps in the
events to year 2106.
The series is also a necessary update as glibc is set to provide
64 bit time_t support for 32 bit binaries. glibc plan is detailed
at https://sourceware.org/glibc/wiki/Y2038ProofnessDesign .
The series is a result of discussions with Arnd Bergmann and
Dmitry Torokhov at last Plumbers.
The plan is to deprecate realtime timestamps anyway as they
are not appropriate for these timestamps as noted in the patch
a80b83b7b8 by John Stultz.
The design also updates the format of the input events read/ written
to the device nodes. This breaks 32 bit interface to the input
events at compile time as preferred by the maintainer.
The userspace library changes to libevdev, libuinput and mtdev
will be posted to the respective mailing groups for review.
Changes from v3:
* Updated uinput to support monotonic time only
* Addressed review comments
Changes from v2:
* Updated the design to break 32 bit interfaces at compile time.
Changes from v1:
* Updated changes according to review comments.
* Posted userspace library changes that go along with the series.
Deepa Dinamani (4):
uinput: Use monotonic times for uinput timestamps.
input: evdev: Replace timeval with timespec64
input: Deprecate real timestamps beyond year 2106
input: serio: Replace timeval by timespec64
drivers/input/evdev.c | 43 +++++++++++++++++++++++++---------------
drivers/input/input-compat.c | 11 +++++-----
drivers/input/input-compat.h | 3 ++-
drivers/input/misc/uinput.c | 5 ++++-
drivers/input/serio/hil_mlc.c | 37 +++++++++++++++++-----------------
drivers/input/serio/hp_sdc.c | 17 ++++++++--------
drivers/input/serio/hp_sdc_mlc.c | 10 +++++-----
include/linux/hil_mlc.h | 6 +++---
include/linux/hp_sdc.h | 6 +++---
include/uapi/linux/input.h | 12 ++++++++++-
10 files changed, 88 insertions(+), 62 deletions(-)
base-commit: b0a84f19a5161418d4360cd57603e94ed489915e
--
2.14.1
^ permalink raw reply
* Re: [PATCH v2] HID: add quirk for another PIXART OEM mouse used by HP
From: Jiri Kosina @ 2017-12-07 10:09 UTC (permalink / raw)
To: Dave Young; +Cc: Benjamin Tissoires, linux-kernel, linux-input, linux-usb
In-Reply-To: <20171201121934.GA3352@dhcp-128-65.nay.redhat.com>
On Fri, 1 Dec 2017, Dave Young wrote:
> This mouse keep disconnecting in runleve 3 like below, add it needs the
> quirk to mute the anoying messages.
>
> [ 111.230555] usb 2-2: USB disconnect, device number 6
> [ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
> [ 112.941594] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
> [ 112.984866] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [ 113.027731] usb 2-2: Product: HP USB Optical Mouse
> [ 113.069977] usb 2-2: Manufacturer: PixArt
> [ 113.113500] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0002/input/input14
> [ 113.156787] hid-generic 0003:03F0:094A.0002: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
> [ 173.262642] usb 2-2: USB disconnect, device number 7
> [ 174.750244] usb 2-2: new low-speed USB device number 8 using xhci_hcd
> [ 174.935740] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
> [ 174.990435] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [ 175.014984] usb 2-2: Product: HP USB Optical Mouse
> [ 175.037886] usb 2-2: Manufacturer: PixArt
> [ 175.061794] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
> [ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: core: lower log level for unknown main item tags to warnings
From: Jiri Kosina @ 2017-12-07 10:06 UTC (permalink / raw)
To: Hans de Goede; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20171206165438.676-1-hdegoede@redhat.com>
On Wed, 6 Dec 2017, Hans de Goede wrote:
> Given all the effort distros have done with splash-screens to give
> users a nice clean boot experience, we really want dmesg --level=err
> to not print anything unless there is a real problem with either the
> hardware or the kernel. Buggy HID descriptors unfortunately happen
> all too often, so lower the log level to warning keep the console
> clear of error messages such as:
>
> [ 441.079664] apple 0005:05AC:0239.0003: unknown main item tag 0x0
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/hid/hid-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 7297b1d1300c..c2560aae5542 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -551,7 +551,7 @@ static int hid_parser_main(struct hid_parser *parser, struct hid_item *item)
> ret = hid_add_field(parser, HID_FEATURE_REPORT, data);
> break;
> default:
> - hid_err(parser->device, "unknown main item tag 0x%x\n", item->tag);
> + hid_warn(parser->device, "unknown main item tag 0x%x\n", item->tag);
> ret = 0;
Applied to for-4.15/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: elecom: rewrite report fixup for EX-G and future mice
From: Jiri Kosina @ 2017-12-07 10:04 UTC (permalink / raw)
To: Tomasz Kramkowski
Cc: Benjamin Tissoires, Yuxuan Shui, Diego Elio Pettenò,
Alex Manoussakis, linux-input, linux-kernel
In-Reply-To: <20171205201307.GA13831@gaia.local>
On Tue, 5 Dec 2017, Tomasz Kramkowski wrote:
> On Mon, Dec 04, 2017 at 08:55:50PM +0000, Tomasz Kramkowski wrote:
> > +static void mouse_button_fixup(struct hid_device *hdev,
> > + __u8 *rdesc, unsigned int *rsize,
> > + int nbuttons)
>
> I've just remembered what has been bugging me yesterday when I was
> reviewing this patch. I had come to the realisation (and then
> subsequently forgotten) that this function should probably return __u8 *
> and also get assigned to rdesc on the other end. It seems to me that it
> makes most sense to allow for the possibility (although slim) of this
> function eventually being expanded to actually replace the report
> descriptor
Sure, but you can extend the API of mouse_button_fixup() once such need
arises; no need to pass data pointers around without having actual use for
them.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH][next] HID: quirks: make array hid_quirks static
From: Jiri Kosina @ 2017-12-07 10:01 UTC (permalink / raw)
To: Colin King; +Cc: Benjamin Tissoires, linux-input, kernel-janitors, linux-kernel
In-Reply-To: <20171204111910.2840-1-colin.king@canonical.com>
On Mon, 4 Dec 2017, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Array hid_quirks is local to the source and does not need to be in
> global scope, so make it static.
>
> Cleans up sparse warning:
> drivers/hid/hid-quirks.c:29:28: warning: symbol 'hid_quirks' was not
> declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to for-4.16/hid-quirks-cleanup/_base. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: core: lower log level for unknown main item tags to warnings
From: Benjamin Tissoires @ 2017-12-06 17:24 UTC (permalink / raw)
To: Hans de Goede; +Cc: Jiri Kosina, linux-input
In-Reply-To: <20171206165438.676-1-hdegoede@redhat.com>
On Wed, Dec 6, 2017 at 5:54 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Given all the effort distros have done with splash-screens to give
> users a nice clean boot experience, we really want dmesg --level=err
> to not print anything unless there is a real problem with either the
> hardware or the kernel. Buggy HID descriptors unfortunately happen
> all too often, so lower the log level to warning keep the console
> clear of error messages such as:
>
> [ 441.079664] apple 0005:05AC:0239.0003: unknown main item tag 0x0
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> drivers/hid/hid-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 7297b1d1300c..c2560aae5542 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -551,7 +551,7 @@ static int hid_parser_main(struct hid_parser *parser, struct hid_item *item)
> ret = hid_add_field(parser, HID_FEATURE_REPORT, data);
> break;
> default:
> - hid_err(parser->device, "unknown main item tag 0x%x\n", item->tag);
> + hid_warn(parser->device, "unknown main item tag 0x%x\n", item->tag);
> ret = 0;
> }
>
> --
> 2.14.3
>
^ permalink raw reply
* [PATCH] HID: core: lower log level for unknown main item tags to warnings
From: Hans de Goede @ 2017-12-06 16:54 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: Hans de Goede, linux-input
Given all the effort distros have done with splash-screens to give
users a nice clean boot experience, we really want dmesg --level=err
to not print anything unless there is a real problem with either the
hardware or the kernel. Buggy HID descriptors unfortunately happen
all too often, so lower the log level to warning keep the console
clear of error messages such as:
[ 441.079664] apple 0005:05AC:0239.0003: unknown main item tag 0x0
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/hid/hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 7297b1d1300c..c2560aae5542 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -551,7 +551,7 @@ static int hid_parser_main(struct hid_parser *parser, struct hid_item *item)
ret = hid_add_field(parser, HID_FEATURE_REPORT, data);
break;
default:
- hid_err(parser->device, "unknown main item tag 0x%x\n", item->tag);
+ hid_warn(parser->device, "unknown main item tag 0x%x\n", item->tag);
ret = 0;
}
--
2.14.3
^ permalink raw reply related
* [PATCH] Input: include "linux/gpio/consumer.h" header file.
From: Anthony Kim @ 2017-12-06 1:41 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, dennis.hong, Anthony Kim
An error occurred during compile because there is no header file
at x86 configure.
Signed-off-by: Anthony Kim <anthony.kim@hideep.com>
---
drivers/input/touchscreen/hideep.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/touchscreen/hideep.c b/drivers/input/touchscreen/hideep.c
index fc080a7..037da00 100644
--- a/drivers/input/touchscreen/hideep.c
+++ b/drivers/input/touchscreen/hideep.c
@@ -12,6 +12,7 @@
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/gpio/machine.h>
+#include <linux/gpio/consumer.h>
#include <linux/i2c.h>
#include <linux/acpi.h>
#include <linux/interrupt.h>
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] HID: elecom: rewrite report fixup for EX-G and future mice
From: Tomasz Kramkowski @ 2017-12-05 20:17 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Yuxuan Shui, Diego Elio Pettenò,
Alex Manoussakis, linux-input, linux-kernel
In-Reply-To: <20171204205550.2621-1-tk@the-tk.com>
On Mon, Dec 04, 2017 at 08:55:50PM +0000, Tomasz Kramkowski wrote:
> +static void mouse_button_fixup(struct hid_device *hdev,
> + __u8 *rdesc, unsigned int *rsize,
> + int nbuttons)
I've just remembered what has been bugging me yesterday when I was
reviewing this patch. I had come to the realisation (and then
subsequently forgotten) that this function should probably return __u8 *
and also get assigned to rdesc on the other end. It seems to me that it
makes most sense to allow for the possibility (although slim) of this
function eventually being expanded to actually replace the report
descriptor (technically the full report descriptor contains a bunch of
useless crap like INPUT reports for media keys and the FEATURE report
which as far as I can tell is totally useless or may or may not be some
tactic by ELECOM to future-proof their firmware).
The other option would be to make rsize not a pointer because it doesn't
need to be. But that kind of makes the flow of the two functions
somewhat inconsistent. I'm not sure if I'm alone in that feeling.
Anyway, I should have written this down when I first caught it, sorry
for the noise. I'll let you guys review this patch and give any other
feedback you might have and I'll try to get a v2 as soon as possible
afterwards.
--
Tomasz Kramkowski | GPG: 40B037BA0A5B8680 | Web: https://the-tk.com/
^ permalink raw reply
* Re: [PATCH v2 3/5] Input: add KEY_ROTATE_LOCK_TOGGLE
From: Jason Gerecke @ 2017-12-05 18:50 UTC (permalink / raw)
To: Brüns, Stefan, Alex Hung
Cc: Bastien Nocera, platform-driver-x86@vger.kernel.org,
linux-input@vger.kernel.org, Dmitry Torokhov,
linux-kernel@vger.kernel.org
In-Reply-To: <2845999.tyV6EiPLrg@sbruens-linux>
Looks like this might also be needed for the MobileStudio Pro...
https://bugzilla.kernel.org/show_bug.cgi?id=197991
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
On Thu, Nov 30, 2017 at 9:51 AM, Brüns, Stefan
<Stefan.Bruens@rwth-aachen.de> wrote:
> On Freitag, 10. November 2017 00:34:53 CET Bastien Nocera wrote:
>> On Thu, 2017-11-09 at 23:44 +0100, Stefan Brüns wrote:
>> > The key has the same use as the SW_ROTATE_LOCK, but is used on
>> > devices
>> > where the state is not tracked by the hardware but has to be handled
>> > in software.
>>
>> I'll let the input and hid subsystem maintainers have the final say
>> here, though I think that sending out Win+O would be easier, as this is
>> already something that desktops need to support for those devices that
>> send the actual Win+O key combination when those buttons are pressed
>> there.
>>
>> If we're going with the separate keycode, could you also file bugs
>> against xkbd-common and xkeyboard-config to get the key added to the
>> list of XF86 keysyms and to the default evdev keymap? Otherwise Wayland
>> and X11 based desktops won't be able to use it.
>
> Filed for xkeyboard-config:
> https://bugs.freedesktop.org/show_bug.cgi?id=103998
>
> and xkb-common:
> https://github.com/xkbcommon/libxkbcommon/issues/55
>
> Regards,
>
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 08/45] drivers: input: remove duplicate includes
From: Dmitry Torokhov @ 2017-12-05 18:22 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Pravin Shedge, Nick Dyer, Arvind Yadav, Colin Ian King,
linux-input, linux-kernel, Jiri Kosina
In-Reply-To: <CAO-hwJLM=T35-RFpn=LS=amZmBi9S3eLHVrqsFOs238D3oQexg@mail.gmail.com>
On Tue, Dec 05, 2017 at 09:15:55AM +0100, Benjamin Tissoires wrote:
> Hi,
>
> [adding Jiri, the HID maintainer in CC]
>
> On Tue, Dec 5, 2017 at 3:01 AM, Pravin Shedge
> <pravin.shedge4linux@gmail.com> wrote:
> > These duplicate includes have been found with scripts/checkincludes.pl but
> > they have been removed manually to avoid removing false positives.
> >
> > Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
> > ---
>
> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Applied, thank you.
>
> Cheers,
> Benjamin
>
> > drivers/input/rmi4/rmi_f34.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/input/rmi4/rmi_f34.c b/drivers/input/rmi4/rmi_f34.c
> > index 4cfe970..f1f5ac5 100644
> > --- a/drivers/input/rmi4/rmi_f34.c
> > +++ b/drivers/input/rmi4/rmi_f34.c
> > @@ -11,7 +11,6 @@
> > #include <linux/rmi.h>
> > #include <linux/firmware.h>
> > #include <asm/unaligned.h>
> > -#include <asm/unaligned.h>
> > #include <linux/bitops.h>
> >
> > #include "rmi_driver.h"
> > --
> > 2.7.4
> >
--
Dmitry
^ permalink raw reply
* Re: [PATCH v6 0/9] i2c: document DMA handling and add helpers for it
From: Jonathan Cameron @ 2017-12-05 11:00 UTC (permalink / raw)
To: Mark Brown
Cc: Wolfram Sang, Wolfram Sang, linux-i2c, linux-kernel,
linux-renesas-soc, linux-iio, linux-input, linux-media
In-Reply-To: <20171204220541.GA11658@finisterre>
On Mon, 4 Dec 2017 22:05:41 +0000
Mark Brown <broonie@kernel.org> wrote:
> On Sun, Dec 03, 2017 at 08:43:47PM +0100, Wolfram Sang wrote:
>
> > > It's a bit different in that it's much more likely that a SPI controller
> > > will actually do DMA than an I2C one since the speeds are higher and
> > > there's frequent applications that do large transfers so it's more
> > > likely that people will do the right thing as issues would tend to come
> > > up if they don't.
>
> > Yes, for SPI this is true. I was thinking more of regmap with its
> > usage of different transport mechanisms. But I guess they should all be
> > DMA safe because some of them need to be DMA safe?
>
> Possibly. Hopefully. I guess we'll find out.
>
Yeah, optimistic assumption. Plenty of drivers use regmap for the
convenience of it's caching and field access etc rather than
because they support multiple buses.
I'll audit the IIO drivers and see where we have issues if we
start assuming DMA safe for regmap (which makes sense to me).
Probably worth fixing them all up anyway and tends to be straightforward.
Jonathan
^ permalink raw reply
* RE: [PATCH] Support TrackStick of Thinkpad L570
From: Masaki Ota @ 2017-12-05 8:29 UTC (permalink / raw)
To: Pali Rohár
Cc: Masaki Ota, dmitry.torokhov@gmail.com,
benjamin.tissoires@redhat.com, aaron.ma@canonical.com,
jaak@ristioja.ee, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, net147@gmail.com
In-Reply-To: <20171204095045.lp2vuxtxmmjpsjo7@pali>
Hi, Pali,
OK, I got it.
So, the problem of structure will be solved next chance.
Best Regards,
Masaki Ota
-----Original Message-----
From: Pali Rohár [mailto:pali.rohar@gmail.com]
Sent: Monday, December 04, 2017 6:51 PM
To: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>
Cc: Masaki Ota <012nexus@gmail.com>; dmitry.torokhov@gmail.com; benjamin.tissoires@redhat.com; aaron.ma@canonical.com; jaak@ristioja.ee; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Support TrackStick of Thinkpad L570
On Monday 04 December 2017 09:40:04 Masaki Ota wrote:
> Hi, Pali,
>
> It does not work in my test result.
Hm.. that is strange, we have dangling pointers in struct alps_data?
Otherwise I have no idea why does not work.
> BTW, other some functions also use both of "struct psmouse" and "struct alps_data" argument.
It does not make sense to pass one structure (via pointers) two times.
And if this "pattern" is already used in code and reason is that one pointer "does not work" because it is dangling, then it is really wrong.
I know it is irrelevant to your patch, but this problem with dangling pointer should be fixed, e.g. in next patches (not in this one).
Problems (with memory allocation/pointers) should not be camouflaged.
Memory corruption in kernel can lead to fatal problems.
> I just followed it.
Blindly following bad code is a bad idea. When we see something like this, we should at least stop and ask question "why is this code pattern used?".
> Best Regards,
> Masaki Ota
> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, December 04, 2017 6:12 PM
> To: 太田 真喜 Masaki Ota <masaki.ota@jp.alps.com>
> Cc: Masaki Ota <012nexus@gmail.com>; dmitry.torokhov@gmail.com;
> benjamin.tissoires@redhat.com; aaron.ma@canonical.com;
> jaak@ristioja.ee; linux-input@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Support TrackStick of Thinkpad L570
>
> On Monday 04 December 2017 04:48:43 Masaki Ota wrote:
> > Hi, Pali,
> >
> > I don't get your point.
> > Please modify the code if you have an idea.
>
> See below
>
> > Best Regards,
> > Masaki Ota
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Saturday, December 02, 2017 6:08 AM
> > To: Masaki Ota <012nexus@gmail.com>
> > Cc: dmitry.torokhov@gmail.com; benjamin.tissoires@redhat.com;
> > aaron.ma@canonical.com; jaak@ristioja.ee; 太田 真喜 Masaki Ota
> > <masaki.ota@jp.alps.com>; linux-input@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] Support TrackStick of Thinkpad L570
> >
> > On Wednesday 29 November 2017 17:33:58 Masaki Ota wrote:
> > > From: Masaki Ota <masaki.ota@jp.alps.com>
> > > - The issue is that Thinkpad L570 TrackStick does not work. Because the main interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 interface Firmware setting of TrackStick. The detail is that TrackStick otp bit is disabled.
> > > - Add the code that checks 0xD7 address value. This value is device number information, so we can identify the device by checking this value.
> > > - If we check 0xD7 value, we need to enable Command mode and after check the value we need to disable Command mode, then we have to enable the device(0xF4 command).
> > > - Thinkpad L570 device number is 0x0C or 0x1D. If it is TRUE, enable ALPS_DUALPOINT flag.
> > >
> > > Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
> > > ---
> > > drivers/input/mouse/alps.c | 24 +++++++++++++++++++++---
> > > 1 file changed, 21 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/input/mouse/alps.c
> > > b/drivers/input/mouse/alps.c index 850b00e3ad8e..6f092bdd9fc5
> > > 100644
> > > --- a/drivers/input/mouse/alps.c
> > > +++ b/drivers/input/mouse/alps.c
> > > @@ -2541,13 +2541,31 @@ static int
> > > alps_update_btn_info_ss4_v2(unsigned char otp[][4], }
> > >
> > > static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
> > > - struct alps_data *priv)
> > > + struct alps_data *priv,
> > > + struct psmouse *psmouse)
> > > {
>
> You can access psmouse from the priv structure as:
>
> struct psmouse *psmouse = priv->psmouse;
>
> Therefore you do not have to extend function parameters with psmouse pointer as that is already present int alps_data.
>
> struct alps_data is defined as:
>
> struct alps_data {
> struct psmouse *psmouse;
> ...
> }
>
> > > bool is_dual = false;
> > > + int reg_val = 0;
> > > + struct ps2dev *ps2dev = &psmouse->ps2dev;
> > >
> > > - if (IS_SS4PLUS_DEV(priv->dev_id))
> > > + if (IS_SS4PLUS_DEV(priv->dev_id)) {
> > > is_dual = (otp[0][0] >> 4) & 0x01;
> > >
> > > + if (!is_dual) {
> > > + /* For support TrackStick of Thinkpad L/E series */
> > > + if (alps_exit_command_mode(psmouse) == 0 &&
> > > + alps_enter_command_mode(psmouse) == 0) {
> > > + reg_val = alps_command_mode_read_reg(psmouse,
> > > + 0xD7);
> > > + }
> > > + alps_exit_command_mode(psmouse);
> > > + ps2_command(ps2dev, NULL, PSMOUSE_CMD_ENABLE);
> > > +
> > > + if (reg_val == 0x0C || reg_val == 0x1D)
> > > + is_dual = true;
> > > + }
> > > + }
> > > +
> > > if (is_dual)
> > > priv->flags |= ALPS_DUALPOINT |
> > > ALPS_DUALPOINT_WITH_PRESSURE; @@ -2570,7 +2588,7 @@ static
> > > int alps_set_defaults_ss4_v2(struct psmouse *psmouse,
> > >
> > > alps_update_btn_info_ss4_v2(otp, priv);
> > >
> > > - alps_update_dual_info_ss4_v2(otp, priv);
> > > + alps_update_dual_info_ss4_v2(otp, priv, psmouse);
> >
> > Now looking at this change... Is there reason why you are passing psmouse parameter there? Because struct alps_data contains psmouse member.
> >
> > >
> > > return 0;
> > > }
> >
> > --
> > Pali Rohár
> > pali.rohar@gmail.com
>
> --
> Pali Rohár
> pali.rohar@gmail.com
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox