* Re: [PATCH] USB: input: gtco.c: fix usb_dev leak
From: Alexey Khoroshilov @ 2014-01-27 10:29 UTC (permalink / raw)
To: Dmitry Torokhov, Greg Kroah-Hartman
Cc: linux-input, linux-kernel, ldv-project
In-Reply-To: <20140127065416.GA11945@core.coreip.homeip.net>
On 27.01.2014 10:54, Dmitry Torokhov wrote:
> Hi Alexey,
>
> On Mon, Jan 27, 2014 at 10:31:36AM +0400, Alexey Khoroshilov wrote:
>> On 21.01.2014 23:59, Dmitry Torokhov wrote:
>>> On Sun, Jan 19, 2014 at 03:24:26AM +0400, Alexey Khoroshilov wrote:
>>>> There is usb_get_dev() in gtco_probe(), but there is no usb_put_dev()
>>>> anywhere in the driver.
>>>>
>>>> The patch adds usb_get_dev() to failure handling code of gtco_probe()
>>>> and to gtco_disconnect(().
>>> Hmm, I think gtco should simply not use usb_get_dev() in the first
>>> place.
>>>
>>> Thanks.
>> Dear Dmitry,
>>
>> Could you please clarify why usb_get_dev() not needed here?
>> We store reference to usb_dev in gtco structure, so we should refcount it.
>> What is wrong in this reasoning?
> The lifetime of gtco structure is already directly tied to lifetime of
> usb_dev: when destroying usb_dev driver core will call remove() function
> of currently bound driver (in our case gtco) which will destroy gtco
> memory.
>
> Taking additional reference is not needed here.
>
> Hope this helps.
Thank you, that helps a lot.
By the way, usb_skeleton suggests to use usb_get_dev()/usb_put_dev()
nevertheless.
Greg, may be it makes sense to fix usb_skeleton as well?
--
Alexey
^ permalink raw reply
* Re: [PATCH] USB: input: gtco.c: fix usb_dev leak
From: Greg Kroah-Hartman @ 2014-01-27 13:17 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: Dmitry Torokhov, linux-input, linux-kernel, ldv-project
In-Reply-To: <52E63503.3060804@ispras.ru>
On Mon, Jan 27, 2014 at 02:29:23PM +0400, Alexey Khoroshilov wrote:
> On 27.01.2014 10:54, Dmitry Torokhov wrote:
> > Hi Alexey,
> >
> > On Mon, Jan 27, 2014 at 10:31:36AM +0400, Alexey Khoroshilov wrote:
> >> On 21.01.2014 23:59, Dmitry Torokhov wrote:
> >>> On Sun, Jan 19, 2014 at 03:24:26AM +0400, Alexey Khoroshilov wrote:
> >>>> There is usb_get_dev() in gtco_probe(), but there is no usb_put_dev()
> >>>> anywhere in the driver.
> >>>>
> >>>> The patch adds usb_get_dev() to failure handling code of gtco_probe()
> >>>> and to gtco_disconnect(().
> >>> Hmm, I think gtco should simply not use usb_get_dev() in the first
> >>> place.
> >>>
> >>> Thanks.
> >> Dear Dmitry,
> >>
> >> Could you please clarify why usb_get_dev() not needed here?
> >> We store reference to usb_dev in gtco structure, so we should refcount it.
> >> What is wrong in this reasoning?
> > The lifetime of gtco structure is already directly tied to lifetime of
> > usb_dev: when destroying usb_dev driver core will call remove() function
> > of currently bound driver (in our case gtco) which will destroy gtco
> > memory.
> >
> > Taking additional reference is not needed here.
> >
> > Hope this helps.
> Thank you, that helps a lot.
>
> By the way, usb_skeleton suggests to use usb_get_dev()/usb_put_dev()
> nevertheless.
>
> Greg, may be it makes sense to fix usb_skeleton as well?
Patches are always welcome.
^ permalink raw reply
* Re: [RFC][PATCH] Input: i8042 - fix PNP modaliases when both aux and kdb are enabled
From: Tom Gundersen @ 2014-01-27 14:57 UTC (permalink / raw)
To: linux-input@vger.kernel.org; +Cc: Tom Gundersen, Dmitry Torokhov
In-Reply-To: <1390770052-26499-1-git-send-email-teg@jklm.no>
On Sun, Jan 26, 2014 at 10:00 PM, Tom Gundersen <teg@jklm.no> wrote:
> Commit 78551277e4 exposed the PNP modaliases for the i8042 module. However,
> the aux entries overrode the kbd ones.
>
> Refactor the device_id lists to expose both the aux and the kbd modaliases.
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Tom Gundersen <teg@jklm.no>
> ---
> Hi Dmitry,
>
> I don't know if there is a better way to do this, so sending as an RFC.
Please disregard this patch for now, I'll first try to get in a
generic fix to MODULE_DEVICE_TABLE().
Cheers,
Tom
> drivers/input/serio/i8042-x86ia64io.h | 67 ++++++++++++++++++++---------------
> 1 file changed, 39 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
> index 0ec9abb..dbc6958 100644
> --- a/drivers/input/serio/i8042-x86ia64io.h
> +++ b/drivers/input/serio/i8042-x86ia64io.h
> @@ -747,25 +747,27 @@ static int i8042_pnp_aux_probe(struct pnp_dev *dev, const struct pnp_device_id *
> return 0;
> }
>
> -static struct pnp_device_id pnp_kbd_devids[] = {
> - { .id = "PNP0300", .driver_data = 0 },
> - { .id = "PNP0301", .driver_data = 0 },
> - { .id = "PNP0302", .driver_data = 0 },
> - { .id = "PNP0303", .driver_data = 0 },
> - { .id = "PNP0304", .driver_data = 0 },
> - { .id = "PNP0305", .driver_data = 0 },
> - { .id = "PNP0306", .driver_data = 0 },
> - { .id = "PNP0309", .driver_data = 0 },
> - { .id = "PNP030a", .driver_data = 0 },
> - { .id = "PNP030b", .driver_data = 0 },
> - { .id = "PNP0320", .driver_data = 0 },
> - { .id = "PNP0343", .driver_data = 0 },
> - { .id = "PNP0344", .driver_data = 0 },
> - { .id = "PNP0345", .driver_data = 0 },
> +#define KBD_DEVIDS \
> + { .id = "PNP0300", .driver_data = 0 }, \
> + { .id = "PNP0301", .driver_data = 0 }, \
> + { .id = "PNP0302", .driver_data = 0 }, \
> + { .id = "PNP0303", .driver_data = 0 }, \
> + { .id = "PNP0304", .driver_data = 0 }, \
> + { .id = "PNP0305", .driver_data = 0 }, \
> + { .id = "PNP0306", .driver_data = 0 }, \
> + { .id = "PNP0309", .driver_data = 0 }, \
> + { .id = "PNP030a", .driver_data = 0 }, \
> + { .id = "PNP030b", .driver_data = 0 }, \
> + { .id = "PNP0320", .driver_data = 0 }, \
> + { .id = "PNP0343", .driver_data = 0 }, \
> + { .id = "PNP0344", .driver_data = 0 }, \
> + { .id = "PNP0345", .driver_data = 0 }, \
> { .id = "CPQA0D7", .driver_data = 0 },
> +
> +static struct pnp_device_id pnp_kbd_devids[] = {
> + KBD_DEVIDS
> { .id = "", },
> };
> -MODULE_DEVICE_TABLE(pnp, pnp_kbd_devids);
>
> static struct pnp_driver i8042_pnp_kbd_driver = {
> .name = "i8042 kbd",
> @@ -773,21 +775,23 @@ static struct pnp_driver i8042_pnp_kbd_driver = {
> .probe = i8042_pnp_kbd_probe,
> };
>
> -static struct pnp_device_id pnp_aux_devids[] = {
> - { .id = "AUI0200", .driver_data = 0 },
> - { .id = "FJC6000", .driver_data = 0 },
> - { .id = "FJC6001", .driver_data = 0 },
> - { .id = "PNP0f03", .driver_data = 0 },
> - { .id = "PNP0f0b", .driver_data = 0 },
> - { .id = "PNP0f0e", .driver_data = 0 },
> - { .id = "PNP0f12", .driver_data = 0 },
> - { .id = "PNP0f13", .driver_data = 0 },
> - { .id = "PNP0f19", .driver_data = 0 },
> - { .id = "PNP0f1c", .driver_data = 0 },
> +#define AUX_DEVIDS \
> + { .id = "AUI0200", .driver_data = 0 }, \
> + { .id = "FJC6000", .driver_data = 0 }, \
> + { .id = "FJC6001", .driver_data = 0 }, \
> + { .id = "PNP0f03", .driver_data = 0 }, \
> + { .id = "PNP0f0b", .driver_data = 0 }, \
> + { .id = "PNP0f0e", .driver_data = 0 }, \
> + { .id = "PNP0f12", .driver_data = 0 }, \
> + { .id = "PNP0f13", .driver_data = 0 }, \
> + { .id = "PNP0f19", .driver_data = 0 }, \
> + { .id = "PNP0f1c", .driver_data = 0 }, \
> { .id = "SYN0801", .driver_data = 0 },
> +
> +static struct pnp_device_id pnp_aux_devids[] = {
> + AUX_DEVIDS
> { .id = "", },
> };
> -MODULE_DEVICE_TABLE(pnp, pnp_aux_devids);
>
> static struct pnp_driver i8042_pnp_aux_driver = {
> .name = "i8042 aux",
> @@ -795,6 +799,13 @@ static struct pnp_driver i8042_pnp_aux_driver = {
> .probe = i8042_pnp_aux_probe,
> };
>
> +static struct pnp_device_id pnp_kdb_aux_devids[] = {
> + KBD_DEVIDS
> + AUX_DEVIDS
> + { .id = "", },
> +};
> +MODULE_DEVICE_TABLE(pnp, pnp_kdb_aux_devids);
> +
> static void i8042_pnp_exit(void)
> {
> if (i8042_pnp_kbd_registered) {
> --
> 1.8.5.3
>
^ permalink raw reply
* [PATCH v2 1/2] HID: sony: Add battery status reporting for the Sixaxis and Dualshock 4 controllers.
From: Frank Praznik @ 2014-01-27 15:17 UTC (permalink / raw)
To: linux-input; +Cc: jkosina, Frank Praznik
Add battery status reporting for the Sixaxis and Dualshock 4 controllers.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
---
v2 of the patch fixes a small logic error where the battery_charging flag was
flipped on the Sixaxis.
The line: battery_charging = rd[30] & 0x01;
should be: battery_charging = !(rd[30] & 0x01);
since the low bit is 0 when charging and 1 when charging is complete.
drivers/hid/hid-sony.c | 186 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 185 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 1235405..04fd611 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -30,6 +30,8 @@
#include <linux/slab.h>
#include <linux/usb.h>
#include <linux/leds.h>
+#include <linux/power_supply.h>
+#include <linux/spinlock.h>
#include "hid-ids.h"
@@ -42,6 +44,7 @@
#define DUALSHOCK4_CONTROLLER_BT BIT(6)
#define SONY_LED_SUPPORT (SIXAXIS_CONTROLLER_USB | BUZZ_CONTROLLER | DUALSHOCK4_CONTROLLER_USB)
+#define SONY_BATTERY_SUPPORT (SIXAXIS_CONTROLLER_USB | SIXAXIS_CONTROLLER_BT | DUALSHOCK4_CONTROLLER_USB)
#define MAX_LEDS 4
@@ -487,18 +490,30 @@ static const unsigned int buzz_keymap[] = {
[20] = BTN_TRIGGER_HAPPY20,
};
+static enum power_supply_property sony_battery_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_SCOPE,
+ POWER_SUPPLY_PROP_STATUS,
+};
+
struct sony_sc {
+ spinlock_t lock;
struct hid_device *hdev;
struct led_classdev *leds[MAX_LEDS];
struct hid_report *output_report;
unsigned long quirks;
struct work_struct state_worker;
+ struct power_supply battery;
#ifdef CONFIG_SONY_FF
__u8 left;
__u8 right;
#endif
+ __u8 cable_state;
+ __u8 battery_charging;
+ __u8 battery_capacity;
__u8 led_state[MAX_LEDS];
__u8 led_count;
};
@@ -599,6 +614,63 @@ static __u8 *sony_report_fixup(struct hid_device *hdev, __u8 *rdesc,
return rdesc;
}
+static void sixaxis_parse_report(struct sony_sc *sc, __u8 *rd, int size)
+{
+ static const __u8 sixaxis_battery_capacity[] = { 0, 1, 25, 50, 75, 100 };
+ unsigned long flags;
+ __u8 cable_state, battery_capacity, battery_charging;
+
+ /* The sixaxis is charging if the battery value is 0xee
+ * and it is fully charged if the value is 0xef.
+ * It does not report the actual level while charging so it
+ * is set to 100% while charging is in progress.
+ */
+ if (rd[30] >= 0xee) {
+ battery_capacity = 100;
+ battery_charging = rd[30] & 0x01;
+ } else {
+ battery_capacity = sixaxis_battery_capacity[rd[30]];
+ battery_charging = 0;
+ }
+ cable_state = (rd[31] >> 4) & 0x01;
+
+ spin_lock_irqsave(&sc->lock, flags);
+ sc->cable_state = cable_state;
+ sc->battery_capacity = battery_capacity;
+ sc->battery_charging = battery_charging;
+ spin_unlock_irqrestore(&sc->lock, flags);
+}
+
+static void dualshock4_parse_report(struct sony_sc *sc, __u8 *rd, int size)
+{
+ unsigned long flags;
+ __u8 cable_state, battery_capacity, battery_charging;
+
+ /* The lower 4 bits of byte 30 contain the battery level
+ * and the 5th bit contains the USB cable state.
+ */
+ cable_state = (rd[30] >> 4) & 0x01;
+ battery_capacity = rd[30] & 0x0F;
+
+ /* On USB the Dualshock 4 battery level goes from 0 to 11.
+ * A battery level of 11 means fully charged.
+ */
+ if (cable_state && battery_capacity == 11)
+ battery_charging = 0;
+ else
+ battery_charging = 1;
+
+ if (battery_capacity > 10)
+ battery_capacity--;
+ battery_capacity *= 10;
+
+ spin_lock_irqsave(&sc->lock, flags);
+ sc->cable_state = cable_state;
+ sc->battery_capacity = battery_capacity;
+ sc->battery_charging = battery_charging;
+ spin_unlock_irqrestore(&sc->lock, flags);
+}
+
static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
__u8 *rd, int size)
{
@@ -613,6 +685,11 @@ static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
swap(rd[43], rd[44]);
swap(rd[45], rd[46]);
swap(rd[47], rd[48]);
+
+ sixaxis_parse_report(sc, rd, size);
+ } else if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && rd[0] == 0x01 &&
+ size == 64) {
+ dualshock4_parse_report(sc, rd, size);
}
return 0;
@@ -1011,6 +1088,91 @@ static void sony_destroy_ff(struct hid_device *hdev)
}
#endif
+static int sony_battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct sony_sc *sc = container_of(psy, struct sony_sc, battery);
+ unsigned long flags;
+ int ret = 0;
+ u8 battery_charging, battery_capacity, cable_state;
+
+ spin_lock_irqsave(&sc->lock, flags);
+ battery_charging = sc->battery_charging;
+ battery_capacity = sc->battery_capacity;
+ cable_state = sc->cable_state;
+ spin_unlock_irqrestore(&sc->lock, flags);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = 1;
+ break;
+ case POWER_SUPPLY_PROP_SCOPE:
+ val->intval = POWER_SUPPLY_SCOPE_DEVICE;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ val->intval = battery_capacity;
+ break;
+ case POWER_SUPPLY_PROP_STATUS:
+ if (battery_charging)
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ else
+ if (battery_capacity == 100 && cable_state)
+ val->intval = POWER_SUPPLY_STATUS_FULL;
+ else
+ val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+
+static int sony_battery_probe(struct sony_sc *sc)
+{
+ static atomic_t power_id_seq = ATOMIC_INIT(0);
+ unsigned long power_id;
+ struct hid_device *hdev = sc->hdev;
+ int ret;
+
+ power_id = (unsigned long)atomic_inc_return(&power_id_seq);
+
+ sc->battery.properties = sony_battery_props;
+ sc->battery.num_properties = ARRAY_SIZE(sony_battery_props);
+ sc->battery.get_property = sony_battery_get_property;
+ sc->battery.type = POWER_SUPPLY_TYPE_BATTERY;
+ sc->battery.use_for_apm = 0;
+ sc->battery.name = kasprintf(GFP_KERNEL, "sony_controller_battery_%lu",
+ power_id);
+ if (!sc->battery.name)
+ return -ENOMEM;
+
+ ret = power_supply_register(&hdev->dev, &sc->battery);
+ if (ret) {
+ hid_err(hdev, "Unable to register battery device\n");
+ goto err_free;
+ }
+
+ power_supply_powers(&sc->battery, &hdev->dev);
+ return 0;
+
+err_free:
+ kfree(sc->battery.name);
+ sc->battery.name = NULL;
+ return ret;
+}
+
+static void sony_battery_remove(struct sony_sc *sc)
+{
+ if (!sc->battery.name)
+ return;
+
+ power_supply_unregister(&sc->battery);
+ kfree(sc->battery.name);
+ sc->battery.name = NULL;
+}
+
static int sony_set_output_report(struct sony_sc *sc, int req_id, int req_size)
{
struct list_head *head, *list;
@@ -1101,14 +1263,31 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
goto err_stop;
}
+ if (sc->quirks & SONY_BATTERY_SUPPORT) {
+ ret = sony_battery_probe(sc);
+ if (ret < 0)
+ goto err_stop;
+
+ /* Open the device to receive reports with battery info */
+ ret = hid_hw_open(hdev);
+ if (ret < 0) {
+ hid_err(hdev, "hw open failed\n");
+ goto err_stop;
+ }
+ }
+
ret = sony_init_ff(hdev);
if (ret < 0)
- goto err_stop;
+ goto err_close;
return 0;
+err_close:
+ hid_hw_close(hdev);
err_stop:
if (sc->quirks & SONY_LED_SUPPORT)
sony_leds_remove(hdev);
+ if (sc->quirks & SONY_BATTERY_SUPPORT)
+ sony_battery_remove(sc);
hid_hw_stop(hdev);
return ret;
}
@@ -1120,6 +1299,11 @@ static void sony_remove(struct hid_device *hdev)
if (sc->quirks & SONY_LED_SUPPORT)
sony_leds_remove(hdev);
+ if (sc->quirks & SONY_BATTERY_SUPPORT) {
+ hid_hw_close(hdev);
+ sony_battery_remove(sc);
+ }
+
sony_destroy_ff(hdev);
hid_hw_stop(hdev);
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 2/2] HID: sony: Add output events for the multi-touch pad on the Dualshock 4.
From: Frank Praznik @ 2014-01-27 15:17 UTC (permalink / raw)
To: linux-input; +Cc: jkosina, Frank Praznik
In-Reply-To: <1390835857-4523-1-git-send-email-frank.praznik@oh.rr.com>
Add output events for the multi-touch pad on the Dualshock 4.
The touchpad has a resolution of 1920x940 and is capable of 2 simultaneous
touches. A 'Type B' stateful slot protocol is implemented as defined in
Documentation/input/multi-touch-protocol.txt
Applications can use the touchpad data by processing the ABS_MT_SLOT,
ABS_MT_TRACKING_ID, ABS_MT_POSITION_X and ABS_MT_POSITION_Y events.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
---
drivers/hid/hid-sony.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 04fd611..2bd3f13 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -32,6 +32,7 @@
#include <linux/leds.h>
#include <linux/power_supply.h>
#include <linux/spinlock.h>
+#include <linux/input/mt.h>
#include "hid-ids.h"
@@ -643,7 +644,11 @@ static void sixaxis_parse_report(struct sony_sc *sc, __u8 *rd, int size)
static void dualshock4_parse_report(struct sony_sc *sc, __u8 *rd, int size)
{
+ struct hid_input *hidinput = list_entry(sc->hdev->inputs.next,
+ struct hid_input, list);
+ struct input_dev *input_dev = hidinput->input;
unsigned long flags;
+ int n, offset = 35;
__u8 cable_state, battery_capacity, battery_charging;
/* The lower 4 bits of byte 30 contain the battery level
@@ -669,6 +674,28 @@ static void dualshock4_parse_report(struct sony_sc *sc, __u8 *rd, int size)
sc->battery_capacity = battery_capacity;
sc->battery_charging = battery_charging;
spin_unlock_irqrestore(&sc->lock, flags);
+
+ /* The Dualshock 4 multi-touch trackpad data starts at offset 35 on USB.
+ * The first 7 bits of the first byte is a counter and bit 8 is a touch
+ * indicator that is 0 when pressed and 1 when not pressed.
+ * The next 3 bytes are two 12 bit touch coordinates, X and Y.
+ * The data for the second touch is in the same format and immediatly
+ * follows the data for the first.
+ */
+ for (n = 0; n < 2; n++) {
+ __u16 x, y;
+
+ x = rd[offset+1] | ((rd[offset+2] & 0xF) << 8);
+ y = ((rd[offset+2] & 0xF0) >> 4) | (rd[offset+3] << 4);
+
+ input_mt_slot(input_dev, n);
+ input_mt_report_slot_state(input_dev, MT_TOOL_FINGER,
+ !(rd[offset] >> 7));
+ input_report_abs(input_dev, ABS_MT_POSITION_X, x);
+ input_report_abs(input_dev, ABS_MT_POSITION_Y, y);
+
+ offset += 4;
+ }
}
static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
@@ -1200,6 +1227,26 @@ static int sony_set_output_report(struct sony_sc *sc, int req_id, int req_size)
return -EINVAL;
}
+static int sony_register_touchpad(struct sony_sc *sc, int touch_count,
+ int w, int h)
+{
+ struct hid_input *hidinput = list_entry(sc->hdev->inputs.next,
+ struct hid_input, list);
+ struct input_dev *input_dev = hidinput->input;
+ int ret;
+
+ ret = input_mt_init_slots(input_dev, touch_count, 0);
+ if (ret < 0) {
+ hid_err(sc->hdev, "Unable to initialize multi-touch slots\n");
+ return ret;
+ }
+
+ input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, w, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, h, 0, 0);
+
+ return 0;
+}
+
static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
{
int ret;
@@ -1249,6 +1296,13 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
if (ret < 0)
goto err_stop;
+ /* The Dualshock 4 touchpad supports 2 touches and has a
+ * resolution of 1920x940.
+ */
+ ret = sony_register_touchpad(sc, 2, 1920, 940);
+ if (ret < 0)
+ goto err_stop;
+
INIT_WORK(&sc->state_worker, dualshock4_state_worker);
} else {
ret = 0;
--
1.8.3.2
^ permalink raw reply related
* Dell Latitude E7440 - ALPS touchpad keeps having state reset
From: Allan Crooks @ 2014-01-27 15:23 UTC (permalink / raw)
To: linux-input
Hi,
I've reported the problem I'm having in more detail here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1258837
In summary - I keep suffering from the mouse pointer jumping around
erratically, with the following messages output to syslog:
psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: DualPoint TouchPad at isa0060/serio1/input0 - driver resynced.
Other people have reported the same problem in that bug report.
Bisecting the kernel, the problem seems to have always been in place
as soon as the touchpad was correctly identified; according to xinput
- it's a "AlpsPS/2 ALPS DualPoint TouchPad". When it was being
identified as a generic PS/2 mouse, there's no problem (though of
course, there's also no touchpad functionality available either).
Is there anything I can do to help provide information to get this fixed?
Thanks,
Allan.
^ permalink raw reply
* Input: zforce - fix various small issues
From: Luis Ortega @ 2014-01-27 18:46 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: heiko, yongjun_wei, linux-input, linux-kernel
As a kernel newbie and owner of a Barnes & Noble e-reader I was
curious to review this driver to learn more about the touchscreen.
The first two patches are fairly innocuous whereas the last two
slightly modify the code to fix two small issues I discovered.
I don't have the setup to test them but they look logically correct
to me.
[PATCH 1/4] Input: zforce - fix spelling errors
[PATCH 2/4] Input: zforce - fix lines exceeding 80 columns
[PATCH 3/4] Input: zforce - Remove unnecessary payload data checks
[PATCH 4/4] Input: zforce - reduce stack memory allocated to frames
^ permalink raw reply
* [PATCH 4/4] Input: zforce - reduce stack memory allocated to frames
From: Luis Ortega @ 2014-01-27 18:46 UTC (permalink / raw)
To: dmitry.torokhov
Cc: heiko, yongjun_wei, linux-input, linux-kernel, Luis Ortega
In-Reply-To: <1390848373-7723-1-git-send-email-luiorpe1@upv.es>
A frame is a u8 array with the following structure:
[PAYLOAD_HEADER, PAYLOAD_LENGTH, ...PAYLOAD_BODY...]
PAYLOAD_BODY can be at most 255 bytes long, as it's size is represented
by PAYLOAD_LENGTH. Therefore we can reduce the stack memory allocated to
payload_buffer[] roughly by half, from 512 to 257 bytes.
Signed-off-by: Luis Ortega <luiorpe1@upv.es>
---
drivers/input/touchscreen/zforce_ts.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/zforce_ts.c b/drivers/input/touchscreen/zforce_ts.c
index e082d5c..afb2492 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -33,6 +33,7 @@
#define WAIT_TIMEOUT msecs_to_jiffies(1000)
#define FRAME_START 0xee
+#define FRAME_MAXSIZE 257
/* Offsets of the different parts of the payload the controller sends */
#define PAYLOAD_HEADER 0
@@ -475,7 +476,7 @@ static irqreturn_t zforce_irq_thread(int irq, void *dev_id)
struct i2c_client *client = ts->client;
const struct zforce_ts_platdata *pdata = dev_get_platdata(&client->dev);
int ret;
- u8 payload_buffer[512];
+ u8 payload_buffer[FRAME_MAXSIZE];
u8 *payload;
/*
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH v2 2/2] HID: sony: Add output events for the multi-touch pad on the Dualshock 4.
From: simon @ 2014-01-27 17:47 UTC (permalink / raw)
Cc: linux-input, jkosina, Frank Praznik
In-Reply-To: <1390835857-4523-2-git-send-email-frank.praznik@oh.rr.com>
> +
> + /* The Dualshock 4 multi-touch trackpad data starts at offset 35 on USB.
> + * The first 7 bits of the first byte is a counter and bit 8 is a touch
> + * indicator that is 0 when pressed and 1 when not pressed.
> + * The next 3 bytes are two 12 bit touch coordinates, X and Y.
> + * The data for the second touch is in the same format and immediatly
> + * follows the data for the first.
> + */
Hi Frank,
I don't know if it helps multitouch, but there is a second set of data in
the HID stream, that is present when a figure is moving/swiping on the
touchpad. This gives us a 'vector' rather than a 'point'.
I previously attempted to describe the format here:
http://www.spinics.net/lists/linux-input/msg28525.html
Ahead of the 'event counter' is a 'point or vector' byte and what might be
a 'pressure' measurement (couldn't really tell).
Interspersed with the data you mention is a second set of X1/Y1/X2/Y2
containing the starting position of the swipe/vector. These are
differentiated with '02' (rather than '01') in the 34'th byte.
1 finger swipe left to right
--
# cat /dev/hidraw0 | hexdump -v -e '64/1 "%02x " "\n"' | cut -d ' ' -f
34-52 | grep -e '^02'
02 01 34 93 90 1d 9e bd e0 23 06 34 94 90 1d 9e bd e0 23
02 1f 34 a5 90 1d 9e bd e0 23 22 34 aa 90 1d 9e bd e0 23
02 3c 34 c3 90 1d 9e bd e0 23 41 34 ca 90 1d 9e bd e0 23
02 7c 34 37 c1 1c 9e bd e0 23 81 34 47 c1 1c 9e bd e0 23
02 bd 34 23 e2 1b 9e bd e0 23 c2 34 3a e2 1b 9e bd e0 23
02 d4 34 8e 82 1b 9e bd e0 23 d9 34 ad 72 1b 9e bd e0 23
02 f8 34 3d 23 1b 9e bd e0 23 fb 34 55 13 1b 9e bd e0 23
02 14 34 a5 e3 1a 9e bd e0 23 1a 34 b6 d3 1a 9e bd e0 23
02 2e 34 f3 b3 1a 9e bd e0 23 31 34 01 a4 1a 9e bd e0 23
02 55 34 40 a4 1a 9e bd e0 23 5a 34 47 a4 1a 9e bd e0 23
02 95 34 71 a4 1a 9e bd e0 23 9a 34 73 a4 1a 9e bd e0 23
02 ad 34 78 a4 1a 9e bd e0 23 b2 34 7a a4 1a 9e bd e0 23
[ data you use....... ] [ start of swipe.... ]
--
2 finger swipe top to bottom
--
# cat /dev/hidraw0 | hexdump -v -e '64/1 "%02x " "\n"' | cut -d ' ' -f
34-52 | grep -e '^02'
02 26 37 4a b6 04 9e bd e0 23 2b 37 4a c6 04 9e bd e0 23
02 5b 37 43 96 05 38 64 80 0b 60 37 43 d6 05 38 64 80 0b
02 84 37 3f 56 08 38 6c b0 0c 89 37 3f e6 08 38 6e 00 0d
02 a7 37 38 86 0d 38 80 c0 0f ad 37 37 b6 0e 38 85 80 10
02 d0 37 32 b6 16 38 bc d0 16 d5 37 32 a6 17 38 c5 c0 17
02 f4 37 32 16 1b 38 e7 00 1b f9 37 32 86 1b 38 eb 50 1b
02 17 37 32 f6 1c 38 f5 70 1c 1c 37 32 26 1d 38 f6 90 1c
02 40 37 32 36 1e 38 fd 40 1d 44 37 32 56 1e 38 fd 50 1d
02 63 37 32 c6 1e 38 00 91 1d 68 37 32 e6 1e 38 00 a1 1d
02 86 37 32 46 1f 38 03 d1 1d 8b 37 32 56 1f 38 03 e1 1d
02 af 37 32 b6 1f 38 06 11 1e b3 37 32 c6 1f 38 06 11 1e
02 3b 37 32 96 20 38 0b 81 1e 41 37 32 96 20 38 0b 91 1e
02 82 37 32 e6 20 38 0c c1 1e 87 37 32 e6 20 38 0c c1 1e
02 a5 37 32 16 21 38 0c 01 1f aa 37 32 26 21 38 0c 01 1f
--
Also note that there are seperate event counters for 1st and 2nd fingers,
which mean that the 2nd finger can remain pressed whilst the 1st is
pressed/released.
--
# cat /dev/hidraw0 | hexdump -v -e '64/1 "%02x " "\n"' | cut -d ' ' -f
34-52 | grep -e '^02'
02 a6>42<16 b1 19 c1 58 21 15 ab 42 16 b1 19 c1 58 21 15 <- 1st press
02 15 42 26 b1 19 c1 58 21 15 1b 42 27 b1 19 c1 58 21 15
02 50 42 2d b1 19 c1 58 21 15 55 42 2e b1 19 c1 58 21 15
02 b6 42 41 b1 19 c3 e2 c6 12 bb 42 41 b1 19 44 b5 96 14
02 01 42 43 b1 19>44<a4 96 14 06 42 43 b1 19 44 a3 96 14 <- 2nd press
02 1f 42 43 b1 19 44 9d 96 14 24 42 43 b1 19 44 9c 96 14
02 6b 42 44 b1 19 44 8e 96 14 70 42 45 b1 19 44 8d 96 14
02 cf 42 46 b1 19 44 81 c6 13 d4 42 46 b1 19 44 80 c6 13
02 38 42 47 b1 19 44 78 a6 13 3d 42 47 b1 19 44 77 a6 13
02 3a 42 48 b1 19 44 6b 56 13 3f 42 48 b1 19 44 6b 56 13
02 f5 42 48 d1 1a 44 67 f6 12 fa 42 48 11 1b 44 67 e6 12
02 18 42 49 d1 1c 44 67 d6 12 1d 42 4a 41 1d 44 67 d6 12
02 47 42 53 81 21 44 66 c6 12 4c 42 54 41 22 44 66 c6 12
02 70 42 5d 01 28 44 66 b6 12 75 42 5f e1 28 44 66 b6 12
02 99 42 65 e1 2d 44 66 a6 12 9e 42 66 91 2e 44 66 a6 12
02 bd 42 68 61 31 44 65 96 12 c2 42 68 d1 31 44 65 96 12
02 0e>c2<6d d1 34 44 64 86 12 13 c2 6d d1 34 44 64 86 12 <- 1st release
02 26 c2 6d d1 34 44 64 86 12 2b c2 6d d1 34 44 64 86 12
02 68 c2 6d d1 34 44 62 76 12 6d c2 6d d1 34 44 62 76 12
02 07>45<52 71 08 44 62 76 12 0c 45 52 d1 08 44 62 76 12 <- 1st press
02 30 45 56 41 0c 44 62 76 12 34 45 57 d1 0c 44 62 76 12
02 58 45 5a 51 10 44 62 76 12 5d 45 5a d1 10 44 62 76 12
02 7b 45 5c f1 12 44 62 76 12 80 45 5d 51 13 44 62 76 12
02 ce 45 64 71 1a 44 62 76 12 d3 45 65 01 1b 44 62 76 12
02 f1 45 67 91 1d 44 62 66 12 f6 45 68 21 1e 44 62 66 12
02 3d 45 6f e1 22 44 62 66 12 42 45 6f 01 23 44 62 66 12
02 60 45 70 b1 23 44 62 66 12 65 45 70 c1 23 44 62 66 12
02 3a>c5<73 41 25 44 7a 56 12 3d c5 73 41 25 44 7d b6 12 <- 1st release
02 57 c5 73 41 25 44 87 f6 12 5c c5 73 41 25 44 8a 06 13
--
Simon.
^ permalink raw reply
* Re: [PATCH 1/4] Input: zforce - fix spelling errors
From: Heiko Stübner @ 2014-01-27 18:41 UTC (permalink / raw)
To: Luis Ortega; +Cc: dmitry.torokhov, yongjun_wei, linux-input, linux-kernel
In-Reply-To: <1390848373-7723-2-git-send-email-luiorpe1@upv.es>
On Monday, 27. January 2014 19:46:10 Luis Ortega wrote:
> Fixed a few spelling errors.
>
> Signed-off-by: Luis Ortega <luiorpe1@upv.es>
Acked-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/input/touchscreen/zforce_ts.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/input/touchscreen/zforce_ts.c
> b/drivers/input/touchscreen/zforce_ts.c index 2175f34..c145c1d 100644
> --- a/drivers/input/touchscreen/zforce_ts.c
> +++ b/drivers/input/touchscreen/zforce_ts.c
> @@ -64,7 +64,7 @@
> #define RESPONSE_STATUS 0X1e
>
> /*
> - * Notifications are send by the touch controller without
> + * Notifications are sent by the touch controller without
> * being requested by the driver and include for example
> * touch indications
> */
> @@ -103,8 +103,8 @@ struct zforce_point {
> * @suspended device suspended
> * @access_mutex serialize i2c-access, to keep multipart reads together
> * @command_done completion to wait for the command result
> - * @command_mutex serialize commands send to the ic
> - * @command_waiting the id of the command that that is currently waiting
> + * @command_mutex serialize commands sent to the ic
> + * @command_waiting the id of the command that is currently waiting
> * for a result
> * @command_result returned result of the command
> */
> @@ -332,7 +332,7 @@ static int zforce_touch_event(struct zforce_ts *ts, u8
> *payload)
>
> count = payload[0];
> if (count > ZFORCE_REPORT_POINTS) {
> - dev_warn(&client->dev, "to many coordinates %d, expected max %d\n",
> + dev_warn(&client->dev, "too many coordinates %d, expected max %d\n",
> count, ZFORCE_REPORT_POINTS);
> count = ZFORCE_REPORT_POINTS;
> }
> @@ -798,7 +798,7 @@ static int zforce_probe(struct i2c_client *client,
> return ret;
> }
>
> - /* this gets the firmware version among other informations */
> + /* this gets the firmware version among other information */
> ret = zforce_command_wait(ts, COMMAND_STATUS);
> if (ret < 0) {
> dev_err(&client->dev, "couldn't get status, %d\n", ret);
^ permalink raw reply
* [PATCH 1/4] Input: zforce - fix spelling errors
From: Luis Ortega @ 2014-01-27 18:46 UTC (permalink / raw)
To: dmitry.torokhov
Cc: heiko, yongjun_wei, linux-input, linux-kernel, Luis Ortega
In-Reply-To: <1390848373-7723-1-git-send-email-luiorpe1@upv.es>
Fixed a few spelling errors.
Signed-off-by: Luis Ortega <luiorpe1@upv.es>
---
drivers/input/touchscreen/zforce_ts.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/zforce_ts.c b/drivers/input/touchscreen/zforce_ts.c
index 2175f34..c145c1d 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -64,7 +64,7 @@
#define RESPONSE_STATUS 0X1e
/*
- * Notifications are send by the touch controller without
+ * Notifications are sent by the touch controller without
* being requested by the driver and include for example
* touch indications
*/
@@ -103,8 +103,8 @@ struct zforce_point {
* @suspended device suspended
* @access_mutex serialize i2c-access, to keep multipart reads together
* @command_done completion to wait for the command result
- * @command_mutex serialize commands send to the ic
- * @command_waiting the id of the command that that is currently waiting
+ * @command_mutex serialize commands sent to the ic
+ * @command_waiting the id of the command that is currently waiting
* for a result
* @command_result returned result of the command
*/
@@ -332,7 +332,7 @@ static int zforce_touch_event(struct zforce_ts *ts, u8 *payload)
count = payload[0];
if (count > ZFORCE_REPORT_POINTS) {
- dev_warn(&client->dev, "to many coordinates %d, expected max %d\n",
+ dev_warn(&client->dev, "too many coordinates %d, expected max %d\n",
count, ZFORCE_REPORT_POINTS);
count = ZFORCE_REPORT_POINTS;
}
@@ -798,7 +798,7 @@ static int zforce_probe(struct i2c_client *client,
return ret;
}
- /* this gets the firmware version among other informations */
+ /* this gets the firmware version among other information */
ret = zforce_command_wait(ts, COMMAND_STATUS);
if (ret < 0) {
dev_err(&client->dev, "couldn't get status, %d\n", ret);
--
1.8.5.3
^ permalink raw reply related
* [PATCH 2/4] Input: zforce - fix lines exceeding 80 columns
From: Luis Ortega @ 2014-01-27 18:46 UTC (permalink / raw)
To: dmitry.torokhov
Cc: heiko, yongjun_wei, linux-input, linux-kernel, Luis Ortega
In-Reply-To: <1390848373-7723-1-git-send-email-luiorpe1@upv.es>
Fixed lines exceeding 80 characters long wherever possible,
as per the coding style.
Signed-off-by: Luis Ortega <luiorpe1@upv.es>
---
drivers/input/touchscreen/zforce_ts.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/zforce_ts.c b/drivers/input/touchscreen/zforce_ts.c
index c145c1d..c1b6b82 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -235,7 +235,8 @@ static int zforce_scan_frequency(struct zforce_ts *ts, u16 idle, u16 finger,
(finger & 0xff), ((finger >> 8) & 0xff),
(stylus & 0xff), ((stylus >> 8) & 0xff) };
- dev_dbg(&client->dev, "set scan frequency to (idle: %d, finger: %d, stylus: %d)\n",
+ dev_dbg(&client->dev,
+ "set scan frequency to (idle: %d, finger: %d, stylus: %d)\n",
idle, finger, stylus);
return zforce_send_wait(ts, &buf[0], ARRAY_SIZE(buf));
@@ -332,7 +333,8 @@ static int zforce_touch_event(struct zforce_ts *ts, u8 *payload)
count = payload[0];
if (count > ZFORCE_REPORT_POINTS) {
- dev_warn(&client->dev, "too many coordinates %d, expected max %d\n",
+ dev_warn(&client->dev,
+ "too many coordinates %d, expected max %d\n",
count, ZFORCE_REPORT_POINTS);
count = ZFORCE_REPORT_POINTS;
}
@@ -494,8 +496,8 @@ static irqreturn_t zforce_irq_thread(int irq, void *dev_id)
while (!gpio_get_value(pdata->gpio_int)) {
ret = zforce_read_packet(ts, payload_buffer);
if (ret < 0) {
- dev_err(&client->dev, "could not read packet, ret: %d\n",
- ret);
+ dev_err(&client->dev,
+ "could not read packet, ret: %d\n", ret);
break;
}
@@ -539,7 +541,8 @@ static irqreturn_t zforce_irq_thread(int irq, void *dev_id)
payload[RESPONSE_DATA + 4];
ts->version_rev = (payload[RESPONSE_DATA + 7] << 8) |
payload[RESPONSE_DATA + 6];
- dev_dbg(&ts->client->dev, "Firmware Version %04x:%04x %04x:%04x\n",
+ dev_dbg(&ts->client->dev,
+ "Firmware Version %04x:%04x %04x:%04x\n",
ts->version_major, ts->version_minor,
ts->version_build, ts->version_rev);
@@ -552,7 +555,8 @@ static irqreturn_t zforce_irq_thread(int irq, void *dev_id)
break;
default:
- dev_err(&ts->client->dev, "unrecognized response id: 0x%x\n",
+ dev_err(&ts->client->dev,
+ "unrecognized response id: 0x%x\n",
payload[RESPONSE_ID]);
break;
}
@@ -618,7 +622,8 @@ static int zforce_suspend(struct device *dev)
enable_irq_wake(client->irq);
} else if (input->users) {
- dev_dbg(&client->dev, "suspend without being a wakeup source\n");
+ dev_dbg(&client->dev,
+ "suspend without being a wakeup source\n");
ret = zforce_stop(ts);
if (ret)
--
1.8.5.3
^ permalink raw reply related
* [PATCH 3/4] Input: zforce - Remove unnecessary payload data checks
From: Luis Ortega @ 2014-01-27 18:46 UTC (permalink / raw)
To: dmitry.torokhov
Cc: heiko, yongjun_wei, linux-input, linux-kernel, Luis Ortega
In-Reply-To: <1390848373-7723-1-git-send-email-luiorpe1@upv.es>
The function zforce_read_packet() reads 2 values (bytes) of payload
header, validates them and then proceeds to read the payload body.
The function stores all these in a u8 buffer.
The PAYLOAD_LENGTH check seems to be trying to detect an overflow error.
However, since we are just reading a u8 value from the buffer, these
checks are unnecessary and we should simply compare against zero.
Signed-off-by: Luis Ortega <luiorpe1@upv.es>
---
drivers/input/touchscreen/zforce_ts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/zforce_ts.c b/drivers/input/touchscreen/zforce_ts.c
index c1b6b82..e082d5c 100644
--- a/drivers/input/touchscreen/zforce_ts.c
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -423,7 +423,7 @@ static int zforce_read_packet(struct zforce_ts *ts, u8 *buf)
goto unlock;
}
- if (buf[PAYLOAD_LENGTH] <= 0 || buf[PAYLOAD_LENGTH] > 255) {
+ if (buf[PAYLOAD_LENGTH] == 0) {
dev_err(&client->dev, "invalid payload length: %d\n",
buf[PAYLOAD_LENGTH]);
ret = -EIO;
--
1.8.5.3
^ permalink raw reply related
* [RFC][PATCH] module: allow multiple calls to MODULE_DEVICE_TABLE() per module
From: Tom Gundersen @ 2014-01-27 19:09 UTC (permalink / raw)
To: linux-kernel
Cc: linux-input, kay, Tom Gundersen, Dmitry Torokhov,
Greg Kroah-Hartman, Rusty Russell
Commit 78551277e4df5: "Input: i8042 - add PNP modaliases" had a bug, where the
second call to MODULE_DEVICE_TABLE() overrode the first resulting in not all
the modaliases being exposed.
This fixes the problem by including the name of the device_id table in the
__mod_*_device_table alias, allowing us to export several device_id tables
per module.
Suggested-by: Kay Sievers <kay@vrfy.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
---
include/linux/module.h | 2 +-
scripts/mod/file2alias.c | 14 +++++++++-----
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 15cd6b1..7732d76 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -143,7 +143,7 @@ extern const struct gtype##_id __mod_##gtype##_table \
#define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
#define MODULE_DEVICE_TABLE(type,name) \
- MODULE_GENERIC_TABLE(type##_device,name)
+ MODULE_GENERIC_TABLE(type##__##name##_device,name)
/* Version of form [<epoch>:]<version>[-<extra-version>].
Or for CVS/RCS ID version, everything but the number is stripped.
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 2370863..6778381 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -42,7 +42,7 @@ typedef unsigned char __u8;
/* This array collects all instances that use the generic do_table */
struct devtable {
- const char *device_id; /* name of table, __mod_<name>_device_table. */
+ const char *device_id; /* name of table, __mod_<name>__*_device_table. */
unsigned long id_size;
void *function;
};
@@ -146,7 +146,8 @@ static void device_id_check(const char *modname, const char *device_id,
if (size % id_size || size < id_size) {
fatal("%s: sizeof(struct %s_device_id)=%lu is not a modulo "
- "of the size of section __mod_%s_device_table=%lu.\n"
+ "of the size of "
+ "section __mod_%s__<identifier>_device_table=%lu.\n"
"Fix definition of struct %s_device_id "
"in mod_devicetable.h\n",
modname, device_id, id_size, device_id, size, device_id);
@@ -1206,7 +1207,7 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
{
void *symval;
char *zeros = NULL;
- const char *name;
+ const char *name, *identifier;
unsigned int namelen;
/* We're looking for a section relative symbol */
@@ -1217,7 +1218,7 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
if (ELF_ST_TYPE(sym->st_info) != STT_OBJECT)
return;
- /* All our symbols are of form <prefix>__mod_XXX_device_table. */
+ /* All our symbols are of form <prefix>__mod_<name>__<identifier>_device_table. */
name = strstr(symname, "__mod_");
if (!name)
return;
@@ -1227,7 +1228,10 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
return;
if (strcmp(name + namelen - strlen("_device_table"), "_device_table"))
return;
- namelen -= strlen("_device_table");
+ identifier = strstr(name, "__");
+ if (!identifier)
+ return;
+ namelen = identifier - name;
/* Handle all-NULL symbols allocated into .bss */
if (info->sechdrs[get_secindex(info, sym)].sh_type & SHT_NOBITS) {
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH 2/4] Input: zforce - fix lines exceeding 80 columns
From: Heiko Stübner @ 2014-01-27 19:12 UTC (permalink / raw)
To: Luis Ortega; +Cc: dmitry.torokhov, yongjun_wei, linux-input, linux-kernel
In-Reply-To: <1390848373-7723-3-git-send-email-luiorpe1@upv.es>
On Monday, 27. January 2014 19:46:11 Luis Ortega wrote:
> Fixed lines exceeding 80 characters long wherever possible,
> as per the coding style.
>
> Signed-off-by: Luis Ortega <luiorpe1@upv.es>
checkpatch did not complain on the initial submission, so I guess it's more an
issue of taste. Nevertheless I don't have a preference for one way or the
other, so
Acked-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/input/touchscreen/zforce_ts.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/input/touchscreen/zforce_ts.c
> b/drivers/input/touchscreen/zforce_ts.c index c145c1d..c1b6b82 100644
> --- a/drivers/input/touchscreen/zforce_ts.c
> +++ b/drivers/input/touchscreen/zforce_ts.c
> @@ -235,7 +235,8 @@ static int zforce_scan_frequency(struct zforce_ts *ts,
> u16 idle, u16 finger, (finger & 0xff), ((finger >> 8) & 0xff),
> (stylus & 0xff), ((stylus >> 8) & 0xff) };
>
> - dev_dbg(&client->dev, "set scan frequency to (idle: %d, finger: %d,
> stylus: %d)\n", + dev_dbg(&client->dev,
> + "set scan frequency to (idle: %d, finger: %d, stylus: %d)\n",
> idle, finger, stylus);
>
> return zforce_send_wait(ts, &buf[0], ARRAY_SIZE(buf));
> @@ -332,7 +333,8 @@ static int zforce_touch_event(struct zforce_ts *ts, u8
> *payload)
>
> count = payload[0];
> if (count > ZFORCE_REPORT_POINTS) {
> - dev_warn(&client->dev, "too many coordinates %d, expected max %d\n",
> + dev_warn(&client->dev,
> + "too many coordinates %d, expected max %d\n",
> count, ZFORCE_REPORT_POINTS);
> count = ZFORCE_REPORT_POINTS;
> }
> @@ -494,8 +496,8 @@ static irqreturn_t zforce_irq_thread(int irq, void
> *dev_id) while (!gpio_get_value(pdata->gpio_int)) {
> ret = zforce_read_packet(ts, payload_buffer);
> if (ret < 0) {
> - dev_err(&client->dev, "could not read packet, ret: %d\n",
> - ret);
> + dev_err(&client->dev,
> + "could not read packet, ret: %d\n", ret);
> break;
> }
>
> @@ -539,7 +541,8 @@ static irqreturn_t zforce_irq_thread(int irq, void
> *dev_id) payload[RESPONSE_DATA + 4];
> ts->version_rev = (payload[RESPONSE_DATA + 7] << 8) |
> payload[RESPONSE_DATA + 6];
> - dev_dbg(&ts->client->dev, "Firmware Version %04x:%04x %04x:
%04x\n",
> + dev_dbg(&ts->client->dev,
> + "Firmware Version %04x:%04x %04x:%04x\n",
> ts->version_major, ts->version_minor,
> ts->version_build, ts->version_rev);
>
> @@ -552,7 +555,8 @@ static irqreturn_t zforce_irq_thread(int irq, void
> *dev_id) break;
>
> default:
> - dev_err(&ts->client->dev, "unrecognized response id: 0x%x\n",
> + dev_err(&ts->client->dev,
> + "unrecognized response id: 0x%x\n",
> payload[RESPONSE_ID]);
> break;
> }
> @@ -618,7 +622,8 @@ static int zforce_suspend(struct device *dev)
>
> enable_irq_wake(client->irq);
> } else if (input->users) {
> - dev_dbg(&client->dev, "suspend without being a wakeup source\n");
> + dev_dbg(&client->dev,
> + "suspend without being a wakeup source\n");
>
> ret = zforce_stop(ts);
> if (ret)
^ permalink raw reply
* Re: [PATCH 2/4] Input: zforce - fix lines exceeding 80 columns
From: Luis Ortega @ 2014-01-27 19:29 UTC (permalink / raw)
To: Heiko Stübner
Cc: Luis Ortega, Dmitry Torokhov, yongjun_wei, linux-input,
linux-kernel
In-Reply-To: <1864335.qYXGSfrppl@phil>
Yeah, I also ran checkpatch on the file and it had nothing to report.
Unfortunately those lines are slightly long and got word wrapped in my
editor, disrupting the flow of text. I thought fixing them wouldn't hurt.
On Mon, Jan 27, 2014 at 8:12 PM, Heiko Stübner <heiko@sntech.de> wrote:
> On Monday, 27. January 2014 19:46:11 Luis Ortega wrote:
>> Fixed lines exceeding 80 characters long wherever possible,
>> as per the coding style.
>>
>> Signed-off-by: Luis Ortega <luiorpe1@upv.es>
>
> checkpatch did not complain on the initial submission, so I guess it's more an
> issue of taste. Nevertheless I don't have a preference for one way or the
> other, so
>
> Acked-by: Heiko Stuebner <heiko@sntech.de>
>
>
>> ---
>> drivers/input/touchscreen/zforce_ts.c | 19 ++++++++++++-------
>> 1 file changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/zforce_ts.c
>> b/drivers/input/touchscreen/zforce_ts.c index c145c1d..c1b6b82 100644
>> --- a/drivers/input/touchscreen/zforce_ts.c
>> +++ b/drivers/input/touchscreen/zforce_ts.c
>> @@ -235,7 +235,8 @@ static int zforce_scan_frequency(struct zforce_ts *ts,
>> u16 idle, u16 finger, (finger & 0xff), ((finger >> 8) & 0xff),
>> (stylus & 0xff), ((stylus >> 8) & 0xff) };
>>
>> - dev_dbg(&client->dev, "set scan frequency to (idle: %d, finger: %d,
>> stylus: %d)\n", + dev_dbg(&client->dev,
>> + "set scan frequency to (idle: %d, finger: %d, stylus: %d)\n",
>> idle, finger, stylus);
>>
>> return zforce_send_wait(ts, &buf[0], ARRAY_SIZE(buf));
>> @@ -332,7 +333,8 @@ static int zforce_touch_event(struct zforce_ts *ts, u8
>> *payload)
>>
>> count = payload[0];
>> if (count > ZFORCE_REPORT_POINTS) {
>> - dev_warn(&client->dev, "too many coordinates %d, expected max %d\n",
>> + dev_warn(&client->dev,
>> + "too many coordinates %d, expected max %d\n",
>> count, ZFORCE_REPORT_POINTS);
>> count = ZFORCE_REPORT_POINTS;
>> }
>> @@ -494,8 +496,8 @@ static irqreturn_t zforce_irq_thread(int irq, void
>> *dev_id) while (!gpio_get_value(pdata->gpio_int)) {
>> ret = zforce_read_packet(ts, payload_buffer);
>> if (ret < 0) {
>> - dev_err(&client->dev, "could not read packet, ret: %d\n",
>> - ret);
>> + dev_err(&client->dev,
>> + "could not read packet, ret: %d\n", ret);
>> break;
>> }
>>
>> @@ -539,7 +541,8 @@ static irqreturn_t zforce_irq_thread(int irq, void
>> *dev_id) payload[RESPONSE_DATA + 4];
>> ts->version_rev = (payload[RESPONSE_DATA + 7] << 8) |
>> payload[RESPONSE_DATA + 6];
>> - dev_dbg(&ts->client->dev, "Firmware Version %04x:%04x %04x:
> %04x\n",
>> + dev_dbg(&ts->client->dev,
>> + "Firmware Version %04x:%04x %04x:%04x\n",
>> ts->version_major, ts->version_minor,
>> ts->version_build, ts->version_rev);
>>
>> @@ -552,7 +555,8 @@ static irqreturn_t zforce_irq_thread(int irq, void
>> *dev_id) break;
>>
>> default:
>> - dev_err(&ts->client->dev, "unrecognized response id: 0x%x\n",
>> + dev_err(&ts->client->dev,
>> + "unrecognized response id: 0x%x\n",
>> payload[RESPONSE_ID]);
>> break;
>> }
>> @@ -618,7 +622,8 @@ static int zforce_suspend(struct device *dev)
>>
>> enable_irq_wake(client->irq);
>> } else if (input->users) {
>> - dev_dbg(&client->dev, "suspend without being a wakeup source\n");
>> + dev_dbg(&client->dev,
>> + "suspend without being a wakeup source\n");
>>
>> ret = zforce_stop(ts);
>> if (ret)
>
--
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
* HID_REQ_GET_REPORT and report not filled during hid_pidff_init
From: Lauri Peltonen @ 2014-01-27 19:31 UTC (permalink / raw)
To: linux-input; +Cc: jkosina
Hi.
I'm making some enhancements to hid/usbhid/hid-pidff.c to support more
force feedback devices, but I've encountered some weird behaviour. I'm
not sure whether it's a bug or something else.
My changes depend on knowing some device information (like memory) in
the initialization phase, and luckily hid-pidff reads the info from
PID_POOL report in hid_pidff_init -> pidff_reset. [1] and [2]
However, I noticed that the report struct never gets filled (all
zeros), even though with usbmon I can see the ctrl message out and the
report coming in with correct data (300 bytes of memory etc). I
managed to locate the line which causes the report to be dropped in
hid/hid-core.c , in hid_input_repor(..)t checking for
driver_input_lock. [3] Commenting out the following lines "fixes" the
issue, and the struct gets filled correctly. Anyways, I think that is
not a real solution.
if (down_trylock(&hid->driver_input_lock))
return -EBUSY;
Now, I wonder if there is a reason why the locking fails? Is the
driver locked during the initialization and hid_hw_request(...
HID_REQ_GET_REPORT) cannot be used? If that is so, what is the correct
way to read device reports during the init? And does the hid-pidff
driver ever read the pool report correctly, or is this just with my
Saitek device?
I'm using kernel 3.13.
Best regards, Lauri Peltonen
[1] http://lxr.free-electrons.com/source/drivers/hid/usbhid/hid-pidff.c#L1268
[2] http://lxr.free-electrons.com/source/drivers/hid/usbhid/hid-pidff.c#L1172
[3] http://lxr.free-electrons.com/source/drivers/hid/hid-core.c#L1392
--
Lauri Peltonen
lauri.peltonen@gmail.com
^ permalink raw reply
* Re: [RFC][PATCH] module: allow multiple calls to MODULE_DEVICE_TABLE() per module
From: Greg Kroah-Hartman @ 2014-01-27 19:54 UTC (permalink / raw)
To: Tom Gundersen
Cc: linux-kernel, linux-input, kay, Dmitry Torokhov, Rusty Russell
In-Reply-To: <1390849795-2155-1-git-send-email-teg@jklm.no>
On Mon, Jan 27, 2014 at 08:09:55PM +0100, Tom Gundersen wrote:
> Commit 78551277e4df5: "Input: i8042 - add PNP modaliases" had a bug, where the
> second call to MODULE_DEVICE_TABLE() overrode the first resulting in not all
> the modaliases being exposed.
>
> This fixes the problem by including the name of the device_id table in the
> __mod_*_device_table alias, allowing us to export several device_id tables
> per module.
>
> Suggested-by: Kay Sievers <kay@vrfy.org>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> ---
> include/linux/module.h | 2 +-
> scripts/mod/file2alias.c | 14 +++++++++-----
> 2 files changed, 10 insertions(+), 6 deletions(-)
Ah, very nice, I've wanted this for a while now, it would make a number
of different drivers much smaller and simpler to add new device ids to
(no multiple lists of ids, one for the module loader and one for the
sub-driver that is in the single file.)
If this doesn't break any userspace tools, I have no objection to it at
all:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH] USB: input: gtco.c: fix usb_dev leak
From: Alexey Khoroshilov @ 2014-01-27 20:10 UTC (permalink / raw)
To: Dmitry Torokhov, Greg Kroah-Hartman
Cc: Alexey Khoroshilov, linux-input, linux-kernel, ldv-project
There is usb_get_dev() in gtco_probe(), but there is no usb_put_dev()
anywhere in the driver.
As pointed out by Dmitry Torokhov:
The lifetime of gtco structure is already directly tied to lifetime of
usb_dev: when destroying usb_dev driver core will call remove() function
of currently bound driver (in our case gtco) which will destroy gtco
memory. Taking additional reference is not needed here.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/input/tablet/gtco.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
index caecffe8caff..858045694e9d 100644
--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -848,7 +848,7 @@ static int gtco_probe(struct usb_interface *usbinterface,
gtco->inputdevice = input_dev;
/* Save interface information */
- gtco->usbdev = usb_get_dev(interface_to_usbdev(usbinterface));
+ gtco->usbdev = interface_to_usbdev(usbinterface);
gtco->intf = usbinterface;
/* Allocate some data for incoming reports */
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 3/4] Input: zforce - Remove unnecessary payload data checks
From: Heiko Stübner @ 2014-01-27 20:16 UTC (permalink / raw)
To: Luis Ortega; +Cc: dmitry.torokhov, yongjun_wei, linux-input, linux-kernel
In-Reply-To: <1390848373-7723-4-git-send-email-luiorpe1@upv.es>
On Monday, 27. January 2014 19:46:12 Luis Ortega wrote:
> The function zforce_read_packet() reads 2 values (bytes) of payload
> header, validates them and then proceeds to read the payload body.
> The function stores all these in a u8 buffer.
>
> The PAYLOAD_LENGTH check seems to be trying to detect an overflow error.
> However, since we are just reading a u8 value from the buffer, these
> checks are unnecessary and we should simply compare against zero.
>
> Signed-off-by: Luis Ortega <luiorpe1@upv.es>
Acked-by: Heiko Stuebner <heiko@sntech.de>
on a bq Cervantes (imx6sl)
Tested-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/input/touchscreen/zforce_ts.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/zforce_ts.c
> b/drivers/input/touchscreen/zforce_ts.c index c1b6b82..e082d5c 100644
> --- a/drivers/input/touchscreen/zforce_ts.c
> +++ b/drivers/input/touchscreen/zforce_ts.c
> @@ -423,7 +423,7 @@ static int zforce_read_packet(struct zforce_ts *ts, u8
> *buf) goto unlock;
> }
>
> - if (buf[PAYLOAD_LENGTH] <= 0 || buf[PAYLOAD_LENGTH] > 255) {
> + if (buf[PAYLOAD_LENGTH] == 0) {
> dev_err(&client->dev, "invalid payload length: %d\n",
> buf[PAYLOAD_LENGTH]);
> ret = -EIO;
^ permalink raw reply
* Re: [PATCH 4/4] Input: zforce - reduce stack memory allocated to frames
From: Heiko Stübner @ 2014-01-27 20:22 UTC (permalink / raw)
To: Luis Ortega; +Cc: dmitry.torokhov, yongjun_wei, linux-input, linux-kernel
In-Reply-To: <1390848373-7723-5-git-send-email-luiorpe1@upv.es>
On Monday, 27. January 2014 19:46:13 Luis Ortega wrote:
> A frame is a u8 array with the following structure:
> [PAYLOAD_HEADER, PAYLOAD_LENGTH, ...PAYLOAD_BODY...]
>
> PAYLOAD_BODY can be at most 255 bytes long, as it's size is represented
> by PAYLOAD_LENGTH. Therefore we can reduce the stack memory allocated to
> payload_buffer[] roughly by half, from 512 to 257 bytes.
Nice catch, thanks
Acked-by: Heiko Stuebner <heiko@sntech.de>
on a bq Cervantes (imx6sl)
Tested-by: Heiko Stuebner <heiko@sntech.de>
As a side-note, this change conflicts with one of my patches adding devicetree
support to the driver [0], which Dmitry will hopefully also look at soon.
So one of us might need to respin his series depending on the ordering.
[0] http://permalink.gmane.org/gmane.linux.kernel.input/33587
>
> Signed-off-by: Luis Ortega <luiorpe1@upv.es>
> ---
> drivers/input/touchscreen/zforce_ts.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/zforce_ts.c
> b/drivers/input/touchscreen/zforce_ts.c index e082d5c..afb2492 100644
> --- a/drivers/input/touchscreen/zforce_ts.c
> +++ b/drivers/input/touchscreen/zforce_ts.c
> @@ -33,6 +33,7 @@
> #define WAIT_TIMEOUT msecs_to_jiffies(1000)
>
> #define FRAME_START 0xee
> +#define FRAME_MAXSIZE 257
>
> /* Offsets of the different parts of the payload the controller sends */
> #define PAYLOAD_HEADER 0
> @@ -475,7 +476,7 @@ static irqreturn_t zforce_irq_thread(int irq, void
> *dev_id) struct i2c_client *client = ts->client;
> const struct zforce_ts_platdata *pdata = dev_get_platdata(&client->dev);
> int ret;
> - u8 payload_buffer[512];
> + u8 payload_buffer[FRAME_MAXSIZE];
> u8 *payload;
>
> /*
^ permalink raw reply
* Re: [PATCH] USB: input: gtco.c: fix usb_dev leak
From: Dmitry Torokhov @ 2014-01-27 20:24 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: Greg Kroah-Hartman, linux-input, linux-kernel, ldv-project
In-Reply-To: <1390853454-31749-1-git-send-email-khoroshilov@ispras.ru>
On Tue, Jan 28, 2014 at 12:10:54AM +0400, Alexey Khoroshilov wrote:
> There is usb_get_dev() in gtco_probe(), but there is no usb_put_dev()
> anywhere in the driver.
>
> As pointed out by Dmitry Torokhov:
> The lifetime of gtco structure is already directly tied to lifetime of
> usb_dev: when destroying usb_dev driver core will call remove() function
> of currently bound driver (in our case gtco) which will destroy gtco
> memory. Taking additional reference is not needed here.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Applied, thank you.
> ---
> drivers/input/tablet/gtco.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
> index caecffe8caff..858045694e9d 100644
> --- a/drivers/input/tablet/gtco.c
> +++ b/drivers/input/tablet/gtco.c
> @@ -848,7 +848,7 @@ static int gtco_probe(struct usb_interface *usbinterface,
> gtco->inputdevice = input_dev;
>
> /* Save interface information */
> - gtco->usbdev = usb_get_dev(interface_to_usbdev(usbinterface));
> + gtco->usbdev = interface_to_usbdev(usbinterface);
> gtco->intf = usbinterface;
>
> /* Allocate some data for incoming reports */
> --
> 1.8.3.2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: i8042-io - Exclude mips platforms when allocating/deallocating IO regions.
From: Aaro Koskinen @ 2014-01-27 20:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Raghu Gandham, linux-input@vger.kernel.org,
linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140127065638.GB11945@core.coreip.homeip.net>
Hi,
On Sun, Jan 26, 2014 at 10:56:38PM -0800, Dmitry Torokhov wrote:
> On Mon, Jan 27, 2014 at 12:32:36AM +0000, Raghu Gandham wrote:
> > > On Sat, Jan 25, 2014 at 11:01:54AM -0800, Raghu Gandham wrote:
> > > > The standard IO regions are already reserved by the platform code on
> > > > most MIPS devices(malta, cobalt, sni). The Commit
> > > > 197a1e96c8be5b6005145af3a4c0e45e2d651444
> > > > ("Input: i8042-io - fix up region handling on MIPS") introduced a bug
> > > > on these MIPS platforms causing i8042 driver to fail when trying to
> > > > reserve IO ports.
> > > > Prior to the above mentioned commit request_region is skipped on MIPS
> > > > but release_region is called.
> > > >
> > > > This patch reverts commit 197a1e96c8be5b6005145af3a4c0e45e2d651444
> > > > and also avoids calling release_region for MIPS.
> > >
> > > The problem is that IO regions are reserved on _most_, but not _all_
> > > devices.
> > > MIPS should figure out what they want to do with i8042 registers and be
> > > consistent on all devices.
> >
> > Please examine the attached patch which went upstream in April of 2004.
> > Since then it had been a convention not to call request_region routine in
> > i8042 for MIPS. The attached patch had a glitch that it guarded
> > request_region in i8042-io.h but skipped guarding release_region in
> > i8042-io.h. I believe that the issue Aaro saw was due to this
> > glitch. Below is the error quoted in Aaro's commit message.
> >
> > [ 2.112000] Trying to free nonexistent resource <0000000000000060-000000000000006f>
> >
> > My patch reinstates the convention followed on MIPS devices along with
> > fixing Aaro's issue.
>
> I assume that Aaro did test his patch and on his box request_region()
> succeeds. That would indicate that various MIPS sub-arches still not
> settled on the topic.
request_region() succeeds on Loongson and OCTEON.
On OCTEONs without PCI, request_region() will fail which is correct as
there is no I/O space.
I wasn't aware of that 2004 patch (it pre-dates GIT history of mainline
Linux). Why the regions are already reserved by the platform code?
A.
^ permalink raw reply
* Re: [RFC][PATCH] module: allow multiple calls to MODULE_DEVICE_TABLE() per module
From: Dmitry Torokhov @ 2014-01-27 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tom Gundersen, linux-kernel, linux-input, kay, Rusty Russell
In-Reply-To: <20140127195422.GB21018@kroah.com>
On Mon, Jan 27, 2014 at 11:54:22AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Jan 27, 2014 at 08:09:55PM +0100, Tom Gundersen wrote:
> > Commit 78551277e4df5: "Input: i8042 - add PNP modaliases" had a bug, where the
> > second call to MODULE_DEVICE_TABLE() overrode the first resulting in not all
> > the modaliases being exposed.
> >
> > This fixes the problem by including the name of the device_id table in the
> > __mod_*_device_table alias, allowing us to export several device_id tables
> > per module.
> >
> > Suggested-by: Kay Sievers <kay@vrfy.org>
> > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > ---
> > include/linux/module.h | 2 +-
> > scripts/mod/file2alias.c | 14 +++++++++-----
> > 2 files changed, 10 insertions(+), 6 deletions(-)
>
> Ah, very nice, I've wanted this for a while now, it would make a number
> of different drivers much smaller and simpler to add new device ids to
> (no multiple lists of ids, one for the module loader and one for the
> sub-driver that is in the single file.)
>
> If this doesn't break any userspace tools, I have no objection to it at
> all:
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Looks great to me as long as module tools keep working.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/2] HID: sony: Add output events for the multi-touch pad on the Dualshock 4.
From: simon @ 2014-01-27 20:40 UTC (permalink / raw)
Cc: linux-input, jkosina, Frank Praznik
In-Reply-To: <1390835857-4523-2-git-send-email-frank.praznik@oh.rr.com>
> + for (n = 0; n < 2; n++) {
> + __u16 x, y;
> +
> + x = rd[offset+1] | ((rd[offset+2] & 0xF) << 8);
> + y = ((rd[offset+2] & 0xF0) >> 4) | (rd[offset+3] << 4);
> +
> + input_mt_slot(input_dev, n);
> + input_mt_report_slot_state(input_dev, MT_TOOL_FINGER,
> + !(rd[offset] >> 7));
> + input_report_abs(input_dev, ABS_MT_POSITION_X, x);
> + input_report_abs(input_dev, ABS_MT_POSITION_Y, y);
> +
> + offset += 4;
> + }
Sorry I have another point/question....
Doesn't this 'spam' the Multitouch interface every incoming report,
regardless on whether anything has actually change? ie. Should HID-Sony
track the values, and only send when it detects a change...
Simon
^ 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