* [PATCH v3] ims-pcu: Add commands supported by the new version of the FW
From: Andrey Smirnov @ 2014-01-22 13:20 UTC (permalink / raw)
To: linux-input; +Cc: andrew.smirnov, dmitry.torokhov, linux-kernel
New version of the PCU firmware supports two new commands:
- IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the
registers of one finger navigation(OFN) chip present on the device
- IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the
registers of said chip.
This commit adds two helper functions to use those commands and sysfs
attributes to use them. It also exposes some OFN configuration
parameters via sysfs.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/misc/ims-pcu.c | 260 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 251 insertions(+), 9 deletions(-)
diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
index e204f26..1d084d9 100644
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -51,6 +51,8 @@ struct ims_pcu_backlight {
#define IMS_PCU_BL_VERSION_LEN (9 + 1)
#define IMS_PCU_BL_RESET_REASON_LEN (2 + 1)
+#define IMS_PCU_PCU_B_DEVICE_ID 5
+
#define IMS_PCU_BUF_SIZE 128
struct ims_pcu {
@@ -68,6 +70,9 @@ struct ims_pcu {
char bl_version[IMS_PCU_BL_VERSION_LEN];
char reset_reason[IMS_PCU_BL_RESET_REASON_LEN];
int update_firmware_status;
+ u8 device_id;
+
+ u8 ofn_reg_addr;
struct usb_interface *ctrl_intf;
@@ -371,6 +376,8 @@ static void ims_pcu_destroy_gamepad(struct ims_pcu *pcu)
#define IMS_PCU_CMD_GET_DEVICE_ID 0xae
#define IMS_PCU_CMD_SPECIAL_INFO 0xb0
#define IMS_PCU_CMD_BOOTLOADER 0xb1 /* Pass data to bootloader */
+#define IMS_PCU_CMD_OFN_SET_CONFIG 0xb3
+#define IMS_PCU_CMD_OFN_GET_CONFIG 0xb4
/* PCU responses */
#define IMS_PCU_RSP_STATUS 0xc0
@@ -389,6 +396,9 @@ static void ims_pcu_destroy_gamepad(struct ims_pcu *pcu)
#define IMS_PCU_RSP_GET_DEVICE_ID 0xce
#define IMS_PCU_RSP_SPECIAL_INFO 0xd0
#define IMS_PCU_RSP_BOOTLOADER 0xd1 /* Bootloader response */
+#define IMS_PCU_RSP_OFN_SET_CONFIG 0xd2
+#define IMS_PCU_RSP_OFN_GET_CONFIG 0xd3
+
#define IMS_PCU_RSP_EVNT_BUTTONS 0xe0 /* Unsolicited, button state */
#define IMS_PCU_GAMEPAD_MASK 0x0001ff80UL /* Bits 7 through 16 */
@@ -1226,7 +1236,7 @@ static struct attribute *ims_pcu_attrs[] = {
&dev_attr_reset_device.attr,
&dev_attr_update_firmware.attr,
&dev_attr_update_firmware_status.attr,
- NULL
+ NULL,
};
static umode_t ims_pcu_is_attr_visible(struct kobject *kobj,
@@ -1256,6 +1266,225 @@ static struct attribute_group ims_pcu_attr_group = {
.attrs = ims_pcu_attrs,
};
+/* Support for a separate OFN attribute group */
+
+#define OFN_REG_RESULT_OFFSET 2
+
+static int ims_pcu_read_ofn_config(struct ims_pcu *pcu, u8 addr, u8 *data)
+{
+ int error;
+ s16 result;
+
+ error = ims_pcu_execute_command(pcu, OFN_GET_CONFIG,
+ &addr, sizeof(addr));
+ if (error)
+ return error;
+
+ result = (s16)get_unaligned_le16(pcu->cmd_buf + OFN_REG_RESULT_OFFSET);
+ if (result < 0)
+ return -EIO;
+
+ /* We only need LSB */
+ *data = pcu->cmd_buf[OFN_REG_RESULT_OFFSET];
+ return 0;
+}
+
+static int ims_pcu_write_ofn_config(struct ims_pcu *pcu, u8 addr, u8 data)
+{
+ u8 buffer[] = { addr, data };
+ int error;
+ u16 result;
+
+ error = ims_pcu_execute_command(pcu, OFN_SET_CONFIG,
+ &buffer, sizeof(buffer));
+ if (error)
+ return error;
+
+ result = (s16)get_unaligned_le16(pcu->cmd_buf + OFN_REG_RESULT_OFFSET);
+ if ((result < 0)
+ return -EIO;
+
+ return 0;
+}
+
+static ssize_t ims_pcu_ofn_reg_data_show(struct device *dev,
+ struct device_attribute *dattr,
+ char *buf)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ims_pcu *pcu = usb_get_intfdata(intf);
+ int error;
+ u8 data;
+
+ mutex_lock(&pcu->cmd_mutex);
+ error = ims_pcu_read_ofn_config(pcu, pcu->ofn_reg_addr, &data);
+ mutex_unlock(&pcu->cmd_mutex);
+
+ if (error)
+ return error;
+
+ return scnprintf(buf, PAGE_SIZE, "%x\n", data);
+}
+
+static ssize_t ims_pcu_ofn_reg_data_store(struct device *dev,
+ struct device_attribute *dattr,
+ const char *buf, size_t count)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ims_pcu *pcu = usb_get_intfdata(intf);
+ int error;
+ u8 value;
+
+ error = kstrtou8(buf, 0, &value);
+ if (error)
+ return error;
+
+ mutex_lock(&pcu->cmd_mutex);
+ error = ims_pcu_write_ofn_config(pcu, pcu->ofn_reg_addr, value);
+ mutex_unlock(&pcu->cmd_mutex);
+
+ return error ?: count;
+}
+
+static DEVICE_ATTR(reg_data, S_IRUGO | S_IWUSR,
+ ims_pcu_ofn_reg_data_show, ims_pcu_ofn_reg_data_store);
+
+static ssize_t ims_pcu_ofn_reg_addr_show(struct device *dev,
+ struct device_attribute *dattr,
+ char *buf)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ims_pcu *pcu = usb_get_intfdata(intf);
+ int error;
+
+ mutex_lock(&pcu->cmd_mutex);
+ error = scnprintf(buf, PAGE_SIZE, "%x\n", pcu->ofn_reg_addr);
+ mutex_unlock(&pcu->cmd_mutex);
+
+ return error;
+}
+
+static ssize_t ims_pcu_ofn_reg_addr_store(struct device *dev,
+ struct device_attribute *dattr,
+ const char *buf, size_t count)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ims_pcu *pcu = usb_get_intfdata(intf);
+ int error;
+ u8 value;
+
+ error = kstrtou8(buf, 0, &value);
+ if (error)
+ return error;
+
+ mutex_lock(&pcu->cmd_mutex);
+ pcu->ofn_reg_addr = value;
+ mutex_unlock(&pcu->cmd_mutex);
+
+ return error ?: count;
+}
+
+static DEVICE_ATTR(reg_addr, S_IRUGO | S_IWUSR,
+ ims_pcu_ofn_reg_addr_show, ims_pcu_ofn_reg_addr_store);
+
+struct ims_pcu_ofn_bit_attribute {
+ struct device_attribute dattr;
+ u8 addr;
+ u8 nr;
+};
+
+static ssize_t ims_pcu_ofn_bit_show(struct device *dev,
+ struct device_attribute *dattr,
+ char *buf)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ims_pcu *pcu = usb_get_intfdata(intf);
+ struct ims_pcu_ofn_bit_attribute *attr =
+ container_of(dattr, struct ims_pcu_ofn_bit_attribute, dattr);
+ int error;
+ u8 data;
+
+ mutex_lock(&pcu->cmd_mutex);
+ error = ims_pcu_read_ofn_config(pcu, attr->addr, &data);
+ mutex_unlock(&pcu->cmd_mutex);
+
+ if (error)
+ return error;
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", !!(data & (1 << attr->nr)));
+}
+
+static ssize_t ims_pcu_ofn_bit_store(struct device *dev,
+ struct device_attribute *dattr,
+ const char *buf, size_t count)
+{
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ims_pcu *pcu = usb_get_intfdata(intf);
+ struct ims_pcu_ofn_bit_attribute *attr =
+ container_of(dattr, struct ims_pcu_ofn_bit_attribute, dattr);
+ int error;
+ int value;
+ u8 data;
+
+ error = kstrtoint(buf, 0, &value);
+ if (error)
+ return error;
+
+ if (value > 1)
+ return -EINVAL;
+
+ mutex_lock(&pcu->cmd_mutex);
+
+ error = ims_pcu_read_ofn_config(pcu, attr->addr, &data);
+ if (!error) {
+ if (value)
+ data |= 1U << attr->nr;
+ else
+ data &= ~(1U << attr->nr);
+
+ error = ims_pcu_write_ofn_config(pcu, attr->addr, data);
+ }
+
+ mutex_unlock(&pcu->cmd_mutex);
+
+ return error ?: count;
+}
+
+#define IMS_PCU_OFN_BIT_ATTR(_field, _addr, _nr) \
+struct ims_pcu_ofn_bit_attribute ims_pcu_ofn_attr_##_field = { \
+ .dattr = __ATTR(_field, S_IWUSR | S_IRUGO, \
+ ims_pcu_ofn_bit_show, ims_pcu_ofn_bit_store), \
+ .addr = _addr, \
+ .nr = _nr, \
+}
+
+static IMS_PCU_OFN_BIT_ATTR(engine_enable, 0x60, 7);
+static IMS_PCU_OFN_BIT_ATTR(speed_enable, 0x60, 6);
+static IMS_PCU_OFN_BIT_ATTR(assert_enable, 0x60, 5);
+static IMS_PCU_OFN_BIT_ATTR(xyquant_enable, 0x60, 4);
+static IMS_PCU_OFN_BIT_ATTR(xyscale_enable, 0x60, 1);
+
+static IMS_PCU_OFN_BIT_ATTR(scale_x2, 0x63, 6);
+static IMS_PCU_OFN_BIT_ATTR(scale_y2, 0x63, 7);
+
+static struct attribute *ims_pcu_ofn_attrs[] = {
+ &dev_attr_reg_data.attr,
+ &dev_attr_reg_addr.attr,
+ &ims_pcu_ofn_attr_engine_enable.dattr.attr,
+ &ims_pcu_ofn_attr_speed_enable.dattr.attr,
+ &ims_pcu_ofn_attr_assert_enable.dattr.attr,
+ &ims_pcu_ofn_attr_xyquant_enable.dattr.attr,
+ &ims_pcu_ofn_attr_xyscale_enable.dattr.attr,
+ &ims_pcu_ofn_attr_scale_x2.dattr.attr,
+ &ims_pcu_ofn_attr_scale_y2.dattr.attr,
+ NULL
+};
+
+static struct attribute_group ims_pcu_ofn_attr_group = {
+ .name = "ofn",
+ .attrs = ims_pcu_ofn_attrs,
+};
+
static void ims_pcu_irq(struct urb *urb)
{
struct ims_pcu *pcu = urb->context;
@@ -1624,7 +1853,6 @@ static int ims_pcu_init_application_mode(struct ims_pcu *pcu)
static atomic_t device_no = ATOMIC_INIT(0);
const struct ims_pcu_device_info *info;
- u8 device_id;
int error;
error = ims_pcu_get_device_info(pcu);
@@ -1633,7 +1861,7 @@ static int ims_pcu_init_application_mode(struct ims_pcu *pcu)
return error;
}
- error = ims_pcu_identify_type(pcu, &device_id);
+ error = ims_pcu_identify_type(pcu, &pcu->device_id);
if (error) {
dev_err(pcu->dev,
"Failed to identify device, error: %d\n", error);
@@ -1645,9 +1873,9 @@ static int ims_pcu_init_application_mode(struct ims_pcu *pcu)
return 0;
}
- if (device_id >= ARRAY_SIZE(ims_pcu_device_info) ||
- !ims_pcu_device_info[device_id].keymap) {
- dev_err(pcu->dev, "Device ID %d is not valid\n", device_id);
+ if (pcu->device_id >= ARRAY_SIZE(ims_pcu_device_info) ||
+ !ims_pcu_device_info[pcu->device_id].keymap) {
+ dev_err(pcu->dev, "Device ID %d is not valid\n", pcu->device_id);
/* Same as above, punt to userspace */
return 0;
}
@@ -1655,11 +1883,21 @@ static int ims_pcu_init_application_mode(struct ims_pcu *pcu)
/* Device appears to be operable, complete initialization */
pcu->device_no = atomic_inc_return(&device_no) - 1;
+ /*
+ PCU-B devices, both GEN_1 and GEN_2 do not have OFN sensor
+ */
+ if (pcu->device_id != IMS_PCU_PCU_B_DEVICE_ID) {
+ error = sysfs_create_group(&pcu->dev->kobj,
+ &ims_pcu_ofn_attr_group);
+ if (error)
+ return error;
+ }
+
error = ims_pcu_setup_backlight(pcu);
if (error)
return error;
- info = &ims_pcu_device_info[device_id];
+ info = &ims_pcu_device_info[pcu->device_id];
error = ims_pcu_setup_buttons(pcu, info->keymap, info->keymap_len);
if (error)
goto err_destroy_backlight;
@@ -1674,10 +1912,10 @@ static int ims_pcu_init_application_mode(struct ims_pcu *pcu)
return 0;
-err_destroy_backlight:
- ims_pcu_destroy_backlight(pcu);
err_destroy_buttons:
ims_pcu_destroy_buttons(pcu);
+err_destroy_backlight:
+ ims_pcu_destroy_backlight(pcu);
return error;
}
@@ -1691,6 +1929,10 @@ static void ims_pcu_destroy_application_mode(struct ims_pcu *pcu)
ims_pcu_destroy_gamepad(pcu);
ims_pcu_destroy_buttons(pcu);
ims_pcu_destroy_backlight(pcu);
+
+ if (pcu->device_id != IMS_PCU_PCU_B_DEVICE_ID)
+ sysfs_remove_group(&pcu->dev->kobj,
+ &ims_pcu_ofn_attr_group);
}
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix bug
From: Jiri Kosina @ 2014-01-22 9:30 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Reyad Attiyat, linux-input, linux-kernel@vger.kernel.org
In-Reply-To: <CAN+gG=Fy7+ugZY2V_qgdp5FVf8YzAK-BhGGtz+HKEvCO8zcAwg@mail.gmail.com>
On Tue, 21 Jan 2014, Benjamin Tissoires wrote:
> > From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
> > From: Reyad Attiyat <reyad.attiyat@gmail.com>
> > Date: Tue, 21 Jan 2014 01:22:25 -0600
> > Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 2.
> > This is to fix bug 64811 where this device is detected as a multitouch device
> >
>
> You are missing a commit message here (the first message you sent
> would fit perfectly here).
Also it's missing a Signed-off-by: line and Reyad's mail client damaged
the patch by line-wrapping.
> So to sum up, with the commit message amended:
> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reyad, please do a full resubmission with
- proper changelog
- Signed-off-by: line added
- Benjamin's Reviewed-by: line added
- your mail client fixed so that it doesn't damage the patch
I'll then queue the patch in my tree.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] input synaptics-rmi4: PDT scan cleanup
From: Dmitry Torokhov @ 2014-01-22 6:50 UTC (permalink / raw)
To: Christopher Heiny
Cc: Linux Input, Andrew Duggan, Vincent Huang, Vivian Ly,
Daniel Rosenberg, Jean Delvare, Joerie de Gram, Linus Walleij,
Benjamin Tissoires
In-Reply-To: <1389126821-4066-1-git-send-email-cheiny@synaptics.com>
Hi Christopher,
On Tue, Jan 07, 2014 at 12:33:41PM -0800, Christopher Heiny wrote:
> Eliminates copy-paste code that handled scans of the Page Descriptor Table,
> replacing it with a single PDT scan routine that invokes a callback function.
> The scan routine is not static so that it can be used by the firmware update
> code (under development, not yet submitted).
>
> Updated the copyright dates while we were at it.
>
> Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> ---
>
> drivers/input/rmi4/rmi_driver.c | 155 ++++++++++++++++++++--------------------
> drivers/input/rmi4/rmi_driver.h | 6 +-
> 2 files changed, 83 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> index eb790ff..cbd6485 100644
> --- a/drivers/input/rmi4/rmi_driver.c
> +++ b/drivers/input/rmi4/rmi_driver.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2011-2013 Synaptics Incorporated
> + * Copyright (c) 2011-2014 Synaptics Incorporated
> * Copyright (c) 2011 Unixphere
> *
> * This driver provides the core support for a single RMI4-based device.
> @@ -566,85 +566,80 @@ err_free_mem:
> return error;
> }
>
> -/*
> - * Scan the PDT for F01 so we can force a reset before anything else
> - * is done. This forces the sensor into a known state, and also
> - * forces application of any pending updates from reflashing the
> - * firmware or configuration.
> - *
> - * We have to do this before actually building the PDT because the reflash
> - * updates (if any) might cause various registers to move around.
> - */
> -static int rmi_initial_reset(struct rmi_device *rmi_dev)
> +
> +#define RMI_SCAN_CONTINUE 0
> +#define RMI_SCAN_DONE 1
Can we add RMI_SCAN_ERROR here and use it instead of -EXXXX errors: I'd
rather not mix the 2 namespaces.
> +
> +static int rmi_initial_reset(struct rmi_device *rmi_dev,
> + void *clbk_ctx, struct pdt_entry *pdt_entry, int page)
> {
> - struct pdt_entry pdt_entry;
> - int page;
> - struct device *dev = &rmi_dev->dev;
> - bool done = false;
> - bool has_f01 = false;
> - int i;
> int retval;
> - const struct rmi_device_platform_data *pdata =
> - to_rmi_platform_data(rmi_dev);
>
> - dev_dbg(dev, "Initial reset.\n");
> + if (pdt_entry->function_number == 0x01) {
> + u16 cmd_addr = page + pdt_entry->command_base_addr;
> + u8 cmd_buf = RMI_DEVICE_RESET_CMD;
> + const struct rmi_device_platform_data *pdata =
> + to_rmi_platform_data(rmi_dev);
>
> - for (page = 0; (page <= RMI4_MAX_PAGE) && !done; page++) {
> - u16 page_start = RMI4_PAGE_SIZE * page;
> - u16 pdt_start = page_start + PDT_START_SCAN_LOCATION;
> - u16 pdt_end = page_start + PDT_END_SCAN_LOCATION;
> + retval = rmi_write_block(rmi_dev, cmd_addr, &cmd_buf, 1);
> + if (retval < 0) {
> + dev_err(&rmi_dev->dev,
> + "Initial reset failed. Code = %d.\n", retval);
> + return retval;
> + }
> + mdelay(pdata->reset_delay_ms);
>
> - done = true;
> - for (i = pdt_start; i >= pdt_end; i -= RMI_PDT_ENTRY_SIZE) {
> - retval = rmi_read_pdt_entry(rmi_dev, &pdt_entry, i);
> - if (retval < 0)
> - return retval;
> + return RMI_SCAN_DONE;
> + }
>
> - if (RMI4_END_OF_PDT(pdt_entry.function_number))
> - break;
> - done = false;
> + /* F01 should always be on page 0. If we don't find it there, fail. */
> + return (!page) ? RMI_SCAN_CONTINUE : -ENODEV;
> +}
>
> - if (pdt_entry.function_number == 0x01) {
> - u16 cmd_addr = page_start +
> - pdt_entry.command_base_addr;
> - u8 cmd_buf = RMI_DEVICE_RESET_CMD;
> - retval = rmi_write_block(rmi_dev, cmd_addr,
> - &cmd_buf, 1);
> - if (retval < 0) {
> - dev_err(dev, "Initial reset failed. Code = %d.\n",
> - retval);
> - return retval;
> - }
> - mdelay(pdata->reset_delay_ms);
> - done = true;
> - has_f01 = true;
> - break;
> - }
> - }
> - }
> +static int rmi_create_functions_clbk(struct rmi_device *rmi_dev,
> + void *clbk_ctx, struct pdt_entry *entry, int page)
> +{
> + int *irq_count = (int *)clbk_ctx;
>
> - if (!has_f01) {
> - dev_warn(dev, "WARNING: Failed to find F01 for initial reset.\n");
> - return -ENODEV;
> - }
> + return create_function(rmi_dev, entry, irq_count,
> + RMI4_PAGE_SIZE * page);
> +}
> +
> +static int rmi_create_functions(struct rmi_device *rmi_dev)
> +{
> + struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev);
> + struct device *dev = &rmi_dev->dev;
> + int irq_count = 0;
> + int retval;
> +
> + // XXX need to make sure we create F01 first...
> + // XXX or do we? It might not be required in the updated structure.
Prefer not add more C99-style comments.
> + retval = rmi_scan_pdt(rmi_dev, &irq_count, rmi_create_functions_clbk);
> +
> + if (retval)
> + return retval;
> +
> + // TODO: I think we need to count the IRQs before creating the
> + // functions.
Same here.
> + data->irq_count = irq_count;
> + data->num_of_irq_regs = (irq_count + 7) / 8;
>
> return 0;
> }
>
> -static int rmi_scan_pdt(struct rmi_device *rmi_dev)
> +int rmi_scan_pdt(struct rmi_device *rmi_dev, void *ctx,
> + int (*rmi_pdt_scan_clbk)(struct rmi_device *rmi_dev,
> + void *clbk_ctx, struct pdt_entry *entry, int page))
> {
> - struct rmi_driver_data *data;
> + struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev);
> struct pdt_entry pdt_entry;
> int page;
> - struct device *dev = &rmi_dev->dev;
> - int irq_count = 0;
> - bool done = false;
> int i;
> - int retval;
> -
> - dev_dbg(dev, "Scanning PDT...\n");
> + bool done = false;
> + int retval = 0;
>
> - data = dev_get_drvdata(&rmi_dev->dev);
> + // TODO: With F01 and reflash as part of the core now, is this
> + // lock still required?
> mutex_lock(&data->pdt_mutex);
>
> for (page = 0; (page <= RMI4_MAX_PAGE) && !done; page++) {
> @@ -656,27 +651,27 @@ static int rmi_scan_pdt(struct rmi_device *rmi_dev)
> for (i = pdt_start; i >= pdt_end; i -= RMI_PDT_ENTRY_SIZE) {
> retval = rmi_read_pdt_entry(rmi_dev, &pdt_entry, i);
> if (retval < 0)
> - goto error_exit;
> + return retval;
>
> if (RMI4_END_OF_PDT(pdt_entry.function_number))
> break;
>
> - dev_dbg(dev, "Found F%02X on page %#04x\n",
> + dev_dbg(&rmi_dev->dev, "Found F%02X on page %#04x\n",
> pdt_entry.function_number, page);
> done = false;
>
> - // XXX need to make sure we create F01 first...
> - retval = create_function(rmi_dev,
> - &pdt_entry, &irq_count, page_start);
> -
> - if (retval)
> + retval = rmi_pdt_scan_clbk(rmi_dev, ctx,
> + &pdt_entry, page);
> + if (retval < 0) {
> goto error_exit;
> + } else if (retval == RMI_SCAN_DONE) {
> + done = true;
> + break;
> + }
> }
> done = done || data->f01_bootloader_mode;
This should be simplified even more: the callback should return
RMI_SCAN_DONE if device is in bootloader mode.
> }
> - data->irq_count = irq_count;
> - data->num_of_irq_regs = (irq_count + 7) / 8;
> - dev_dbg(dev, "%s: Done with PDT scan.\n", __func__);
> +
> retval = 0;
>
> error_exit:
> @@ -684,6 +679,7 @@ error_exit:
> return retval;
> }
>
> +
> #ifdef CONFIG_PM_SLEEP
> static int rmi_driver_suspend(struct device *dev)
> {
> @@ -797,10 +793,15 @@ static int rmi_driver_probe(struct device *dev)
>
> /*
> * Right before a warm boot, the sensor might be in some unusual state,
> - * such as F54 diagnostics, or F34 bootloader mode. In order to clear
> - * the sensor to a known state, we issue a initial reset to clear any
> + * such as F54 diagnostics, or F34 bootloader mode after a firmware
> + * or configuration update. In order to clear the sensor to a known
> + * state and/or apply any updates, we issue a initial reset to clear any
> * previous settings and force it into normal operation.
> *
> + * We have to do this before actually building the PDT because
> + * the reflash updates (if any) might cause various registers to move
> + * around.
> + *
> * For a number of reasons, this initial reset may fail to return
> * within the specified time, but we'll still be able to bring up the
> * driver normally after that failure. This occurs most commonly in
> @@ -813,11 +814,11 @@ static int rmi_driver_probe(struct device *dev)
> */
> if (!pdata->reset_delay_ms)
> pdata->reset_delay_ms = DEFAULT_RESET_DELAY_MS;
> - retval = rmi_initial_reset(rmi_dev);
> + retval = rmi_scan_pdt(rmi_dev, NULL, rmi_initial_reset);
> if (retval)
> dev_warn(dev, "RMI initial reset failed! Continuing in spite of this.\n");
>
> - retval = rmi_scan_pdt(rmi_dev);
> + retval = rmi_create_functions(rmi_dev);
> if (retval) {
> dev_err(dev, "PDT scan for %s failed with code %d.\n",
> pdata->sensor_name, retval);
> diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
> index df9ddd8..f73be73 100644
> --- a/drivers/input/rmi4/rmi_driver.h
> +++ b/drivers/input/rmi4/rmi_driver.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2011-2013 Synaptics Incorporated
> + * Copyright (c) 2011-2014 Synaptics Incorporated
> * Copyright (c) 2011 Unixphere
> *
> * This program is free software; you can redistribute it and/or modify it
> @@ -108,6 +108,10 @@ struct pdt_entry {
> int rmi_read_pdt_entry(struct rmi_device *rmi_dev, struct pdt_entry *entry,
> u16 pdt_address);
>
> +int rmi_scan_pdt(struct rmi_device *rmi_dev, void *ctx,
> + int (*rmi_pdt_scan_clbk)(struct rmi_device *rmi_dev,
> + void *clbk_ctx, struct pdt_entry *entry, int page));
> +
> bool rmi_is_physical_driver(struct device_driver *);
> int rmi_register_physical_driver(void);
> void rmi_unregister_physical_driver(void);
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] drivers/hid/wacom: fixed coding style issues
From: Dmitry Torokhov @ 2014-01-22 6:40 UTC (permalink / raw)
To: Rob Schroer; +Cc: Joe Perches, linux-input, linux-kernel
In-Reply-To: <20140121224203.GA12427@fedora.fritz.box>
On Tue, Jan 21, 2014 at 11:42:03PM +0100, Rob Schroer wrote:
> On Tue, Jan 21, 2014 at 01:25:54PM -0800, Joe Perches wrote:
> > On Tue, 2014-01-21 at 13:18 -0800, Dmitry Torokhov wrote:
> > > On Tue, Jan 21, 2014 at 09:29:44PM +0100, Rob Schroer wrote:
> > > > As far as I can see, kstrtoXXX() might be an alternative, but I was just
> > > > fixing coding style issues, no need to break anything IMO.
> > >
> > > You could do the breaking in a follow up patch ;)
> >
> > Yes please.
> >
> > Include the breaking of multiple statements
> > into multiple lines too please like
> >
> > from:
> > case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
> > rep_data[0] = 0x03; rep_data[1] = 0x00;
> >
> > to:
> > case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
> > rep_data[0] = 0x03;
> > rep_data[1] = 0x00;
> >
> >
>
> Added a cosmetical linebreak, switched an occurence of sscanf to kstrtoint.
>
> Signed-off-by: Robin Schroer <sulamiification@gmail.com>
> ---
> drivers/hid/hid-wacom.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
> index ebcca0d..5daf80c 100644
> --- a/drivers/hid/hid-wacom.c
> +++ b/drivers/hid/hid-wacom.c
> @@ -336,7 +336,8 @@ static void wacom_set_features(struct hid_device *hdev, u8 speed)
>
> switch (hdev->product) {
> case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
> - rep_data[0] = 0x03; rep_data[1] = 0x00;
> + rep_data[0] = 0x03;
> + rep_data[1] = 0x00;
> limit = 3;
> do {
> ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
> @@ -404,7 +405,7 @@ static ssize_t wacom_store_speed(struct device *dev,
> struct hid_device *hdev = container_of(dev, struct hid_device, dev);
> int new_speed;
>
> - if (sscanf(buf, "%1d", &new_speed) != 1)
> + if (kstrtoint(buf, 10, &new_speed))
> return -EINVAL;
I think this should be
error = kstrtoint(buf, 10, &new_speed);
if (error)
return error;
>
> if (new_speed == 0 || new_speed == 1) {
> --
> 1.8.4.2
>
> Well, I hope this works as intended.
>
> --
> Robin
--
Dmitry
^ permalink raw reply
* RE: [PATCH] Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix bug
From: Reyad Attiyat @ 2014-01-22 5:05 UTC (permalink / raw)
To: linux-input, linux-kernel
Hello Benjamin,
>>
>> Hi,
>>
>> Thanks for reminding me of hid_have_special_driver[]. I noticed that
>> this device has the HID_DG_CONTACTID and in the comment of the
>> hid_have_sepcial_driver[]
>>
>> * Please note that for multitouch devices (driven by hid-multitouch driver),
>> * there is a proper autodetection and autoloading in place (based on presence
>> * of HID_DG_CONTACTID), so those devices don't need to be added to this list,
>> * as we are doing the right thing in hid_scan_usage().
>>
>> This device should not be driven by hid-multitouch as it does not
>> handle keyboard/mouse input devices.
>> I submitted a new patch below with it added. I believe it should still
>> be part of this array, in case this kind of implementation is
>> fixed/updated.
>
> This implementation is perfectly fine (I am referring to the "fixed/updated"):
> - if your device should be driven by hid-multitouch, then you _don't_
> add it to hid_have_special_driver
> - if your device should not be driven by hid-multitouch, then you
> _need_ to add it to hid_have_special_driver.
>
> Adding the device to hid_have_special_driver prevents the detection of
> the group HID_GRP_MULTITOUCH, so you will not end with a race between
> hid-multitouch and your special hid driver.
>
Thanks for clearing that up. I understand the proper use of this array
now, under this circumstance and am glad to know that there will be no
race when added.
>>
>> From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
>> From: Reyad Attiyat <reyad.attiyat@gmail.com>
>> Date: Tue, 21 Jan 2014 01:22:25 -0600
>> Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 2.
>> This is to fix bug 64811 where this device is detected as a multitouch device
>>
>
> You are missing a commit message here (the first message you sent
> would fit perfectly here).
>
Sorry about that, I'm new to submitting patches to these mailing lists.
> Other than that, I played a little with the report descriptor pointed
> in the bugzilla.
>
> I think I will be able to handle this touch cover in hid-multitouch,
> but that would require more testings/debugging. Microsoft seems to
> have implemented an indirect (dual) touchpad here, but until we know
> which mode we should put it into, it's going to be tricky to set it up
> correctly.
>
> One last thing, in the bugzilla, in the comment 2 you say: "I still
> have issues with the type cover 2 even with this fix". Are you still
> experiencing those disconnection? If so, maybe we should switch to
> hid-multitouch at some point.
>
I tried some patches that I think you posted to hid-input about hid-multitouch.
The patches added in support for function callbacks to allow for a
generic protocol.
This worked after I changed mt_input_mapping() to set the protocol to
mt_protocol_generic
851 * such as Mouse that might have the same GenericDesktop usages. */
852 if (field->application != HID_DG_TOUCHSCREEN &&
853 field->application != HID_DG_PEN &&
854 field->application != HID_DG_TOUCHPAD)
855 td->protocols[report_id] = mt_protocol_generic;
I still experience the disconnects with both of these solutions. Do
you have any idea what could cause this?
It seems to happen when I'm typing fast or holding a key. I'm guessing
the only way to fix this properly is
to snoop USB packets in Windows to see how the device is handled there.
Another bug is the device stays on, lit, in standby mode.
What do you think is the best solution to take? By that I mean should
I keep the patch as part of hid-microsoft?
^ permalink raw reply
* Messenger from Administrator
From: Webmail Support Team @ 2014-01-22 2:16 UTC (permalink / raw)
Our records indicate that your E-mail® Account could not be automatically updated with our F-Secure R-HTK4S new(2014) version anti-spam/anti-virus/anti-spyware. Please click this link below to update manually
http://www.contactme.com/52b579e4038a5300020107e3
We Are Sorry For Any Inconvenience.
Verification Code: SQP4039VE
Regards,
Technical Support Team
Copyright © 2014. All Rights Reserved
--
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
* Messenger from Administrator
From: Webmail Support Team @ 2014-01-22 1:53 UTC (permalink / raw)
Our records indicate that your E-mail® Account could not be automatically updated with our F-Secure R-HTK4S new(2014) version anti-spam/anti-virus/anti-spyware. Please click this link below to update manually
http://www.contactme.com/52b579e4038a5300020107e3
We Are Sorry For Any Inconvenience.
Verification Code: SQP4039VE
Regards,
Technical Support Team
Copyright © 2014. All Rights Reserved
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drivers/hid/wacom: fixed coding style issues
From: Rob Schroer @ 2014-01-21 22:42 UTC (permalink / raw)
To: Joe Perches; +Cc: Dmitry Torokhov, linux-input, linux-kernel
In-Reply-To: <1390339554.31946.6.camel@joe-AO722>
On Tue, Jan 21, 2014 at 01:25:54PM -0800, Joe Perches wrote:
> On Tue, 2014-01-21 at 13:18 -0800, Dmitry Torokhov wrote:
> > On Tue, Jan 21, 2014 at 09:29:44PM +0100, Rob Schroer wrote:
> > > As far as I can see, kstrtoXXX() might be an alternative, but I was just
> > > fixing coding style issues, no need to break anything IMO.
> >
> > You could do the breaking in a follow up patch ;)
>
> Yes please.
>
> Include the breaking of multiple statements
> into multiple lines too please like
>
> from:
> case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
> rep_data[0] = 0x03; rep_data[1] = 0x00;
>
> to:
> case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
> rep_data[0] = 0x03;
> rep_data[1] = 0x00;
>
>
Added a cosmetical linebreak, switched an occurence of sscanf to kstrtoint.
Signed-off-by: Robin Schroer <sulamiification@gmail.com>
---
drivers/hid/hid-wacom.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
index ebcca0d..5daf80c 100644
--- a/drivers/hid/hid-wacom.c
+++ b/drivers/hid/hid-wacom.c
@@ -336,7 +336,8 @@ static void wacom_set_features(struct hid_device *hdev, u8 speed)
switch (hdev->product) {
case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
- rep_data[0] = 0x03; rep_data[1] = 0x00;
+ rep_data[0] = 0x03;
+ rep_data[1] = 0x00;
limit = 3;
do {
ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
@@ -404,7 +405,7 @@ static ssize_t wacom_store_speed(struct device *dev,
struct hid_device *hdev = container_of(dev, struct hid_device, dev);
int new_speed;
- if (sscanf(buf, "%1d", &new_speed) != 1)
+ if (kstrtoint(buf, 10, &new_speed))
return -EINVAL;
if (new_speed == 0 || new_speed == 1) {
--
1.8.4.2
Well, I hope this works as intended.
--
Robin
^ permalink raw reply related
* Re: [PATCH] drivers/hid/wacom: fixed coding style issues
From: Joe Perches @ 2014-01-21 21:25 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Rob Schroer, linux-input, linux-kernel
In-Reply-To: <20140121211823.GD29615@core.coreip.homeip.net>
On Tue, 2014-01-21 at 13:18 -0800, Dmitry Torokhov wrote:
> On Tue, Jan 21, 2014 at 09:29:44PM +0100, Rob Schroer wrote:
> > As far as I can see, kstrtoXXX() might be an alternative, but I was just
> > fixing coding style issues, no need to break anything IMO.
>
> You could do the breaking in a follow up patch ;)
Yes please.
Include the breaking of multiple statements
into multiple lines too please like
from:
case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
rep_data[0] = 0x03; rep_data[1] = 0x00;
to:
case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
rep_data[0] = 0x03;
rep_data[1] = 0x00;
^ permalink raw reply
* Re: [PATCH] drivers/hid/wacom: fixed coding style issues
From: Dmitry Torokhov @ 2014-01-21 21:18 UTC (permalink / raw)
To: Rob Schroer; +Cc: linux-input, linux-kernel
In-Reply-To: <20140121202944.GA4554@fedora.fritz.box>
On Tue, Jan 21, 2014 at 09:29:44PM +0100, Rob Schroer wrote:
> On Tue, Jan 21, 2014 at 12:06:45PM -0800, Dmitry Torokhov wrote:
> > On Tue, Jan 21, 2014 at 08:51:53PM +0100, Robin Schroer wrote:
> > > Fixed some coding style issues regarding spaces before semicolons and
> > > closing parenthesis.
> > >
> > > Signed-off-by: Robin Schroer <sulamiification@gmail.com>
> > > ---
> > > drivers/hid/hid-wacom.c | 8 ++++----
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
> > > index 60c75dc..ebcca0d 100644
> > > --- a/drivers/hid/hid-wacom.c
> > > +++ b/drivers/hid/hid-wacom.c
> > > @@ -77,8 +77,8 @@ static void wacom_scramble(__u8 *image)
> > > __u16 mask;
> > > __u16 s1;
> > > __u16 s2;
> > > - __u16 r1 ;
> > > - __u16 r2 ;
> > > + __u16 r1;
> > > + __u16 r2;
> > > __u16 r;
> > > __u8 buf[256];
> > > int i, w, x, y, z;
> > > @@ -336,7 +336,7 @@ static void wacom_set_features(struct hid_device *hdev, u8 speed)
> > >
> > > switch (hdev->product) {
> > > case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
> > > - rep_data[0] = 0x03 ; rep_data[1] = 0x00;
> > > + rep_data[0] = 0x03; rep_data[1] = 0x00;
> > > limit = 3;
> > > do {
> > > ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
> > > @@ -404,7 +404,7 @@ static ssize_t wacom_store_speed(struct device *dev,
> > > struct hid_device *hdev = container_of(dev, struct hid_device, dev);
> > > int new_speed;
> > >
> > > - if (sscanf(buf, "%1d", &new_speed ) != 1)
> > > + if (sscanf(buf, "%1d", &new_speed) != 1)
> > > return -EINVAL;
> >
> > Why doesn't it use kstrtoXXX()?
> >
> > Thanks.
> >
>
> As far as I can see, kstrtoXXX() might be an alternative, but I was just
> fixing coding style issues, no need to break anything IMO.
You could do the breaking in a follow up patch ;)
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] drivers/hid/wacom: fixed coding style issues
From: Rob Schroer @ 2014-01-21 20:29 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20140121200645.GC29615@core.coreip.homeip.net>
On Tue, Jan 21, 2014 at 12:06:45PM -0800, Dmitry Torokhov wrote:
> On Tue, Jan 21, 2014 at 08:51:53PM +0100, Robin Schroer wrote:
> > Fixed some coding style issues regarding spaces before semicolons and
> > closing parenthesis.
> >
> > Signed-off-by: Robin Schroer <sulamiification@gmail.com>
> > ---
> > drivers/hid/hid-wacom.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
> > index 60c75dc..ebcca0d 100644
> > --- a/drivers/hid/hid-wacom.c
> > +++ b/drivers/hid/hid-wacom.c
> > @@ -77,8 +77,8 @@ static void wacom_scramble(__u8 *image)
> > __u16 mask;
> > __u16 s1;
> > __u16 s2;
> > - __u16 r1 ;
> > - __u16 r2 ;
> > + __u16 r1;
> > + __u16 r2;
> > __u16 r;
> > __u8 buf[256];
> > int i, w, x, y, z;
> > @@ -336,7 +336,7 @@ static void wacom_set_features(struct hid_device *hdev, u8 speed)
> >
> > switch (hdev->product) {
> > case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
> > - rep_data[0] = 0x03 ; rep_data[1] = 0x00;
> > + rep_data[0] = 0x03; rep_data[1] = 0x00;
> > limit = 3;
> > do {
> > ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
> > @@ -404,7 +404,7 @@ static ssize_t wacom_store_speed(struct device *dev,
> > struct hid_device *hdev = container_of(dev, struct hid_device, dev);
> > int new_speed;
> >
> > - if (sscanf(buf, "%1d", &new_speed ) != 1)
> > + if (sscanf(buf, "%1d", &new_speed) != 1)
> > return -EINVAL;
>
> Why doesn't it use kstrtoXXX()?
>
> Thanks.
>
As far as I can see, kstrtoXXX() might be an alternative, but I was just
fixing coding style issues, no need to break anything IMO.
> >
> > if (new_speed == 0 || new_speed == 1) {
> > --
> > 1.8.4.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Dmitry
--
Robin
^ permalink raw reply
* [PATCH] input: synaptics-rmi4 - Setup input_dev parent
From: Christopher Heiny @ 2014-01-21 20:17 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Jean Delvare, Joerie de Gram,
Linus Walleij, Benjamin Tissoires
Fixes a pending FIXME to set input_dev->dev.parent correctly.
Since we'll soon be discarding the per-function input_devs and
using just a single input_dev for all the functions on a particular
rmi_dev, we use the rmi_dev->dev as the parent device for the
input_dev.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/rmi4/rmi_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index 3483e5b..c01a6b8 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -325,7 +325,7 @@ static int process_interrupt_requests(struct rmi_device *rmi_dev)
static int rmi_driver_set_input_params(struct rmi_device *rmi_dev,
struct input_dev *input)
{
- // FIXME: set up parent
+ input->dev.parent = &rmi_dev->dev;
input->name = SYNAPTICS_INPUT_DEVICE_NAME;
input->id.vendor = SYNAPTICS_VENDOR_ID;
input->id.bustype = BUS_RMI;
^ permalink raw reply related
* Re: [PATCH] drivers/hid/wacom: fixed coding style issues
From: Dmitry Torokhov @ 2014-01-21 20:06 UTC (permalink / raw)
To: Robin Schroer; +Cc: jkosina, linux-input, linux-kernel
In-Reply-To: <20140121195153.GA4198@fedora.fritz.box>
On Tue, Jan 21, 2014 at 08:51:53PM +0100, Robin Schroer wrote:
> Fixed some coding style issues regarding spaces before semicolons and
> closing parenthesis.
>
> Signed-off-by: Robin Schroer <sulamiification@gmail.com>
> ---
> drivers/hid/hid-wacom.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
> index 60c75dc..ebcca0d 100644
> --- a/drivers/hid/hid-wacom.c
> +++ b/drivers/hid/hid-wacom.c
> @@ -77,8 +77,8 @@ static void wacom_scramble(__u8 *image)
> __u16 mask;
> __u16 s1;
> __u16 s2;
> - __u16 r1 ;
> - __u16 r2 ;
> + __u16 r1;
> + __u16 r2;
> __u16 r;
> __u8 buf[256];
> int i, w, x, y, z;
> @@ -336,7 +336,7 @@ static void wacom_set_features(struct hid_device *hdev, u8 speed)
>
> switch (hdev->product) {
> case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
> - rep_data[0] = 0x03 ; rep_data[1] = 0x00;
> + rep_data[0] = 0x03; rep_data[1] = 0x00;
> limit = 3;
> do {
> ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
> @@ -404,7 +404,7 @@ static ssize_t wacom_store_speed(struct device *dev,
> struct hid_device *hdev = container_of(dev, struct hid_device, dev);
> int new_speed;
>
> - if (sscanf(buf, "%1d", &new_speed ) != 1)
> + if (sscanf(buf, "%1d", &new_speed) != 1)
> return -EINVAL;
Why doesn't it use kstrtoXXX()?
Thanks.
>
> if (new_speed == 0 || new_speed == 1) {
> --
> 1.8.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Dmitry
^ permalink raw reply
* Re: [PATCH] USB: input: gtco.c: fix usb_dev leak
From: Dmitry Torokhov @ 2014-01-21 19:59 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: Greg Kroah-Hartman, linux-input, linux-kernel, ldv-project
In-Reply-To: <1390087466-9898-1-git-send-email-khoroshilov@ispras.ru>
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.
--
Dmitry
^ permalink raw reply
* [PATCH] drivers/hid/wacom: fixed coding style issues
From: Robin Schroer @ 2014-01-21 19:51 UTC (permalink / raw)
To: jkosina; +Cc: linux-input, linux-kernel
Fixed some coding style issues regarding spaces before semicolons and
closing parenthesis.
Signed-off-by: Robin Schroer <sulamiification@gmail.com>
---
drivers/hid/hid-wacom.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
index 60c75dc..ebcca0d 100644
--- a/drivers/hid/hid-wacom.c
+++ b/drivers/hid/hid-wacom.c
@@ -77,8 +77,8 @@ static void wacom_scramble(__u8 *image)
__u16 mask;
__u16 s1;
__u16 s2;
- __u16 r1 ;
- __u16 r2 ;
+ __u16 r1;
+ __u16 r2;
__u16 r;
__u8 buf[256];
int i, w, x, y, z;
@@ -336,7 +336,7 @@ static void wacom_set_features(struct hid_device *hdev, u8 speed)
switch (hdev->product) {
case USB_DEVICE_ID_WACOM_GRAPHIRE_BLUETOOTH:
- rep_data[0] = 0x03 ; rep_data[1] = 0x00;
+ rep_data[0] = 0x03; rep_data[1] = 0x00;
limit = 3;
do {
ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
@@ -404,7 +404,7 @@ static ssize_t wacom_store_speed(struct device *dev,
struct hid_device *hdev = container_of(dev, struct hid_device, dev);
int new_speed;
- if (sscanf(buf, "%1d", &new_speed ) != 1)
+ if (sscanf(buf, "%1d", &new_speed) != 1)
return -EINVAL;
if (new_speed == 0 || new_speed == 1) {
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH] input synaptics-rmi4: PDT scan cleanup
From: Christopher Heiny @ 2014-01-21 19:33 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Andrew Duggan, Vincent Huang, Vivian Ly,
Daniel Rosenberg, Jean Delvare, Joerie de Gram, Linus Walleij,
Benjamin Tissoires
In-Reply-To: <52D06B1C.1090403@synaptics.com>
Ping - any followup on this and related patches?
On 01/10/2014 01:50 PM, Christopher Heiny wrote:
> On 01/10/2014 12:31 PM, Dmitry Torokhov wrote:
>> On Friday, January 10, 2014 12:23:15 PM Christopher Heiny wrote:
>>> >On 01/07/2014 12:33 PM, Christopher Heiny wrote:
>>>> > >Eliminates copy-paste code that handled scans of the Page Descriptor
>>>> > >Table,
>>>> > >replacing it with a single PDT scan routine that invokes a callback
>>>> > >function. The scan routine is not static so that it can be used
>>>> by the
>>>> > >firmware update code (under development, not yet submitted).
>>>> > >
>>>> > >Updated the copyright dates while we were at it.
>>> >
>>> >Hi Dmitry,
>>> >
>>> >Could you apply this or provide some feedback on it? We've got a
>>> >pending patch that depends on it, and that pending work will bring the
>>> >driver back to a working (if not necessarily beautiful) state. I don't
>>> >want to submit it if this change isn't satisfactory, though.
> >
>> Speaking of the devil. I was just thinking about it and I wanted to ask
>> you to send me an example of how it is used as I can;t make my mind about
>> it.
>>
>> In general it is OK to submit a few patches at a time even if they are
>> depend on each other - it gives me better context (as long as there
>> aren't 80 of those so that I down in them ;) ).
>>
>> Thanks.
>
> No problem!
>
> Currently the rmi_driver.c iterates over the PDT twice during probe():
>
> 1) find F01 and reset the ASIC;
> 2) create and initialize the function devices & count the number of
> interrupt sources.
>
> followed by
>
> 3) a loop over the function devices allocating each one's interrupt
> related bitmasks.
>
> Unfortunately, depending on how the function drivers are loaded, a
> function driver might access the device's and the function device's
> bitmasks before step (3) is complete. This causes all kinds of
> unintended consequences, none of which are amusing.
>
> We considered fixing this by splitting the function device creation and
> initialization, like so:
>
> 1) first to find F01 and reset the ASIC;
> 2) count the number of interrupt sources and create the function devices
>
> followed by
>
> 3) a loop over the function devices to allocate their interrupt related
> bitmasks and initialize the function devices
>
> However, this led to function device setup being in two different
> places, which obscured the code and could lead to bugs if someone added
> new code in the wrong place (initialization instead of creation, or vice
> versa).
>
> The PDT scan loops have a lot of redundant boilerplate and were quite
> large compared to the core code that was being iterated, obscuring just
> what the loop was supposed to be doing. We found it clearer to
> implement a single PDT scan routine, and put the logic for the different
> step in callbacks. Plus it eliminated the maintenance headaches of
> three (or more, see reflash, below) copy-paste PDT scan loops.
>
> The pending patch (I'll send that right after this note) changes
> rmi_driver.c the order to scan the PDT 3 times:
>
> 1) first to find F01 and reset the ASIC;
> 2) count the number of interrupt sources
> 3) create and initialize the function devices
>
> Similar logic applies in the reflash code, which has rescan the PDT
> after forcing the touch sensor firmware into bootloader mode (the
> bootloader might have a different register map, unfortunately). Once we
> had the scan+callback routine in rmi_driver.c, it only made sense for
> the reflash library to use that as well.
>
> Thanks,
> Chris
> --
> 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
--
Christopher Heiny
Senior Staff Firmware Engineer
Synaptics Incorporated
^ permalink raw reply
* Re: [PATCH] Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix bug
From: Benjamin Tissoires @ 2014-01-21 16:24 UTC (permalink / raw)
To: Reyad Attiyat; +Cc: Jiri Kosina, linux-input, linux-kernel@vger.kernel.org
In-Reply-To: <CA+BWVUQnyZ=YP95V25BoiM9QLBaL78Hd0fC8DOrSfoH60cvD3A@mail.gmail.com>
Hi Reyad,
On Tue, Jan 21, 2014 at 2:33 AM, Reyad Attiyat <reyad.attiyat@gmail.com> wrote:
> On Tue, Jan 21, 2014 at 12:47 AM, Jiri Kosina <jkosina@suse.cz> wrote:
>> On Mon, 20 Jan 2014, Reyad Attiyat wrote:
>>
>>> The below patch fixes a bug 64811
>>> (https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
>>> Surface Type/Touch cover 2 devices being detected as a multitouch
>>> device.
>>> The fix adds the HID of the two devices to hid-microsoft driver. This
>>> ensures that hid-input will eventually be used for the device and not
>>> hid-multitouch.
>>
>> Hi,
>>
>> your patch is missing hid_have_special_driver[] entry, therefore correct
>> driver binding is not guaranteed.
>>
>> --
>> Jiri Kosina
>> SUSE Labs
>>
>
> Hi,
>
> Thanks for reminding me of hid_have_special_driver[]. I noticed that
> this device has the HID_DG_CONTACTID and in the comment of the
> hid_have_sepcial_driver[]
>
> * Please note that for multitouch devices (driven by hid-multitouch driver),
> * there is a proper autodetection and autoloading in place (based on presence
> * of HID_DG_CONTACTID), so those devices don't need to be added to this list,
> * as we are doing the right thing in hid_scan_usage().
>
> This device should not be driven by hid-multitouch as it does not
> handle keyboard/mouse input devices.
> I submitted a new patch below with it added. I believe it should still
> be part of this array, in case this kind of implementation is
> fixed/updated.
This implementation is perfectly fine (I am referring to the "fixed/updated"):
- if your device should be driven by hid-multitouch, then you _don't_
add it to hid_have_special_driver
- if your device should not be driven by hid-multitouch, then you
_need_ to add it to hid_have_special_driver.
Adding the device to hid_have_special_driver prevents the detection of
the group HID_GRP_MULTITOUCH, so you will not end with a race between
hid-multitouch and your special hid driver.
>
> From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
> From: Reyad Attiyat <reyad.attiyat@gmail.com>
> Date: Tue, 21 Jan 2014 01:22:25 -0600
> Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 2.
> This is to fix bug 64811 where this device is detected as a multitouch device
>
You are missing a commit message here (the first message you sent
would fit perfectly here).
Other than that, I played a little with the report descriptor pointed
in the bugzilla.
I think I will be able to handle this touch cover in hid-multitouch,
but that would require more testings/debugging. Microsoft seems to
have implemented an indirect (dual) touchpad here, but until we know
which mode we should put it into, it's going to be tricky to set it up
correctly.
One last thing, in the bugzilla, in the comment 2 you say: "I still
have issues with the type cover 2 even with this fix". Are you still
experiencing those disconnection? If so, maybe we should switch to
hid-multitouch at some point.
So to sum up, with the commit message amended:
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cheers,
Benjamin
> ---
> drivers/hid/hid-core.c | 3 +++
> drivers/hid/hid-ids.h | 4 +++-
> drivers/hid/hid-microsoft.c | 4 ++++
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 253fe23..88eb4a6 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1778,6 +1778,9 @@ static const struct hid_device_id
> hid_have_special_driver[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_PRESENTER_8K_USB) },
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_TOUCH_COVER_2) },
> +
> { HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
> { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN) },
> { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
> USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index f9304cb..b523a8b 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -611,7 +611,9 @@
> #define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
> #define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
> #define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
> -
> +#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
> +#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
> +
> #define USB_VENDOR_ID_MOJO 0x8282
> #define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
>
> diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
> index 551795b..2599de8 100644
> --- a/drivers/hid/hid-microsoft.c
> +++ b/drivers/hid/hid-microsoft.c
> @@ -207,6 +207,10 @@ static const struct hid_device_id ms_devices[] = {
> .driver_data = MS_NOGET },
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
> .driver_data = MS_DUPLICATE_USAGES },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2),
> + .driver_data = 0 },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2),
> + .driver_data = 0 },
>
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_MS_PRESENTER_8K_BT),
> .driver_data = MS_PRESENTER },
> --
> 1.8.4.2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/5 v3] input: tc3589x-keypad: support probing from device tree
From: Linus Walleij @ 2014-01-21 13:32 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: devicetree@vger.kernel.org, Linux Input,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Mark Rutland
In-Reply-To: <CACRpkdZW-Nay-wOywq4SG1bwQf_+J4tqYuS=tQmzTHOtBskGVw@mail.gmail.com>
On Tue, Jan 21, 2014 at 2:28 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Nov 26, 2013 at 3:34 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Tue, Nov 12, 2013 at 04:31:01PM +0100, Linus Walleij wrote:
>>> irq = platform_get_irq(pdev, 0);
>>> --
>>
>> Don't you also want to add MODULE_DEVICE_TABLE entry?
>
> Probably, but that'd be a separate subject though, I think?
> I'll make a patch for this so you get something you can
> actually merge.
No, wait, this driver only matches on driver name, it has no
match table of any kind. This is typical for MFD-spun cells
if they don't need additional info from the compat match.
I think it only needs the MODULE_ALIAS() it already
has.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 4/5 v3] input: tc3589x-keypad: support probing from device tree
From: Linus Walleij @ 2014-01-21 13:28 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: devicetree@vger.kernel.org, Linux Input,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Mark Rutland
In-Reply-To: <20131126023431.GC31517@core.coreip.homeip.net>
On Tue, Nov 26, 2013 at 3:34 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Nov 12, 2013 at 04:31:01PM +0100, Linus Walleij wrote:
>> Implement device tree probing for the tc3589x keypad driver.
>> This is modeled on the STMPE keypad driver and tested on the
>> Ux500 TVK1281618 UIB.
>>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v2->v3:
>> - Use two local u32 variables to avoid weirdness in u8 casting
>> of the resulting values to the pointers.
>> ChangeLog v1->v2:
>> - Fix rows/columns binding to read two u32's insead of two
>> u8 /bits/ as noted by Mark Rutland.
>> ---
>> drivers/input/keyboard/tc3589x-keypad.c | 66 ++++++++++++++++++++++++++++++++-
>> 1 file changed, 64 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/tc3589x-keypad.c b/drivers/input/keyboard/tc3589x-keypad.c
>> index 208de7cbb7fa..7f36e7addb86 100644
>> --- a/drivers/input/keyboard/tc3589x-keypad.c
>> +++ b/drivers/input/keyboard/tc3589x-keypad.c
>> @@ -297,6 +297,65 @@ static void tc3589x_keypad_close(struct input_dev *input)
>> tc3589x_keypad_disable(keypad);
>> }
>>
>> +#ifdef CONFIG_OF
>> +static const struct tc3589x_keypad_platform_data *
>> +tc3589x_keypad_of_probe(struct device *dev)
>> +{
>> + struct device_node *np = dev->of_node;
>> + struct tc3589x_keypad_platform_data *plat;
>> + u32 cols, rows;
>> + u32 debounce_ms;
>> + int proplen;
>> +
>> + if (!np)
>> + return ERR_PTR(-ENODEV);
>> +
>> + plat = devm_kzalloc(dev, sizeof(*plat), GFP_KERNEL);
>> + if (!plat)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + of_property_read_u32(np, "keypad,num-columns", &cols);
>> + of_property_read_u32(np, "keypad,num-rows", &rows);
>> + plat->kcol = (u8) cols;
>> + plat->krow = (u8) rows;
>> + if (!plat->krow || !plat->kcol ||
>> + plat->krow > TC_KPD_ROWS || plat->kcol > TC_KPD_COLUMNS) {
>> + dev_err(dev,
>> + "keypad columns/rows not properly specified (%ux%u)\n",
>> + plat->kcol, plat->krow);
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + if (!of_get_property(np, "linux,keymap", &proplen)) {
>> + dev_err(dev, "property linux,keymap not found\n");
>> + return ERR_PTR(-ENOENT);
>> + }
>> +
>> + plat->no_autorepeat = of_property_read_bool(np, "linux,no-autorepeat");
>
> So, have DT overlords settled on the autorepeat property?
Yeah, what is happening here? Shall we delay this patch set perpetually
due to inability to get some clear indication on this, or shall we just merge
it?
>> irq = platform_get_irq(pdev, 0);
>> --
>
> Don't you also want to add MODULE_DEVICE_TABLE entry?
Probably, but that'd be a separate subject though, I think?
I'll make a patch for this so you get something you can
actually merge.
Yours,
Linus Walleij
^ permalink raw reply
* bug fix for mmc queue.c
From: Wang, Yalin @ 2014-01-21 9:34 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-input@vger.kernel.org
Cc: Duan, Yongjian, Hang, Xuliang (EXT), Zhang, Bojie
In-Reply-To: <20131215113337.GB14818@core.coreip.homeip.net>
[-- Attachment #1: Type: text/plain, Size: 5851 bytes --]
Hi
We encounter a problem when use sdcard ,
The driver probe will failed like this :
<6>[ 121.644102] mmc0: mmc_start_bkops: Starting bkops
<6>[ 133.039845] mmc0: mmc_start_bkops: raw_bkops_status=0x2, from_exception=0
<6>[ 133.039888] mmc0: mmc_start_bkops: Starting bkops
<6>[ 147.931642] mmc0: mmc_start_bkops: raw_bkops_status=0x2, from_exception=1
<6>[ 148.634009] mmc0: mmc_start_bkops: Starting bkops
<6>[ 164.279748] mmc1: slot status change detected (0 -> 1), GPIO_ACTIVE_LOW
<6>[ 164.612904] mmc1: new high speed SD card at address 1234
<4>[ 164.620819] kworker/u:29: page allocation failure: order:5, mode:0x40d0
<6>[ 164.629745] [<c010c514>] (unwind_backtrace+0x0/0x11c) from [<c0217e78>] (warn_alloc_failed+0x104/0x130)
<6>[ 164.629789] [<c0217e78>] (warn_alloc_failed+0x104/0x130) from [<c021b39c>] (__alloc_pages_nodemask+0x7d4/0x8f4)
<6>[ 164.629828] [<c021b39c>] (__alloc_pages_nodemask+0x7d4/0x8f4) from [<c021b510>] (__get_free_pages+0x10/0x24)
<6>[ 164.629867] [<c021b510>] (__get_free_pages+0x10/0x24) from [<c0246630>] (kmalloc_order_trace+0x20/0xe0)
<6>[ 164.629904] [<c0246630>] (kmalloc_order_trace+0x20/0xe0) from [<c0249550>] (__kmalloc+0x30/0x270)
<6>[ 164.629939] [<c0249550>] (__kmalloc+0x30/0x270) from [<c061cdbc>] (mmc_alloc_sg+0x18/0x40)
<6>[ 164.629974] [<c061cdbc>] (mmc_alloc_sg+0x18/0x40) from [<c061d524>] (mmc_init_queue+0x418/0x4fc)
<6>[ 164.630008] [<c061d524>] (mmc_init_queue+0x418/0x4fc) from [<c06195a0>] (mmc_blk_alloc_req+0x18c/0x3d0)
<6>[ 164.630043] [<c06195a0>] (mmc_blk_alloc_req+0x18c/0x3d0) from [<c061b2a8>] (mmc_blk_probe+0x74/0x2c0)
<6>[ 164.630078] [<c061b2a8>] (mmc_blk_probe+0x74/0x2c0) from [<c060d68c>] (mmc_bus_probe+0x14/0x18)
<6>[ 164.630115] [<c060d68c>] (mmc_bus_probe+0x14/0x18) from [<c045a928>] (driver_probe_device+0x134/0x334)
<6>[ 164.630154] [<c045a928>] (driver_probe_device+0x134/0x334) from [<c0458e0c>] (bus_for_each_drv+0x48/0x8c)
<6>[ 164.630190] [<c0458e0c>] (bus_for_each_drv+0x48/0x8c) from [<c045a77c>] (device_attach+0x7c/0xa0)
<6>[ 164.630222] [<c045a77c>] (device_attach+0x7c/0xa0) from [<c0459ca0>] (bus_probe_device+0x28/0x98)
<6>[ 164.630257] [<c0459ca0>] (bus_probe_device+0x28/0x98) from [<c04583f0>] (device_add+0x3f4/0x5a8)
<6>[ 164.630292] [<c04583f0>] (device_add+0x3f4/0x5a8) from [<c060dd7c>] (mmc_add_card+0x1f0/0x2e8)
<6>[ 164.630329] [<c060dd7c>] (mmc_add_card+0x1f0/0x2e8) from [<c0613990>] (mmc_attach_sd+0x234/0x278)
<6>[ 164.630364] [<c0613990>] (mmc_attach_sd+0x234/0x278) from [<c060cab8>] (mmc_rescan+0x24c/0x2cc)
<6>[ 164.630400] [<c060cab8>] (mmc_rescan+0x24c/0x2cc) from [<c01a2a40>] (process_one_work+0x200/0x400)
<6>[ 164.630438] [<c01a2a40>] (process_one_work+0x200/0x400) from [<c01a2df0>] (worker_thread+0x184/0x2a4)
<6>[ 164.630474] [<c01a2df0>] (worker_thread+0x184/0x2a4) from [<c01a74ac>] (kthread+0x80/0x90)
<6>[ 164.630510] [<c01a74ac>] (kthread+0x80/0x90) from [<c0106aec>] (kernel_thread_exit+0x0/0x8)
<6>[ 164.630529] Mem-info:
<6>[ 164.630542] Normal per-cpu:
<6>[ 164.630559] CPU 0: hi: 186, btch: 31 usd: 0
<6>[ 164.630573] HighMem per-cpu:
<6>[ 164.630588] CPU 0: hi: 90, btch: 15 usd: 0
<6>[ 164.630624] active_anon:96301 inactive_anon:586 isolated_anon:4
<6>[ 164.630633] active_file:26021 inactive_file:25748 isolated_file:0
<6>[ 164.630641] unevictable:694 dirty:4 writeback:0 unstable:0
<6>[ 164.630649] free:5131 slab_reclaimable:3282 slab_unreclaimable:5632
<6>[ 164.630658] mapped:36273 shmem:649 pagetables:3794 bounce:0
<6>[ 164.630666] free_cma:139
<6>[ 164.630716] Normal free:18660kB min:3136kB low:3920kB high:4704kB active_anon:183052kB inactive_anon:1980kB active_file:98188kB inactive_file:98364kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:616020kB mlocked:0kB dirty:8kB writeback:0kB mapped:134632kB shmem:1992kB slab_reclaimable:13128kB slab_unreclaimable:22528kB kernel_stack:10528kB pagetables:15176kB unstable:0kB bounce:0kB free_cma:112kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
<6>[ 164.630769] lowmem_reserve[]: 0 1691 1691
<6>[ 164.630831] HighMem free:1864kB min:208kB low:480kB high:756kB active_anon:202152kB inactive_anon:364kB active_file:5896kB inactive_file:4628kB unevictable:2776kB isolated(anon):16kB isolated(file):0kB present:216488kB mlocked:0kB dirty:8kB writeback:0kB mapped:10460kB shmem:604kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:444kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
<6>[ 164.630883] lowmem_reserve[]: 0 0 0
<6>[ 164.630913] Normal: 1215*4kB (UEMC) 421*8kB (UEMC) 396*16kB (UM) 114*32kB (UM) 7*64kB (UM) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 18660kB
<6>[ 164.631034] HighMem: 190*4kB (UMRC) 26*8kB (UMRC) 9*16kB (UMC) 1*32kB (C) 0*64kB 1*128kB (C) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1272kB
<6>[ 164.631154] 53112 total pagecache pages
<6>[ 164.631167] 0 pages in swap cache
<6>[ 164.631183] Swap cache stats: add 0, delete 0, find 0/0
<6>[ 164.631197] Free swap = 0kB
<6>[ 164.631209] Total swap = 0kB
<6>[ 164.648069] 230912 pages of RAM
<6>[ 164.648087] 12304 free pages
<6>[ 164.648099] 30954 reserved pages
<6>[ 164.648111] 5947 slab pages
<6>[ 164.648123] 358720 pages shared
<6>[ 164.648135] 0 pages swap cached
<4>[ 164.648468] mmcblk: probe of mmc1:1234 failed with error -12
The reason is that mmc_alloc_sg() function will use kmalloc to init
Scatterlist , in this issue, it is 32KB memory , the kmalloc will fail if there is
Not enough low memory , instead, we can use vmalloc if the request memory is larger than
A PAGE_SIZE , we make a patch for this problems (see attachment patch.diff) ,
Hope can be merged into mainline .
Thanks
[-- Attachment #2: patch.diff --]
[-- Type: application/octet-stream, Size: 2508 bytes --]
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index cef1a41..839b506 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -15,6 +15,7 @@
#include <linux/freezer.h>
#include <linux/kthread.h>
#include <linux/scatterlist.h>
+#include <linux/vmalloc.h>
#include <linux/mmc/card.h>
#include <linux/mmc/host.h>
@@ -198,8 +199,13 @@ static void mmc_urgent_request(struct request_queue *q)
static struct scatterlist *mmc_alloc_sg(int sg_len, int *err)
{
struct scatterlist *sg;
+ size_t size = sizeof(struct scatterlist)*sg_len;
+
+ if (size > PAGE_SIZE)
+ sg = vmalloc(size);
+ else
+ sg = kmalloc(size, GFP_KERNEL);
- sg = kmalloc(sizeof(struct scatterlist)*sg_len, GFP_KERNEL);
if (!sg)
*err = -ENOMEM;
else {
@@ -210,6 +216,14 @@ static struct scatterlist *mmc_alloc_sg(int sg_len, int *err)
return sg;
}
+static void mmc_alloc_free(const void *addr)
+{
+ if (is_vmalloc_addr(addr))
+ vfree(addr);
+ else
+ kfree(addr);
+}
+
static void mmc_queue_setup_discard(struct request_queue *q,
struct mmc_card *card)
{
@@ -397,20 +411,20 @@ success:
return 0;
free_bounce_sg:
- kfree(mqrq_cur->bounce_sg);
+ mmc_alloc_free(mqrq_cur->bounce_sg);
mqrq_cur->bounce_sg = NULL;
- kfree(mqrq_prev->bounce_sg);
+ mmc_alloc_free(mqrq_prev->bounce_sg);
mqrq_prev->bounce_sg = NULL;
cleanup_queue:
- kfree(mqrq_cur->sg);
+ mmc_alloc_free(mqrq_cur->sg);
mqrq_cur->sg = NULL;
- kfree(mqrq_cur->bounce_buf);
+ mmc_alloc_free(mqrq_cur->bounce_buf);
mqrq_cur->bounce_buf = NULL;
- kfree(mqrq_prev->sg);
+ mmc_alloc_free(mqrq_prev->sg);
mqrq_prev->sg = NULL;
- kfree(mqrq_prev->bounce_buf);
+ mmc_alloc_free(mqrq_prev->bounce_buf);
mqrq_prev->bounce_buf = NULL;
blk_cleanup_queue(mq->queue);
@@ -436,22 +450,22 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
blk_start_queue(q);
spin_unlock_irqrestore(q->queue_lock, flags);
- kfree(mqrq_cur->bounce_sg);
+ mmc_alloc_free(mqrq_cur->bounce_sg);
mqrq_cur->bounce_sg = NULL;
- kfree(mqrq_cur->sg);
+ mmc_alloc_free(mqrq_cur->sg);
mqrq_cur->sg = NULL;
- kfree(mqrq_cur->bounce_buf);
+ mmc_alloc_free(mqrq_cur->bounce_buf);
mqrq_cur->bounce_buf = NULL;
- kfree(mqrq_prev->bounce_sg);
+ mmc_alloc_free(mqrq_prev->bounce_sg);
mqrq_prev->bounce_sg = NULL;
- kfree(mqrq_prev->sg);
+ mmc_alloc_free(mqrq_prev->sg);
mqrq_prev->sg = NULL;
- kfree(mqrq_prev->bounce_buf);
+ mmc_alloc_free(mqrq_prev->bounce_buf);
mqrq_prev->bounce_buf = NULL;
mq->card = NULL;
^ permalink raw reply related
* Re: [PATCH] Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix bug
From: Reyad Attiyat @ 2014-01-21 7:33 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, linux-kernel
In-Reply-To: <alpine.LRH.2.00.1401210747120.12934@twin.jikos.cz>
On Tue, Jan 21, 2014 at 12:47 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Mon, 20 Jan 2014, Reyad Attiyat wrote:
>
>> The below patch fixes a bug 64811
>> (https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
>> Surface Type/Touch cover 2 devices being detected as a multitouch
>> device.
>> The fix adds the HID of the two devices to hid-microsoft driver. This
>> ensures that hid-input will eventually be used for the device and not
>> hid-multitouch.
>
> Hi,
>
> your patch is missing hid_have_special_driver[] entry, therefore correct
> driver binding is not guaranteed.
>
> --
> Jiri Kosina
> SUSE Labs
>
Hi,
Thanks for reminding me of hid_have_special_driver[]. I noticed that
this device has the HID_DG_CONTACTID and in the comment of the
hid_have_sepcial_driver[]
* Please note that for multitouch devices (driven by hid-multitouch driver),
* there is a proper autodetection and autoloading in place (based on presence
* of HID_DG_CONTACTID), so those devices don't need to be added to this list,
* as we are doing the right thing in hid_scan_usage().
This device should not be driven by hid-multitouch as it does not
handle keyboard/mouse input devices.
I submitted a new patch below with it added. I believe it should still
be part of this array, in case this kind of implementation is
fixed/updated.
>From 291742873dcf181faf9657b41279487f31302c73 Mon Sep 17 00:00:00 2001
From: Reyad Attiyat <reyad.attiyat@gmail.com>
Date: Tue, 21 Jan 2014 01:22:25 -0600
Subject: [PATCH 1/1] Added in HID's for Microsoft Surface Type/Touch cover 2.
This is to fix bug 64811 where this device is detected as a multitouch device
---
drivers/hid/hid-core.c | 3 +++
drivers/hid/hid-ids.h | 4 +++-
drivers/hid/hid-microsoft.c | 4 ++++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 253fe23..88eb4a6 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1778,6 +1778,9 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_USB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_TOUCH_COVER_2) },
+
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..b523a8b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -611,7 +611,9 @@
#define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
-
+#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
+
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 551795b..2599de8 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -207,6 +207,10 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
.driver_data = MS_DUPLICATE_USAGES },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2),
+ .driver_data = 0 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2),
+ .driver_data = 0 },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH 1/2] Add annotated HID descriptor for the Dualshock 4.
From: Jiri Kosina @ 2014-01-21 7:01 UTC (permalink / raw)
To: Frank Praznik; +Cc: linux-input
In-Reply-To: <1390238822-18164-1-git-send-email-frank.praznik@oh.rr.com>
On Mon, 20 Jan 2014, Frank Praznik wrote:
> Add annotated HID descriptor for the Dualshock 4.
>
> Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
>
> ---
>
> Apply against jikos/hid.git/for-3.14/sony
I am taking both for 3.14 still (although it's really on a borderline,
timing-wise :) ).
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix bug
From: Jiri Kosina @ 2014-01-21 6:47 UTC (permalink / raw)
To: Reyad Attiyat; +Cc: linux-input, linux-kernel
In-Reply-To: <CA+BWVUTkaUt8Ys_40r7zFV_wBtY7iWTTmUUL+bHj=e3NwAtgNg@mail.gmail.com>
On Mon, 20 Jan 2014, Reyad Attiyat wrote:
> The below patch fixes a bug 64811
> (https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
> Surface Type/Touch cover 2 devices being detected as a multitouch
> device.
> The fix adds the HID of the two devices to hid-microsoft driver. This
> ensures that hid-input will eventually be used for the device and not
> hid-multitouch.
Hi,
your patch is missing hid_have_special_driver[] entry, therefore correct
driver binding is not guaranteed.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3] input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path
From: Dmitry Torokhov @ 2014-01-21 4:12 UTC (permalink / raw)
To: Peter Hutterer
Cc: Benjamin Tissoires, Benjamin Tissoires, David Herrmann,
linux-input, linux-kernel@vger.kernel.org
In-Reply-To: <20140120225651.GA30049@yabbi.local>
On Tue, Jan 21, 2014 at 08:56:51AM +1000, Peter Hutterer wrote:
> On Mon, Jan 20, 2014 at 05:17:08PM -0500, Benjamin Tissoires wrote:
> > On Mon, Jan 20, 2014 at 4:53 PM, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > > Hi Benjamin,
> > >
> > > On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires wrote:
> > >> Evemu [1] uses uinput to replay devices traces it has recorded. However,
> > >> the way evemu uses uinput is slightly different from how uinput is
> > >> supposed to be used.
> > >> Evemu relies on libevdev, which creates the device node through uinput.
> > >> It then injects events through the input device node directly (and it
> > >> completely skips the uinput node).
> > >>
> > >> Currently, libevdev relies on an heuristic to guess which input node was
> > >> created. The problem is that is heuristic is subjected to races between
> > >> different uinput devices or even with physical devices. Having a way
> > >> to retrieve the sysfs path allows us to find the event node without
> > >> having to rely on this heuristic.
> > >
> > > I have been thinking about it and I think that providing tight coupling
> > > between uinput and resulting event device is wrong thing to do. We do
> > > allow sending input events through uinput interface and I think evemu
> > > should be using it, instead of going halfway through uinput and halfway
> > > though evdev. Replaying though uinput would actually be more correct as
> > > it would involve the same code paths throgugh input core as with using
> > > real devices (see input_event() vs. input_inject_event() that is used by
> > > input handlers).
> > >
> >
> > Yes, I am perfectly aware of the fact that evemu is not using uinput
> > in the way it is intended to be.
> > I agree that it should be using the uinput node to inject events but
> > this means that only the process which has created the virtual device
> > can access it. It seems weird, I know, but the typical use of evemu is
> > the following:
> > - in a first terminal: $> sudo evemu-device mydevice.desc
> > - In a second: $> sudo evemu-play /dev/input/event12 < mydevice.events
> >
> > It looks weird here, but it allows to inject different events
> > recording for the same virtual device node.
>
> it also allows replaying an event through the device it was recorded on.
> it's not always necessary or desirable to create a uinput device, sometimes
> replaying it through the actual device is better to reproduce a certain bug.
I was not saying that we should remove ability to inject events through
evdev nodes, so I am not sure why you are bringing your last point, but
form your and Benjamin's other mails I can see why going through evdev
(that has a separate device node) might be beneficial.
Benjamin, please clean up the issues brought up by David and I should be
able to apply the patch.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix bug
From: Reyad Attiyat @ 2014-01-21 0:42 UTC (permalink / raw)
To: linux-input, linux-kernel
The below patch fixes a bug 64811
(https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
Surface Type/Touch cover 2 devices being detected as a multitouch
device.
The fix adds the HID of the two devices to hid-microsoft driver. This
ensures that hid-input will eventually be used for the device and not
hid-multitouch.
>From 866c814f3f6740a5a79858fdf8bf5bbcdc3b57f8 Mon Sep 17 00:00:00 2001
From: Reyad Attiyat <reyad.attiyat@gmail.com>
Date: Mon, 20 Jan 2014 16:24:49 -0600
Subject: [PATCH 1/2] Added in ID's for Surface Type/Touch cover 2 to the
hid-microsoft driver
---
drivers/hid/hid-ids.h | 4 +++-
drivers/hid/hid-microsoft.c | 4 ++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..b523a8b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -611,7 +611,9 @@
#define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
-
+#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
+
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 551795b..2599de8 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -207,6 +207,10 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
.driver_data = MS_DUPLICATE_USAGES },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2),
+ .driver_data = 0 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2),
+ .driver_data = 0 },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
--
1.8.4.2
^ permalink raw reply related
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