[RFT/PATCH] Input: bfin_rotary - introduce open and close methods

[Dmitry Torokhov]

Introduce open and close methods for the input device to postpone enabling
the device until it is needed.

Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---

Hi Sonic,

Could you please tell me if the driver still works with this parch?

Thanks!

 drivers/input/misc/bfin_rotary.c | 70 
 1 file changed, 42 insertions(+), 28 deletions(-)

diff --git a/drivers/input/misc/bfin_rotary.c b/drivers/input/misc/bfin_rotary.c
index 09d7612..1bc9409 100644
--- a/drivers/input/misc/bfin_rotary.c
+++ b/drivers/input/misc/bfin_rotary.c
@@ -35,6 +35,10 @@ struct bfin_rot {
unsigned int down_key;
unsigned int button_key;
unsigned int rel_code;
+
+   unsigned short mode;
+   unsigned short debounce;
+
unsigned short cnt_config;
unsigned short cnt_imask;
unsigned short cnt_debounce;
@@ -94,6 +98,35 @@ static irqreturn_t bfin_rotary_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+static int bfin_rotary_open(struct input_dev *input)
+{
+   struct bfin_rot *rotary = input_get_drvdata(input);
+   unsigned short val;
+
+   if (rotary-mode  ROT_DEBE)
+   writew(rotary-debounce  DPRESCALE,
+   rotary-base + CNT_DEBOUNCE_OFF);
+
+   writew(rotary-mode  ~CNTE, rotary-base + CNT_CONFIG_OFF);
+
+   val = UCIE | DCIE;
+   if (rotary-button_key)
+   val |= CZMIE;
+   writew(val, rotary-base + CNT_IMASK_OFF);
+
+   writew(rotary-mode | CNTE, rotary-base + CNT_CONFIG_OFF);
+
+   return 0;
+}
+
+static void bfin_rotary_close(struct input_dev *input)
+{
+   struct bfin_rot *rotary = input_get_drvdata(input);
+
+   writew(0, rotary-base + CNT_CONFIG_OFF);
+   writew(0, rotary-base + CNT_IMASK_OFF);
+}
+
 static void bfin_rotary_free_action(void *data)
 {
peripheral_free_list(data);
@@ -154,6 +187,9 @@ static int bfin_rotary_probe(struct platform_device *pdev)
rotary-button_key = pdata-rotary_button_key;
rotary-rel_code = pdata-rotary_rel_code;
 
+   rotary-mode = pdata-mode;
+   rotary-debounce = pdata-debounce;
+
input-name = pdev-name;
input-phys = bfin-rotary/input0;
input-dev.parent = pdev-dev;
@@ -165,6 +201,9 @@ static int bfin_rotary_probe(struct platform_device *pdev)
input-id.product = 0x0001;
input-id.version = 0x0100;
 
+   input-open = bfin_rotary_open;
+   input-close = bfin_rotary_close;
+
if (rotary-up_key) {
__set_bit(EV_KEY, input-evbit);
__set_bit(rotary-up_key, input-keybit);
@@ -179,6 +218,9 @@ static int bfin_rotary_probe(struct platform_device *pdev)
__set_bit(rotary-button_key, input-keybit);
}
 
+   /* Quiesce the device before requesting irq */
+   bfin_rotary_close(input);
+
rotary-irq = platform_get_irq(pdev, 0);
if (rotary-irq  0) {
dev_err(dev, No rotary IRQ specified\n);
@@ -199,39 +241,12 @@ static int bfin_rotary_probe(struct platform_device *pdev)
return error;
}
 
-   if (pdata-rotary_button_key)
-   writew(CZMIE, rotary-base + CNT_IMASK_OFF);
-
-   if (pdata-mode  ROT_DEBE)
-   writew(pdata-debounce  DPRESCALE,
-   rotary-base + CNT_DEBOUNCE_OFF);
-
-   if (pdata-mode)
-   writew(readw(rotary-base + CNT_CONFIG_OFF) |
-   (pdata-mode  ~CNTE),
-   rotary-base + CNT_CONFIG_OFF);
-
-   writew(readw(rotary-base + CNT_IMASK_OFF) | UCIE | DCIE,
-   rotary-base + CNT_IMASK_OFF);
-   writew(readw(rotary-base + CNT_CONFIG_OFF) | CNTE,
-   rotary-base + CNT_CONFIG_OFF);
-
platform_set_drvdata(pdev, rotary);
device_init_wakeup(pdev-dev, 1);
 
return 0;
 }
 
-static int bfin_rotary_remove(struct platform_device *pdev)
-{
-   struct bfin_rot *rotary = platform_get_drvdata(pdev);
-
-   writew(0, rotary-base + CNT_CONFIG_OFF);
-   writew(0, rotary-base + CNT_IMASK_OFF);
-
-   return 0;
-}
-
 static int __maybe_unused bfin_rotary_suspend(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -270,7 +285,6 @@ static SIMPLE_DEV_PM_OPS(bfin_rotary_pm_ops,
 
 static struct platform_driver bfin_rotary_device_driver = {
.probe  = bfin_rotary_probe,
-   .remove = bfin_rotary_remove,
.driver = {
.name   = bfin-rotary,
.pm = bfin_rotary_pm_ops,
-- 
2.2.0.rc0.207.ga3a616c


-- 
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] bfin_rotary: convert to use managed resources

[Dmitry Torokhov]

On Thu, Feb 05, 2015 at 04:29:13PM +0800, Sonic Zhang wrote:
 From: Sonic Zhang sonic.zh...@analog.com
 
 - remap rotary register physical address into kernel space in probe
 - replace kzalloc with devm_kzalloc
 - replace request_irq with devm_request_irq
 - remove memory free and irq free from the device remove function
 - use devm_input_allocate_device
 
 v2-changes:
 - remove rotary register address remap operation from this patch
 - Use devm_add_action() to integrate freeing of pins into the
 rest of devm* unwind sequence.
 
 Signed-off-by: Sonic Zhang sonic.zh...@analog.com
 ---
  drivers/input/misc/bfin_rotary.c |   84 
 ++
  1 file changed, 39 insertions(+), 45 deletions(-)
 
 diff --git a/drivers/input/misc/bfin_rotary.c 
 b/drivers/input/misc/bfin_rotary.c
 index dd929ad..80f66e7 100644
 --- a/drivers/input/misc/bfin_rotary.c
 +++ b/drivers/input/misc/bfin_rotary.c
 @@ -93,6 +93,13 @@ static irqreturn_t bfin_rotary_isr(int irq, void *dev_id)
   return IRQ_HANDLED;
  }
  
 +
 +static void bfin_rotary_free_action(void *data)
 +{
 + unsigned short *pin_list = (unsigned short *)data;
 + peripheral_free_list(pin_list);

This gives me warnign about unused variable because your stub for
peripheral_free_list() is not that great. Please convert them into empty
static inline functions so that you enjoy proper typechecking in all
cases.

In the meantime I'd like to apply the following version of the patch
(note that I adjusted the previous patch to check that pin_list is not
NULL so that this series does not depend on the arch patch you posted).

Thanks.

-- 
Dmitry

Input: bfin_rotary - convert to use managed resources

From: Sonic Zhang sonic.zh...@analog.com

Use of managed resources simplifies error handling.

Signed-off-by: Sonic Zhang sonic.zh...@analog.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
 drivers/input/misc/bfin_rotary.c |   84 ++
 1 file changed, 39 insertions(+), 45 deletions(-)

diff --git a/drivers/input/misc/bfin_rotary.c b/drivers/input/misc/bfin_rotary.c
index 70ee33a..a39793c 100644
--- a/drivers/input/misc/bfin_rotary.c
+++ b/drivers/input/misc/bfin_rotary.c
@@ -94,6 +94,11 @@ static irqreturn_t bfin_rotary_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+static void bfin_rotary_free_action(void *data)
+{
+   peripheral_free_list(data);
+}
+
 static int bfin_rotary_probe(struct platform_device *pdev)
 {
const struct bfin_rotary_platform_data *pdata =
@@ -110,28 +115,37 @@ static int bfin_rotary_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+   rotary = devm_kzalloc(dev, sizeof(struct bfin_rot), GFP_KERNEL);
+   if (!rotary)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   rotary-base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(rotary-base))
+   return PTR_ERR(rotary-base);
+
if (pdata-pin_list) {
error = peripheral_request_list(pdata-pin_list,
dev_name(pdev-dev));
if (error) {
-   dev_err(pdev-dev, requesting peripherals failed\n);
+   dev_err(dev, requesting peripherals failed: %d\n,
+   error);
return error;
}
-   }
 
-   rotary = kzalloc(sizeof(struct bfin_rot), GFP_KERNEL);
-   input = input_allocate_device();
-   if (!rotary || !input) {
-   error = -ENOMEM;
-   goto out1;
+   error = devm_add_action(dev, bfin_rotary_free_action,
+   pdata-pin_list);
+   if (error) {
+   dev_err(dev, setting cleanup action failed: %d\n,
+   error);
+   peripheral_free_list(pdata-pin_list);
+   return error;
+   }
}
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   rotary-base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(rotary-base)) {
-   error = PTR_ERR(rotary-base);
-   goto out1;
-   }
+   input = devm_input_allocate_device(dev);
+   if (!input)
+   return -ENOMEM;
 
rotary-input = input;
 
@@ -140,10 +154,6 @@ static int bfin_rotary_probe(struct platform_device *pdev)
rotary-button_key = pdata-rotary_button_key;
rotary-rel_code = pdata-rotary_rel_code;
 
-   error = rotary-irq = platform_get_irq(pdev, 0);
-   if (error  0)
-   goto out1;
-
input-name = pdev-name;
input-phys = bfin-rotary/input0;
input-dev.parent = pdev-dev;
@@ -169,20 +179,24 @@ static int bfin_rotary_probe(struct platform_device *pdev)
__set_bit(rotary-button_key, input-keybit);
}
 
-   error = 

[PATCH] Input: bfin_rotary - mark suspend and resume code as __maybe_unused

[Dmitry Torokhov]

Instead of using #ifdef to guard potentially unused suspend and resume code
let's mark them as __maybe_unused so they still get discarded if they are
not used but we do not get warning. This allows for better compile coverage.

Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
 drivers/input/misc/bfin_rotary.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/input/misc/bfin_rotary.c b/drivers/input/misc/bfin_rotary.c
index a39793c..09d7612 100644
--- a/drivers/input/misc/bfin_rotary.c
+++ b/drivers/input/misc/bfin_rotary.c
@@ -232,8 +232,7 @@ static int bfin_rotary_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-static int bfin_rotary_suspend(struct device *dev)
+static int __maybe_unused bfin_rotary_suspend(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct bfin_rot *rotary = platform_get_drvdata(pdev);
@@ -248,7 +247,7 @@ static int bfin_rotary_suspend(struct device *dev)
return 0;
 }
 
-static int bfin_rotary_resume(struct device *dev)
+static int __maybe_unused bfin_rotary_resume(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct bfin_rot *rotary = platform_get_drvdata(pdev);
@@ -266,20 +265,15 @@ static int bfin_rotary_resume(struct device *dev)
return 0;
 }
 
-static const struct dev_pm_ops bfin_rotary_pm_ops = {
-   .suspend= bfin_rotary_suspend,
-   .resume = bfin_rotary_resume,
-};
-#endif
+static SIMPLE_DEV_PM_OPS(bfin_rotary_pm_ops,
+bfin_rotary_suspend, bfin_rotary_resume);
 
 static struct platform_driver bfin_rotary_device_driver = {
.probe  = bfin_rotary_probe,
.remove = bfin_rotary_remove,
.driver = {
.name   = bfin-rotary,
-#ifdef CONFIG_PM
.pm = bfin_rotary_pm_ops,
-#endif
},
 };
 module_platform_driver(bfin_rotary_device_driver);
-- 
2.2.0.rc0.207.ga3a616c


-- 
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Input: soc_button_array - Use Windows key for Home

[Bastien Nocera]

KEY_HOME is the key to go back to the beginning of the line, not
the key to get into an overview mode, as Windows does. GNOME can already
make use of the Windows key on multiple form factors, and other
desktop environments can use it depending on the form factor.

Using Windows as the emitted key also means that the keycode sent out
matches the symbol on the key itself.

So switch KEY_HOME to KEY_LEFTMETA (Windows key).
---
 drivers/input/misc/soc_button_array.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/misc/soc_button_array.c 
b/drivers/input/misc/soc_button_array.c
index 79cc0f7..e8e010a 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -195,7 +195,7 @@ static int soc_button_probe(struct platform_device *pdev)
 
 static struct soc_button_info soc_button_PNP0C40[] = {
{ power, 0, EV_KEY, KEY_POWER, false, true },
-   { home, 1, EV_KEY, KEY_HOME, false, true },
+   { home, 1, EV_KEY, KEY_LEFTMETA, false, true },
{ volume_up, 2, EV_KEY, KEY_VOLUMEUP, true, false },
{ volume_down, 3, EV_KEY, KEY_VOLUMEDOWN, true, false },
{ rotation_lock, 4, EV_SW, SW_ROTATE_LOCK, false, false },
-- 
2.1.0


--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] Input: soc_button_array - Use Windows key for Home

[Bastien Nocera]

KEY_HOME is the key to go back to the beginning of the line, not
the key to get into an overview mode, as Windows does. GNOME can already
make use of the Windows key on multiple form factors, and other
desktop environments can use it depending on the form factor.

Using Windows as the emitted key also means that the keycode sent out
matches the symbol on the key itself.

So switch KEY_HOME to KEY_LEFTMETA (Windows key).

Signed-off-by: Bastien Nocera had...@hadess.net
---
 drivers/input/misc/soc_button_array.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/misc/soc_button_array.c 
b/drivers/input/misc/soc_button_array.c
index 79cc0f7..e8e010a 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -195,7 +195,7 @@ static int soc_button_probe(struct platform_device *pdev)
 
 static struct soc_button_info soc_button_PNP0C40[] = {
{ power, 0, EV_KEY, KEY_POWER, false, true },
-   { home, 1, EV_KEY, KEY_HOME, false, true },
+   { home, 1, EV_KEY, KEY_LEFTMETA, false, true },
{ volume_up, 2, EV_KEY, KEY_VOLUMEUP, true, false },
{ volume_down, 3, EV_KEY, KEY_VOLUMEDOWN, true, false },
{ rotation_lock, 4, EV_SW, SW_ROTATE_LOCK, false, false },


--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Input: soc_button_array - Use Windows key for Home

[Bastien Nocera]

On Thu, 2015-02-05 at 14:31 +0100, Bastien Nocera wrote:
 KEY_HOME is the key to go back to the beginning of the line, not
 the key to get into an overview mode, as Windows does. GNOME can already
 make use of the Windows key on multiple form factors, and other
 desktop environments can use it depending on the form factor.
 
 Using Windows as the emitted key also means that the keycode sent out
 matches the symbol on the key itself.
 
 So switch KEY_HOME to KEY_LEFTMETA (Windows key).

Disregard that one, I forgot the SoB...

--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] Input: synaptics - Skip quirks when post-2013 dimensions

[Benjamin Tissoires]

On Sat, Jan 31, 2015 at 3:18 AM, Daniel Martin consume.no...@gmail.com wrote:
 On Fri, Jan 30, 2015 at 10:34:22AM -0500, Benjamin Tissoires wrote:
 On Fri, Jan 30, 2015 at 4:59 AM, Hans de Goede hdego...@redhat.com wrote:
  Hi,
 
  On 01/29/2015 08:50 PM, Benjamin Tissoires wrote:
  On Thu, Jan 29, 2015 at 2:02 PM, Benjamin Tissoires
  benjamin.tissoi...@gmail.com wrote:
  Hi Daniel,
 
  On Tue, Jan 27, 2015 at 3:34 AM, Daniel Martin
  daniel.mar...@secunet.com wrote:
  From: Daniel Martin consume.no...@gmail.com
 
  If we queried min/max dimensions of x [1266..5674], y [1170..4684] we
  have post-2013 model and don't need to apply any quirk.
 
  Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541
  Signed-off-by: Daniel Martin consume.no...@gmail.com
  ---
   drivers/input/mouse/synaptics.c | 5 +
   1 file changed, 5 insertions(+)
 
  diff --git a/drivers/input/mouse/synaptics.c 
  b/drivers/input/mouse/synaptics.c
  index 37d4dff..f6c43ff 100644
  --- a/drivers/input/mouse/synaptics.c
  +++ b/drivers/input/mouse/synaptics.c
  @@ -420,6 +420,11 @@ static int synaptics_quirks(struct psmouse 
  *psmouse)
  struct synaptics_data *priv = psmouse-private;
  int i;
 
  +   /* Post-2013 models expose correct dimensions. */
  +   if (priv-x_min == 1266  priv-x_max == 5674 
  +   priv-y_min == 1170  priv-y_max == 4684)
  +   return 0;
  +
 
  Well, this one, I don't like it either :(
 
  At least, the test should be within the psmouse_matches_pnp_id() below
  to ensure we are deciding with Lenovo devices only.
 
  The other concern is hardcoding these values in the code directly.
  What if Synaptics/Lenovo decides to ship a new released model with
  proper min_max ranges but with a different offset?
 
  Andrew told us that the board ID should be enough to discriminate old
  and faulty touchpads from the new and valid touchpads.
 
  My concern here is that we will have to backport these changes in the
  various stable kernel and the various distributions. And if we do not
  end up with the right solution right now, that means that we will have
  to do the job over and over.
 
  I am quite tempted to find a solution in the userspace for that fix.
  Not sure I'll be able to find the right one right now, but it may
  worth trying.
 
 
  So, the user space solution seems difficult because we do not export
  either the board_id or the firmware_id. So that would required to
  update the kernel anyway, a bunch of user space tools and a hwdb... :(
 
  How about we just add an extra min/max in struct min_max_quirk,
  compare the current min/max with the 2 possible values and if there is
  a match, we do not override the values.
  This way, we keep the crap of wrong/correct min max in the small list
  of device we know are problematic, and if the new batch of E540 has a
  different correct min/max range, then we will be able to adjust it
  without breaking the other we fixed.
 
  Dmitry, Hans, any comments on this?
 
  I'm thinking more along the lines of adding a max_broken_board_id field
  to the quirks, and if the touchpad board_id is larger then the
  max_broken_board_id not use the quirk.
 

 Yep, this was confirmed by Synaptics that the board id will be
 incremented only at each new board revision. So it should be safe to
 only check for that.

 Could you ask your contact for an exact board id, since when the ranges
 have been fixed? From the data I can look at it seems to be = 2962.

IIRC, Andrew said in a private mail that extracting this kind of
information is quite tricky.

I would say that we should add a per-pnp_id board limit with the data we know.

I think you could add this in the struct min_max_quirk, and if the
max_board_id is  0, we check against it.
This way, we could have a finer grain when dealing with the hardware refreshes.

Cheers,
Benjamin
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] bfin_rotary: convert to use managed resources

[Sonic Zhang]

From: Sonic Zhang sonic.zh...@analog.com

- remap rotary register physical address into kernel space in probe
- replace kzalloc with devm_kzalloc
- replace request_irq with devm_request_irq
- remove memory free and irq free from the device remove function
- use devm_input_allocate_device

v2-changes:
- remove rotary register address remap operation from this patch
- Use devm_add_action() to integrate freeing of pins into the
rest of devm* unwind sequence.

Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
 drivers/input/misc/bfin_rotary.c |   84 ++
 1 file changed, 39 insertions(+), 45 deletions(-)

diff --git a/drivers/input/misc/bfin_rotary.c b/drivers/input/misc/bfin_rotary.c
index dd929ad..80f66e7 100644
--- a/drivers/input/misc/bfin_rotary.c
+++ b/drivers/input/misc/bfin_rotary.c
@@ -93,6 +93,13 @@ static irqreturn_t bfin_rotary_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+
+static void bfin_rotary_free_action(void *data)
+{
+   unsigned short *pin_list = (unsigned short *)data;
+   peripheral_free_list(pin_list);
+}
+
 static int bfin_rotary_probe(struct platform_device *pdev)
 {
struct device *dev = pdev-dev;
@@ -102,6 +109,31 @@ static int bfin_rotary_probe(struct platform_device *pdev)
struct input_dev *input;
int error;
 
+   rotary = devm_kzalloc(dev, sizeof(struct bfin_rot), GFP_KERNEL);
+   if (!rotary) {
+   dev_err(dev, fail to malloc bfin_rot\n);
+   return -ENOMEM;
+   }
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   rotary-base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(rotary-base))
+   return PTR_ERR(rotary-base);
+
+   rotary-irq = platform_get_irq(pdev, 0);
+   if (rotary-irq  0) {
+   dev_err(dev, No rotary IRQ specified\n);
+   return -ENOENT;
+   }
+
+   error = devm_request_irq(dev, rotary-irq, bfin_rotary_isr,
+   0, dev_name(pdev-dev), pdev);
+   if (error) {
+   dev_err(dev, unable to claim irq %d; error %d\n,
+   rotary-irq, error);
+   return error;
+   }
+
/* Basic validation */
if ((pdata-rotary_up_key  !pdata-rotary_down_key) ||
(!pdata-rotary_up_key  pdata-rotary_down_key)) {
@@ -110,23 +142,15 @@ static int bfin_rotary_probe(struct platform_device *pdev)
 
error = peripheral_request_list(pdata-pin_list, dev_name(pdev-dev));
if (error) {
-   dev_err(pdev-dev, requesting peripherals failed\n);
+   dev_err(dev, requesting peripherals failed\n);
return error;
}
 
-   rotary = kzalloc(sizeof(struct bfin_rot), GFP_KERNEL);
-   input = input_allocate_device();
-   if (!rotary || !input) {
-   error = -ENOMEM;
-   goto out1;
-   }
+   devm_add_action(dev, bfin_rotary_free_action, pdata-pin_list);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   rotary-base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(rotary-base)) {
-   error = PTR_ERR(rotary-base);
-   goto out1;
-   }
+   input = devm_input_allocate_device(dev);
+   if (!input)
+   return -ENOMEM;
 
rotary-input = input;
 
@@ -135,10 +159,6 @@ static int bfin_rotary_probe(struct platform_device *pdev)
rotary-button_key = pdata-rotary_button_key;
rotary-rel_code = pdata-rotary_rel_code;
 
-   error = rotary-irq = platform_get_irq(pdev, 0);
-   if (error  0)
-   goto out1;
-
input-name = pdev-name;
input-phys = bfin-rotary/input0;
input-dev.parent = pdev-dev;
@@ -164,20 +184,10 @@ static int bfin_rotary_probe(struct platform_device *pdev)
__set_bit(rotary-button_key, input-keybit);
}
 
-   error = request_irq(rotary-irq, bfin_rotary_isr,
-   0, dev_name(pdev-dev), pdev);
-   if (error) {
-   dev_err(pdev-dev,
-   unable to claim irq %d; error %d\n,
-   rotary-irq, error);
-   goto out1;
-   }
-
error = input_register_device(input);
if (error) {
-   dev_err(pdev-dev,
-   unable to register input device (%d)\n, error);
-   goto out2;
+   dev_err(dev, unable to register input device (%d)\n, error);
+   return error;
}
 
if (pdata-rotary_button_key)
@@ -201,31 +211,15 @@ static int bfin_rotary_probe(struct platform_device *pdev)
device_init_wakeup(pdev-dev, 1);
 
return 0;
-
-out2:
-   free_irq(rotary-irq, pdev);
-out1:
-   input_free_device(input);
-   kfree(rotary);
-   peripheral_free_list(pdata-pin_list);
-
-   return error;
 }
 
 static int bfin_rotary_remove(struct platform_device *pdev)
 {
-   struct 

Re: i2c_hid issues with sensor hub on Surface Pro 3

[Yani Ioannou]

Well, this is embarrassing. Turns out I'm just looking in the wrong
place for them. Looks like they are all there under
/sys/bus/iio/devices/, but I read somewhere to check
/proc/bus/input/devices.

When I saw all the errors (even without debug) from i2c_hid in the
kernel log, I assumed too quickly that there was a problem.

Very sorry to have wasted your time!

Yani

On Thu, Feb 5, 2015 at 6:47 PM, Benjamin Tissoires
benjamin.tissoi...@gmail.com wrote:
 On Thu, Feb 5, 2015 at 1:44 PM, Yani Ioannou yani.ioan...@gmail.com wrote:
 Indeed you are correct, looks like one of the devices listed there is
 the sensor hub - so I'm barking up the wrong tree.

 Not quite actually. If the i2c-hid driver works but the hid-sensor-hub
 does not pick up, there is probably an error in hid-sensor-hub.

 Could you paste the content of the rdesc file so we can check if
 hid-sensor-hub messed up or if your device has a wrong report
 descriptor?

 Cheers,
 Benjamin


 Will have to move on to the sensor drivers themselves I guess. Thanks
 for your help!

 Yani

 On Thu, Feb 5, 2015 at 6:10 PM, Benjamin Tissoires
 benjamin.tissoi...@gmail.com wrote:
 On Thu, Feb 5, 2015 at 12:56 PM, Yani Ioannou yani.ioan...@gmail.com 
 wrote:
 Hi Benjamin,

 As far as I'm aware the sensor hub didn't show up under any kernel (I'll 
 try
 an earlier kernel to figure out if this is true) I didn't mean to say this
 is a regression, sorry.

 Oh, my bad.


 The errors for the MSHW0030 device seem to be fatal - since the initial
 report request fails, the driver doesn't try to work with the device. The
 NTRG device however, is as you suggest, and it is fine - I shouldn't have
 included the output for that device perhaps.

 Not being able to retrieve the reports should not be fatal in i2c_hid.

 There should be 2 devices showing up in:
 /sys/kernel/debug/hid/
 (if you have debugfs mounted in /sys/kernel/debug)

 One of them is the Ntrig (0018:1B96:1B05.*), the other should be the sensor 
 hub.

 Can you paste here the content of the rdesc file which is in the sensor_hub 
 dir?

 And yes, if there is no sensor hub device showing under the hid
 debugfs dir (or under /sys/bus/hid/devices), that means that i2c-hid
 has removed the device.

 Cheers,
 Benjamin


 So in summary I'm trying to work out why the sensor hub driver is never
 loaded, and as far as I can tell this is why.

 Thanks,
 Yani


 On Thu, Feb 5, 2015, 17:44 Benjamin Tissoires 
 benjamin.tissoi...@gmail.com
 wrote:

 Hi,

 On Thu, Feb 5, 2015 at 11:29 AM, Yani Ioannou yani.ioan...@gmail.com
 wrote:
  Hi,
 
  I've been trying to debug why the sensor hub on a Surface pro 3 isn't
  detected in the latest mainline kernel (3.19-rc6). When I enable debug
  I get the following output showing a bunch of errors trying to
  communicate with the device MSHW0030, which seems to be the sensor
  hub.

 These errors do not bother me that much. They appear when we try to
 read the reports from the device, and this has been known to not work
 on many devices.
 As long as the device emits by itself the reports, we are fine.

 There has been very few changes in the v3.19 series regarding i2c-hid,
 so if you get the same debug output on a v3.18 kernel (and the sensor
 hub works), I would think that the problem you are having is in the
 IIO subsystem.

 Cheers,
 Benjamin

 
  I've looked into the code/protocol a little and it seems the initial
  feature reports that are returned are of incorrect size, but I don't
  understand why without much prior knowledge of the domain.
 
  Any help and/or further debugging tips would be greatly appreciated.
 
  Thanks,
  Yani
 
  [ 83.133219] i2c_hid i2c-MSHW0030:00: Fetching the HID descriptor
  [ 83.133224] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=01 00
  [ 83.134826] i2c_hid i2c-MSHW0030:00: HID Descriptor: 1e 00 00 01 bf
  08 02 00 03 00 3f 00 04 00 3f 00 05 00 06 00 5e 04 c4 07 04 00 00 00
  00 00
  [ 83.134928] i2c_hid i2c-MSHW0030:00: entering i2c_hid_parse
  [ 83.134932] i2c_hid i2c-MSHW0030:00: i2c_hid_hwreset
  [ 83.134935] i2c_hid i2c-MSHW0030:00: i2c_hid_set_power
  [ 83.134938] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 08
  [ 83.135629] i2c_hid i2c-MSHW0030:00: resetting...
  [ 83.135633] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 01
  [ 83.136305] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: waiting...
  [ 83.138471] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: finished.
  [ 83.138475] i2c_hid i2c-MSHW0030:00: asking HID report descriptor
  [ 83.138477] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=02 00
  [ 83.191568] i2c_hid i2c-MSHW0030:00: Report Descriptor: 05 20 09 01
  a1 01 85 01 05 20 09 73 a1 00 0a 09 03 15 00 25 02 75 08 95 01 a1 02
  0a 30 08 0a 31 08 0a 32 08 b1 00 c0 0a 0e 03 15 00 27 ff ff ff ff 75
  20 95 01 55 00 b1 02 0a 52 14 15 00 26 ff
  [ 83.193819] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.193822] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 31 02
  06 00
  [ 83.194952] i2c_hid 

Regression in dtor/input.git/next - flush pending events on clock type change

[Benjamin Tissoires]

Hi Anshul,

The commit 0c3e99437a66e4c869c60c2398449e6d98f3a988 in dtor/input.git/next
tree introduce an interesting regression in libinput. The tests fail :)

Actually, evemu-record and libinput switch the clock to monotonic when
opening an input node, and the first thing that gets queued is a
SYN_DROPPED event.

However, in the libinput test suite, events are the bare minimum, and
most of the tests contain only one event set (one EV_SYN).
When seeing the SYN_DROPPED, the clients are supposed to drain the events
until the next EV_SYN, and so they are losing the events that came long
after the ioctl call.
And in the end, the test suite does not receive any events.

Removing the evdev_queue_syn_dropped() call in the ioctl handling fixes
the test suite, and Peter suggested that maybe we should queue a
SYN_DROPPED event iff there are events in the queue.

Cheers,
Benjamin
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in dtor/input.git/next - flush pending events on clock type change

[Dmitry Torokhov]

Hi Benjamin,

On Thu, Feb 05, 2015 at 06:06:29PM -0500, Benjamin Tissoires wrote:
 Hi Anshul,
 
 The commit 0c3e99437a66e4c869c60c2398449e6d98f3a988 in dtor/input.git/next
 tree introduce an interesting regression in libinput. The tests fail :)
 
 Actually, evemu-record and libinput switch the clock to monotonic when
 opening an input node, and the first thing that gets queued is a
 SYN_DROPPED event.
 
 However, in the libinput test suite, events are the bare minimum, and
 most of the tests contain only one event set (one EV_SYN).
 When seeing the SYN_DROPPED, the clients are supposed to drain the events
 until the next EV_SYN, and so they are losing the events that came long
 after the ioctl call.
 And in the end, the test suite does not receive any events.
 
 Removing the evdev_queue_syn_dropped() call in the ioctl handling fixes
 the test suite, and Peter suggested that maybe we should queue a
 SYN_DROPPED event iff there are events in the queue.

Does the following patch fixe it? But I would like to see libinput
tests more robust.

Thanks.

-- 
Dmitry

Input: evdev - do not queue SYN_DROPPED if queue is empty

From: Dmitry Torokhov dmitry.torok...@gmail.com

Reported-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
 drivers/input/evdev.c |   34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index e7cee38..f2a494a 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -108,10 +108,8 @@ static void __evdev_flush_queue(struct evdev_client 
*client, unsigned int type)
client-head = head;
 }
 
-/* queue SYN_DROPPED event and flush queue if flush parameter is true */
-static void evdev_queue_syn_dropped(struct evdev_client *client, bool flush)
+static void __evdev_queue_syn_dropped(struct evdev_client *client)
 {
-   unsigned long flags;
struct input_event ev;
ktime_t time;
 
@@ -126,11 +124,6 @@ static void evdev_queue_syn_dropped(struct evdev_client 
*client, bool flush)
ev.code = SYN_DROPPED;
ev.value = 0;
 
-   spin_lock_irqsave(client-buffer_lock, flags);
-
-   if (flush)
-   client-packet_head = client-head = client-tail;
-
client-buffer[client-head++] = ev;
client-head = client-bufsize - 1;
 
@@ -139,12 +132,21 @@ static void evdev_queue_syn_dropped(struct evdev_client 
*client, bool flush)
client-tail = (client-head - 1)  (client-bufsize - 1);
client-packet_head = client-tail;
}
+}
+
+static void evdev_queue_syn_dropped(struct evdev_client *client)
+{
+   unsigned long flags;
 
+   spin_lock_irqsave(client-buffer_lock, flags);
+   __evdev_queue_syn_dropped(client);
spin_unlock_irqrestore(client-buffer_lock, flags);
 }
 
 static int evdev_set_clk_type(struct evdev_client *client, unsigned int clkid)
 {
+   unsigned long flags;
+
if (client-clk_type == clkid)
return 0;
 
@@ -163,8 +165,18 @@ static int evdev_set_clk_type(struct evdev_client *client, 
unsigned int clkid)
return -EINVAL;
}
 
-   /* Flush pending events and queue SYN_DROPPED event.*/
-   evdev_queue_syn_dropped(client, true);
+   /*
+* Flush pending events and queue SYN_DROPPED event,
+* but only if queue is not empty.
+*/
+   spin_lock_irqsave(client-buffer_lock, flags);
+
+   if (client-head != client-tail) {
+   client-packet_head = client-head = client-tail;
+   __evdev_queue_syn_dropped(client);
+   }
+
+   spin_unlock_irqrestore(client-buffer_lock, flags);
 
return 0;
 }
@@ -803,7 +815,7 @@ static int evdev_handle_get_val(struct evdev_client *client,
 
ret = bits_to_user(mem, maxbit, maxlen, p, compat);
if (ret  0)
-   evdev_queue_syn_dropped(client, false);
+   evdev_queue_syn_dropped(client);
 
kfree(mem);
 
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

i2c_hid issues with sensor hub on Surface Pro 3

[Yani Ioannou]

Hi,

I've been trying to debug why the sensor hub on a Surface pro 3 isn't
detected in the latest mainline kernel (3.19-rc6). When I enable debug
I get the following output showing a bunch of errors trying to
communicate with the device MSHW0030, which seems to be the sensor
hub.

I've looked into the code/protocol a little and it seems the initial
feature reports that are returned are of incorrect size, but I don't
understand why without much prior knowledge of the domain.

Any help and/or further debugging tips would be greatly appreciated.

Thanks,
Yani

[ 83.133219] i2c_hid i2c-MSHW0030:00: Fetching the HID descriptor
[ 83.133224] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=01 00
[ 83.134826] i2c_hid i2c-MSHW0030:00: HID Descriptor: 1e 00 00 01 bf
08 02 00 03 00 3f 00 04 00 3f 00 05 00 06 00 5e 04 c4 07 04 00 00 00
00 00
[ 83.134928] i2c_hid i2c-MSHW0030:00: entering i2c_hid_parse
[ 83.134932] i2c_hid i2c-MSHW0030:00: i2c_hid_hwreset
[ 83.134935] i2c_hid i2c-MSHW0030:00: i2c_hid_set_power
[ 83.134938] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 08
[ 83.135629] i2c_hid i2c-MSHW0030:00: resetting...
[ 83.135633] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 01
[ 83.136305] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: waiting...
[ 83.138471] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: finished.
[ 83.138475] i2c_hid i2c-MSHW0030:00: asking HID report descriptor
[ 83.138477] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=02 00
[ 83.191568] i2c_hid i2c-MSHW0030:00: Report Descriptor: 05 20 09 01
a1 01 85 01 05 20 09 73 a1 00 0a 09 03 15 00 25 02 75 08 95 01 a1 02
0a 30 08 0a 31 08 0a 32 08 b1 00 c0 0a 0e 03 15 00 27 ff ff ff ff 75
20 95 01 55 00 b1 02 0a 52 14 15 00 26 ff
[ 83.193819] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.193822] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 31 02 06 00
[ 83.194952] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 01 01 60
00 00 00 14 00 01 06 02 10
[ 83.194957] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.194959] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 32 02 06 00
[ 83.196162] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 02 01 10
00 00 00 00 00 01 06 02 10
[ 83.196166] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.196167] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 33 02 06 00
[ 83.196991] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 03 01 c8
00 00 00 00 00 01 06 02 c8
[ 83.196998] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.197000] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 34 02 06 00
[ 83.198233] i2c_hid i2c-MSHW0030:00: report (len=30): 1e 00 04 01 64
00 00 00 3c 00 0a 00 64 00 0b 00 64 00 40 1f f4 01 41 1f 64 00 01 06
02 64
[ 83.198238] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.198240] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 35 02 06 00
[ 83.199093] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 05 01 10
00 00 00 00 00 01 06 02 10
[ 83.199096] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.199098] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 36 02 06 00
[ 83.199699] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 06 01 10
00 00 00 00 00 01 06 02 10
[ 83.199703] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.199705] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 3f
02 20 06 00
[ 83.202008] i2c_hid i2c-MSHW0030:00: report (len=63): 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
[ 83.202011] i2c_hid i2c-MSHW0030:00: error in i2c_hid_init_report
size:63 / ret_size:0
[ 83.202014] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.202015] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 3f
02 21 06 00
[ 83.204331] i2c_hid i2c-MSHW0030:00: report (len=63): 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
[ 83.204335] i2c_hid i2c-MSHW0030:00: error in i2c_hid_init_report
size:63 / ret_size:0
[ 83.204337] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.204339] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 3f
02 22 06 00
[ 83.205447] i2c_hid i2c-MSHW0030:00: report (len=19): 13 00 22 cb a8
07 02 03 00 00 00 00 00 00 00 00 00 00 00
[ 83.205451] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.205453] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 3f
02 23 06 00
[ 83.206745] i2c_hid i2c-MSHW0030:00: report (len=19): 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 83.206749] i2c_hid i2c-MSHW0030:00: error in i2c_hid_init_report
size:19 / ret_size:0
[ 83.206752] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
[ 83.206753] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 3f
02 24 06 00
[ 83.207780] i2c_hid i2c-MSHW0030:00: report (len=19): 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 83.207783] i2c_hid i2c-MSHW0030:00: 

[PATCH] Input: Delete an unnecessary check before the function call input_free_device

[SF Markus Elfring]

From: Markus Elfring elfr...@users.sourceforge.net
Date: Thu, 5 Feb 2015 17:35:35 +0100

The input_free_device() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
 drivers/input/joystick/adi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/input/joystick/adi.c b/drivers/input/joystick/adi.c
index b784257..d09cefa 100644
--- a/drivers/input/joystick/adi.c
+++ b/drivers/input/joystick/adi.c
@@ -535,8 +535,7 @@ static int adi_connect(struct gameport *gameport, struct 
gameport_driver *drv)
}
}
  fail2:for (i = 0; i  2; i++)
-   if (port-adi[i].dev)
-   input_free_device(port-adi[i].dev);
+   input_free_device(port-adi[i].dev);
gameport_close(gameport);
  fail1:gameport_set_drvdata(gameport, NULL);
kfree(port);
-- 
2.2.2

--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in dtor/input.git/next - flush pending events on clock type change

[Dmitry Torokhov]

On Thu, Feb 05, 2015 at 08:28:28PM -0500, Benjamin Tissoires wrote:
 On Feb 5, 2015 7:04 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
 
  Hi Benjamin,
 
  On Thu, Feb 05, 2015 at 06:06:29PM -0500, Benjamin Tissoires wrote:
   Hi Anshul,
  
   The commit 0c3e99437a66e4c869c60c2398449e6d98f3a988 in
 dtor/input.git/next
   tree introduce an interesting regression in libinput. The tests fail :)
  
   Actually, evemu-record and libinput switch the clock to monotonic when
   opening an input node, and the first thing that gets queued is a
   SYN_DROPPED event.
  
   However, in the libinput test suite, events are the bare minimum, and
   most of the tests contain only one event set (one EV_SYN).
   When seeing the SYN_DROPPED, the clients are supposed to drain the
 events
   until the next EV_SYN, and so they are losing the events that came long
   after the ioctl call.
   And in the end, the test suite does not receive any events.
  
   Removing the evdev_queue_syn_dropped() call in the ioctl handling fixes
   the test suite, and Peter suggested that maybe we should queue a
   SYN_DROPPED event iff there are events in the queue.
 
  Does the following patch fixe it? But I would like to see libinput
  tests more robust.
 
 It does. Thanks for the quick fix.
 
 Regarding libinput tests, I am not sure we could make them more robust in
 this situation. The tests rely on uinput to create predetermined kernel
 devices, with a known set of events. Usually, we test one feature/previous
 bug we already seen in the past per device per test. The mentioned commit
 changed the kernel behavior and I think there is no automatic way to detect
 that the problem lies in the kernel rather than in the libinput event
 processing.
 
 For example, the simplest test creates one mouse, waits for libinput to
 open it, sends REL_X, EV_SYN, and ensures that libinput gets the REL_X
 event. Without this fix, the event is not seen, so the test fails. Which is
 right, because that means that any libinput client will see the first
 events dropped. This is not something we want for our users, especially for
 keyboards, when the first thing you do is typing your password for example.

OK, fair enough. I'll queue the patch with your tested-by then.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] Input - synaptics: do not release extra buttons once they are pressed

[Andrew Duggan]

On 02/04/2015 01:29 PM, Benjamin Tissoires wrote:

On Feb 02 2015 or thereabouts, Benjamin Tissoires wrote:

On Mon, Feb 2, 2015 at 4:46 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:

On Wed, Jan 28, 2015 at 03:10:05PM -0500, Benjamin Tissoires wrote:

The current code releases the extra buttons right after they are pressed.
As soon as a new serio report comes in, the hw state is reset to 0
and so the buttons are released.

Check for the report type before acting on the current extra buttons
state.

No:

If Ext is 0 (if bit 1 of bytes 1 and 4 are the same) then there are no
external buttons being pressed (or all external buttons have been
released). - Synaptics PS/2 TouchPad Interfacing Guide PN:
511-000275-01 Rev. B


Hmm, indeed, the current code follows the spec. Yeah! a new firmware bug!

So when I dumped the ps/2 reports, I clearly saw the release report
being sent with the Ext bit to 1, and other reports were in between
with no information (because no fingers were on the touchpad).


OK, so with the hardware, here are the results:

After each incoming event (being a button or touch), when there is no
more information to send (i.e. touch released or button pressed or
released), I receive 80 times the following buffer:
80 00 00 c0 00 00

The number 80 seems quite consistant, though I got once 96.
Not sure that this repeated buffer might be of interest however.

When a finger is touched on the sensor, I receive the following:

b0 ba 35 c0 8d ed - first finger down on the sensor

b0 ba 3b c0 6f d0
b0 ba 3b c2 6d d0 - button 1 pressed
b0 ba 3b c0 6f d0

b0 ba 3b c0 6f d0
b0 ba 3c c2 6c d0 - button 1 released
b0 ba 3c c0 6f d0

90 ba 26 c0 6f d0
80 00 00 c0 00 00 - first finger released from the sensor
80 00 00 c0 00 00 - repeated 80 times

So here, either the spec is wrong, either the Synaptics with FW 8.1 in
the Lenovos are not following it. But I clearly see that the extended
buttons are reported only when the Ext bit is 1.

Andrew, could you help us determine which way to go?
Ideally, could you point out at a firmware version where we could be
sure that the spec has not been followed so we can add a quirk in the
driver?


I got confirmation that this is a firmware bug and that it has probably 
been there since 2011. This bug is definitely in 8.1 and probably 
several versions before it. But, we haven't shipped anything with 
extended buttons in a long time, so applying the quirk to firmware 
revision 8.1 should be adequate. When we fix the bug we will bump the 
minor version.


Andrew


Cheers,
Benjamin


--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Input - synaptics: re-route tracksticks buttons on the Lenovo 2015 series

[Andrew Duggan]

On 02/05/2015 12:38 PM, Benjamin Tissoires wrote:

Lenovos 2015 series has the physical tracktick buttons wired
through the touchpad. The kernel should re-route them through
the pass-through interface.

Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
---

Hi Dmitry,

Well, in one of your replies regarding the Synaptics Lenovo 2015
series, you mentioned that you wouldn't mind having the trackstick
buttons re-routed through the trackstick (pass-through interface).

I came out with this patch (checkpatch complains a lot about it but
today's setup is not that convenient), and I'd like to hear what you
think of it.

If you agree to go this path, I'll remove the warnings from checkpatch
and do a proper submission.

The patch is still not future proof (if Synaptics updates the board like
they did for the *40 series, we will need to fix this all over again),
so I might have a little bit more of work to do. Anyway, it works.


I discovered that there is a firmware query to determine if the touchpad 
has stick buttons which are wired to the touchpad and are reported as 
extended buttons. Query $01 bit 17 indicates that Query $10 exists. Then 
Query $10 bit 0 indicates indicates the extended buttons should be 
mapped to the guest stick buttons.


Additional information and some diagrams are in the pdf here:
https://www.dropbox.com/s/vv1j4zsytgrw7mm/synaptics-tp-stick-buttons.pdf?dl=0


Cheers,
Benjamin

  drivers/input/mouse/synaptics.c | 55 -
  drivers/input/mouse/synaptics.h |  2 ++
  2 files changed, 46 insertions(+), 11 deletions(-)

diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index fc0099c..e32cac1 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -190,6 +190,11 @@ static const char * const topbuttonpad_pnp_ids[] = {
NULL
  };
  
+static const char * const trackstick_buttons_pnp_ids[] = {

+   LEN0048,
+   NULL
+};
+
  /*
   *Synaptics communications functions
   /
@@ -512,18 +517,20 @@ static int synaptics_is_pt_packet(unsigned char *buf)
return (buf[0]  0xFC) == 0x84  (buf[3]  0xCC) == 0xC4;
  }
  
-static void synaptics_pass_pt_packet(struct serio *ptport, unsigned char *packet)

+static void synaptics_pass_pt_packet(struct psmouse *psmouse, struct serio 
*ptport,
+   unsigned char *packet)
  {
+   struct synaptics_data *priv = psmouse-private;
struct psmouse *child = serio_get_drvdata(ptport);
  
  	if (child  child-state == PSMOUSE_ACTIVATED) {

-   serio_interrupt(ptport, packet[1], 0);
+   serio_interrupt(ptport, packet[1] | priv-pt_buttons, 0);
serio_interrupt(ptport, packet[4], 0);
serio_interrupt(ptport, packet[5], 0);
if (child-pktsize == 4)
serio_interrupt(ptport, packet[2], 0);
} else
-   serio_interrupt(ptport, packet[1], 0);
+   serio_interrupt(ptport, packet[1] | priv-pt_buttons, 0);
  }
  
  static void synaptics_pt_activate(struct psmouse *psmouse)

@@ -782,11 +789,33 @@ static void synaptics_report_buttons(struct psmouse 
*psmouse,
input_report_key(dev, BTN_BACK, hw-down);
}
  
-	for (i = 0; i  ext_bits; i++) {

-   input_report_key(dev, BTN_0 + 2 * i,
-hw-ext_buttons  (1  i));
-   input_report_key(dev, BTN_1 + 2 * i,
-hw-ext_buttons  (1  (i + ext_bits)));
+   if (!priv-override_pt_buttons) {
+   for (i = 0; i  ext_bits; i++) {
+   input_report_key(dev, BTN_0 + 2 * i,
+hw-ext_buttons  (1  i));
+   input_report_key(dev, BTN_1 + 2 * i,
+hw-ext_buttons  (1  (i + 
ext_bits)));
+   }
+   } else {
+   /*
+* This generation of touchpads has the trackstick buttons
+* physically wired to the touchpad. Re-route them through
+* the pass-through interface.
+*/
+   if (priv-pt_port 
+   SYN_CAP_MULTI_BUTTON_NO(priv-ext_cap) 
+   ((psmouse-packet[0] ^ psmouse-packet[3])  0x02)) {
+   char buf[6] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+   priv-pt_buttons = 0x00;
+   /* ext_bits is guaranteed to be = 4 */
+   for (i = 0; i  ext_bits; i++) {
+   if (hw-ext_buttons  (1  i))
+   priv-pt_buttons |= 1  (2 * i);
+   if (hw-ext_buttons  (1  (i + ext_bits)))
+   priv-pt_buttons |= 1 

Re: [RFC] Input - synaptics: re-route tracksticks buttons on the Lenovo 2015 series

[Dmitry Torokhov]

On Thu, Feb 05, 2015 at 05:33:07PM -0800, Andrew Duggan wrote:
 On 02/05/2015 12:38 PM, Benjamin Tissoires wrote:
 Lenovos 2015 series has the physical tracktick buttons wired
 through the touchpad. The kernel should re-route them through
 the pass-through interface.
 
 Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
 ---
 
 Hi Dmitry,
 
 Well, in one of your replies regarding the Synaptics Lenovo 2015
 series, you mentioned that you wouldn't mind having the trackstick
 buttons re-routed through the trackstick (pass-through interface).
 
 I came out with this patch (checkpatch complains a lot about it but
 today's setup is not that convenient), and I'd like to hear what you
 think of it.
 
 If you agree to go this path, I'll remove the warnings from checkpatch
 and do a proper submission.
 
 The patch is still not future proof (if Synaptics updates the board like
 they did for the *40 series, we will need to fix this all over again),
 so I might have a little bit more of work to do. Anyway, it works.
 
 I discovered that there is a firmware query to determine if the
 touchpad has stick buttons which are wired to the touchpad and are
 reported as extended buttons. Query $01 bit 17 indicates that Query
 $10 exists. Then Query $10 bit 0 indicates indicates the extended
 buttons should be mapped to the guest stick buttons.
 
 Additional information and some diagrams are in the pdf here:
 https://www.dropbox.com/s/vv1j4zsytgrw7mm/synaptics-tp-stick-buttons.pdf?dl=0

Awesome, thanks Andrew.

-- 
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] Fixes for ALPS trackstick

[Pali Rohár]

On Monday 02 February 2015 06:49:31 Dmitry Torokhov wrote:
 On Sun, Jan 18, 2015 at 10:47:06AM +0100, Pali Rohár wrote:
  On Sunday 18 January 2015 08:22:45 Dmitry Torokhov wrote:
   On Sat, Jan 17, 2015 at 11:01:56AM +0100, Pali Rohár wrote:
On Thursday 15 January 2015 22:02:16 Dmitry Torokhov 
wrote:
 On Thu, Jan 15, 2015 at 09:28:41PM +0100, Pali Rohár 
wrote:
  On Thursday 15 January 2015 20:38:18 Dmitry Torokhov
  
  wrote:
   On Thu, Jan 15, 2015 at 08:19:59PM +0100, Pali
   Rohár
  
  wrote:
On Thursday 15 January 2015 19:18:20 Dmitry
Torokhov

wrote:
 On Thu, Jan 15, 2015 at 11:49:32AM +0100, Pali
 Rohár

wrote:
  On Wednesday 14 January 2015 23:55:48 Dmitry
  Torokhov
  
  wrote:
   Hi Pali,
   
   This series try to address the issue you
   brought regarding trackstick
   initialization on Dell Latitudes in a
   different way than the patches you
   proposed. Basically in this series we
   move resetting and all detection in
   alps_detect() and make sure we keep the
   state so alps_init() can reuse it and not
   perform the detection all over again.
   Doing this allows us to set up device
   characteristics (name, version, etc)
   properly from the get go while still
   performing reset only once.
   
   This is untested as I do not have any ALPS
   devices anymore so I'd appreciate you
   giving it a spin.
   
   Thanks!
  
  Hi Dmitry,
  
  on top of which branch/repository should I
  apply your patches?
 
 Should be applicable to my 'next' branch
 (which I just upreved to 3.19-rc4).
 
 Thanks.

Not working at top of next (0c3e994).

Applying: Input: ALPS - renumber protocol
numbers Applying: Input: ALPS - make Rushmore a
separate protocol error: patch failed:
drivers/input/mouse/alps.c:1275 error:
drivers/input/mouse/alps.c: patch does not apply
Patch failed at 0002 Input: ALPS - make Rushmore
a separate protocol
   
   Hmm.. I created a new alps branch (based on
   3.19-rc4), can you try it?
   
   Thanks.
  
  Compiled from your new alps branch (with if
  (!priv) fix) and modprobing psmouse.ko caused
  laptop freeze :-( Even sysrq not responded. So
  something is not working...
 
 Hmm, is it on text console or in X? Any chance you
 could go through pathes - there are only 8 of them
 including 2 of yours that should be unmodified.
 
 Thanks.

Hi, now I tested patch by patch and kernel crash is
caused only by last patch 6/6 and only after I touch
touchpad or trackstick.

In text console it prints lot of panic messages and
because it prints lot of messages I cannot read (or
record) more then last.

In last call trace I see that
alps_register_bare_ps2_mouse() was called and it
generated page_fault.
   
   That happens because while you added priv-psmouse pointer
   it looks like you forgot to initialize it and I missed
   that too...
  
  Right your patch 6/6 does not initialize priv-psmouse. I
  looked into my original patch and it initialize it, so
  there was some copy-paste error.
  
  Look at other emails... can you fix problems and send new
  version of your patches for testing?
 
 I think I did. Can you please take another look at my alps
 branch?
 
 Thanks!

You did not fixed commit message which add dev3 device. It should 
be do not mix trackstick 

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: Regression in dtor/input.git/next - flush pending events on clock type change

[Benjamin Tissoires]

On Thu, Feb 5, 2015 at 8:28 PM, Benjamin Tissoires
benjamin.tissoi...@gmail.com wrote:

 On Feb 5, 2015 7:04 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote:

 Hi Benjamin,

 On Thu, Feb 05, 2015 at 06:06:29PM -0500, Benjamin Tissoires wrote:
  Hi Anshul,
 
  The commit 0c3e99437a66e4c869c60c2398449e6d98f3a988 in
  dtor/input.git/next
  tree introduce an interesting regression in libinput. The tests fail :)
 
  Actually, evemu-record and libinput switch the clock to monotonic when
  opening an input node, and the first thing that gets queued is a
  SYN_DROPPED event.
 
  However, in the libinput test suite, events are the bare minimum, and
  most of the tests contain only one event set (one EV_SYN).
  When seeing the SYN_DROPPED, the clients are supposed to drain the
  events
  until the next EV_SYN, and so they are losing the events that came long
  after the ioctl call.
  And in the end, the test suite does not receive any events.
 
  Removing the evdev_queue_syn_dropped() call in the ioctl handling fixes
  the test suite, and Peter suggested that maybe we should queue a
  SYN_DROPPED event iff there are events in the queue.

 Does the following patch fixe it? But I would like to see libinput
 tests more robust.

 It does. Thanks for the quick fix.

 Regarding libinput tests, I am not sure we could make them more robust in
 this situation. The tests rely on uinput to create predetermined kernel
 devices, with a known set of events. Usually, we test one feature/previous
 bug we already seen in the past per device per test. The mentioned commit
 changed the kernel behavior and I think there is no automatic way to detect
 that the problem lies in the kernel rather than in the libinput event
 processing.

 For example, the simplest test creates one mouse, waits for libinput to open
 it, sends REL_X, EV_SYN, and ensures that libinput gets the REL_X event.
 Without this fix, the event is not seen, so the test fails. Which is right,
 because that means that any libinput client will see the first events
 dropped. This is not something we want for our users, especially for
 keyboards, when the first thing you do is typing your password for example.

 Cheers,
 Benjamin


Grmbl, sorry for the dup. Re-sending the mail not from the tablet
which can not send the mail in plain text... :(

Cheers,
Benajmin
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Input - synaptics: re-route tracksticks buttons on the Lenovo 2015 series

[Benjamin Tissoires]

On Thu, Feb 5, 2015 at 8:49 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 On Thu, Feb 05, 2015 at 05:33:07PM -0800, Andrew Duggan wrote:
 On 02/05/2015 12:38 PM, Benjamin Tissoires wrote:
 Lenovos 2015 series has the physical tracktick buttons wired
 through the touchpad. The kernel should re-route them through
 the pass-through interface.
 
 Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
 ---
 
 Hi Dmitry,
 
 Well, in one of your replies regarding the Synaptics Lenovo 2015
 series, you mentioned that you wouldn't mind having the trackstick
 buttons re-routed through the trackstick (pass-through interface).
 
 I came out with this patch (checkpatch complains a lot about it but
 today's setup is not that convenient), and I'd like to hear what you
 think of it.
 
 If you agree to go this path, I'll remove the warnings from checkpatch
 and do a proper submission.
 
 The patch is still not future proof (if Synaptics updates the board like
 they did for the *40 series, we will need to fix this all over again),
 so I might have a little bit more of work to do. Anyway, it works.

 I discovered that there is a firmware query to determine if the
 touchpad has stick buttons which are wired to the touchpad and are
 reported as extended buttons. Query $01 bit 17 indicates that Query
 $10 exists. Then Query $10 bit 0 indicates indicates the extended
 buttons should be mapped to the guest stick buttons.

 Additional information and some diagrams are in the pdf here:
 https://www.dropbox.com/s/vv1j4zsytgrw7mm/synaptics-tp-stick-buttons.pdf?dl=0

 Awesome, thanks Andrew.


Yep, definitively awesome. Also the firmware bump when you will fix
the auto-repeat key will greatly help us.

I'll prepare a patch series tomorrow!

Cheers,
Benjamin
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

EPERM instead of EINVAL?

[simon]

Hi all,
Michal is working on another round of changes for the Logitech wheel
(hid-lg4ff), and we are including code to switch between different modes -
thus allowing a G27 wheel (for example) to emulate a simpler wheel.

At present we automatically 'upgrade' wheel to the best mode they can
handle, we then allow the user to 'downgrade' as they wish.

However, we have to prevent them downgrading to the simplest
(USB_DEVICE_ID_LOGITECH_WHEEL) as when the devices does the USB
detach/attach it would then just upgrade automatically.

We have a module parameter which prevents the automatic upgrade if the
user _really_ wants their expensive wheel to behave like the cheapest.

The code does this:
--
/* Automatic switching has to be disabled for the switch to DF-EX
mode to work
correctly */
if (target_product_id == USB_DEVICE_ID_LOGITECH_WHEEL 
!lg4ff_no_autoswitch) {
hid_info(hid, \%s\ cannot be switched to \DF-EX\
mode. Load the
\hid_logitech\ module with \lg4ff_no_autoswitch=1\ parameter set and try
again.\n,
   entry-real_name);
return -EINVAL;
}
--

So it throws an EINVAL if you try to set simplest when auto-switch is
enabled.

The message on the console is a little confusing, but hid debug explains.
--
root@bigbox:/storage/linux-git# echo DF-EX 
/sys/bus/hid/devices/0003\:046D\:C298.000F/alternate_modes
bash: echo: write error: Invalid argument
--
Feb  4 22:21:01 bigbox kernel: [ 7715.452435] logitech
0003:046D:C298.000F: G27 Racing Wheel cannot be switched to DF-EX
mode. Load the hid_logitech module with lg4ff_no_autoswitch=1
parameter set and try again.
--

Would it make more sense to use EPERM, or is there another error code we
can throw to be more informative.

Thanks,
Simon.

--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: i2c_hid issues with sensor hub on Surface Pro 3

[Yani Ioannou]

Indeed you are correct, looks like one of the devices listed there is
the sensor hub - so I'm barking up the wrong tree.

Will have to move on to the sensor drivers themselves I guess. Thanks
for your help!

Yani

On Thu, Feb 5, 2015 at 6:10 PM, Benjamin Tissoires
benjamin.tissoi...@gmail.com wrote:
 On Thu, Feb 5, 2015 at 12:56 PM, Yani Ioannou yani.ioan...@gmail.com wrote:
 Hi Benjamin,

 As far as I'm aware the sensor hub didn't show up under any kernel (I'll try
 an earlier kernel to figure out if this is true) I didn't mean to say this
 is a regression, sorry.

 Oh, my bad.


 The errors for the MSHW0030 device seem to be fatal - since the initial
 report request fails, the driver doesn't try to work with the device. The
 NTRG device however, is as you suggest, and it is fine - I shouldn't have
 included the output for that device perhaps.

 Not being able to retrieve the reports should not be fatal in i2c_hid.

 There should be 2 devices showing up in:
 /sys/kernel/debug/hid/
 (if you have debugfs mounted in /sys/kernel/debug)

 One of them is the Ntrig (0018:1B96:1B05.*), the other should be the sensor 
 hub.

 Can you paste here the content of the rdesc file which is in the sensor_hub 
 dir?

 And yes, if there is no sensor hub device showing under the hid
 debugfs dir (or under /sys/bus/hid/devices), that means that i2c-hid
 has removed the device.

 Cheers,
 Benjamin


 So in summary I'm trying to work out why the sensor hub driver is never
 loaded, and as far as I can tell this is why.

 Thanks,
 Yani


 On Thu, Feb 5, 2015, 17:44 Benjamin Tissoires benjamin.tissoi...@gmail.com
 wrote:

 Hi,

 On Thu, Feb 5, 2015 at 11:29 AM, Yani Ioannou yani.ioan...@gmail.com
 wrote:
  Hi,
 
  I've been trying to debug why the sensor hub on a Surface pro 3 isn't
  detected in the latest mainline kernel (3.19-rc6). When I enable debug
  I get the following output showing a bunch of errors trying to
  communicate with the device MSHW0030, which seems to be the sensor
  hub.

 These errors do not bother me that much. They appear when we try to
 read the reports from the device, and this has been known to not work
 on many devices.
 As long as the device emits by itself the reports, we are fine.

 There has been very few changes in the v3.19 series regarding i2c-hid,
 so if you get the same debug output on a v3.18 kernel (and the sensor
 hub works), I would think that the problem you are having is in the
 IIO subsystem.

 Cheers,
 Benjamin

 
  I've looked into the code/protocol a little and it seems the initial
  feature reports that are returned are of incorrect size, but I don't
  understand why without much prior knowledge of the domain.
 
  Any help and/or further debugging tips would be greatly appreciated.
 
  Thanks,
  Yani
 
  [ 83.133219] i2c_hid i2c-MSHW0030:00: Fetching the HID descriptor
  [ 83.133224] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=01 00
  [ 83.134826] i2c_hid i2c-MSHW0030:00: HID Descriptor: 1e 00 00 01 bf
  08 02 00 03 00 3f 00 04 00 3f 00 05 00 06 00 5e 04 c4 07 04 00 00 00
  00 00
  [ 83.134928] i2c_hid i2c-MSHW0030:00: entering i2c_hid_parse
  [ 83.134932] i2c_hid i2c-MSHW0030:00: i2c_hid_hwreset
  [ 83.134935] i2c_hid i2c-MSHW0030:00: i2c_hid_set_power
  [ 83.134938] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 08
  [ 83.135629] i2c_hid i2c-MSHW0030:00: resetting...
  [ 83.135633] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 01
  [ 83.136305] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: waiting...
  [ 83.138471] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: finished.
  [ 83.138475] i2c_hid i2c-MSHW0030:00: asking HID report descriptor
  [ 83.138477] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=02 00
  [ 83.191568] i2c_hid i2c-MSHW0030:00: Report Descriptor: 05 20 09 01
  a1 01 85 01 05 20 09 73 a1 00 0a 09 03 15 00 25 02 75 08 95 01 a1 02
  0a 30 08 0a 31 08 0a 32 08 b1 00 c0 0a 0e 03 15 00 27 ff ff ff ff 75
  20 95 01 55 00 b1 02 0a 52 14 15 00 26 ff
  [ 83.193819] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.193822] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 31 02
  06 00
  [ 83.194952] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 01 01 60
  00 00 00 14 00 01 06 02 10
  [ 83.194957] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.194959] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 32 02
  06 00
  [ 83.196162] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 02 01 10
  00 00 00 00 00 01 06 02 10
  [ 83.196166] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.196167] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 33 02
  06 00
  [ 83.196991] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 03 01 c8
  00 00 00 00 00 01 06 02 c8
  [ 83.196998] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.197000] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 34 02
  06 00
  [ 83.198233] i2c_hid i2c-MSHW0030:00: report (len=30): 1e 00 04 01 64
  00 00 00 3c 00 0a 00 64 00 0b 00 64 00 40 1f f4 01 41 1f 64 00 01 06
  02 64

Re: i2c_hid issues with sensor hub on Surface Pro 3

[Benjamin Tissoires]

On Thu, Feb 5, 2015 at 1:44 PM, Yani Ioannou yani.ioan...@gmail.com wrote:
 Indeed you are correct, looks like one of the devices listed there is
 the sensor hub - so I'm barking up the wrong tree.

Not quite actually. If the i2c-hid driver works but the hid-sensor-hub
does not pick up, there is probably an error in hid-sensor-hub.

Could you paste the content of the rdesc file so we can check if
hid-sensor-hub messed up or if your device has a wrong report
descriptor?

Cheers,
Benjamin


 Will have to move on to the sensor drivers themselves I guess. Thanks
 for your help!

 Yani

 On Thu, Feb 5, 2015 at 6:10 PM, Benjamin Tissoires
 benjamin.tissoi...@gmail.com wrote:
 On Thu, Feb 5, 2015 at 12:56 PM, Yani Ioannou yani.ioan...@gmail.com wrote:
 Hi Benjamin,

 As far as I'm aware the sensor hub didn't show up under any kernel (I'll try
 an earlier kernel to figure out if this is true) I didn't mean to say this
 is a regression, sorry.

 Oh, my bad.


 The errors for the MSHW0030 device seem to be fatal - since the initial
 report request fails, the driver doesn't try to work with the device. The
 NTRG device however, is as you suggest, and it is fine - I shouldn't have
 included the output for that device perhaps.

 Not being able to retrieve the reports should not be fatal in i2c_hid.

 There should be 2 devices showing up in:
 /sys/kernel/debug/hid/
 (if you have debugfs mounted in /sys/kernel/debug)

 One of them is the Ntrig (0018:1B96:1B05.*), the other should be the sensor 
 hub.

 Can you paste here the content of the rdesc file which is in the sensor_hub 
 dir?

 And yes, if there is no sensor hub device showing under the hid
 debugfs dir (or under /sys/bus/hid/devices), that means that i2c-hid
 has removed the device.

 Cheers,
 Benjamin


 So in summary I'm trying to work out why the sensor hub driver is never
 loaded, and as far as I can tell this is why.

 Thanks,
 Yani


 On Thu, Feb 5, 2015, 17:44 Benjamin Tissoires benjamin.tissoi...@gmail.com
 wrote:

 Hi,

 On Thu, Feb 5, 2015 at 11:29 AM, Yani Ioannou yani.ioan...@gmail.com
 wrote:
  Hi,
 
  I've been trying to debug why the sensor hub on a Surface pro 3 isn't
  detected in the latest mainline kernel (3.19-rc6). When I enable debug
  I get the following output showing a bunch of errors trying to
  communicate with the device MSHW0030, which seems to be the sensor
  hub.

 These errors do not bother me that much. They appear when we try to
 read the reports from the device, and this has been known to not work
 on many devices.
 As long as the device emits by itself the reports, we are fine.

 There has been very few changes in the v3.19 series regarding i2c-hid,
 so if you get the same debug output on a v3.18 kernel (and the sensor
 hub works), I would think that the problem you are having is in the
 IIO subsystem.

 Cheers,
 Benjamin

 
  I've looked into the code/protocol a little and it seems the initial
  feature reports that are returned are of incorrect size, but I don't
  understand why without much prior knowledge of the domain.
 
  Any help and/or further debugging tips would be greatly appreciated.
 
  Thanks,
  Yani
 
  [ 83.133219] i2c_hid i2c-MSHW0030:00: Fetching the HID descriptor
  [ 83.133224] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=01 00
  [ 83.134826] i2c_hid i2c-MSHW0030:00: HID Descriptor: 1e 00 00 01 bf
  08 02 00 03 00 3f 00 04 00 3f 00 05 00 06 00 5e 04 c4 07 04 00 00 00
  00 00
  [ 83.134928] i2c_hid i2c-MSHW0030:00: entering i2c_hid_parse
  [ 83.134932] i2c_hid i2c-MSHW0030:00: i2c_hid_hwreset
  [ 83.134935] i2c_hid i2c-MSHW0030:00: i2c_hid_set_power
  [ 83.134938] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 08
  [ 83.135629] i2c_hid i2c-MSHW0030:00: resetting...
  [ 83.135633] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 01
  [ 83.136305] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: waiting...
  [ 83.138471] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: finished.
  [ 83.138475] i2c_hid i2c-MSHW0030:00: asking HID report descriptor
  [ 83.138477] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=02 00
  [ 83.191568] i2c_hid i2c-MSHW0030:00: Report Descriptor: 05 20 09 01
  a1 01 85 01 05 20 09 73 a1 00 0a 09 03 15 00 25 02 75 08 95 01 a1 02
  0a 30 08 0a 31 08 0a 32 08 b1 00 c0 0a 0e 03 15 00 27 ff ff ff ff 75
  20 95 01 55 00 b1 02 0a 52 14 15 00 26 ff
  [ 83.193819] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.193822] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 31 02
  06 00
  [ 83.194952] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 01 01 60
  00 00 00 14 00 01 06 02 10
  [ 83.194957] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.194959] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 32 02
  06 00
  [ 83.196162] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 02 01 10
  00 00 00 00 00 01 06 02 10
  [ 83.196166] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.196167] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 33 02
  06 00
  [ 83.196991] 

Re: i2c_hid issues with sensor hub on Surface Pro 3

[Benjamin Tissoires]

On Thu, Feb 5, 2015 at 12:56 PM, Yani Ioannou yani.ioan...@gmail.com wrote:
 Hi Benjamin,

 As far as I'm aware the sensor hub didn't show up under any kernel (I'll try
 an earlier kernel to figure out if this is true) I didn't mean to say this
 is a regression, sorry.

Oh, my bad.


 The errors for the MSHW0030 device seem to be fatal - since the initial
 report request fails, the driver doesn't try to work with the device. The
 NTRG device however, is as you suggest, and it is fine - I shouldn't have
 included the output for that device perhaps.

Not being able to retrieve the reports should not be fatal in i2c_hid.

There should be 2 devices showing up in:
/sys/kernel/debug/hid/
(if you have debugfs mounted in /sys/kernel/debug)

One of them is the Ntrig (0018:1B96:1B05.*), the other should be the sensor hub.

Can you paste here the content of the rdesc file which is in the sensor_hub dir?

And yes, if there is no sensor hub device showing under the hid
debugfs dir (or under /sys/bus/hid/devices), that means that i2c-hid
has removed the device.

Cheers,
Benjamin


 So in summary I'm trying to work out why the sensor hub driver is never
 loaded, and as far as I can tell this is why.

 Thanks,
 Yani


 On Thu, Feb 5, 2015, 17:44 Benjamin Tissoires benjamin.tissoi...@gmail.com
 wrote:

 Hi,

 On Thu, Feb 5, 2015 at 11:29 AM, Yani Ioannou yani.ioan...@gmail.com
 wrote:
  Hi,
 
  I've been trying to debug why the sensor hub on a Surface pro 3 isn't
  detected in the latest mainline kernel (3.19-rc6). When I enable debug
  I get the following output showing a bunch of errors trying to
  communicate with the device MSHW0030, which seems to be the sensor
  hub.

 These errors do not bother me that much. They appear when we try to
 read the reports from the device, and this has been known to not work
 on many devices.
 As long as the device emits by itself the reports, we are fine.

 There has been very few changes in the v3.19 series regarding i2c-hid,
 so if you get the same debug output on a v3.18 kernel (and the sensor
 hub works), I would think that the problem you are having is in the
 IIO subsystem.

 Cheers,
 Benjamin

 
  I've looked into the code/protocol a little and it seems the initial
  feature reports that are returned are of incorrect size, but I don't
  understand why without much prior knowledge of the domain.
 
  Any help and/or further debugging tips would be greatly appreciated.
 
  Thanks,
  Yani
 
  [ 83.133219] i2c_hid i2c-MSHW0030:00: Fetching the HID descriptor
  [ 83.133224] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=01 00
  [ 83.134826] i2c_hid i2c-MSHW0030:00: HID Descriptor: 1e 00 00 01 bf
  08 02 00 03 00 3f 00 04 00 3f 00 05 00 06 00 5e 04 c4 07 04 00 00 00
  00 00
  [ 83.134928] i2c_hid i2c-MSHW0030:00: entering i2c_hid_parse
  [ 83.134932] i2c_hid i2c-MSHW0030:00: i2c_hid_hwreset
  [ 83.134935] i2c_hid i2c-MSHW0030:00: i2c_hid_set_power
  [ 83.134938] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 08
  [ 83.135629] i2c_hid i2c-MSHW0030:00: resetting...
  [ 83.135633] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 01
  [ 83.136305] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: waiting...
  [ 83.138471] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: finished.
  [ 83.138475] i2c_hid i2c-MSHW0030:00: asking HID report descriptor
  [ 83.138477] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=02 00
  [ 83.191568] i2c_hid i2c-MSHW0030:00: Report Descriptor: 05 20 09 01
  a1 01 85 01 05 20 09 73 a1 00 0a 09 03 15 00 25 02 75 08 95 01 a1 02
  0a 30 08 0a 31 08 0a 32 08 b1 00 c0 0a 0e 03 15 00 27 ff ff ff ff 75
  20 95 01 55 00 b1 02 0a 52 14 15 00 26 ff
  [ 83.193819] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.193822] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 31 02
  06 00
  [ 83.194952] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 01 01 60
  00 00 00 14 00 01 06 02 10
  [ 83.194957] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.194959] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 32 02
  06 00
  [ 83.196162] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 02 01 10
  00 00 00 00 00 01 06 02 10
  [ 83.196166] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.196167] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 33 02
  06 00
  [ 83.196991] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 03 01 c8
  00 00 00 00 00 01 06 02 c8
  [ 83.196998] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.197000] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 34 02
  06 00
  [ 83.198233] i2c_hid i2c-MSHW0030:00: report (len=30): 1e 00 04 01 64
  00 00 00 3c 00 0a 00 64 00 0b 00 64 00 40 1f f4 01 41 1f 64 00 01 06
  02 64
  [ 83.198238] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.198240] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 35 02
  06 00
  [ 83.199093] i2c_hid i2c-MSHW0030:00: report (len=14): 0e 00 05 01 10
  00 00 00 00 00 01 06 02 10
  [ 83.199096] i2c_hid i2c-MSHW0030:00: i2c_hid_get_report
  [ 83.199098] 

Re: i2c_hid issues with sensor hub on Surface Pro 3

[Benjamin Tissoires]

On Thu, Feb 5, 2015 at 2:18 PM, Yani Ioannou yani.ioan...@gmail.com wrote:
 Well, this is embarrassing. Turns out I'm just looking in the wrong
 place for them. Looks like they are all there under
 /sys/bus/iio/devices/, but I read somewhere to check
 /proc/bus/input/devices.

Yes, now the hid sensors are handled through IIO.

FWIW, Gnome has some preliminary support for those.


 When I saw all the errors (even without debug) from i2c_hid in the
 kernel log, I assumed too quickly that there was a problem.

 Very sorry to have wasted your time!

No problems, glad you solved your issue.

Cheers,
Benjamin


 benjamin.tissoi...@gmail.com wrote:
 On Thu, Feb 5, 2015 at 1:44 PM, Yani Ioannou yani.ioan...@gmail.com wrote:
 Indeed you are correct, looks like one of the devices listed there is
 the sensor hub - so I'm barking up the wrong tree.

 Not quite actually. If the i2c-hid driver works but the hid-sensor-hub
 does not pick up, there is probably an error in hid-sensor-hub.

 Could you paste the content of the rdesc file so we can check if
 hid-sensor-hub messed up or if your device has a wrong report
 descriptor?

 Cheers,
 Benjamin


 Will have to move on to the sensor drivers themselves I guess. Thanks
 for your help!

 Yani

 On Thu, Feb 5, 2015 at 6:10 PM, Benjamin Tissoires
 benjamin.tissoi...@gmail.com wrote:
 On Thu, Feb 5, 2015 at 12:56 PM, Yani Ioannou yani.ioan...@gmail.com 
 wrote:
 Hi Benjamin,

 As far as I'm aware the sensor hub didn't show up under any kernel (I'll 
 try
 an earlier kernel to figure out if this is true) I didn't mean to say this
 is a regression, sorry.

 Oh, my bad.


 The errors for the MSHW0030 device seem to be fatal - since the initial
 report request fails, the driver doesn't try to work with the device. The
 NTRG device however, is as you suggest, and it is fine - I shouldn't have
 included the output for that device perhaps.

 Not being able to retrieve the reports should not be fatal in i2c_hid.

 There should be 2 devices showing up in:
 /sys/kernel/debug/hid/
 (if you have debugfs mounted in /sys/kernel/debug)

 One of them is the Ntrig (0018:1B96:1B05.*), the other should be the 
 sensor hub.

 Can you paste here the content of the rdesc file which is in the 
 sensor_hub dir?

 And yes, if there is no sensor hub device showing under the hid
 debugfs dir (or under /sys/bus/hid/devices), that means that i2c-hid
 has removed the device.

 Cheers,
 Benjamin


 So in summary I'm trying to work out why the sensor hub driver is never
 loaded, and as far as I can tell this is why.

 Thanks,
 Yani


 On Thu, Feb 5, 2015, 17:44 Benjamin Tissoires 
 benjamin.tissoi...@gmail.com
 wrote:

 Hi,

 On Thu, Feb 5, 2015 at 11:29 AM, Yani Ioannou yani.ioan...@gmail.com
 wrote:
  Hi,
 
  I've been trying to debug why the sensor hub on a Surface pro 3 isn't
  detected in the latest mainline kernel (3.19-rc6). When I enable debug
  I get the following output showing a bunch of errors trying to
  communicate with the device MSHW0030, which seems to be the sensor
  hub.

 These errors do not bother me that much. They appear when we try to
 read the reports from the device, and this has been known to not work
 on many devices.
 As long as the device emits by itself the reports, we are fine.

 There has been very few changes in the v3.19 series regarding i2c-hid,
 so if you get the same debug output on a v3.18 kernel (and the sensor
 hub works), I would think that the problem you are having is in the
 IIO subsystem.

 Cheers,
 Benjamin

 
  I've looked into the code/protocol a little and it seems the initial
  feature reports that are returned are of incorrect size, but I don't
  understand why without much prior knowledge of the domain.
 
  Any help and/or further debugging tips would be greatly appreciated.
 
  Thanks,
  Yani
 
  [ 83.133219] i2c_hid i2c-MSHW0030:00: Fetching the HID descriptor
  [ 83.133224] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=01 00
  [ 83.134826] i2c_hid i2c-MSHW0030:00: HID Descriptor: 1e 00 00 01 bf
  08 02 00 03 00 3f 00 04 00 3f 00 05 00 06 00 5e 04 c4 07 04 00 00 00
  00 00
  [ 83.134928] i2c_hid i2c-MSHW0030:00: entering i2c_hid_parse
  [ 83.134932] i2c_hid i2c-MSHW0030:00: i2c_hid_hwreset
  [ 83.134935] i2c_hid i2c-MSHW0030:00: i2c_hid_set_power
  [ 83.134938] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 
  08
  [ 83.135629] i2c_hid i2c-MSHW0030:00: resetting...
  [ 83.135633] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=05 00 00 
  01
  [ 83.136305] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: waiting...
  [ 83.138471] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: finished.
  [ 83.138475] i2c_hid i2c-MSHW0030:00: asking HID report descriptor
  [ 83.138477] i2c_hid i2c-MSHW0030:00: __i2c_hid_command: cmd=02 00
  [ 83.191568] i2c_hid i2c-MSHW0030:00: Report Descriptor: 05 20 09 01
  a1 01 85 01 05 20 09 73 a1 00 0a 09 03 15 00 25 02 75 08 95 01 a1 02
  0a 30 08 0a 31 08 0a 32 08 b1 00 c0 0a 0e 03 15 00 27 ff ff ff ff 75
  20 95 01 55 00 

[RFC] Input - synaptics: re-route tracksticks buttons on the Lenovo 2015 series

[Benjamin Tissoires]

Lenovos 2015 series has the physical tracktick buttons wired
through the touchpad. The kernel should re-route them through
the pass-through interface.

Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
---

Hi Dmitry,

Well, in one of your replies regarding the Synaptics Lenovo 2015
series, you mentioned that you wouldn't mind having the trackstick
buttons re-routed through the trackstick (pass-through interface).

I came out with this patch (checkpatch complains a lot about it but
today's setup is not that convenient), and I'd like to hear what you
think of it.

If you agree to go this path, I'll remove the warnings from checkpatch
and do a proper submission.

The patch is still not future proof (if Synaptics updates the board like
they did for the *40 series, we will need to fix this all over again),
so I might have a little bit more of work to do. Anyway, it works.

Cheers,
Benjamin

 drivers/input/mouse/synaptics.c | 55 -
 drivers/input/mouse/synaptics.h |  2 ++
 2 files changed, 46 insertions(+), 11 deletions(-)

diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index fc0099c..e32cac1 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -190,6 +190,11 @@ static const char * const topbuttonpad_pnp_ids[] = {
NULL
 };
 
+static const char * const trackstick_buttons_pnp_ids[] = {
+   LEN0048,
+   NULL
+};
+
 /*
  * Synaptics communications functions
  /
@@ -512,18 +517,20 @@ static int synaptics_is_pt_packet(unsigned char *buf)
return (buf[0]  0xFC) == 0x84  (buf[3]  0xCC) == 0xC4;
 }
 
-static void synaptics_pass_pt_packet(struct serio *ptport, unsigned char 
*packet)
+static void synaptics_pass_pt_packet(struct psmouse *psmouse, struct serio 
*ptport,
+   unsigned char *packet)
 {
+   struct synaptics_data *priv = psmouse-private;
struct psmouse *child = serio_get_drvdata(ptport);
 
if (child  child-state == PSMOUSE_ACTIVATED) {
-   serio_interrupt(ptport, packet[1], 0);
+   serio_interrupt(ptport, packet[1] | priv-pt_buttons, 0);
serio_interrupt(ptport, packet[4], 0);
serio_interrupt(ptport, packet[5], 0);
if (child-pktsize == 4)
serio_interrupt(ptport, packet[2], 0);
} else
-   serio_interrupt(ptport, packet[1], 0);
+   serio_interrupt(ptport, packet[1] | priv-pt_buttons, 0);
 }
 
 static void synaptics_pt_activate(struct psmouse *psmouse)
@@ -782,11 +789,33 @@ static void synaptics_report_buttons(struct psmouse 
*psmouse,
input_report_key(dev, BTN_BACK, hw-down);
}
 
-   for (i = 0; i  ext_bits; i++) {
-   input_report_key(dev, BTN_0 + 2 * i,
-hw-ext_buttons  (1  i));
-   input_report_key(dev, BTN_1 + 2 * i,
-hw-ext_buttons  (1  (i + ext_bits)));
+   if (!priv-override_pt_buttons) {
+   for (i = 0; i  ext_bits; i++) {
+   input_report_key(dev, BTN_0 + 2 * i,
+hw-ext_buttons  (1  i));
+   input_report_key(dev, BTN_1 + 2 * i,
+hw-ext_buttons  (1  (i + 
ext_bits)));
+   }
+   } else {
+   /* 
+* This generation of touchpads has the trackstick buttons
+* physically wired to the touchpad. Re-route them through
+* the pass-through interface.
+*/
+   if (priv-pt_port 
+   SYN_CAP_MULTI_BUTTON_NO(priv-ext_cap) 
+   ((psmouse-packet[0] ^ psmouse-packet[3])  0x02)) {
+   char buf[6] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+   priv-pt_buttons = 0x00;
+   /* ext_bits is guaranteed to be = 4 */
+   for (i = 0; i  ext_bits; i++) {
+   if (hw-ext_buttons  (1  i))
+   priv-pt_buttons |= 1  (2 * i);
+   if (hw-ext_buttons  (1  (i + ext_bits)))
+   priv-pt_buttons |= 1  (2 * i + 1);
+   }
+   synaptics_pass_pt_packet(psmouse, priv-pt_port, buf);
+   }
}
 }
 
@@ -1008,7 +1037,8 @@ static psmouse_ret_t synaptics_process_byte(struct 
psmouse *psmouse)
if (SYN_CAP_PASS_THROUGH(priv-capabilities) 
synaptics_is_pt_packet(psmouse-packet)) {
if (priv-pt_port)
-   synaptics_pass_pt_packet(priv-pt_port, 
psmouse-packet);
+