* [PATCH RESEND v4 2/2] elantech: Call psmouse_reset when elantech probe fails
From: Ulrik De Bie @ 2014-08-20 18:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Hans de Goede, David Herrmann, ulrik.debie-os
In-Reply-To: <1408558692-11736-1-git-send-email-ulrik.debie-os@e2big.org>
elantech_init() calls elantech_set_absolute_mode which sets the driver in
an absolute mode. When after this the elantech_init fails, it is best
to turn the ps/2 mouse emulation mode back on by calling psmouse_reset()
so that it can work as a regular mouse.
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org>
---
drivers/input/mouse/elantech.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 5dd620a..771291c 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1620,6 +1620,7 @@ int elantech_init(struct psmouse *psmouse)
sysfs_remove_group(&psmouse->ps2dev.serio->dev.kobj,
&elantech_attr_group);
init_fail:
+ psmouse_reset(psmouse);
kfree(etd);
return error;
}
--
2.1.0.rc1
^ permalink raw reply related
* [PATCH RESEND v4 1/2] elantech: Add support for trackpoint found on some v3 models
From: Ulrik De Bie @ 2014-08-20 18:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Hans de Goede, David Herrmann, ulrik.debie-os
In-Reply-To: <1408558692-11736-1-git-send-email-ulrik.debie-os@e2big.org>
Some elantech v3 touchpad equipped laptops also have a trackpoint, before
this commit, these give sync errors. With this patch, the trackpoint is
provided as another input device: 'Elantech PS/2 TrackPoint'
The patch will also output messages that do not follow the expected pattern.
In the mean time I've seen 2 unknown packets occasionally:
0x04 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00
0x00 , 0x00 , 0x00 , 0x02 , 0x00 , 0x00
I don't know what those are for, but they can be safely ignored.
Currently all packets that are not known to v3 touchpad and where
packet[3] (the fourth byte) lowest nibble is 6 are now recognized as
PACKET_TRACKPOINT and processed by the new elantech_report_trackpoint.
This has been verified to work on a laptop Lenovo L530 where the
touchpad/trackpoint combined identify themselves as:
psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x350f02)
psmouse serio1: elantech: Synaptics capabilities query result 0xb9, 0x15, 0x0c.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ulrik De Bie <ulrik.debie-os@e2big.org>
---
drivers/input/mouse/elantech.c | 122 +++++++++++++++++++++++++++++++++++++++--
drivers/input/mouse/elantech.h | 3 +
2 files changed, 121 insertions(+), 4 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index ee2a04d..5dd620a 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -403,6 +403,71 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
input_sync(dev);
}
+static void elantech_report_trackpoint(struct psmouse *psmouse,
+ int packet_type)
+{
+ /*
+ * byte 0: 0 0 ~sx ~sy 0 M R L
+ * byte 1: sx 0 0 0 0 0 0 0
+ * byte 2: sy 0 0 0 0 0 0 0
+ * byte 3: 0 0 sy sx 0 1 1 0
+ * byte 4: x7 x6 x5 x4 x3 x2 x1 x0
+ * byte 5: y7 y6 y5 y4 y3 y2 y1 y0
+ *
+ * x and y are written in two's complement spread
+ * over 9 bits with sx/sy the relative top bit and
+ * x7..x0 and y7..y0 the lower bits.
+ * The sign of y is opposite to what the input driver
+ * expects for a relative movement
+ */
+
+ struct elantech_data *etd = psmouse->private;
+ struct input_dev *tp_dev = etd->tp_dev;
+ unsigned char *packet = psmouse->packet;
+ int x, y;
+ u32 t;
+
+ if (!tp_dev) {
+ static bool __section(.data.unlikely) __warned;
+
+ if (!__warned) {
+ __warned = true;
+ psmouse_err(psmouse, "Unexpected trackpoint message\n");
+ if (etd->debug == 1)
+ elantech_packet_dump(psmouse);
+ }
+
+ return;
+ }
+
+ input_report_key(tp_dev, BTN_LEFT, packet[0] & 0x01);
+ input_report_key(tp_dev, BTN_RIGHT, packet[0] & 0x02);
+ input_report_key(tp_dev, BTN_MIDDLE, packet[0] & 0x04);
+
+ x = ((packet[1] & 0x80) ? 0U : 0xFFFFFF00U) | packet[4];
+ y = -(int)(((packet[2] & 0x80) ? 0U : 0xFFFFFF00U) | packet[5]);
+
+ input_report_rel(tp_dev, REL_X, x);
+ input_report_rel(tp_dev, REL_Y, y);
+
+ t = (((u32)packet[0] & 0xF8) << 24) | ((u32)packet[1] << 16)
+ | (u32)packet[2] << 8 | (u32)packet[3];
+ switch (t) {
+ case 0x00808036U:
+ case 0x10008026U:
+ case 0x20800016U:
+ case 0x30000006U:
+ break;
+ default:
+ /* Dump unexpected packet sequences if debug=1 (default) */
+ if (etd->debug == 1)
+ elantech_packet_dump(psmouse);
+ break;
+ }
+
+ input_sync(tp_dev);
+}
+
/*
* Interpret complete data packets and report absolute mode input events for
* hardware version 3. (12 byte packets for two fingers)
@@ -715,6 +780,8 @@ static int elantech_packet_check_v3(struct psmouse *psmouse)
if ((packet[0] & 0x0c) == 0x0c && (packet[3] & 0xce) == 0x0c)
return PACKET_V3_TAIL;
+ if ((packet[3] & 0x0f) == 0x06)
+ return PACKET_TRACKPOINT;
}
return PACKET_UNKNOWN;
@@ -798,7 +865,10 @@ static psmouse_ret_t elantech_process_byte(struct psmouse *psmouse)
if (packet_type == PACKET_UNKNOWN)
return PSMOUSE_BAD_DATA;
- elantech_report_absolute_v3(psmouse, packet_type);
+ if (packet_type == PACKET_TRACKPOINT)
+ elantech_report_trackpoint(psmouse, packet_type);
+ else
+ elantech_report_absolute_v3(psmouse, packet_type);
break;
case 4:
@@ -1018,8 +1088,10 @@ static int elantech_get_resolution_v4(struct psmouse *psmouse,
* Asus UX31 0x361f00 20, 15, 0e clickpad
* Asus UX32VD 0x361f02 00, 15, 0e clickpad
* Avatar AVIU-145A2 0x361f00 ? clickpad
+ * Fujitsu H730 0x570f00 c0, 14, 0c 3 hw buttons (**)
* Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons
* Lenovo L430 0x350f02 b9, 15, 0c 2 hw buttons (*)
+ * Lenovo L530 0x350f02 b9, 15, 0c 2 hw buttons (*)
* Samsung NF210 0x150b00 78, 14, 0a 2 hw buttons
* Samsung NP770Z5E 0x575f01 10, 15, 0f clickpad
* Samsung NP700Z5B 0x361f06 21, 15, 0f clickpad
@@ -1029,6 +1101,8 @@ static int elantech_get_resolution_v4(struct psmouse *psmouse,
* Samsung RF710 0x450f00 ? 2 hw buttons
* System76 Pangolin 0x250f01 ? 2 hw buttons
* (*) + 3 trackpoint buttons
+ * (**) + 0 trackpoint buttons
+ * Note: Lenovo L430 and Lenovo L430 have the same fw_version/caps
*/
static void elantech_set_buttonpad_prop(struct psmouse *psmouse)
{
@@ -1324,6 +1398,10 @@ int elantech_detect(struct psmouse *psmouse, bool set_properties)
*/
static void elantech_disconnect(struct psmouse *psmouse)
{
+ struct elantech_data *etd = psmouse->private;
+
+ if (etd->tp_dev)
+ input_unregister_device(etd->tp_dev);
sysfs_remove_group(&psmouse->ps2dev.serio->dev.kobj,
&elantech_attr_group);
kfree(psmouse->private);
@@ -1438,8 +1516,10 @@ static int elantech_set_properties(struct elantech_data *etd)
int elantech_init(struct psmouse *psmouse)
{
struct elantech_data *etd;
- int i, error;
+ int i;
+ int error = -EINVAL;
unsigned char param[3];
+ struct input_dev *tp_dev;
psmouse->private = etd = kzalloc(sizeof(struct elantech_data), GFP_KERNEL);
if (!etd)
@@ -1498,14 +1578,48 @@ int elantech_init(struct psmouse *psmouse)
goto init_fail;
}
+ /* The MSB indicates the presence of the trackpoint */
+ if ((etd->capabilities[0] & 0x80) == 0x80) {
+ tp_dev = input_allocate_device();
+
+ if (!tp_dev) {
+ error = -ENOMEM;
+ goto init_fail_tp_alloc;
+ }
+
+ etd->tp_dev = tp_dev;
+ snprintf(etd->tp_phys, sizeof(etd->tp_phys), "%s/input1",
+ psmouse->ps2dev.serio->phys);
+ tp_dev->phys = etd->tp_phys;
+ tp_dev->name = "Elantech PS/2 TrackPoint";
+ tp_dev->id.bustype = BUS_I8042;
+ tp_dev->id.vendor = 0x0002;
+ tp_dev->id.product = PSMOUSE_ELANTECH;
+ tp_dev->id.version = 0x0000;
+ tp_dev->dev.parent = &psmouse->ps2dev.serio->dev;
+ tp_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REL);
+ tp_dev->relbit[BIT_WORD(REL_X)] =
+ BIT_MASK(REL_X) | BIT_MASK(REL_Y);
+ tp_dev->keybit[BIT_WORD(BTN_LEFT)] =
+ BIT_MASK(BTN_LEFT) | BIT_MASK(BTN_MIDDLE) |
+ BIT_MASK(BTN_RIGHT);
+ error = input_register_device(etd->tp_dev);
+ if (error < 0)
+ goto init_fail_tp_reg;
+ }
+
psmouse->protocol_handler = elantech_process_byte;
psmouse->disconnect = elantech_disconnect;
psmouse->reconnect = elantech_reconnect;
psmouse->pktsize = etd->hw_version > 1 ? 6 : 4;
return 0;
-
+ init_fail_tp_reg:
+ input_free_device(tp_dev);
+ init_fail_tp_alloc:
+ sysfs_remove_group(&psmouse->ps2dev.serio->dev.kobj,
+ &elantech_attr_group);
init_fail:
kfree(etd);
- return -1;
+ return error;
}
diff --git a/drivers/input/mouse/elantech.h b/drivers/input/mouse/elantech.h
index 9e0e2a1..e410336 100644
--- a/drivers/input/mouse/elantech.h
+++ b/drivers/input/mouse/elantech.h
@@ -94,6 +94,7 @@
#define PACKET_V4_HEAD 0x05
#define PACKET_V4_MOTION 0x06
#define PACKET_V4_STATUS 0x07
+#define PACKET_TRACKPOINT 0x08
/*
* track up to 5 fingers for v4 hardware
@@ -114,6 +115,8 @@ struct finger_pos {
};
struct elantech_data {
+ struct input_dev *tp_dev; /* Relative device for trackpoint */
+ char tp_phys[32];
unsigned char reg_07;
unsigned char reg_10;
unsigned char reg_11;
--
2.1.0.rc1
^ permalink raw reply related
* [PATCH RESEND v4 0/2] Input: Support in the elantech driver of the trackpoint present on for instance Lenovo L530
From: Ulrik De Bie @ 2014-08-20 18:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Hans de Goede, David Herrmann, ulrik.debie-os
Hi Dmitry,
I posted these 2 months ago, but haven't seen any comments from you.
Could you please review these ?
Thanks,
Ulrik
Patch 1 adds support for trackpoint on elantech driver for v3 models.
Patch 2 adds a psmouse_reset when the elantech probes fails. Patch 2 depends
on Patch 1.
Changes since v3:
* Patch1: added (correct) error after input_allocate_device failure in elantech_init()
* Patch2: added more explanation to the why
Changes since v2:
* psmouse_reset change is now moved to a separate patch
* comments/white spaces/newlines cleanup
* Unexpected trackpoint message warning now only printed once
* removed some unnecessary casts
* Deleted etd->trackpoint_present and use instead etd->tp_dev to indicate the
presence of a trackpoint
* Propagate the error when elantech_init fails
Changes since v1:
* New patch now with reference to 3.14rc1
* Added etd->trackpoint_present to indicate presence of trackpoint (based
on MSB of etd->capabilities[0])
* trackpoint will only be registered now when MSB of etd->capabilities[0] is
set; got confirmation that this is the indicator of trackpoint
* Added input_unregister_device/input_free_device in elantech_disconnect()
* Fixed a bug in cleaning up when elantech_init fails
* Rename commit to be more specific (now also applicable to future elantech
v3 models with trackpoint)
* input device name 'TPPS/2 IBM TrackPoint' changed to
'Elantech PS/2 TrackPoint', this patch is not ibm/lenovo specific!
* dev2 renamed to tp_dev to indicate that this is the trackpoint device
* etd->phys renamed to etd->tp_phys
* Added Lenovo 530 and Fujitsu H730 to the laptop list because those are now
also known.
* Added psmouse_reset at the end of elantech_init when it fails
* Added warning when trackpoint packets are received with no trackpoint detected
The patches are also available from:
https://github.com/ulrikdb/linux/commit/53d8424bc2143d34c2be76064892079fe1917a9e
https://github.com/ulrikdb/linux/commit/cf12fcc6cdf51a7aad48d056750478aecd9d7eca
Ulrik De Bie (2):
elantech: Add support for trackpoint found on some v3 models
elantech: Call psmouse_reset when elantech probe fails
drivers/input/mouse/elantech.c | 123 +++++++++++++++++++++++++++++++++++++++--
drivers/input/mouse/elantech.h | 3 +
2 files changed, 122 insertions(+), 4 deletions(-)
--
2.1.0.rc1
^ permalink raw reply
* Re: [RESEND PATCH 3/7] mfd: cros_ec: stop calling ->cmd_xfer() directly
From: Doug Anderson @ 2014-08-20 22:33 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Lee Jones, Wolfram Sang, Dmitry Torokhov, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c@vger.kernel.org,
linux-input@vger.kernel.org, linux-samsung-soc
In-Reply-To: <1408536812-7836-4-git-send-email-javier.martinez@collabora.co.uk>
Javier,
On Wed, Aug 20, 2014 at 5:13 AM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> From: Andrew Bresticker <abrestic@chromium.org>
>
> Instead of having users of the ChromeOS EC call the interface-specific
> cmd_xfer() callback directly, introduce a central cros_ec_cmd_xfer()
> to use instead. This will allow us to put all the locking and retry
> logic in one place instead of duplicating it across the different
> drivers.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
> drivers/input/keyboard/cros_ec_keyb.c | 2 +-
> drivers/mfd/cros_ec.c | 7 +++++++
> include/linux/mfd/cros_ec.h | 24 ++++++++++++++++++------
> 4 files changed, 27 insertions(+), 8 deletions(-)
Reviewed-by: Doug Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [RESEND PATCH 4/7] mfd: cros_ec: move locking into cros_ec_cmd_xfer
From: Doug Anderson @ 2014-08-20 22:36 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Lee Jones, Wolfram Sang, Dmitry Torokhov, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c@vger.kernel.org,
linux-input@vger.kernel.org, linux-samsung-soc
In-Reply-To: <1408536812-7836-5-git-send-email-javier.martinez@collabora.co.uk>
Javier,
On Wed, Aug 20, 2014 at 5:13 AM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> From: Andrew Bresticker <abrestic@chromium.org>
>
> Now that there's a central cros_ec_cmd_xfer(), move the locking
> out of the SPI and LPC drivers.
Slight nit that the LPC driver doesn't exist upstream. This is in
prep for adding the LPC driver, though.
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> drivers/mfd/cros_ec.c | 10 +++++++++-
> drivers/mfd/cros_ec_spi.c | 11 -----------
> 2 files changed, 9 insertions(+), 12 deletions(-)
After comment nitfix:
Reviewed-by: Doug Anderson <dianders@chromium.org>
^ permalink raw reply
* RE: [PATCH v4 0/14] input: cyapa: re-architecture driver to support multi-trackpads in one driver
From: Dudley Du @ 2014-08-21 1:36 UTC (permalink / raw)
To: Dudley Du, Dmitry Torokhov, Rafael J. Wysocki
Cc: Benson Leung, Patrik Fimml, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <53c77101.0374440a.664d.46e2@mx.google.com>
Hi Dmitry, Patrik,
Is there any update or feedback on the re-submitted v4 cyapa driver patches?
Thanks,
Dudley
> -----Original Message-----
> From: linux-input-owner@vger.kernel.org [mailto:linux-input-
> owner@vger.kernel.org] On Behalf Of Dudley Du
> Sent: Thursday, July 17, 2014 2:45 PM
> To: Dmitry Torokhov; Rafael J. Wysocki
> Cc: Benson Leung; Patrik Fimml; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH v4 0/14] input: cyapa: re-architecture driver to support
> multi-trackpads in one driver
>
> This patch set is made based on kernel 3.16.0-rc5.
> It's aimed to re-architecture the cyapa driver to support
> old gen3 trackpad device and new gen5 trackpad device in one
> cyapa driver for easily productions support based on
> customers' requirements, and add sysfs functions and interfaces
> supported that required by users and customers.
> Because the earlier gen3 and the latest gen5 trackpad devies using
> two different chipsets, and have different protocol and interfaces.
> If supported these two trackpad devices in two different drivers, then
> it will be difficult to manage productions and later firmware updates.
> it will cause customer don't know which one to use and update
> because these two trackpad devices have been used and integrated
> in same one productions at a time, so must to support these two trackpad
> devices in same on driver.
>
> Compare to v3, it has below changes:
> 1) Eliminate irq-state-remembering logic, remove irq help functions;
> 2) Remove state sync help functions instead of mutex_lock/mutex_unlock;
> 3) Fix comments and charaters errors and not consistent issues.
> 4) Fix other issues that pointed out in the review.
>
>
> The new architecture is made of:
> cyapa.c - the core of the architecture, supply interfaces and
> functions to system and read trackpad devices.
> cyapa_gen3.c - functions support for gen3 trackpad devices,
> cyapa_gen5.c - functions support for gen5 trackpad devices.
>
> Beside this introduction patch, it has 14 patches listed as below.
> For these patches each one is patched based on previous one.
>
> patch 1/14: re-architecture cyapa driver with core functions,
> and applying the device detecting function in async thread to speed
> up system boot time.
>
> patch 2/14: add cyapa driver power management interfaces support.
>
> patch 3/14: add cyapa driver runtime power management interfaces support.
>
> patch 4/14: add cyapa key function interfaces in sysfs system.
> Including read firmware version, get production ID, read baseline,
> re-calibrate trackpad baselines and do trackpad firmware update.
>
> patch 5/14: add read firmware image and read raw trackpad device'
> sensors' raw data interface in debugfs system.
>
> patch 6/14: add gen3 trackpad device basic functions support.
>
> patch 7/14: add gen3 trackpad device firmware update function support.
>
> patch 8/14: add gen3 trackpad device report baseline and do force
> re-calibrate functions support.
>
> patch 9/14: add gen3 trackpad device read firmware image function support.
>
> patch 10/14: add gen5 trackpad device basic functions support.
>
> patch 11/14: add gen5 trackpad device firmware update function support.
>
> patch 12/14: add gen5 trackpad device report baseline and do force
> re-calibrate functions support.
>
> patch 13/14: add gen5 trackpad device read firmware image and report
> sensors' raw data values functions support.
>
> patch 14/14: add function to monitor LID close event to off trackpad device.
>
> --
> 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
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
^ permalink raw reply
* [RFC 1/4] HID:hid-logitech: Add modparam to allow/disable switch to native mode
From: Simon Wood @ 2014-08-21 4:51 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Jiri Kosina, Simon Wood
---
drivers/hid/hid-lg.c | 17 ++++++++++++++++-
drivers/hid/hid-lg.h | 7 +++++--
drivers/hid/hid-lg4ff.c | 4 ++--
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index a976f48..81ba24d 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -334,6 +334,16 @@ static __u8 momo2_rdesc_fixed[] = {
};
/*
+ * Certain Logitech wheels provide various compatibililty modes
+ * for games that cannot handle their advanced features properly.
+ * This switch forces the wheel into a specific compatibililty
+ * instead of its native mode
+ */
+#ifdef CONFIG_LOGIWHEELS_FF
+static int lg4ff_switch_mode = LG4FF_MSW_NAT; /* Default to native mode */
+#endif
+
+/*
* Certain Logitech keyboards send in report #3 keys which are far
* above the logical maximum described in descriptor. This extends
* the original value of 0x28c of logical maximum to 0x104d
@@ -717,7 +727,7 @@ static int lg_probe(struct hid_device *hdev, const struct hid_device_id *id)
if (drv_data->quirks & LG_FF3)
lg3ff_init(hdev);
if (drv_data->quirks & LG_FF4)
- lg4ff_init(hdev);
+ lg4ff_init(hdev, lg4ff_switch_mode);
return 0;
err_free:
@@ -818,4 +828,9 @@ static struct hid_driver lg_driver = {
};
module_hid_driver(lg_driver);
+#ifdef CONFIG_LOGIWHEELS_FF
+module_param_named(lg4ff_switch_mode, lg4ff_switch_mode, int, S_IRUGO);
+MODULE_PARM_DESC(lg4ff_switch_mode, "Enable switch from compatibililty mode to native mode (only certain devices)");
+#endif
+
MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-lg.h b/drivers/hid/hid-lg.h
index 142ce3f..fc4bdae 100644
--- a/drivers/hid/hid-lg.h
+++ b/drivers/hid/hid-lg.h
@@ -25,14 +25,17 @@ static inline int lg3ff_init(struct hid_device *hdev) { return -1; }
#endif
#ifdef CONFIG_LOGIWHEELS_FF
+#define LG4FF_MSW_NAT -1 /* allow native mode */
+#define LG4FF_MSW_EMU 0 /* remain in or force emulation mode */
+
int lg4ff_adjust_input_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value, struct lg_drv_data *drv_data);
-int lg4ff_init(struct hid_device *hdev);
+int lg4ff_init(struct hid_device *hdev, const int switch_mode);
int lg4ff_deinit(struct hid_device *hdev);
#else
static inline int lg4ff_adjust_input_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value, struct lg_drv_data *drv_data) { return 0; }
-static inline int lg4ff_init(struct hid_device *hdev) { return -1; }
+static inline int lg4ff_init(struct hid_device *hdev, const int switch_mode) { return -1; }
static inline int lg4ff_deinit(struct hid_device *hdev) { return -1; }
#endif
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index cc2bd20..9247227 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -556,7 +556,7 @@ static enum led_brightness lg4ff_led_get_brightness(struct led_classdev *led_cde
}
#endif
-int lg4ff_init(struct hid_device *hid)
+int lg4ff_init(struct hid_device *hid, const int switch_mode)
{
struct hid_input *hidinput = list_entry(hid->inputs.next, struct hid_input, list);
struct input_dev *dev = hidinput->input;
@@ -594,7 +594,7 @@ int lg4ff_init(struct hid_device *hid)
rev_maj = bcdDevice >> 8;
rev_min = bcdDevice & 0xff;
- if (lg4ff_devices[i].product_id == USB_DEVICE_ID_LOGITECH_WHEEL) {
+ if (lg4ff_devices[i].product_id == USB_DEVICE_ID_LOGITECH_WHEEL && switch_mode != LG4FF_MSW_EMU) {
dbg_hid("Generic wheel detected, can it do native?\n");
dbg_hid("USB revision: %2x.%02x\n", rev_maj, rev_min);
--
1.9.1
^ permalink raw reply related
* [RFC 2/4] HID:hid-logitech: New detection of native capable devices
From: Simon Wood @ 2014-08-21 4:51 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Jiri Kosina, Simon Wood
In-Reply-To: <1408596702-3895-1-git-send-email-simon@mungewell.org>
---
drivers/hid/hid-lg.h | 5 +++
drivers/hid/hid-lg4ff.c | 115 ++++++++++++++++++++++++------------------------
2 files changed, 63 insertions(+), 57 deletions(-)
diff --git a/drivers/hid/hid-lg.h b/drivers/hid/hid-lg.h
index fc4bdae..cf442e5 100644
--- a/drivers/hid/hid-lg.h
+++ b/drivers/hid/hid-lg.h
@@ -27,6 +27,11 @@ static inline int lg3ff_init(struct hid_device *hdev) { return -1; }
#ifdef CONFIG_LOGIWHEELS_FF
#define LG4FF_MSW_NAT -1 /* allow native mode */
#define LG4FF_MSW_EMU 0 /* remain in or force emulation mode */
+#define LG4FF_MSW_DFP 1
+#define LG4FF_MSW_G25 2
+#define LG4FF_MSW_DFGT 3
+#define LG4FF_MSW_G27 4
+#define LG4FF_MSW_MAX 5 /* end-stop */
int lg4ff_adjust_input_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value, struct lg_drv_data *drv_data);
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index 9247227..eda07a2 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -56,6 +56,7 @@ static DEVICE_ATTR(range, S_IRWXU | S_IRWXG | S_IROTH, lg4ff_range_show, lg4ff_r
struct lg4ff_device_entry {
__u32 product_id;
+ __u16 type;
__u16 range;
__u16 min_range;
__u16 max_range;
@@ -73,23 +74,19 @@ static const signed short lg4ff_wheel_effects[] = {
-1
};
-struct lg4ff_wheel {
- const __u32 product_id;
- const signed short *ff_effects;
- const __u16 min_range;
- const __u16 max_range;
+struct lg4ff_mode_switcher {
+ const u16 bcdDevice;
+ const u16 mask;
+ const u16 type;
+ const __u32 native_pid;
void (*set_range)(struct hid_device *hid, u16 range);
};
-static const struct lg4ff_wheel lg4ff_devices[] = {
- {USB_DEVICE_ID_LOGITECH_WHEEL, lg4ff_wheel_effects, 40, 270, NULL},
- {USB_DEVICE_ID_LOGITECH_MOMO_WHEEL, lg4ff_wheel_effects, 40, 270, NULL},
- {USB_DEVICE_ID_LOGITECH_DFP_WHEEL, lg4ff_wheel_effects, 40, 900, hid_lg4ff_set_range_dfp},
- {USB_DEVICE_ID_LOGITECH_G25_WHEEL, lg4ff_wheel_effects, 40, 900, hid_lg4ff_set_range_g25},
- {USB_DEVICE_ID_LOGITECH_DFGT_WHEEL, lg4ff_wheel_effects, 40, 900, hid_lg4ff_set_range_g25},
- {USB_DEVICE_ID_LOGITECH_G27_WHEEL, lg4ff_wheel_effects, 40, 900, hid_lg4ff_set_range_g25},
- {USB_DEVICE_ID_LOGITECH_MOMO_WHEEL2, lg4ff_wheel_effects, 40, 270, NULL},
- {USB_DEVICE_ID_LOGITECH_WII_WHEEL, lg4ff_wheel_effects, 40, 270, NULL}
+static const struct lg4ff_mode_switcher lg4ff_mode_switchers[] = { /* Note: Order is important for detection process */
+ {0x1300, 0xff00, LG4FF_MSW_DFGT, USB_DEVICE_ID_LOGITECH_DFGT_WHEEL, hid_lg4ff_set_range_g25},
+ {0x1230, 0xfff0, LG4FF_MSW_G27, USB_DEVICE_ID_LOGITECH_G27_WHEEL, hid_lg4ff_set_range_g25},
+ {0x1200, 0xff00, LG4FF_MSW_G25, USB_DEVICE_ID_LOGITECH_G25_WHEEL, hid_lg4ff_set_range_g25},
+ {0x1000, 0xf000, LG4FF_MSW_DFP, USB_DEVICE_ID_LOGITECH_DFP_WHEEL, hid_lg4ff_set_range_dfp},
};
struct lg4ff_native_cmd {
@@ -570,50 +567,12 @@ int lg4ff_init(struct hid_device *hid, const int switch_mode)
if (!hid_validate_values(hid, HID_OUTPUT_REPORT, 0, 0, 7))
return -1;
- /* Check what wheel has been connected */
- for (i = 0; i < ARRAY_SIZE(lg4ff_devices); i++) {
- if (hid->product == lg4ff_devices[i].product_id) {
- dbg_hid("Found compatible device, product ID %04X\n", lg4ff_devices[i].product_id);
- break;
- }
- }
-
- if (i == ARRAY_SIZE(lg4ff_devices)) {
- hid_err(hid, "Device is not supported by lg4ff driver. If you think it should be, consider reporting a bug to"
- "LKML, Simon Wood <simon@mungewell.org> or Michal Maly <madcatxster@gmail.com>\n");
- return -1;
- }
-
/* Attempt to switch wheel to native mode when applicable */
udesc = &(hid_to_usb_dev(hid)->descriptor);
if (!udesc) {
hid_err(hid, "NULL USB device descriptor\n");
return -1;
}
- bcdDevice = le16_to_cpu(udesc->bcdDevice);
- rev_maj = bcdDevice >> 8;
- rev_min = bcdDevice & 0xff;
-
- if (lg4ff_devices[i].product_id == USB_DEVICE_ID_LOGITECH_WHEEL && switch_mode != LG4FF_MSW_EMU) {
- dbg_hid("Generic wheel detected, can it do native?\n");
- dbg_hid("USB revision: %2x.%02x\n", rev_maj, rev_min);
-
- for (j = 0; j < ARRAY_SIZE(lg4ff_revs); j++) {
- if (lg4ff_revs[j].rev_maj == rev_maj && lg4ff_revs[j].rev_min == rev_min) {
- hid_lg4ff_switch_native(hid, lg4ff_revs[j].command);
- hid_info(hid, "Switched to native mode\n");
- }
- }
- }
-
- /* Set supported force feedback capabilities */
- for (j = 0; lg4ff_devices[i].ff_effects[j] >= 0; j++)
- set_bit(lg4ff_devices[i].ff_effects[j], dev->ffbit);
-
- error = input_ff_create_memless(dev, NULL, hid_lg4ff_play);
-
- if (error)
- return error;
/* Get private driver data */
drv_data = hid_get_drvdata(hid);
@@ -630,10 +589,52 @@ int lg4ff_init(struct hid_device *hid, const int switch_mode)
}
drv_data->device_props = entry;
- entry->product_id = lg4ff_devices[i].product_id;
- entry->min_range = lg4ff_devices[i].min_range;
- entry->max_range = lg4ff_devices[i].max_range;
- entry->set_range = lg4ff_devices[i].set_range;
+ entry->product_id = hid->product;
+ entry->set_range = NULL;
+ entry->type = LG4FF_MSW_EMU;
+
+ /* Check which wheel has been connected */
+ bcdDevice = le16_to_cpu(udesc->bcdDevice);
+ rev_maj = bcdDevice >> 8;
+ rev_min = bcdDevice & 0xff;
+
+ for (i = 0; i < ARRAY_SIZE(lg4ff_mode_switchers); i++) {
+ const struct lg4ff_mode_switcher *s = &lg4ff_mode_switchers[i];
+
+ if (s->bcdDevice != (bcdDevice & s->mask))
+ continue;
+
+ entry->type = s->type;
+ dbg_hid("Native capable device detected (Native ID %04X, type %d)\n", s->native_pid, s->type);
+
+ if (hid->product == s->native_pid) {
+ entry->product_id = s->native_pid;
+ entry->min_range = 40;
+ entry->max_range = 900;
+ entry->set_range = s->set_range;
+ }
+
+ if (hid->product != s->native_pid && switch_mode != LG4FF_MSW_EMU) {
+ dbg_hid("Switching to native mode\n");
+
+ for (j = 0; j < ARRAY_SIZE(lg4ff_revs); j++) {
+ if (lg4ff_revs[j].rev_maj == rev_maj && lg4ff_revs[j].rev_min == rev_min) {
+ hid_lg4ff_switch_native(hid, lg4ff_revs[j].command);
+ hid_info(hid, "Switched to native mode\n");
+ }
+ }
+ }
+ break;
+ }
+
+ /* Set supported force feedback capabilities */
+ for (j = 0; lg4ff_wheel_effects[j] >= 0; j++)
+ set_bit(lg4ff_wheel_effects[j], dev->ffbit);
+
+ error = input_ff_create_memless(dev, NULL, hid_lg4ff_play);
+
+ if (error)
+ return error;
/* Check if autocentering is available and
* set the centering force to zero by default */
@@ -663,7 +664,7 @@ int lg4ff_init(struct hid_device *hid, const int switch_mode)
for (j = 0; j < 5; j++)
entry->led[j] = NULL;
- if (lg4ff_devices[i].product_id == USB_DEVICE_ID_LOGITECH_G27_WHEEL) {
+ if (entry->type == LG4FF_MSW_G27) {
struct led_classdev *led;
size_t name_sz;
char *name;
--
1.9.1
^ permalink raw reply related
* Re: PATCH hid: Implement mode switching on Logitech gaming wheels accordingly to the documentation
From: simon @ 2014-08-21 4:55 UTC (permalink / raw)
Cc: "Michal Malý", Jiri Kosina, simon@mungewell.org,
linux-input, linux-kernel@vger.kernel.org, edwin,
elias.vds@gmail.com, Roland Bosa
In-Reply-To: <629e44bcbdb7061b2f004cf9125fed9b.squirrel@mungewell.org>
> Whilst it is my intention to submit them, I might not achieve the 'very
> soon' part.... earliest I think would be mid next week as they still need
> a little tweaking.
I've sent in patches as 'RFC' as I think they still need a little more
testing and I'm tied up with work stuff for the next week or so (and won't
have access to the hardware).
If people can test/comment that would be great,
Simon
^ permalink raw reply
* [RFC 3/4] HID:hid-logitech: Use new native switch method
From: Simon Wood @ 2014-08-21 4:51 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Jiri Kosina, Simon Wood
In-Reply-To: <1408596702-3895-1-git-send-email-simon@mungewell.org>
---
drivers/hid/hid-lg4ff.c | 126 +++++++++++++++++++++---------------------------
1 file changed, 55 insertions(+), 71 deletions(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index eda07a2..0ba0838 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -32,21 +32,10 @@
#include "hid-lg.h"
#include "hid-ids.h"
-#define DFGT_REV_MAJ 0x13
-#define DFGT_REV_MIN 0x22
-#define DFGT2_REV_MIN 0x26
-#define DFP_REV_MAJ 0x11
-#define DFP_REV_MIN 0x06
-#define FFEX_REV_MAJ 0x21
-#define FFEX_REV_MIN 0x00
-#define G25_REV_MAJ 0x12
-#define G25_REV_MIN 0x22
-#define G27_REV_MAJ 0x12
-#define G27_REV_MIN 0x38
-#define G27_2_REV_MIN 0x39
-
#define to_hid_device(pdev) container_of(pdev, struct hid_device, dev)
+#define LG4FF_FFEX_BCDDEVICE 0x2100
+
static void hid_lg4ff_set_range_dfp(struct hid_device *hid, u16 range);
static void hid_lg4ff_set_range_g25(struct hid_device *hid, u16 range);
static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute *attr, char *buf);
@@ -89,48 +78,6 @@ static const struct lg4ff_mode_switcher lg4ff_mode_switchers[] = { /* Note: Orde
{0x1000, 0xf000, LG4FF_MSW_DFP, USB_DEVICE_ID_LOGITECH_DFP_WHEEL, hid_lg4ff_set_range_dfp},
};
-struct lg4ff_native_cmd {
- const __u8 cmd_num; /* Number of commands to send */
- const __u8 cmd[];
-};
-
-struct lg4ff_usb_revision {
- const __u16 rev_maj;
- const __u16 rev_min;
- const struct lg4ff_native_cmd *command;
-};
-
-static const struct lg4ff_native_cmd native_dfp = {
- 1,
- {0xf8, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00}
-};
-
-static const struct lg4ff_native_cmd native_dfgt = {
- 2,
- {0xf8, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, /* 1st command */
- 0xf8, 0x09, 0x03, 0x01, 0x00, 0x00, 0x00} /* 2nd command */
-};
-
-static const struct lg4ff_native_cmd native_g25 = {
- 1,
- {0xf8, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00}
-};
-
-static const struct lg4ff_native_cmd native_g27 = {
- 2,
- {0xf8, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, /* 1st command */
- 0xf8, 0x09, 0x04, 0x01, 0x00, 0x00, 0x00} /* 2nd command */
-};
-
-static const struct lg4ff_usb_revision lg4ff_revs[] = {
- {DFGT_REV_MAJ, DFGT_REV_MIN, &native_dfgt}, /* Driving Force GT */
- {DFGT_REV_MAJ, DFGT2_REV_MIN, &native_dfgt}, /* Driving Force GT v2 */
- {DFP_REV_MAJ, DFP_REV_MIN, &native_dfp}, /* Driving Force Pro */
- {G25_REV_MAJ, G25_REV_MIN, &native_g25}, /* G25 */
- {G27_REV_MAJ, G27_REV_MIN, &native_g27}, /* G27 */
- {G27_REV_MAJ, G27_2_REV_MIN, &native_g27}, /* G27 v2 */
-};
-
/* Recalculates X axis value accordingly to currently selected range */
static __s32 lg4ff_adjust_dfp_x_axis(__s32 value, __u16 range)
{
@@ -397,19 +344,63 @@ static void hid_lg4ff_set_range_dfp(struct hid_device *hid, __u16 range)
hid_hw_request(hid, report, HID_REQ_SET_REPORT);
}
-static void hid_lg4ff_switch_native(struct hid_device *hid, const struct lg4ff_native_cmd *cmd)
+static int lg4ff_switch_mode(struct hid_device *hid, __u16 type, int mode)
{
struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
struct hid_report *report = list_entry(report_list->next, struct hid_report, list);
- __u8 i, j;
+ __s32 *value = report->field[0]->value;
+
+ if (mode >= LG4FF_MSW_MAX || mode <= LG4FF_MSW_NAT) mode = type;
+
+ if (type == LG4FF_MSW_G25 && mode == LG4FF_MSW_G25) {
+ value[0] = 0xf8;
+ value[1] = 0x10;
+ value[2] = 0x00;
+ value[3] = 0x00;
+ value[4] = 0x00;
+ value[5] = 0x00;
+ value[6] = 0x00;
+
+ hid_hw_request(hid, report, HID_REQ_SET_REPORT);
+ return 0;
+ }
- j = 0;
- while (j < 7*cmd->cmd_num) {
- for (i = 0; i < 7; i++)
- report->field[0]->value[i] = cmd->cmd[j++];
+ if (mode == LG4FF_MSW_DFP) {
+ value[0] = 0xf8;
+ value[1] = 0x01;
+ value[2] = 0x00;
+ value[3] = 0x00;
+ value[4] = 0x00;
+ value[5] = 0x00;
+ value[6] = 0x00;
hid_hw_request(hid, report, HID_REQ_SET_REPORT);
+ return 0;
}
+
+ /* Prevent compat mode on USB reset */
+ if (type == LG4FF_MSW_DFGT || type == LG4FF_MSW_G27) {
+ value[0] = 0xf8;
+ value[1] = 0x0a;
+ value[2] = 0x00;
+ value[3] = 0x00;
+ value[4] = 0x00;
+ value[5] = 0x00;
+ value[6] = 0x00;
+
+ hid_hw_request(hid, report, HID_REQ_SET_REPORT);
+ }
+
+ value[0] = 0xf8;
+ value[1] = 0x09;
+ value[2] = mode;
+ value[3] = 0x01;
+ value[4] = 0x00;
+ value[5] = 0x00;
+ value[6] = 0x00;
+
+ hid_hw_request(hid, report, HID_REQ_SET_REPORT);
+ return 0;
}
/* Read current range and display it in terminal */
@@ -608,21 +599,14 @@ int lg4ff_init(struct hid_device *hid, const int switch_mode)
dbg_hid("Native capable device detected (Native ID %04X, type %d)\n", s->native_pid, s->type);
if (hid->product == s->native_pid) {
- entry->product_id = s->native_pid;
entry->min_range = 40;
entry->max_range = 900;
entry->set_range = s->set_range;
}
- if (hid->product != s->native_pid && switch_mode != LG4FF_MSW_EMU) {
+ if (hid->product == USB_DEVICE_ID_LOGITECH_WHEEL && switch_mode != LG4FF_MSW_EMU) {
dbg_hid("Switching to native mode\n");
-
- for (j = 0; j < ARRAY_SIZE(lg4ff_revs); j++) {
- if (lg4ff_revs[j].rev_maj == rev_maj && lg4ff_revs[j].rev_min == rev_min) {
- hid_lg4ff_switch_native(hid, lg4ff_revs[j].command);
- hid_info(hid, "Switched to native mode\n");
- }
- }
+ lg4ff_switch_mode(hid, s->type, switch_mode);
}
break;
}
@@ -639,7 +623,7 @@ int lg4ff_init(struct hid_device *hid, const int switch_mode)
/* Check if autocentering is available and
* set the centering force to zero by default */
if (test_bit(FF_AUTOCENTER, dev->ffbit)) {
- if (rev_maj == FFEX_REV_MAJ && rev_min == FFEX_REV_MIN) /* Formula Force EX expects different autocentering command */
+ if (bcdDevice == LG4FF_FFEX_BCDDEVICE) /* Formula Force EX does not seem to support hi-res autocentering */
dev->ff->set_autocenter = hid_lg4ff_set_autocenter_ffex;
else
dev->ff->set_autocenter = hid_lg4ff_set_autocenter_default;
--
1.9.1
^ permalink raw reply related
* [RFC 4/4] HID:hid-logitech: Add mode control via /sys interface
From: Simon Wood @ 2014-08-21 4:51 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Jiri Kosina, Simon Wood
In-Reply-To: <1408596702-3895-1-git-send-email-simon@mungewell.org>
---
drivers/hid/hid-lg4ff.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 78 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index 0ba0838..1be561e 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -41,11 +41,16 @@ static void hid_lg4ff_set_range_g25(struct hid_device *hid, u16 range);
static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute *attr, char *buf);
static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
+static ssize_t lg4ff_mode_show(struct device *dev, struct device_attribute *attr, char *buf);
+static ssize_t lg4ff_mode_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count);
+
static DEVICE_ATTR(range, S_IRWXU | S_IRWXG | S_IROTH, lg4ff_range_show, lg4ff_range_store);
+static DEVICE_ATTR(mode, S_IRWXU | S_IRWXG | S_IROTH, lg4ff_mode_show, lg4ff_mode_store);
struct lg4ff_device_entry {
__u32 product_id;
__u16 type;
+ __u16 mode;
__u16 range;
__u16 min_range;
__u16 max_range;
@@ -362,7 +367,7 @@ static int lg4ff_switch_mode(struct hid_device *hid, __u16 type, int mode)
value[6] = 0x00;
hid_hw_request(hid, report, HID_REQ_SET_REPORT);
- return 0;
+ return LG4FF_MSW_G25;
}
if (mode == LG4FF_MSW_DFP) {
@@ -375,7 +380,7 @@ static int lg4ff_switch_mode(struct hid_device *hid, __u16 type, int mode)
value[6] = 0x00;
hid_hw_request(hid, report, HID_REQ_SET_REPORT);
- return 0;
+ return LG4FF_MSW_DFP;
}
/* Prevent compat mode on USB reset */
@@ -400,7 +405,7 @@ static int lg4ff_switch_mode(struct hid_device *hid, __u16 type, int mode)
value[6] = 0x00;
hid_hw_request(hid, report, HID_REQ_SET_REPORT);
- return 0;
+ return mode;
}
/* Read current range and display it in terminal */
@@ -461,6 +466,66 @@ static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute *at
return count;
}
+/* Read current mode and display it in terminal */
+static ssize_t lg4ff_mode_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct hid_device *hid = to_hid_device(dev);
+ struct lg4ff_device_entry *entry;
+ struct lg_drv_data *drv_data;
+ size_t count;
+
+ drv_data = hid_get_drvdata(hid);
+ if (!drv_data) {
+ hid_err(hid, "Private driver data not found!\n");
+ return 0;
+ }
+
+ entry = drv_data->device_props;
+ if (!entry) {
+ hid_err(hid, "Device properties not found!\n");
+ return 0;
+ }
+
+ count = scnprintf(buf, PAGE_SIZE, "%u\n", entry->mode);
+ return count;
+}
+
+/* Set mode to user specified value */
+static ssize_t lg4ff_mode_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct hid_device *hid = to_hid_device(dev);
+ struct lg4ff_device_entry *entry;
+ struct lg_drv_data *drv_data;
+ int err;
+ __u16 mode = simple_strtoul(buf, NULL, 10);
+
+ drv_data = hid_get_drvdata(hid);
+ if (!drv_data) {
+ hid_err(hid, "Private driver data not found!\n");
+ return -EINVAL;
+ }
+
+ entry = drv_data->device_props;
+ if (!entry) {
+ hid_err(hid, "Device properties not found!\n");
+ return -EINVAL;
+ }
+
+ if (mode == entry->mode) {
+ dbg_hid("Device is already in mode %d\n", mode);
+ return count;
+ }
+
+ err = lg4ff_switch_mode(hid, entry->type, mode);
+ if (err != mode) {
+ hid_err(hid, "Unable to switch mode\n");
+ return -1;
+ }
+
+ entry->mode = mode;
+ return count;
+}
+
#ifdef CONFIG_LEDS_CLASS
static void lg4ff_set_leds(struct hid_device *hid, __u8 leds)
{
@@ -583,6 +648,7 @@ int lg4ff_init(struct hid_device *hid, const int switch_mode)
entry->product_id = hid->product;
entry->set_range = NULL;
entry->type = LG4FF_MSW_EMU;
+ entry->mode = LG4FF_MSW_EMU;
/* Check which wheel has been connected */
bcdDevice = le16_to_cpu(udesc->bcdDevice);
@@ -602,6 +668,11 @@ int lg4ff_init(struct hid_device *hid, const int switch_mode)
entry->min_range = 40;
entry->max_range = 900;
entry->set_range = s->set_range;
+
+ if (switch_mode == LG4FF_MSW_NAT)
+ entry->mode = s->type;
+ else
+ entry->mode = switch_mode;
}
if (hid->product == USB_DEVICE_ID_LOGITECH_WHEEL && switch_mode != LG4FF_MSW_EMU) {
@@ -635,6 +706,9 @@ int lg4ff_init(struct hid_device *hid, const int switch_mode)
error = device_create_file(&hid->dev, &dev_attr_range);
if (error)
return error;
+ error = device_create_file(&hid->dev, &dev_attr_mode);
+ if (error)
+ return error;
dbg_hid("sysfs interface created\n");
/* Set the maximum range to start with */
@@ -705,6 +779,7 @@ int lg4ff_deinit(struct hid_device *hid)
struct lg_drv_data *drv_data;
device_remove_file(&hid->dev, &dev_attr_range);
+ device_remove_file(&hid->dev, &dev_attr_mode);
drv_data = hid_get_drvdata(hid);
if (!drv_data) {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Geert Uytterhoeven @ 2014-08-21 7:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Takashi Iwai, Andreas Mohr, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, Vojtech Pavlik, Jiri Kosina
In-Reply-To: <20140820144952.GB18099@core.coreip.homeip.net>
Hi Dmitry,
On Wed, Aug 20, 2014 at 4:49 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Aug 20, 2014 at 02:15:30PM +0200, Takashi Iwai wrote:
>> At Wed, 20 Aug 2014 09:05:58 +0200,
>> Takashi Iwai wrote:
>> > Well, it worked on my test machine a year ago or so. Maybe I had a
>> > good luck.
>>
>> FYI, now I tested again an analog joystick on SB Live put on a Dell
>> IvyBridge desktop with 3.17-rc1 x86-64 kernel, and it worked fine as
>> is.
>>
>> So it's not that broken.
>
> That's probably because in your system TSCs are stable when switching CPU
> frequency. Earlier systems had bunch of issues there IIRC.
>From the success stories above, it seems gameport doesn't work on only
a limited number of systems.
Perhaps the subsystem can fail with a big fat warning at runtime if such
a system is detected?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RESEND PATCH 4/7] mfd: cros_ec: move locking into cros_ec_cmd_xfer
From: Javier Martinez Canillas @ 2014-08-21 10:24 UTC (permalink / raw)
To: Doug Anderson
Cc: Lee Jones, Wolfram Sang, Dmitry Torokhov, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c@vger.kernel.org,
linux-input@vger.kernel.org, linux-samsung-soc
In-Reply-To: <CAD=FV=WAMKrmDTQbDrjR2XtFcNVUuzJfWspN5a7nE7kLWS9=4A@mail.gmail.com>
Hello Doug,
On 08/21/2014 12:36 AM, Doug Anderson wrote:
> Javier,
>
> On Wed, Aug 20, 2014 at 5:13 AM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> From: Andrew Bresticker <abrestic@chromium.org>
>>
>> Now that there's a central cros_ec_cmd_xfer(), move the locking
>> out of the SPI and LPC drivers.
>
> Slight nit that the LPC driver doesn't exist upstream. This is in
> prep for adding the LPC driver, though.
>
Right, the downstream commit was also touching the LPC driver and I
stripped that part but forget to update the commit message, sorry about
that. I'll fix it and do a re-spin.
>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Reviewed-by: Simon Glass <sjg@chromium.org>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>> drivers/mfd/cros_ec.c | 10 +++++++++-
>> drivers/mfd/cros_ec_spi.c | 11 -----------
>> 2 files changed, 9 insertions(+), 12 deletions(-)
>
> After comment nitfix:
>
> Reviewed-by: Doug Anderson <dianders@chromium.org>
>
Thanks and best regards,
Javier
^ permalink raw reply
* Re: USB reset xhci_hcd for ELAN touchscreen
From: Johan Hovold @ 2014-08-21 10:54 UTC (permalink / raw)
To: Jiri Kosina
Cc: Johan Hovold, Greg KH, Alan Stern, Bjørn Mork, Sarah Sharp,
Drew Von Spreecken, linux-usb, Mathias Nyman, linux-input
In-Reply-To: <alpine.LNX.2.00.1408200817330.23162@pobox.suse.cz>
On Wed, Aug 20, 2014 at 08:20:43AM -0500, Jiri Kosina wrote:
> On Mon, 14 Jul 2014, Johan Hovold wrote:
>
> > From 8101c0dfd42a232f1d2872de4f412d8d61d5646f Mon Sep 17 00:00:00 2001
> > From: Johan Hovold <johan@kernel.org>
> > Date: Mon, 14 Jul 2014 18:43:31 +0200
> > Subject: [PATCH] HID: usbhid: add HID_QUIRK_IN
> >
> > Add quirk to submit the interrupt-in urb already at start() rather than
> > at open().
> >
> > This is needed for devices that disconnects from the bus unless the
> > interrupt endpoint has been polled at least once or when not responding
> > to input events.
>
> It's not really super-nice, but if no other way around it has been found
> to be possible in USB core, I am willing to take this.
Agreed, it's not that nice, but I'm not aware of any other way to
prevent the device firmware from disconnecting.
Autosuspend still seems to work, so it would not cause much overhead
for people not actually using the touchscreen (as long as autosuspend
is enabled) either.
> > ---
> > drivers/hid/usbhid/hid-core.c | 26 +++++++++++++++++++++++---
> > include/linux/hid.h | 1 +
> > 2 files changed, 24 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> > index 7b88f4c..4b5d986 100644
> > --- a/drivers/hid/usbhid/hid-core.c
> > +++ b/drivers/hid/usbhid/hid-core.c
> > @@ -82,7 +82,7 @@ static int hid_start_in(struct hid_device *hid)
> > struct usbhid_device *usbhid = hid->driver_data;
> >
> > spin_lock_irqsave(&usbhid->lock, flags);
> > - if (hid->open > 0 &&
> > + if ((hid->open > 0 || hid->quirks & HID_QUIRK_IN) &&
> > !test_bit(HID_DISCONNECTED, &usbhid->iofl) &&
> > !test_bit(HID_SUSPENDED, &usbhid->iofl) &&
> > !test_and_set_bit(HID_IN_RUNNING, &usbhid->iofl)) {
> > @@ -292,6 +292,8 @@ static void hid_irq_in(struct urb *urb)
> > case 0: /* success */
> > usbhid_mark_busy(usbhid);
> > usbhid->retry_delay = 0;
> > + if ((hid->quirks & HID_QUIRK_IN) && !hid->open)
> > + break;
> > hid_input_report(urb->context, HID_INPUT_REPORT,
> > urb->transfer_buffer,
> > urb->actual_length, 1);
> > @@ -734,8 +736,10 @@ void usbhid_close(struct hid_device *hid)
> > if (!--hid->open) {
> > spin_unlock_irq(&usbhid->lock);
> > hid_cancel_delayed_stuff(usbhid);
> > - usb_kill_urb(usbhid->urbin);
> > - usbhid->intf->needs_remote_wakeup = 0;
> > + if (!(hid->quirks & HID_QUIRK_IN)) {
> > + usb_kill_urb(usbhid->urbin);
> > + usbhid->intf->needs_remote_wakeup = 0;
> > + }
> > } else {
> > spin_unlock_irq(&usbhid->lock);
> > }
> > @@ -1133,6 +1137,20 @@ static int usbhid_start(struct hid_device *hid)
> >
> > set_bit(HID_STARTED, &usbhid->iofl);
> >
> > + hid->quirks |= HID_QUIRK_IN; /* FIXME */
>
> This of course needs to be set on per-device basis :)
Of course.
> > + if (hid->quirks & HID_QUIRK_IN) {
> > + ret = usb_autopm_get_interface(usbhid->intf);
> > + if (ret)
> > + goto fail;
> > + usbhid->intf->needs_remote_wakeup = 1;
> > + ret = hid_start_in(hid);
> > + if (ret) {
> > + dev_err(&hid->dev,
> > + "failed to start in urb: %d\n", ret);
> > + }
> > + usb_autopm_put_interface(usbhid->intf);
> > + }
> > +
> > /* Some keyboards don't work until their LEDs have been set.
> > * Since BIOSes do set the LEDs, it must be safe for any device
> > * that supports the keyboard boot protocol.
> > @@ -1165,6 +1183,8 @@ static void usbhid_stop(struct hid_device *hid)
> > if (WARN_ON(!usbhid))
> > return;
> >
> > + usbhid->intf->needs_remote_wakeup = 0;
> > +
> > clear_bit(HID_STARTED, &usbhid->iofl);
> > spin_lock_irq(&usbhid->lock); /* Sync with error and led handlers */
> > set_bit(HID_DISCONNECTED, &usbhid->iofl);
> > diff --git a/include/linux/hid.h b/include/linux/hid.h
> > index 77632cf..13f81ae 100644
> > --- a/include/linux/hid.h
> > +++ b/include/linux/hid.h
> > @@ -286,6 +286,7 @@ struct hid_item {
> > #define HID_QUIRK_HIDINPUT_FORCE 0x00000080
> > #define HID_QUIRK_NO_EMPTY_INPUT 0x00000100
> > #define HID_QUIRK_NO_INIT_INPUT_REPORTS 0x00000200
> > +#define HID_QUIRK_IN 0x00000400
>
> 0x00000400 has been removed before dynamic quirks started to be possible,
> so there is no potential clash, that's fine.
>
> I'd just propose some more descriptive name for the quirk ... how about
> something like HID_QUIRK_EARLY_INTERRUPT?
Yeah, IN was just a working name. How about HID_QUIRK_ALWAYS_POLL or
similar as it is not just about disconnect before the device is opened,
but also if there's an event after the device has been closed (e.g.
stopping X)?
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH 1/2] SOUND: kill gameport bits
From: Takashi Iwai @ 2014-08-21 11:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andreas Mohr, linux-input, linux-kernel, Vojtech Pavlik,
Jiri Kosina
In-Reply-To: <s5htx57hc89.wl-tiwai@suse.de>
At Wed, 20 Aug 2014 09:05:58 +0200,
Takashi Iwai wrote:
>
> > > > > Also, I'm left wondering why e.g. my Athlon XP system (a very popular
> > > > > choice for longer times) would be affected by Cpufreq...
> > > > > And there are no details on how exactly cpufreq is a problem or how this
> > > > > timing issue could be fixed...
> > > >
> > > > If you take a look at gameport_measure_speed() in gameport.c you will see that
> > > > it counts cycles for timing, which obviously does not work that well when CPU
> > > > frequency changes.
> > > >
> > > > The bugs have been opened in bugzilla/reported on lists ages ago but nobody
> > > > stepped up to fix that.
> > >
> > > Hm, can't we just use the standard ktime for measuring the time diff?
> >
> > We could use high-res timers, if they are available. Are they available on such
> > old hardware and are they sufficiently fast to provide needed timings? I
> > definitely do not have any hardware to est with.
>
> The boards aren't necessarily bound with the old hardware. PCI boards
> run fine on the modern machines if they still have a PCI slot (how
> lucky). And, the highres timer itself isn't so new...
I did a quick hack and it seems working on my box.
The patch is below.
thanks,
Takashi
-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] Input: joystick - Use ktime for measuring timing
The current codes in gameport and analog joystick drivers for the time
accounting have a long-standing problem when the system is running
with CPU freq; since the timing is measured via TSC or sample counter,
the calculation isn't reliable.
In this patch, as a simple fix, use the standard ktime to measure the
timing. In case where no high resolution timer is available,
use_ktime bool option is provided to both modules. Setting
use_ktime=false switches to the old methods.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/input/gameport/gameport.c | 38 ++++++++++++++++++++-
drivers/input/joystick/analog.c | 70 ++++++++++++++++++++++++++++-----------
2 files changed, 88 insertions(+), 20 deletions(-)
diff --git a/drivers/input/gameport/gameport.c b/drivers/input/gameport/gameport.c
index 24c41ba7d4e0..48d91f12e397 100644
--- a/drivers/input/gameport/gameport.c
+++ b/drivers/input/gameport/gameport.c
@@ -23,6 +23,7 @@
#include <linux/workqueue.h>
#include <linux/sched.h> /* HZ */
#include <linux/mutex.h>
+#include <linux/timekeeping.h>
/*#include <asm/io.h>*/
@@ -30,6 +31,9 @@ MODULE_AUTHOR("Vojtech Pavlik <vojtech@ucw.cz>");
MODULE_DESCRIPTION("Generic gameport layer");
MODULE_LICENSE("GPL");
+static bool use_ktime = true;
+module_param(use_ktime, bool, 0400);
+
/*
* gameport_mutex protects entire gameport subsystem and is taken
* every time gameport port or driver registrered or unregistered.
@@ -76,6 +80,36 @@ static unsigned int get_time_pit(void)
static int gameport_measure_speed(struct gameport *gameport)
{
+ unsigned int i, t, tx;
+ u64 t1, t2;
+ unsigned long flags;
+
+ if (gameport_open(gameport, NULL, GAMEPORT_MODE_RAW))
+ return 0;
+
+ tx = ~0;
+
+ for (i = 0; i < 50; i++) {
+ local_irq_save(flags);
+ t1 = ktime_get_ns();
+ for (t = 0; t < 50; t++)
+ gameport_read(gameport);
+ t2 = ktime_get_ns();
+ local_irq_restore(flags);
+ udelay(i * 10);
+ if (t2 - t1 < tx)
+ tx = t2 - t1;
+ }
+
+ gameport_close(gameport);
+ t = 1000000 * 50;
+ if (tx)
+ t /= tx;
+ return t;
+}
+
+static int old_gameport_measure_speed(struct gameport *gameport)
+{
#if defined(__i386__)
unsigned int i, t, t1, t2, t3, tx;
@@ -521,7 +555,9 @@ static void gameport_add_port(struct gameport *gameport)
if (gameport->parent)
gameport->parent->child = gameport;
- gameport->speed = gameport_measure_speed(gameport);
+ gameport->speed = use_ktime ?
+ gameport_measure_speed(gameport) :
+ old_gameport_measure_speed(gameport);
list_add_tail(&gameport->node, &gameport_list);
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index ab0fdcd36e18..723276d40b58 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -36,6 +36,7 @@
#include <linux/gameport.h>
#include <linux/jiffies.h>
#include <linux/timex.h>
+#include <linux/timekeeping.h>
#define DRIVER_DESC "Analog joystick and gamepad driver"
@@ -43,6 +44,9 @@ MODULE_AUTHOR("Vojtech Pavlik <vojtech@ucw.cz>");
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
+static bool use_ktime = true;
+module_param(use_ktime, bool, 0400);
+
/*
* Option parsing.
*/
@@ -171,6 +175,25 @@ static unsigned long analog_faketime = 0;
#warning Precise timer not defined for this architecture.
#endif
+static inline u64 get_time(void)
+{
+ if (use_ktime) {
+ return ktime_get_ns();
+ } else {
+ unsigned int x;
+ GET_TIME(x);
+ return x;
+ }
+}
+
+static inline unsigned int delta(u64 x, u64 y)
+{
+ if (use_ktime)
+ return y - x;
+ else
+ return DELTA((unsigned int)x, (unsigned int)y);
+}
+
/*
* analog_decode() decodes analog joystick data and reports input events.
*/
@@ -226,7 +249,8 @@ static void analog_decode(struct analog *analog, int *axes, int *initial, int bu
static int analog_cooked_read(struct analog_port *port)
{
struct gameport *gameport = port->gameport;
- unsigned int time[4], start, loop, now, loopout, timeout;
+ u64 time[4], start, loop, now;
+ unsigned int loopout, timeout;
unsigned char data[4], this, last;
unsigned long flags;
int i, j;
@@ -236,7 +260,7 @@ static int analog_cooked_read(struct analog_port *port)
local_irq_save(flags);
gameport_trigger(gameport);
- GET_TIME(now);
+ now = get_time();
local_irq_restore(flags);
start = now;
@@ -249,16 +273,16 @@ static int analog_cooked_read(struct analog_port *port)
local_irq_disable();
this = gameport_read(gameport) & port->mask;
- GET_TIME(now);
+ now = get_time();
local_irq_restore(flags);
- if ((last ^ this) && (DELTA(loop, now) < loopout)) {
+ if ((last ^ this) && (delta(loop, now) < loopout)) {
data[i] = last ^ this;
time[i] = now;
i++;
}
- } while (this && (i < 4) && (DELTA(start, now) < timeout));
+ } while (this && (i < 4) && (delta(start, now) < timeout));
this <<= 4;
@@ -266,7 +290,7 @@ static int analog_cooked_read(struct analog_port *port)
this |= data[i];
for (j = 0; j < 4; j++)
if (data[i] & (1 << j))
- port->axes[j] = (DELTA(start, time[i]) << ANALOG_FUZZ_BITS) / port->loop;
+ port->axes[j] = (delta(start, time[i]) << ANALOG_FUZZ_BITS) / port->loop;
}
return -(this != port->mask);
@@ -365,31 +389,39 @@ static void analog_close(struct input_dev *dev)
static void analog_calibrate_timer(struct analog_port *port)
{
struct gameport *gameport = port->gameport;
- unsigned int i, t, tx, t1, t2, t3;
+ unsigned int i, t, tx;
+ u64 t1, t2, t3;
unsigned long flags;
- local_irq_save(flags);
- GET_TIME(t1);
+ if (use_ktime) {
+ port->speed = 1000000;
+ } else {
+ local_irq_save(flags);
+ t1 = get_time();
#ifdef FAKE_TIME
- analog_faketime += 830;
+ analog_faketime += 830;
#endif
- mdelay(1);
- GET_TIME(t2);
- GET_TIME(t3);
- local_irq_restore(flags);
+ mdelay(1);
+ t2 = get_time();
+ t3 = get_time();
+ local_irq_restore(flags);
- port->speed = DELTA(t1, t2) - DELTA(t2, t3);
+ port->speed = delta(t1, t2) - delta(t2, t3);
+ }
tx = ~0;
for (i = 0; i < 50; i++) {
local_irq_save(flags);
- GET_TIME(t1);
- for (t = 0; t < 50; t++) { gameport_read(gameport); GET_TIME(t2); }
- GET_TIME(t3);
+ t1 = get_time();
+ for (t = 0; t < 50; t++) {
+ gameport_read(gameport);
+ t2 = get_time();
+ }
+ t3 = get_time();
local_irq_restore(flags);
udelay(i);
- t = DELTA(t1, t2) - DELTA(t2, t3);
+ t = delta(t1, t2) - delta(t2, t3);
if (t < tx) tx = t;
}
--
2.0.4
^ permalink raw reply related
* Re: [RESEND PATCH 1/7] mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC
From: Lee Jones @ 2014-08-21 13:37 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c, linux-input,
linux-samsung-soc
In-Reply-To: <1408536812-7836-2-git-send-email-javier.martinez@collabora.co.uk>
On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:
> From: Doug Anderson <dianders@chromium.org>
>
> If someone sends a EC_CMD_REBOOT_EC to the EC, the EC will likely be
> unresponsive for quite a while. Add a delay to the end of the command
> to prevent random failures of future commands.
>
> NOTES:
> * This could be optimized a bit by simply delaying the next command
> sent, but EC_CMD_REBOOT_EC is such a rare command that the extra
> complexity doesn't seem worth it.
> * This is a bit of an "ugly hack" since the SPI driver is effectively
> snooping on the communication and making a lot of assumptions. It
> would be nice to architect in some better solution long term.
Are you planning on doing that?
> * This same logic probably needs to be applied to the i2c driver.
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Reviewed-by: Randall Spangler <rspangler@chromium.org>
> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> drivers/mfd/cros_ec_spi.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
I'm willing to accept this as a stand-in.
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [RESEND PATCH 1/7] mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC
From: Javier Martinez Canillas @ 2014-08-21 13:49 UTC (permalink / raw)
To: Lee Jones
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c, linux-input,
linux-samsung-soc
In-Reply-To: <20140821133747.GJ4266@lee--X1>
Hello Lee,
On 08/21/2014 03:37 PM, Lee Jones wrote:
> On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:
>> From: Doug Anderson <dianders@chromium.org>
>>
>> If someone sends a EC_CMD_REBOOT_EC to the EC, the EC will likely be
>> unresponsive for quite a while. Add a delay to the end of the command
>> to prevent random failures of future commands.
>>
>> NOTES:
>> * This could be optimized a bit by simply delaying the next command
>> sent, but EC_CMD_REBOOT_EC is such a rare command that the extra
>> complexity doesn't seem worth it.
>> * This is a bit of an "ugly hack" since the SPI driver is effectively
>> snooping on the communication and making a lot of assumptions. It
>> would be nice to architect in some better solution long term.
>
> Are you planning on doing that?
>
Yes, I'll add to my TO-DO list to look how better solve this after the
remaining functionality that is present in downstream but is still not in
mainline gets merged.
>> * This same logic probably needs to be applied to the i2c driver.
>>
>> Signed-off-by: Doug Anderson <dianders@chromium.org>
>> Reviewed-by: Randall Spangler <rspangler@chromium.org>
>> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>> drivers/mfd/cros_ec_spi.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>
> I'm willing to accept this as a stand-in.
>
Thanks.
> Acked-by: Lee Jones <lee.jones@linaro.org>
>
Best regards,
Javier
^ permalink raw reply
* Re: [RESEND PATCH 3/7] mfd: cros_ec: stop calling ->cmd_xfer() directly
From: Lee Jones @ 2014-08-21 14:08 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c, linux-input,
linux-samsung-soc
In-Reply-To: <1408536812-7836-4-git-send-email-javier.martinez@collabora.co.uk>
On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:
> From: Andrew Bresticker <abrestic@chromium.org>
>
> Instead of having users of the ChromeOS EC call the interface-specific
> cmd_xfer() callback directly, introduce a central cros_ec_cmd_xfer()
> to use instead. This will allow us to put all the locking and retry
> logic in one place instead of duplicating it across the different
> drivers.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
> drivers/input/keyboard/cros_ec_keyb.c | 2 +-
> drivers/mfd/cros_ec.c | 7 +++++++
> include/linux/mfd/cros_ec.h | 24 ++++++++++++++++++------
> 4 files changed, 27 insertions(+), 8 deletions(-)
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [RESEND PATCH 4/7] mfd: cros_ec: move locking into cros_ec_cmd_xfer
From: Lee Jones @ 2014-08-21 14:09 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber, linux-i2c, linux-input,
linux-samsung-soc
In-Reply-To: <1408536812-7836-5-git-send-email-javier.martinez@collabora.co.uk>
On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:
> From: Andrew Bresticker <abrestic@chromium.org>
>
> Now that there's a central cros_ec_cmd_xfer(), move the locking
> out of the SPI and LPC drivers.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> drivers/mfd/cros_ec.c | 10 +++++++++-
> drivers/mfd/cros_ec_spi.c | 11 -----------
> 2 files changed, 9 insertions(+), 12 deletions(-)
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [RESEND PATCH 5/7] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS
From: Lee Jones @ 2014-08-21 14:21 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1408536812-7836-6-git-send-email-javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:
> From: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
> When an EC command returns EC_RES_IN_PROGRESS, we need to query
> the state of the EC until it indicates that it is no longer busy.
> Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
> commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
> it is working on the in-progress command.
>
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Reviewed-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8rSCDK34cm6iQ@public.gmane.org.uk>
> ---
> drivers/mfd/cros_ec.c | 35 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index c53804a..634c434 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -23,6 +23,10 @@
> #include <linux/mfd/core.h>
> #include <linux/mfd/cros_ec.h>
> #include <linux/mfd/cros_ec_commands.h>
> +#include <linux/delay.h>
> +
> +#define EC_COMMAND_RETRIES 50
> +#define EC_RETRY_DELAY_MS 10
>
> int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
> struct cros_ec_command *msg)
> @@ -65,10 +69,39 @@ EXPORT_SYMBOL(cros_ec_check_result);
> int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
> struct cros_ec_command *msg)
> {
> - int ret;
> + int ret, i;
>
> mutex_lock(&ec_dev->lock);
> ret = ec_dev->cmd_xfer(ec_dev, msg);
> + if (ret == -EAGAIN && msg->result == EC_RES_IN_PROGRESS) {
> + /*
> + * Query the EC's status until it's no longer busy or
> + * we encounter an error.
> + */
> + for (i = 0; i < EC_COMMAND_RETRIES; i++) {
> + struct cros_ec_command status_msg;
> + struct ec_response_get_comms_status status;
> +
> + msleep(EC_RETRY_DELAY_MS);
> +
> + status_msg.version = 0;
> + status_msg.command = EC_CMD_GET_COMMS_STATUS;
> + status_msg.outdata = NULL;
> + status_msg.outsize = 0;
> + status_msg.indata = (uint8_t *)&status;
> + status_msg.insize = sizeof(status);
> +
> + ret = ec_dev->cmd_xfer(ec_dev, &status_msg);
> + if (ret < 0)
> + break;
> +
> + msg->result = status_msg.result;
> + if (status_msg.result != EC_RES_SUCCESS)
> + break;
> + if (!(status.flags & EC_COMMS_STATUS_PROCESSING))
> + break;
> + }
> + }
Wow! Things just got ugly real fast.
Do the *xfer() calls fiddle with msg passed into cros_ec_cmd_xfer()?
If not, why is it necessary to keep populating it?
If all this stuff is necessary (and I really hope that it's not) I
think it would be better to have the for() loop as the outer layer.
Then we only have one instance of cmd_xfer() invocation and we save a
layer of tabbing.
> mutex_unlock(&ec_dev->lock);
>
> return ret;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [RESEND PATCH 6/7] mfd: cros_ec: Instantiate sub-devices from device tree
From: Lee Jones @ 2014-08-21 14:25 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Wolfram Sang, Dmitry Torokhov, Doug Anderson, Simon Glass,
Bill Richardson, Andrew Bresticker, Derek Basehore, Todd Broch,
Olof Johansson, Andreas Färber,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1408536812-7836-7-git-send-email-javier.martinez-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:
> From: Todd Broch <tbroch-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
> If the EC device tree node has sub-nodes, try to instantiate them as
> MFD sub-devices. We can configure the EC features provided by the board.
>
> Signed-off-by: Todd Broch <tbroch-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Javier Martinez Canillas <javier.martinez-ZGY8ohtN/8rSCDK34cm6iQ@public.gmane.org.uk>
> ---
> drivers/mfd/cros_ec.c | 40 ++++++++++++++++++++++++++++++----------
> 1 file changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 634c434..96c926c 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -21,6 +21,7 @@
> #include <linux/slab.h>
> #include <linux/module.h>
> #include <linux/mfd/core.h>
> +#include <linux/of_platform.h>
> #include <linux/mfd/cros_ec.h>
> #include <linux/mfd/cros_ec_commands.h>
> #include <linux/delay.h>
> @@ -109,22 +110,16 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
> EXPORT_SYMBOL(cros_ec_cmd_xfer);
>
> static const struct mfd_cell cros_devs[] = {
> - {
> - .name = "cros-ec-keyb",
> - .id = 1,
> - .of_compatible = "google,cros-ec-keyb",
> - },
> - {
> - .name = "cros-ec-i2c-tunnel",
> - .id = 2,
> - .of_compatible = "google,cros-ec-i2c-tunnel",
> - },
> };
Why are you keeping this round if it's empty?
> int cros_ec_register(struct cros_ec_device *ec_dev)
> {
> struct device *dev = ec_dev->dev;
> int err = 0;
> +#ifdef CONFIG_OF
> + struct device_node *node;
> + int id = ARRAY_SIZE(cros_devs);
> +#endif
>
> if (ec_dev->din_size) {
> ec_dev->din = devm_kzalloc(dev, ec_dev->din_size, GFP_KERNEL);
> @@ -146,6 +141,31 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> dev_err(dev, "failed to add mfd devices\n");
> return err;
> }
> +#ifdef CONFIG_OF
> + /*
> + * Add sub-devices declared in the device tree. NOTE they should NOT be
> + * declared in cros_devs
> + */
> + for_each_child_of_node(dev->of_node, node) {
> + char name[128];
> + struct mfd_cell cell = {
> + .id = 0,
> + .name = name,
> + };
> +
> + if (of_modalias_node(node, name, sizeof(name)) < 0) {
> + dev_err(dev, "modalias failure on %s\n",
> + node->full_name);
> + continue;
> + }
> + dev_dbg(dev, "adding MFD sub-device %s\n", node->name);
> + cell.of_compatible = of_get_property(node, "compatible", NULL);
> + err = mfd_add_devices(dev, ++id, &cell, 1, NULL, ec_dev->irq,
> + NULL);
> + if (err)
> + dev_err(dev, "fail to add %s\n", node->full_name);
> + }
> +#endif
This is grim!
Why don't you use of_platform_populate()?
> dev_info(dev, "Chrome EC device registered\n");
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] HID: logitech: fix bounds checking on LED report size
From: Jiri Kosina @ 2014-08-21 15:41 UTC (permalink / raw)
To: Ben Hawkes, Benjamin Tissoires; +Cc: linux-input, linux-kernel
The check on report size for REPORT_TYPE_LEDS in logi_dj_ll_raw_request()
is wrong; the current check doesn't make any sense -- the report allocated
by HID core in hid_hw_raw_request() can be much larger than
DJREPORT_SHORT_LENGTH, and currently logi_dj_ll_raw_request() doesn't
handle this properly at all.
Fix the check by actually trimming down the report size properly if it is
too large.
Cc: stable@vger.kernel.org
Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-logitech-dj.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 486dbde..ca0ab51 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -557,7 +557,7 @@ static int logi_dj_ll_raw_request(struct hid_device *hid,
if (!out_buf)
return -ENOMEM;
- if (count < DJREPORT_SHORT_LENGTH - 2)
+ if (count > DJREPORT_SHORT_LENGTH - 2)
count = DJREPORT_SHORT_LENGTH - 2;
out_buf[0] = REPORT_ID_DJ_SHORT;
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* [PATCH] HID: logitech: perform bounds checking on device_id early enough
From: Jiri Kosina @ 2014-08-21 15:45 UTC (permalink / raw)
To: Ben Hawkes, Benjamin Tissoires; +Cc: linux-input, linux-kernel
device_index is a char type and the size of paired_dj_deivces is 7
elements, therefore proper bounds checking has to be applied to
device_index before it is used.
We are currently performing the bounds checking in
logi_dj_recv_add_djhid_device(), which is too late, as malicious device
could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the
problem in one of the report forwarding functions called from
logi_dj_raw_event().
Fix this by performing the check at the earliest possible ocasion in
logi_dj_raw_event().
Cc: stable@vger.kernel.org
Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-logitech-dj.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index ca0ab51..b7ba829 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -238,13 +238,6 @@ static void logi_dj_recv_add_djhid_device(struct dj_receiver_dev *djrcv_dev,
return;
}
- if ((dj_report->device_index < DJ_DEVICE_INDEX_MIN) ||
- (dj_report->device_index > DJ_DEVICE_INDEX_MAX)) {
- dev_err(&djrcv_hdev->dev, "%s: invalid device index:%d\n",
- __func__, dj_report->device_index);
- return;
- }
-
if (djrcv_dev->paired_dj_devices[dj_report->device_index]) {
/* The device is already known. No need to reallocate it. */
dbg_hid("%s: device is already known\n", __func__);
@@ -690,6 +683,12 @@ static int logi_dj_raw_event(struct hid_device *hdev,
* device (via hid_input_report() ) and return 1 so hid-core does not do
* anything else with it.
*/
+ if ((dj_report->device_index < DJ_DEVICE_INDEX_MIN) ||
+ (dj_report->device_index > DJ_DEVICE_INDEX_MAX)) {
+ dev_err(&hdev->dev, "%s: invalid device index:%d\n",
+ __func__, dj_report->device_index);
+ return false;
+ }
spin_lock_irqsave(&djrcv_dev->lock, flags);
if (dj_report->report_id == REPORT_ID_DJ_SHORT) {
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* [PATCH] HID: fix a couple of off-by-ones
From: Jiri Kosina @ 2014-08-21 15:46 UTC (permalink / raw)
To: Ben Hawkes, Benjamin Tissoires; +Cc: linux-input, linux-kernel
There are a few very theoretical off-by-one bugs in report descriptor size
checking when performing a pre-parsing fixup. Fix those.
Cc: stable@vger.kernel.org
Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-cherry.c | 2 +-
drivers/hid/hid-kye.c | 2 +-
drivers/hid/hid-lg.c | 4 ++--
drivers/hid/hid-monterey.c | 2 +-
drivers/hid/hid-petalynx.c | 2 +-
drivers/hid/hid-sunplus.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-cherry.c b/drivers/hid/hid-cherry.c
index 1bdcccc..f745d2c 100644
--- a/drivers/hid/hid-cherry.c
+++ b/drivers/hid/hid-cherry.c
@@ -28,7 +28,7 @@
static __u8 *ch_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- if (*rsize >= 17 && rdesc[11] == 0x3c && rdesc[12] == 0x02) {
+ if (*rsize >= 18 && rdesc[11] == 0x3c && rdesc[12] == 0x02) {
hid_info(hdev, "fixing up Cherry Cymotion report descriptor\n");
rdesc[11] = rdesc[16] = 0xff;
rdesc[12] = rdesc[17] = 0x03;
diff --git a/drivers/hid/hid-kye.c b/drivers/hid/hid-kye.c
index e776963..b92bf01 100644
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -300,7 +300,7 @@ static __u8 *kye_report_fixup(struct hid_device *hdev, __u8 *rdesc,
* - change the button usage range to 4-7 for the extra
* buttons
*/
- if (*rsize >= 74 &&
+ if (*rsize >= 75 &&
rdesc[61] == 0x05 && rdesc[62] == 0x08 &&
rdesc[63] == 0x19 && rdesc[64] == 0x08 &&
rdesc[65] == 0x29 && rdesc[66] == 0x0f &&
diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index a976f48..f91ff14 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -345,14 +345,14 @@ static __u8 *lg_report_fixup(struct hid_device *hdev, __u8 *rdesc,
struct usb_device_descriptor *udesc;
__u16 bcdDevice, rev_maj, rev_min;
- if ((drv_data->quirks & LG_RDESC) && *rsize >= 90 && rdesc[83] == 0x26 &&
+ if ((drv_data->quirks & LG_RDESC) && *rsize >= 91 && rdesc[83] == 0x26 &&
rdesc[84] == 0x8c && rdesc[85] == 0x02) {
hid_info(hdev,
"fixing up Logitech keyboard report descriptor\n");
rdesc[84] = rdesc[89] = 0x4d;
rdesc[85] = rdesc[90] = 0x10;
}
- if ((drv_data->quirks & LG_RDESC_REL_ABS) && *rsize >= 50 &&
+ if ((drv_data->quirks & LG_RDESC_REL_ABS) && *rsize >= 51 &&
rdesc[32] == 0x81 && rdesc[33] == 0x06 &&
rdesc[49] == 0x81 && rdesc[50] == 0x06) {
hid_info(hdev,
diff --git a/drivers/hid/hid-monterey.c b/drivers/hid/hid-monterey.c
index 9e14c00..25daf28 100644
--- a/drivers/hid/hid-monterey.c
+++ b/drivers/hid/hid-monterey.c
@@ -24,7 +24,7 @@
static __u8 *mr_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- if (*rsize >= 30 && rdesc[29] == 0x05 && rdesc[30] == 0x09) {
+ if (*rsize >= 31 && rdesc[29] == 0x05 && rdesc[30] == 0x09) {
hid_info(hdev, "fixing up button/consumer in HID report descriptor\n");
rdesc[30] = 0x0c;
}
diff --git a/drivers/hid/hid-petalynx.c b/drivers/hid/hid-petalynx.c
index 736b250..6aca4f2 100644
--- a/drivers/hid/hid-petalynx.c
+++ b/drivers/hid/hid-petalynx.c
@@ -25,7 +25,7 @@
static __u8 *pl_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- if (*rsize >= 60 && rdesc[39] == 0x2a && rdesc[40] == 0xf5 &&
+ if (*rsize >= 62 && rdesc[39] == 0x2a && rdesc[40] == 0xf5 &&
rdesc[41] == 0x00 && rdesc[59] == 0x26 &&
rdesc[60] == 0xf9 && rdesc[61] == 0x00) {
hid_info(hdev, "fixing up Petalynx Maxter Remote report descriptor\n");
diff --git a/drivers/hid/hid-sunplus.c b/drivers/hid/hid-sunplus.c
index 87fc91e..91072fa 100644
--- a/drivers/hid/hid-sunplus.c
+++ b/drivers/hid/hid-sunplus.c
@@ -24,7 +24,7 @@
static __u8 *sp_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- if (*rsize >= 107 && rdesc[104] == 0x26 && rdesc[105] == 0x80 &&
+ if (*rsize >= 112 && rdesc[104] == 0x26 && rdesc[105] == 0x80 &&
rdesc[106] == 0x03) {
hid_info(hdev, "fixing up Sunplus Wireless Desktop report descriptor\n");
rdesc[105] = rdesc[110] = 0x03;
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* [PATCH V2 0/2] Input: palmas: add support for palmas power button
From: Nishanth Menon @ 2014-08-21 16:02 UTC (permalink / raw)
To: Dmitry Torokhov, Dmitry Torokhov
Cc: devicetree, linux-kernel, linux-input, linux-omap,
linux-arm-kernel, Nishanth Menon
In-Reply-To: <1408392810-16011-1-git-send-email-nm@ti.com>
Many Palmas PMIC variants have support for power button feature. This
feature depends on certain One Time Program (OTP) and board pull
configurations (POWERHOLD signal). However, on many platforms such
as DRA72-evm, OMAP5-uevm, this may be used to generate input events
similar to twl4030-pwrbutton.c
Series is based on v3.17-rc1
V2 of the series incorporating comments from http://marc.info/?l=linux-input&m=140839287431882&w=2
Nishanth Menon (2):
doc: dt/bindings: input: introduce palmas power button description
Input: misc: introduce palmas-pwrbutton
.../bindings/input/ti,palmas-pwrbutton.txt | 36 ++
drivers/input/misc/Kconfig | 10 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/palmas-pwrbutton.c | 356 ++++++++++++++++++++
4 files changed, 403 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
create mode 100644 drivers/input/misc/palmas-pwrbutton.c
--
1.7.9.5
^ 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