* Re: [PATCH 3/3] synaptics: Change min/max quirk table to pnp-id matching
From: Hans de Goede @ 2014-05-26 11:47 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Peter Hutterer, Benjamin Tissoires, linux-input, stable
In-Reply-To: <5379C5FD.1040401@redhat.com>
Hi Dmitry,
On 05/19/2014 10:51 AM, Hans de Goede wrote:
> Hi,
>
> On 05/18/2014 10:35 PM, Dmitry Torokhov wrote:
>> On Fri, May 16, 2014 at 08:46:49PM +0200, Hans de Goede wrote:
>>> Most of the affected models share pnp-ids for the touchpad. So switching
>>> to pnp-ids give us 2 advantages:
>>> 1) It shrinks the quirk list
>>> 2) It will lower the new quirk addition frequency, ie the recently added W540
>>> quirk would not have been necessary since it uses the same LEN0034 pnp ids
>>> as other models already added before it
>>>
>>> As an added bonus it actually puts the quirk on the actual psmouse, rather then
>>> on the machine, which is technically more correct.
>>>
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>> drivers/input/mouse/synaptics.c | 149 ++++++++++------------------------------
>>> 1 file changed, 36 insertions(+), 113 deletions(-)
>>>
>>> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
>>> index 395ec9c..c5ec703 100644
>>> --- a/drivers/input/mouse/synaptics.c
>>> +++ b/drivers/input/mouse/synaptics.c
>>> @@ -117,6 +117,31 @@ void synaptics_reset(struct psmouse *psmouse)
>>> }
>>>
>>> #ifdef CONFIG_MOUSE_PS2_SYNAPTICS
>>> +struct min_max_quirk {
>>> + const char * const *pnp_ids;
>>> + int x_min, x_max, y_min, y_max;
>>> +};
>>
>>
>> Why don't we define this as 1 quirk per PNP id?
>>
>> struct min_max_quirk {
>> const char *pnp_id;
>> int x_min, x_max, y_min, y_max;
>> };
>>
>> ?
>
> 1) I thought it would be better to allow multiple ids for one min/max quad,
> since there seem to only be a few types of touchpads out there, which are
> sometimes referenced to by multiple ids. IE LEN0034 and LEN2004 refer to the
> exact same touchpad (exact same firmware and board id). Also this way we avoid
> people adding entries with values which are slightly off since determining
> the min/max range on a single model will give some noise.
>
> 2) This way we can use one helper function for the matching for both the
> INPUT_PROP_TOPBUTTONPAD quirks and for the min/max quirks.
I've not heard back from you on this, does that mean that you are ok with
taking this patch-set as is ?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] HID: Debug: Add labels for HID Sensor Usages
From: Jiri Kosina @ 2014-05-26 8:37 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Reyad Attiyat, linux-iio, linux-kernel, linux-input,
Srinivas Pandruvada
In-Reply-To: <53807397.9080807@kernel.org>
On Sat, 24 May 2014, Jonathan Cameron wrote:
> This looks reasonable to me, but I haven't checked every entry. Also
> Reyad, you need to sign off on the patch if you expect anyone to pick it
> up.
>
> Jiri, this is one for you. (note Jiri should probably have been cc'd in the
> first place as the HID maintainer - unless he specifically asked not to be).
I definitely want (and need) to be CCed on such patches, thanks for
letting me know, Jonathan.
Reyad, please add you signoff as Jonathan said, and resend the patch
properly to me.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Input: mc13783-pwrbutton: Allocate resources using managed interfaces
From: Dmitry Torokhov @ 2014-05-26 5:32 UTC (permalink / raw)
To: Himangi Saraogi; +Cc: linux-input, linux-kernel, julia.lawall
In-Reply-To: <20140525101400.GA19075@himangi-Dell>
On Sun, May 25, 2014 at 03:44:01PM +0530, Himangi Saraogi wrote:
> This patch moves most data allocated in the probe function from
> unmanaged interfaces to managed interfaces. The kfrees and error
> handling code is done away with. The unnecesary labels are
> removed. Also, linux/device.h is added to make sure the devm_*()
> routine declarations are unambiguously available. The name of label
> free_priv is changed to unlock as it does not free priv anymore.
>
> The following Coccinelle semantic patch was used for making a part of
> the change:
>
> @platform@
> identifier p, probefn, removefn;
> @@
> struct platform_driver p = {
> .probe = probefn,
> .remove = removefn,
> };
>
> @prb@
> identifier platform.probefn, pdev;
> expression e, e1, e2;
> @@
> probefn(struct platform_device *pdev, ...) {
> <+...
> - e = kzalloc(e1, e2)
> + e = devm_kzalloc(&pdev->dev, e1, e2)
> ...
> ?-kfree(e);
> ...+>
> }
>
> @rem depends on prb@
> identifier platform.removefn;
> expression e;
> @@
> removefn(...) {
> <...
> - kfree(e);
> ...>
> }
>
> Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
> Acked-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
> Not compiled due to incompatible architecture.
>
> mc13xxx_irq_request is not devm'd, and doing so looks complicated due to
> the locks around the frees. Is there some way to resolve this issue?
Yes there us - let's leave the driver as is so we are not mixing the 2
styles.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: jornada680_kbd: Allocate resources using managed interfaces
From: Dmitry Torokhov @ 2014-05-26 5:31 UTC (permalink / raw)
To: Himangi Saraogi; +Cc: linux-input, linux-kernel, julia.lawall
In-Reply-To: <20140524121709.GA6504@himangi-Dell>
On Sat, May 24, 2014 at 05:47:09PM +0530, Himangi Saraogi wrote:
> This patch moves most data allocated in the probe function from
> unmanaged interfaces to managed interfaces. The kfrees and error
> handling code is done away with. Also, the unnecesary labels are
> removed and the function mrstouch_remove is removed as it becomes
> empty after removing the no longer required function calls. Also,
> linux/device.h is added to make sure the devm_*() routine declarations
> are unambiguously available.
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 20/51] Input: atmel_mxt_ts - Set default irqflags when there is no pdata
From: Dmitry Torokhov @ 2014-05-26 5:23 UTC (permalink / raw)
To: Yufeng Shen
Cc: Nick Dyer, Benson Leung, Henrik Rydberg, Daniel Kurtz,
Joonyoung Shim, Alan Bowens, linux-input,
linux-kernel@vger.kernel.org, Peter Meerwald, Olof Johansson
In-Reply-To: <CAPDwgkP5KjP6PcZBeYTMPuewO4exyUFfCX8rhzmgDO65ti=3Mg@mail.gmail.com>
On Fri, May 23, 2014 at 12:37:46PM -0400, Yufeng Shen wrote:
> On Thu, May 22, 2014 at 10:29 AM, Nick Dyer <nick.dyer@itdev.co.uk> wrote:
> >
> > Dmitry Torokhov wrote:
> > > On Thu, Jul 18, 2013 at 07:17:44PM +0200, rydberg@euromail.se wrote:
> > >>> From: Yufeng Shen <miletus@chromium.org>
> > >>> This is the preparation for supporting the code path when there is
> > >>> platform data provided and still boot the device into a sane state
> > >>> with backup NVRAM config.
> > >>>
> > >>> Make the irqflags default to be IRQF_TRIGGER_FALLING if no platform data is
> > >>> provided.
> > >
> > > I think if there is no platform data we should use 0 as IRQ falgs and
> > > assume that IRQ line is properly configured by the board code or via
> > > device tree.
> >
> > Beson/Yufeng - do you still have a requirement to probe without platform
> > data or device tree? I'm just merging in some changes to add device tree
> > support, and it would simplify things a bit if I can drop this patch.
>
>
> It has been working for quite a while for boards/devices that don't
> provide platform
> data. If we drop the default IRQ flags, sure we can add code for each
> board to configure
> the IRQ separately, but that's just adding extra work. Is there strong
> reason why we
> should not do the default setting in the driver if it is not already
> configured in platform
> data ?
I am not saying that board code needs to add platform data. I am saying
that the board code needs to set up interrupt properly (via
irq_set_irq_type() or similar) and then the driver can use 0 as irqflags
argument in request_irq() in absence of DT/platform data.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: gpio_keys: Add IRQF_NO_SUSPEND flag to wake-up from freeze state
From: Sachin Kamat @ 2014-05-26 5:02 UTC (permalink / raw)
To: Chanwoo Choi; +Cc: LKML, Dmitry Torokhov, linux-input@vger.kernel.org
In-Reply-To: <1401080234-31174-1-git-send-email-cw00.choi@samsung.com>
Hi Chanwoo,
On 26 May 2014 10:27, Chanwoo Choi <cw00.choi@samsung.com> wrote:
> This patch add IRQF_NO_SUSPEND flag before requesting interrupt handler
> if button->wakeup is true. If ther interrupt of gpio-keys hasn't included
> IRQF_NO_SUSPEND, wouldn't wake-up from freeze state when pressing button.
Please refer to the below thread. Looks like it was similar to what
you are proposing.
http://www.spinics.net/lists/linux-input/msg28780.html
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH] input: gpio_keys: Add IRQF_NO_SUSPEND flag to wake-up from freeze state
From: Chanwoo Choi @ 2014-05-26 4:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Chanwoo Choi, Dmitry Torokhov, Sachin Kamat, linux-input
This patch add IRQF_NO_SUSPEND flag before requesting interrupt handler
if button->wakeup is true. If ther interrupt of gpio-keys hasn't included
IRQF_NO_SUSPEND, wouldn't wake-up from freeze state when pressing button.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/input/keyboard/gpio_keys.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 2db1324..40f3963 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -503,6 +503,9 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
if (!button->can_disable)
irqflags |= IRQF_SHARED;
+ if (button->wakeup)
+ irqflags |= IRQF_NO_SUSPEND;
+
error = request_any_context_irq(bdata->irq, isr, irqflags, desc, bdata);
if (error < 0) {
dev_err(dev, "Unable to claim irq %d; error %d\n",
--
1.8.0
^ permalink raw reply related
* Re: Additional driver for USB touch support
From: Prajosh Premdas @ 2014-05-25 21:14 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: daniel.ritz, linux-input, Henrik Rydberg
In-Reply-To: <CAN+gG=HA1Y-aJbt+RHYfoWJfPeypduCaCE5NKNLJJBhtMa4C6g@mail.gmail.com>
Hi Benjamin
Thanks for the suggestion. I have a slight probem.
I am able to send the commands on the control endpoint 0. But i get
the response on the interrupt endpoint which is also used by the touch
interface. And response data starts with 06 which had been used to
differenciate the touch data with 01 i.e. Report ID (I know this is a
stupid design but cant change for this is a legacy system).
Since a report ID with 06 is not mentioned in the Report descriptor
this message is not forwarded to the driver even as raw data. I am
able to read the touch data which uses the correct Report ID but not
this data. If i change the report ID to 01 I get teh data but I cannot
do this in the final system as this breaks our tools in Windows. Is
there any solution to get this data up?
On Fri, May 23, 2014 at 2:51 PM, Benjamin Tissoires
<benjamin.tissoires@gmail.com> wrote:
> Hi Prajosh,
>
> On Fri, May 23, 2014 at 6:55 AM, Prajosh Premdas
> <premdas.prajosh@gmail.com> wrote:
>> Hi
>>
>> I have some USB based touch controllers. These controllers are working
>> well using the hid_multitouch driver.
>>
>> I would also like to add some additional protocol support for
>> diagnostics and re calibration. I am using the touch interface for the
>> same, whereby the control endpoint is used to send the request and
>> digitizer end point is used to get the response. (it is a legacy
>> design so i cannot change it)
>>
>> My plan is to add the additional driver support to this file
>> drivers/input/touchscreen/usbtouchscreen.c and disable the default
>> support for the hid_multitouch by making an entry in the hid-blacklist
>> array in this file drivers/hid/usbhid/hid-quirks.c
>
> 2 things:
> - adding the device to hid-blacklist either in hid-quirks or
> hid-core.c will not help, the device will still be bound to the HID
> subsystem, and the usb driver will not be able to catch it. If you
> were to go to this road, you would have to add the VID/PID to
> hid-ignore in hid-core.c
> - I don't think it is a good idea to move from hid-multitouch to
> usbtouchscreen: as far as I know, this driver only support single
> touch devices, and it will be a burden to implement the multitouch
> part
>
>>
>> Is there a better idea than this?
>
> If you need to talk to the device through the control endpoint and get
> the responses through the interrupt endpoint, hidraw seems to be
> perfect for your case:
> you can either use the ioctl HIDIOCSFEATURE or directly write on the
> hidraw node to send reports, and reading back to the node will give
> you the interrupts. Bonus point, you are enterily in userspace, so no
> risk of crashing your kernel. Then, you just set up an udev rule if
> you need the commands to be launched at plug.
>
> You can find an example in samples/hidraw/hid-example.c in the kernel tree.
>
> Cheers,
> Benjamin
--
Regards,
Prajosh Premdas
^ permalink raw reply
* [PATCH] Input: mc13783-pwrbutton: Allocate resources using managed interfaces
From: Himangi Saraogi @ 2014-05-25 10:14 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, linux-kernel; +Cc: julia.lawall
This patch moves most data allocated in the probe function from
unmanaged interfaces to managed interfaces. The kfrees and error
handling code is done away with. The unnecesary labels are
removed. Also, linux/device.h is added to make sure the devm_*()
routine declarations are unambiguously available. The name of label
free_priv is changed to unlock as it does not free priv anymore.
The following Coccinelle semantic patch was used for making a part of
the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
<+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(&pdev->dev, e1, e2)
...
?-kfree(e);
...+>
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
<...
- kfree(e);
...>
}
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
Not compiled due to incompatible architecture.
mc13xxx_irq_request is not devm'd, and doing so looks complicated due to
the locks around the frees. Is there some way to resolve this issue?
To send to: Dmitry Torokhov <dmitry.torokhov@gmail.com>,linux-input@vger.kernel.org,linux-kernel@vger.kernel.org
drivers/input/misc/mc13783-pwrbutton.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
index 0df6e8d..6afea1a 100644
--- a/drivers/input/misc/mc13783-pwrbutton.c
+++ b/drivers/input/misc/mc13783-pwrbutton.c
@@ -28,6 +28,7 @@
#include <linux/mfd/mc13783.h>
#include <linux/sched.h>
#include <linux/slab.h>
+#include <linux/device.h>
struct mc13783_pwrb {
struct input_dev *pwr;
@@ -103,17 +104,16 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
return -ENODEV;
}
- pwr = input_allocate_device();
+ pwr = devm_input_allocate_device(&pdev->dev);
if (!pwr) {
dev_dbg(&pdev->dev, "Can't allocate power button\n");
return -ENOMEM;
}
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
- err = -ENOMEM;
dev_dbg(&pdev->dev, "Can't allocate power button\n");
- goto free_input_dev;
+ return -ENOMEM;
}
reg |= (pdata->b1on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON1BDBNC;
@@ -140,7 +140,7 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
button_irq, "b1on", priv);
if (err) {
dev_dbg(&pdev->dev, "Can't request irq\n");
- goto free_priv;
+ goto unlock;
}
}
@@ -219,12 +219,8 @@ free_irq_b1:
if (pdata->b1on_flags & MC13783_BUTTON_ENABLE)
mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD1, priv);
-free_priv:
+unlock:
mc13xxx_unlock(mc13783);
- kfree(priv);
-
-free_input_dev:
- input_free_device(pwr);
return err;
}
@@ -247,9 +243,6 @@ static int mc13783_pwrbutton_remove(struct platform_device *pdev)
mc13xxx_unlock(priv->mc13783);
- input_unregister_device(priv->pwr);
- kfree(priv);
-
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 20/51] Input: atmel_mxt_ts - Set default irqflags when there is no pdata
From: Nick Dyer @ 2014-05-24 12:41 UTC (permalink / raw)
To: Yufeng Shen
Cc: Benson Leung, Dmitry Torokhov, Henrik Rydberg, Daniel Kurtz,
Joonyoung Shim, Alan Bowens, linux-input,
linux-kernel@vger.kernel.org, Peter Meerwald, Olof Johansson
In-Reply-To: <CAPDwgkP5KjP6PcZBeYTMPuewO4exyUFfCX8rhzmgDO65ti=3Mg@mail.gmail.com>
Yufeng Shen wrote:
> On Thu, May 22, 2014 at 10:29 AM, Nick Dyer <nick.dyer@itdev.co.uk> wrote:
>> Dmitry Torokhov wrote:
>>>>> Make the irqflags default to be IRQF_TRIGGER_FALLING if no platform data is
>>>>> provided.
>>>
>>> I think if there is no platform data we should use 0 as IRQ falgs and
>>> assume that IRQ line is properly configured by the board code or via
>>> device tree.
>>
>> Benson/Yufeng - do you still have a requirement to probe without platform
>> data or device tree? I'm just merging in some changes to add device tree
>> support, and it would simplify things a bit if I can drop this patch.
>
> It has been working for quite a while for boards/devices that don't
> provide platform data. If we drop the default IRQ flags, sure we can add
> code for each board to configure the IRQ separately, but that's just
> adding extra work. Is there strong reason why we should not do the
> default setting in the driver if it is not already configured in
> platform data?
OK, I will keep it in my tree for the moment, since you are using it.
The reason I checked is that in general, I would like to be conservative
about what is pushed upstream, because it will need maintaining for a long
time.
The other reason is that in fact Atmel recommend IRQF_TRIGGER_LOW for these
chips, not IRQF_TRIGGER_FALLING, so there is a bit of an inconsistency here.
^ permalink raw reply
* [PATCH] input: tc3589x-keypad: Allocate resources using managed interfaces
From: Himangi Saraogi @ 2014-05-24 12:18 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, linux-kernel; +Cc: julia.lawall
This patch moves most data allocated in the probe function from
unmanaged interfaces to managed interfaces. The kfrees and error
handling code is done away with. Also, the unnecesary labels are
removed. The include for linux/device.h is added to make sure the
devm_*() routine declarations are unambiguously available.
The following Coccinelle semantic patch was used for making a part of
the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
<+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(&pdev->dev, e1, e2)
...
?-kfree(e);
...+>
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
<...
- kfree(e);
...>
}
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
---
drivers/input/keyboard/tc3589x-keypad.c | 35 +++++++++++----------------------
1 file changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/input/keyboard/tc3589x-keypad.c b/drivers/input/keyboard/tc3589x-keypad.c
index ad7abae..c412abe 100644
--- a/drivers/input/keyboard/tc3589x-keypad.c
+++ b/drivers/input/keyboard/tc3589x-keypad.c
@@ -17,6 +17,7 @@
#include <linux/i2c.h>
#include <linux/slab.h>
#include <linux/mfd/tc3589x.h>
+#include <linux/device.h>
/* Maximum supported keypad matrix row/columns size */
#define TC3589x_MAX_KPROW 8
@@ -376,12 +377,12 @@ static int tc3589x_keypad_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
- keypad = kzalloc(sizeof(struct tc_keypad), GFP_KERNEL);
- input = input_allocate_device();
+ keypad = devm_kzalloc(&pdev->dev, sizeof(struct tc_keypad),
+ GFP_KERNEL);
+ input = devm_input_allocate_device(&pdev->dev);
if (!keypad || !input) {
dev_err(&pdev->dev, "failed to allocate keypad memory\n");
- error = -ENOMEM;
- goto err_free_mem;
+ return -ENOMEM;
}
keypad->board = plat;
@@ -400,7 +401,7 @@ static int tc3589x_keypad_probe(struct platform_device *pdev)
NULL, input);
if (error) {
dev_err(&pdev->dev, "Failed to build keymap\n");
- goto err_free_mem;
+ return error;
}
keypad->keymap = input->keycode;
@@ -411,20 +412,20 @@ static int tc3589x_keypad_probe(struct platform_device *pdev)
input_set_drvdata(input, keypad);
- error = request_threaded_irq(irq, NULL,
- tc3589x_keypad_irq, plat->irqtype,
- "tc3589x-keypad", keypad);
+ error = devm_request_threaded_irq(&pdev->dev, irq, NULL,
+ tc3589x_keypad_irq, plat->irqtype,
+ "tc3589x-keypad", keypad);
if (error < 0) {
dev_err(&pdev->dev,
"Could not allocate irq %d,error %d\n",
irq, error);
- goto err_free_mem;
+ return error;
}
error = input_register_device(input);
if (error) {
dev_err(&pdev->dev, "Could not register input device\n");
- goto err_free_irq;
+ return error;
}
/* let platform decide if keypad is a wakeup source or not */
@@ -434,29 +435,15 @@ static int tc3589x_keypad_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, keypad);
return 0;
-
-err_free_irq:
- free_irq(irq, keypad);
-err_free_mem:
- input_free_device(input);
- kfree(keypad);
- return error;
}
static int tc3589x_keypad_remove(struct platform_device *pdev)
{
struct tc_keypad *keypad = platform_get_drvdata(pdev);
- int irq = platform_get_irq(pdev, 0);
if (!keypad->keypad_stopped)
tc3589x_keypad_disable(keypad);
- free_irq(irq, keypad);
-
- input_unregister_device(keypad->input);
-
- kfree(keypad);
-
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH] input: jornada680_kbd: Allocate resources using managed interfaces
From: Himangi Saraogi @ 2014-05-24 12:17 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, linux-kernel; +Cc: julia.lawall
This patch moves most data allocated in the probe function from
unmanaged interfaces to managed interfaces. The kfrees and error
handling code is done away with. Also, the unnecesary labels are
removed and the function mrstouch_remove is removed as it becomes
empty after removing the no longer required function calls. Also,
linux/device.h is added to make sure the devm_*() routine declarations
are unambiguously available.
The following Coccinelle semantic patch was used for making a part of
the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
<+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(&pdev->dev, e1, e2)
...
?-kfree(e);
...+>
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
<...
- kfree(e);
...>
}
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
---
Not compile tested due to incompatible architecture.
drivers/input/keyboard/jornada680_kbd.c | 21 ++++-----------------
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/input/keyboard/jornada680_kbd.c b/drivers/input/keyboard/jornada680_kbd.c
index 69b1f00..806dc6b 100644
--- a/drivers/input/keyboard/jornada680_kbd.c
+++ b/drivers/input/keyboard/jornada680_kbd.c
@@ -16,6 +16,7 @@
* published by the Free Software Foundation.
*/
+#include <linux/device.h>
#include <linux/input.h>
#include <linux/input-polldev.h>
#include <linux/interrupt.h>
@@ -185,11 +186,12 @@ static int jornada680kbd_probe(struct platform_device *pdev)
struct input_dev *input_dev;
int i, error;
- jornadakbd = kzalloc(sizeof(struct jornadakbd), GFP_KERNEL);
+ jornadakbd = devm_kzalloc(&pdev->dev, sizeof(struct jornadakbd),
+ GFP_KERNEL);
if (!jornadakbd)
return -ENOMEM;
- poll_dev = input_allocate_polled_device();
+ poll_dev = devm_input_allocate_polled_device(&pdev->dev);
if (!poll_dev) {
error = -ENOMEM;
goto failed;
@@ -232,21 +234,7 @@ static int jornada680kbd_probe(struct platform_device *pdev)
failed:
printk(KERN_ERR "Jornadakbd: failed to register driver, error: %d\n",
error);
- input_free_polled_device(poll_dev);
- kfree(jornadakbd);
return error;
-
-}
-
-static int jornada680kbd_remove(struct platform_device *pdev)
-{
- struct jornadakbd *jornadakbd = platform_get_drvdata(pdev);
-
- input_unregister_polled_device(jornadakbd->poll_dev);
- input_free_polled_device(jornadakbd->poll_dev);
- kfree(jornadakbd);
-
- return 0;
}
static struct platform_driver jornada680kbd_driver = {
@@ -255,7 +243,6 @@ static struct platform_driver jornada680kbd_driver = {
.owner = THIS_MODULE,
},
.probe = jornada680kbd_probe,
- .remove = jornada680kbd_remove,
};
module_platform_driver(jornada680kbd_driver);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] HID: hid-sensor-hub: Fix lockdep warning for dynamic callback locks.
From: Jonathan Cameron @ 2014-05-24 10:32 UTC (permalink / raw)
To: Reyad Attiyat, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-input,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Srinivas Pandruvada,
Jiri Kosina
In-Reply-To: <CA+BWVUSm2FQ+U9sHu-Gj5FFpo1kQfjKmxw8PpripExaDXGwUjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 14/05/14 02:49, Reyad Attiyat wrote:
> Here is a sample of the kernel lockdep warning I got after turingon
> dynamic debugging:
> https://bugzilla.kernel.org/show_bug.cgi?id=73321#c3
>
>
>
> On Tue, May 13, 2014 at 8:03 PM, Reyad Attiyat <reyad.attiyat-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Changes all dyn_callback_lock spinlocks to spinlocks that disable
>> interrupts. The dynamic callback lock (dyn_callback_lock) must not be
>> interrupted when locked as it is used in an interrupt handler
>> function, sensor_hub_raw_event.
Looks sane to me, but no sign off and Jiri not cc'd.
Would like an ack from Srinivas as well ideally.
Acked-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> drivers/hid/hid-sensor-hub.c | 31 ++++++++++++++++++-------------
>> 1 file changed, 18 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
>> index af8244b..1e1644c 100644
>> --- a/drivers/hid/hid-sensor-hub.c
>> +++ b/drivers/hid/hid-sensor-hub.c
>> @@ -133,10 +133,11 @@ static struct hid_sensor_hub_callbacks
>> *sensor_hub_get_callback(
>> struct hid_sensor_hub_device **hsdev,
>> void **priv)
>> {
>> + unsigned long flags;
>> struct hid_sensor_hub_callbacks_list *callback;
>> struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
>>
>> - spin_lock(&pdata->dyn_callback_lock);
>> + spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
>> list_for_each_entry(callback, &pdata->dyn_callback_list, list)
>> if (callback->usage_id == usage_id &&
>> (collection_index >=
>> @@ -145,10 +146,10 @@ static struct hid_sensor_hub_callbacks
>> *sensor_hub_get_callback(
>> callback->hsdev->end_collection_index)) {
>> *priv = callback->priv;
>> *hsdev = callback->hsdev;
>> - spin_unlock(&pdata->dyn_callback_lock);
>> + spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
>> return callback->usage_callback;
>> }
>> - spin_unlock(&pdata->dyn_callback_lock);
>> + spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
>>
>> return NULL;
>> }
>> @@ -157,19 +158,20 @@ int sensor_hub_register_callback(struct
>> hid_sensor_hub_device *hsdev,
>> u32 usage_id,
>> struct hid_sensor_hub_callbacks *usage_callback)
>> {
>> + unsigned long flags;
>> struct hid_sensor_hub_callbacks_list *callback;
>> struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
>>
>> - spin_lock(&pdata->dyn_callback_lock);
>> + spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
>> list_for_each_entry(callback, &pdata->dyn_callback_list, list)
>> if (callback->usage_id == usage_id &&
>> callback->hsdev == hsdev) {
>> - spin_unlock(&pdata->dyn_callback_lock);
>> + spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
>> return -EINVAL;
>> }
>> callback = kzalloc(sizeof(*callback), GFP_ATOMIC);
>> if (!callback) {
>> - spin_unlock(&pdata->dyn_callback_lock);
>> + spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
>> return -ENOMEM;
>> }
>> callback->hsdev = hsdev;
>> @@ -177,7 +179,7 @@ int sensor_hub_register_callback(struct
>> hid_sensor_hub_device *hsdev,
>> callback->usage_id = usage_id;
>> callback->priv = NULL;
>> list_add_tail(&callback->list, &pdata->dyn_callback_list);
>> - spin_unlock(&pdata->dyn_callback_lock);
>> + spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
>>
>> return 0;
>> }
>> @@ -186,10 +188,11 @@ EXPORT_SYMBOL_GPL(sensor_hub_register_callback);
>> int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev,
>> u32 usage_id)
>> {
>> + unsigned long flags;
>> struct hid_sensor_hub_callbacks_list *callback;
>> struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
>>
>> - spin_lock(&pdata->dyn_callback_lock);
>> + spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
>> list_for_each_entry(callback, &pdata->dyn_callback_list, list)
>> if (callback->usage_id == usage_id &&
>> callback->hsdev == hsdev) {
>> @@ -197,7 +200,7 @@ int sensor_hub_remove_callback(struct
>> hid_sensor_hub_device *hsdev,
>> kfree(callback);
>> break;
>> }
>> - spin_unlock(&pdata->dyn_callback_lock);
>> + spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
>>
>> return 0;
>> }
>> @@ -376,34 +379,36 @@ EXPORT_SYMBOL_GPL(sensor_hub_input_get_attribute_info);
>> #ifdef CONFIG_PM
>> static int sensor_hub_suspend(struct hid_device *hdev, pm_message_t message)
>> {
>> + unsigned long flags;
>> struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
>> struct hid_sensor_hub_callbacks_list *callback;
>>
>> hid_dbg(hdev, " sensor_hub_suspend\n");
>> - spin_lock(&pdata->dyn_callback_lock);
>> + spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
>> list_for_each_entry(callback, &pdata->dyn_callback_list, list) {
>> if (callback->usage_callback->suspend)
>> callback->usage_callback->suspend(
>> callback->hsdev, callback->priv);
>> }
>> - spin_unlock(&pdata->dyn_callback_lock);
>> + spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
>>
>> return 0;
>> }
>>
>> static int sensor_hub_resume(struct hid_device *hdev)
>> {
>> + unsigned long flags;
>> struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
>> struct hid_sensor_hub_callbacks_list *callback;
>>
>> hid_dbg(hdev, " sensor_hub_resume\n");
>> - spin_lock(&pdata->dyn_callback_lock);
>> + spin_lock_irqsave(&pdata->dyn_callback_lock, flags);
>> list_for_each_entry(callback, &pdata->dyn_callback_list, list) {
>> if (callback->usage_callback->resume)
>> callback->usage_callback->resume(
>> callback->hsdev, callback->priv);
>> }
>> - spin_unlock(&pdata->dyn_callback_lock);
>> + spin_unlock_irqrestore(&pdata->dyn_callback_lock, flags);
>>
>> return 0;
>> }
>> --
>> 1.9.0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] HID: hid-sensor-hub: Add Microsoft Surface Pro 2 HID ID and set report quirk
From: Jonathan Cameron @ 2014-05-24 10:27 UTC (permalink / raw)
To: Reyad Attiyat, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Jiri Kosina
In-Reply-To: <1400031685-28090-1-git-send-email-reyad.attiyat-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 14/05/14 02:41, Reyad Attiyat wrote:
Again, this has no sign off and is not cc'd to Jiri.
Note these don't need my Ack as far as I'm concerned.
Jonathan
> ---
> drivers/hid/hid-ids.h | 3 +++
> drivers/hid/hid-sensor-hub.c | 9 +++++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 34bb220..18e2099 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -633,6 +633,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_SURFACE_PRO_2 0x0799
> +#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-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index be14b56..eefaaf6 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -711,6 +711,15 @@ static const struct hid_device_id sensor_hub_devices[] = {
> { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_TEXAS_INSTRUMENTS,
> USB_DEVICE_ID_TEXAS_INSTRUMENTS_LENOVO_YOGA),
> .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
> + { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
> + USB_DEVICE_ID_MS_SURFACE_PRO_2),
> + .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
> + { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
> + USB_DEVICE_ID_MS_TOUCH_COVER_2),
> + .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
> + { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
> + USB_DEVICE_ID_MS_TYPE_COVER_2),
> + .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
> { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, HID_ANY_ID,
> HID_ANY_ID) },
> { }
>
^ permalink raw reply
* Re: [PATCH] HID: Debug: Add labels for HID Sensor Usages
From: Jonathan Cameron @ 2014-05-24 10:25 UTC (permalink / raw)
To: Reyad Attiyat, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-input,
Srinivas Pandruvada, Jiri Kosina
In-Reply-To: <CA+BWVUTOHr-sktWtpGL7-1wTdz2suDWFjcyX=fFU+JHjs5+TTQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 14/05/14 01:54, Reyad Attiyat wrote:
> ---
This looks reasonable to me, but I haven't checked every entry. Also Reyad, you
need to sign off on the patch if you expect anyone to pick it up.
Jiri, this is one for you. (note Jiri should probably have been cc'd in the
first place as the HID maintainer - unless he specifically asked not to be).
Jonathan
> drivers/hid/hid-debug.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
>
> diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
> index 53b771d..25cc71c 100644
> --- a/drivers/hid/hid-debug.c
> +++ b/drivers/hid/hid-debug.c
> @@ -272,6 +272,85 @@ static const struct hid_usage_entry hid_usage_table[] = {
> {0, 0xAA, "Shared_Parameter_Blocks"},
> {0, 0xAB, "Create_New_Effect_Report"},
> {0, 0xAC, "RAM_Pool_Available"},
> + { 0x20, 0, "Sensor" },
> + { 0x20, 0x01, "Sensor" },
> + { 0x20, 0x10, "Biometric" },
> + { 0x20, 0x11, "BiometricHumanPresence" },
> + { 0x20, 0x12, "BiometricHumanProximity" },
> + { 0x20, 0x13, "BiometricHumanTouch" },
> + { 0x20, 0x20, "Electrical" },
> + { 0x20, 0x21, "ElectricalCapacitance" },
> + { 0x20, 0x22, "ElectricalCurrent" },
> + { 0x20, 0x23, "ElectricalPower" },
> + { 0x20, 0x24, "ElectricalInductance" },
> + { 0x20, 0x25, "ElectricalResistance" },
> + { 0x20, 0x26, "ElectricalVoltage" },
> + { 0x20, 0x27, "ElectricalPoteniometer" },
> + { 0x20, 0x28, "ElectricalFrequency" },
> + { 0x20, 0x29, "ElectricalPeriod" },
> + { 0x20, 0x30, "Environmental" },
> + { 0x20, 0x31, "EnvironmentalAtmosphericPressure" },
> + { 0x20, 0x32, "EnvironmentalHumidity" },
> + { 0x20, 0x33, "EnvironmentalTemperature" },
> + { 0x20, 0x34, "EnvironmentalWindDirection" },
> + { 0x20, 0x35, "EnvironmentalWindSpeed" },
> + { 0x20, 0x40, "Light" },
> + { 0x20, 0x41, "LightAmbientLight" },
> + { 0x20, 0x42, "LightConsumerInfrared" },
> + { 0x20, 0x50, "Location" },
> + { 0x20, 0x51, "LocationBroadcast" },
> + { 0x20, 0x52, "LocationDeadReckoning" },
> + { 0x20, 0x53, "LocationGPS" },
> + { 0x20, 0x54, "LocationLookup" },
> + { 0x20, 0x55, "LocationOther" },
> + { 0x20, 0x56, "LocationStatic" },
> + { 0x20, 0x57, "LocationTriangulation" },
> + { 0x20, 0x60, "Mechanical" },
> + { 0x20, 0x61, "MechanicalBooleanSwitch" },
> + { 0x20, 0x62, "MechanicalBooleanSwitchArray" },
> + { 0x20, 0x63, "MechanicalMultivalueSwitch" },
> + { 0x20, 0x64, "MechanicalForce" },
> + { 0x20, 0x65, "MechanicalPressure" },
> + { 0x20, 0x66, "MechanicalStrain" },
> + { 0x20, 0x67, "MechanicalWeight" },
> + { 0x20, 0x68, "MechanicalHapticVibrator" },
> + { 0x20, 0x69, "MechanicalHallEffectSwitch" },
> + { 0x20, 0x70, "Motion" },
> + { 0x20, 0x71, "MotionAccelerometer1D" },
> + { 0x20, 0x72, "MotionAccelerometer2D" },
> + { 0x20, 0x73, "MotionAccelerometer3D" },
> + { 0x20, 0x74, "MotionGyrometer1D" },
> + { 0x20, 0x75, "MotionGyrometer2D" },
> + { 0x20, 0x76, "MotionGyrometer3D" },
> + { 0x20, 0x77, "MotionMotionDetector" },
> + { 0x20, 0x78, "MotionSpeedometer" },
> + { 0x20, 0x79, "MotionAccelerometer" },
> + { 0x20, 0x7A, "MotionGyrometer" },
> + { 0x20, 0x80, "Orientation" },
> + { 0x20, 0x81, "OrientationCompass1D" },
> + { 0x20, 0x82, "OrientationCompass2D" },
> + { 0x20, 0x83, "OrientationCompass3D" },
> + { 0x20, 0x84, "OrientationInclinometer1D" },
> + { 0x20, 0x85, "OrientationInclinometer2D" },
> + { 0x20, 0x86, "OrientationInclinometer3D" },
> + { 0x20, 0x87, "OrientationDistance1D" },
> + { 0x20, 0x88, "OrientationDistance2D" },
> + { 0x20, 0x89, "OrientationDistance3D" },
> + { 0x20, 0x8A, "OrientationDeviceOrientation" },
> + { 0x20, 0x8B, "OrientationCompass" },
> + { 0x20, 0x8C, "OrientationInclinometer" },
> + { 0x20, 0x8D, "OrientationDistance" },
> + { 0x20, 0x90, "Scanner" },
> + { 0x20, 0x91, "ScannerBarcode" },
> + { 0x20, 0x91, "ScannerRFID" },
> + { 0x20, 0x91, "ScannerNFC" },
> + { 0x20, 0xA0, "Time" },
> + { 0x20, 0xA1, "TimeAlarmTimer" },
> + { 0x20, 0xA2, "TimeRealTimeClock" },
> + { 0x20, 0xE0, "Other" },
> + { 0x20, 0xE1, "OtherCustom" },
> + { 0x20, 0xE2, "OtherGeneric" },
> + { 0x20, 0xE3, "OtherGenericEnumerator" },
> { 0x84, 0, "Power Device" },
> { 0x84, 0x02, "PresentStatus" },
> { 0x84, 0x03, "ChangeStatus" },
>
^ permalink raw reply
* [PATCH 13/24] Drivers:input: Use is_compat_task for ARM64 also.
From: Andrew Pinski @ 2014-05-24 7:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Andrew Pinski
In-Reply-To: <1400914939-9708-1-git-send-email-apinski@cavium.com>
Since TIF_32BIT in ARM64 (with ILP32 added) is not always says if this is a compat task, we need to have the input driver understand that and use is_compat_task instead.
Thanks,
Andrew Pinski
Signed-off-by: Andrew Pinski <apinski@cavium.com>
---
drivers/input/input-compat.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/input/input-compat.h b/drivers/input/input-compat.h
index 148f66f..6656957 100644
--- a/drivers/input/input-compat.h
+++ b/drivers/input/input-compat.h
@@ -19,7 +19,7 @@
/* Note to the author of this code: did it ever occur to
you why the ifdefs are needed? Think about it again. -AK */
-#if defined(CONFIG_X86_64) || defined(CONFIG_TILE)
+#if defined(CONFIG_X86_64) || defined(CONFIG_TILE) || defined(CONFIG_ARM64)
# define INPUT_COMPAT_TEST is_compat_task()
#elif defined(CONFIG_S390)
# define INPUT_COMPAT_TEST test_thread_flag(TIF_31BIT)
--
1.7.2.5
^ permalink raw reply related
* [PATCH 13/24] Drivers:input: Use is_compat_task for ARM64 also.
From: Andrew Pinski @ 2014-05-24 7:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel; +Cc: Andrew Pinski
In-Reply-To: <1400914939-9708-1-git-send-email-apinski@cavium.com>
Since TIF_32BIT in ARM64 (with ILP32 added) is not always says if this is a compat task, we need to have the input driver understand that and use is_compat_task instead.
Thanks,
Andrew Pinski
Signed-off-by: Andrew Pinski <apinski@cavium.com>
---
drivers/input/input-compat.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/input/input-compat.h b/drivers/input/input-compat.h
index 148f66f..6656957 100644
--- a/drivers/input/input-compat.h
+++ b/drivers/input/input-compat.h
@@ -19,7 +19,7 @@
/* Note to the author of this code: did it ever occur to
you why the ifdefs are needed? Think about it again. -AK */
-#if defined(CONFIG_X86_64) || defined(CONFIG_TILE)
+#if defined(CONFIG_X86_64) || defined(CONFIG_TILE) || defined(CONFIG_ARM64)
# define INPUT_COMPAT_TEST is_compat_task()
#elif defined(CONFIG_S390)
# define INPUT_COMPAT_TEST test_thread_flag(TIF_31BIT)
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH 20/51] Input: atmel_mxt_ts - Set default irqflags when there is no pdata
From: Yufeng Shen @ 2014-05-23 16:37 UTC (permalink / raw)
To: Nick Dyer
Cc: Benson Leung, Dmitry Torokhov, Henrik Rydberg, Daniel Kurtz,
Joonyoung Shim, Alan Bowens, linux-input,
linux-kernel@vger.kernel.org, Peter Meerwald, Olof Johansson
In-Reply-To: <537E09D6.7050604@itdev.co.uk>
On Thu, May 22, 2014 at 10:29 AM, Nick Dyer <nick.dyer@itdev.co.uk> wrote:
>
> Dmitry Torokhov wrote:
> > On Thu, Jul 18, 2013 at 07:17:44PM +0200, rydberg@euromail.se wrote:
> >>> From: Yufeng Shen <miletus@chromium.org>
> >>> This is the preparation for supporting the code path when there is
> >>> platform data provided and still boot the device into a sane state
> >>> with backup NVRAM config.
> >>>
> >>> Make the irqflags default to be IRQF_TRIGGER_FALLING if no platform data is
> >>> provided.
> >
> > I think if there is no platform data we should use 0 as IRQ falgs and
> > assume that IRQ line is properly configured by the board code or via
> > device tree.
>
> Beson/Yufeng - do you still have a requirement to probe without platform
> data or device tree? I'm just merging in some changes to add device tree
> support, and it would simplify things a bit if I can drop this patch.
It has been working for quite a while for boards/devices that don't
provide platform
data. If we drop the default IRQ flags, sure we can add code for each
board to configure
the IRQ separately, but that's just adding extra work. Is there strong
reason why we
should not do the default setting in the driver if it is not already
configured in platform
data ?
^ permalink raw reply
* Re: Additional driver for USB touch support
From: Benjamin Tissoires @ 2014-05-23 12:51 UTC (permalink / raw)
To: Prajosh Premdas; +Cc: daniel.ritz, linux-input, Henrik Rydberg
In-Reply-To: <CAAFf3B-1-G9e8+2Ci1MWf2OJfXCWk38e50nOA3piTpAQLM-J7g@mail.gmail.com>
Hi Prajosh,
On Fri, May 23, 2014 at 6:55 AM, Prajosh Premdas
<premdas.prajosh@gmail.com> wrote:
> Hi
>
> I have some USB based touch controllers. These controllers are working
> well using the hid_multitouch driver.
>
> I would also like to add some additional protocol support for
> diagnostics and re calibration. I am using the touch interface for the
> same, whereby the control endpoint is used to send the request and
> digitizer end point is used to get the response. (it is a legacy
> design so i cannot change it)
>
> My plan is to add the additional driver support to this file
> drivers/input/touchscreen/usbtouchscreen.c and disable the default
> support for the hid_multitouch by making an entry in the hid-blacklist
> array in this file drivers/hid/usbhid/hid-quirks.c
2 things:
- adding the device to hid-blacklist either in hid-quirks or
hid-core.c will not help, the device will still be bound to the HID
subsystem, and the usb driver will not be able to catch it. If you
were to go to this road, you would have to add the VID/PID to
hid-ignore in hid-core.c
- I don't think it is a good idea to move from hid-multitouch to
usbtouchscreen: as far as I know, this driver only support single
touch devices, and it will be a burden to implement the multitouch
part
>
> Is there a better idea than this?
If you need to talk to the device through the control endpoint and get
the responses through the interrupt endpoint, hidraw seems to be
perfect for your case:
you can either use the ioctl HIDIOCSFEATURE or directly write on the
hidraw node to send reports, and reading back to the node will give
you the interrupts. Bonus point, you are enterily in userspace, so no
risk of crashing your kernel. Then, you just set up an udev rule if
you need the commands to be launched at plug.
You can find an example in samples/hidraw/hid-example.c in the kernel tree.
Cheers,
Benjamin
^ permalink raw reply
* Additional driver for USB touch support
From: Prajosh Premdas @ 2014-05-23 10:55 UTC (permalink / raw)
To: daniel.ritz, linux-input, rydberg
Hi
I have some USB based touch controllers. These controllers are working
well using the hid_multitouch driver.
I would also like to add some additional protocol support for
diagnostics and re calibration. I am using the touch interface for the
same, whereby the control endpoint is used to send the request and
digitizer end point is used to get the response. (it is a legacy
design so i cannot change it)
My plan is to add the additional driver support to this file
drivers/input/touchscreen/usbtouchscreen.c and disable the default
support for the hid_multitouch by making an entry in the hid-blacklist
array in this file drivers/hid/usbhid/hid-quirks.c
Is there a better idea than this?
--
Regards,
Prajosh Premdas
^ permalink raw reply
* Re: Re: [PATCH v6 0/7] mfd: AXP20x: Add support for AXP202 and AXP209
From: Lee Jones @ 2014-05-23 10:12 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Carlo Caione, Mark Brown, linux-arm-kernel, Maxime Ripard,
Hans De Goede, Emilio Lopez, wens Tsai,
sameo-VuQAYsv1563Yd54FQh9/CA, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Boris BREZILLON,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20140522195523.GB7708-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
> > >> >> This set of patches introduces the core driver and support for two different
> > >> >> subsystems:
> > >> >> - Regulators
> > >> >
> > >> >> .../ABI/testing/sysfs-driver-input-axp-pek | 11 +
> > >> >> Documentation/devicetree/bindings/mfd/axp20x.txt | 93 +++++++
> > >> >> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > >> >> arch/arm/configs/multi_v7_defconfig | 3 +
> > >> >> arch/arm/configs/sunxi_defconfig | 4 +
> > >> >> drivers/input/misc/Kconfig | 11 +
> > >> >> drivers/input/misc/Makefile | 1 +
> > >> >> drivers/input/misc/axp20x-pek.c | 281 +++++++++++++++++++++
> > >> >> drivers/mfd/Kconfig | 12 +
> > >> >> drivers/mfd/Makefile | 1 +
> > >> >> drivers/mfd/axp20x.c | 258 +++++++++++++++++++
> > >> >> include/linux/mfd/axp20x.h | 180 +++++++++++++
> > >> >> 12 files changed, 856 insertions(+)
> > >> >
> > >> > The regulator changes don't appear to be showing up in the diffstat or
> > >> > obviously in the series?
> > >>
> > >> Right. Cut-and-paste error.
> > >> You have already applied the regulator patches so I didn't include
> > >> them here (in theory I posted this series to be picked up by Lee).
> > >
> > > That's fine. Just tell me which patches need to stay together and
> > > which are able to be applied through their respective subsystem trees
> > > separately. Then, once I have all the Acks I can apply no problem.
> >
> > Hi Lee,
> > I'd say #1 for the MFD tree, #4 for the input subsystem, #2 #3 and #5
> > are documentations, #6 and #7 defconfigs add-on.
>
> I am fine with the input piece going through MFD tree, no need to split
> it from the rest.
Do you want a pull-request i.e. will this cause conflicts when Linus
merges it with your tree, or is it okay for me to just apply it?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] input: zforce: add regulator handling
From: Heiko Stübner @ 2014-05-23 7:51 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Henrik Rydberg, linux-input, Rob Herring, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, devicetree
In-Reply-To: <60795928.lIAcBxC0Ao@phil>
Hi Dmitry,
Am Dienstag, 22. April 2014, 21:19:57 schrieb Heiko Stübner:
> From: Heiko Stuebner <heiko.stuebner@bq.com>
>
> It's possible that the controller has an individually switchable power
> supply. Therefore add support to control a supplying regulator.
>
> As this is not always the case, the regulator is requested as optional.
>
> Signed-off-by: Heiko Stuebner <heiko.stuebner@bq.com>
ping?
Thanks
Heiko
> ---
> .../bindings/input/touchscreen/zforce_ts.txt | 4 +++
> drivers/input/touchscreen/zforce_ts.c | 30
> ++++++++++++++++++++++ 2 files changed, 34 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt index
> 2faf1f1..80c37df 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
> @@ -9,6 +9,9 @@ Required properties:
> - x-size: horizontal resolution of touchscreen
> - y-size: vertical resolution of touchscreen
>
> +Optional properties:
> +- vdd-supply: Regulator controlling the controller supply
> +
> Example:
>
> i2c@00000000 {
> @@ -18,6 +21,7 @@ Example:
> compatible = "neonode,zforce";
> reg = <0x50>;
> interrupts = <2 0>;
> + vdd-supply = <®_zforce_vdd>;
>
> gpios = <&gpio5 6 0>, /* INT */
> <&gpio5 9 0>; /* RST */
> diff --git a/drivers/input/touchscreen/zforce_ts.c
> b/drivers/input/touchscreen/zforce_ts.c index 01d30ce..39ca962 100644
> --- a/drivers/input/touchscreen/zforce_ts.c
> +++ b/drivers/input/touchscreen/zforce_ts.c
> @@ -29,6 +29,8 @@
> #include <linux/sysfs.h>
> #include <linux/input/mt.h>
> #include <linux/platform_data/zforce_ts.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/delay.h>
> #include <linux/of.h>
> #include <linux/of_gpio.h>
>
> @@ -117,6 +119,8 @@ struct zforce_ts {
> const struct zforce_ts_platdata *pdata;
> char phys[32];
>
> + struct regulator *reg_vdd;
> +
> bool suspending;
> bool suspended;
> bool boot_complete;
> @@ -690,6 +694,11 @@ static void zforce_reset(void *data)
> struct zforce_ts *ts = data;
>
> gpio_set_value(ts->pdata->gpio_rst, 0);
> +
> + udelay(10);
> +
> + if (!IS_ERR(ts->reg_vdd))
> + regulator_disable(ts->reg_vdd);
> }
>
> static struct zforce_ts_platdata *zforce_parse_dt(struct device *dev)
> @@ -765,10 +774,31 @@ static int zforce_probe(struct i2c_client *client,
> return ret;
> }
>
> + ts->reg_vdd = devm_regulator_get_optional(&client->dev, "vdd");
> + if (IS_ERR(ts->reg_vdd) && PTR_ERR(ts->reg_vdd) == -EPROBE_DEFER)
> + return PTR_ERR(ts->reg_vdd);
> +
> + if (!IS_ERR(ts->reg_vdd)) {
> + ret = regulator_enable(ts->reg_vdd);
> + if (ret)
> + return ret;
> +
> + /*
> + * according to datasheet add 100us grace time after regular
> + * regulator enable delay.
> + */
> + udelay(100);
> + }
> +
> ret = devm_add_action(&client->dev, zforce_reset, ts);
> if (ret) {
> dev_err(&client->dev, "failed to register reset action, %d\n",
> ret);
> +
> + /* hereafter the regulator will be disabled by the action */
> + if (!IS_ERR(ts->reg_vdd))
> + regulator_disable(ts->reg_vdd);
> +
> return ret;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Aiptek T-6000U staying in relative mode.
From: Jan Kandziora @ 2014-05-23 1:48 UTC (permalink / raw)
To: linux-input
Hi all,
recently I tried wanted to use my tablet again with linux-3.11.6. After
a while I found out the kernel driver doesn't succeed to bring the
tablet to absolute mode. After fiddling around with the kernel driver,
I found it is related to the order of commands sent to the tablet while
initialization. My tablet insists the absolute mode command the last
one sent. So I patched my aiptek.c as follows:
-----------------------------------------------------------------------------------------
--- drivers/input/tablet/aiptek.c.orig 2014-05-23 03:35:05.402422214 +0200
+++ drivers/input/tablet/aiptek.c 2014-05-23 03:31:27.351508397 +0200
@@ -1003,6 +1003,18 @@
return ret;
input_set_abs_params(aiptek->inputdev, ABS_PRESSURE, 0, ret - 1, 0, 0);
+ /* Enable the macro keys */
+ if ((ret = aiptek_command(aiptek, 0x11, 0x02)) < 0)
+ return ret;
+#if 0
+ /* Execute FilterOn */
+ if ((ret = aiptek_command(aiptek, 0x17, 0x00)) < 0)
+ return ret;
+#endif
+ /* Execute AutoGainOn */
+ if ((ret = aiptek_command(aiptek, 0x12, 0xff)) < 0)
+ return ret;
+
/* Depending on whether we are in absolute or relative mode, we will
* do a switchToTablet(absolute) or switchToMouse(relative) command.
*/
@@ -1019,19 +1031,6 @@
}
}
- /* Enable the macro keys */
- if ((ret = aiptek_command(aiptek, 0x11, 0x02)) < 0)
- return ret;
-#if 0
- /* Execute FilterOn */
- if ((ret = aiptek_command(aiptek, 0x17, 0x00)) < 0)
- return ret;
-#endif
-
- /* Execute AutoGainOn */
- if ((ret = aiptek_command(aiptek, 0x12, 0xff)) < 0)
- return ret;
-
/* Reset the eventCount, so we track events from last (re)programming
*/
aiptek->diagnostic = AIPTEK_DIAGNOSTIC_NA;
-----------------------------------------------------------------------------------------
That way it works in both relative and absolute mode and the macro keys are enabled, too.
There are some problems remaining with aiptek.c and my tablet. Anyone else here who has
aiptek hardware to test if my patches break anything with their tablets?
Kind regards
Jan
^ permalink raw reply
* Re: [PATCH] dt/sparc: Introduce the use of the managed version of kzalloc
From: Julia Lawall @ 2014-05-23 0:07 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Himangi Saraogi, linux-input, linux-kernel
In-Reply-To: <20140522231434.GA9546@core.coreip.homeip.net>
On Thu, 22 May 2014, Dmitry Torokhov wrote:
> Hi Julia,
>
> On Fri, May 23, 2014 at 07:03:37AM +0800, Julia Lawall wrote:
> >
> >
> > On Thu, 22 May 2014, Dmitry Torokhov wrote:
> >
> > > Hi Himangi,
> > >
> > > On Fri, May 23, 2014 at 01:04:30AM +0530, Himangi Saraogi wrote:
> > > > This patch moves data allocated using kzalloc to managed data allocated
> > > > using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> > > > functions. Also the unnecessary labels are done away with.
> > >
> > > Please no more partial devm conversions. I am not interested in patches
> > > that change only 1 resource to be managed and leaving the rest as is.
> > >
> > > If you want to do devm conversion please do it if you convert all (or at
> > > least majority) of resource handling to managed resources.
> >
> > Sorry, I don't think we are clear on what is wanted. Himangi's patches
> > convert everything where a devm function is already available (to our
> > knowledge). Do you prefer that new devm functions be introduced? On the
> > one hand, that is perhaps useful from a safety point of view. On the
> > other hand, it could lead to a huge number of rarely used devm functions
> > that no one knows about and to a lot of code diversity. So I don't know
> > what is the good solution.
>
> I strongly dislike changes that mix managed and non-managed resources in
> the same driver as it only leads to confusion: should this resource be
> freed or will it be freed automatically.
>
> I am applying patches that convert all (or almost all) resources in a
> driver into managed ones, but if that is not [currently] possible then
> those drivers are probably better left alone (maybe after additional
> audit).
OK, we will try to take that into account. Are the new managed functoins
added to the devres docuentation?
thanks,
julia
^ permalink raw reply
* Re: [PATCH] dt/sparc: Introduce the use of the managed version of kzalloc
From: Julia Lawall @ 2014-05-22 23:35 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Himangi Saraogi, linux-input, linux-kernel
In-Reply-To: <alpine.DEB.2.10.1405230700090.2606@hadrien>
On Fri, 23 May 2014, Julia Lawall wrote:
>
>
> On Thu, 22 May 2014, Dmitry Torokhov wrote:
>
> > Hi Himangi,
> >
> > On Fri, May 23, 2014 at 01:04:30AM +0530, Himangi Saraogi wrote:
> > > This patch moves data allocated using kzalloc to managed data allocated
> > > using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> > > functions. Also the unnecessary labels are done away with.
> >
> > Please no more partial devm conversions. I am not interested in patches
> > that change only 1 resource to be managed and leaving the rest as is.
> >
> > If you want to do devm conversion please do it if you convert all (or at
> > least majority) of resource handling to managed resources.
>
> Sorry, I don't think we are clear on what is wanted. Himangi's patches
> convert everything where a devm function is already available (to our
> knowledge). Do you prefer that new devm functions be introduced? On the
> one hand, that is perhaps useful from a safety point of view. On the
> other hand, it could lead to a huge number of rarely used devm functions
> that no one knows about and to a lot of code diversity. So I don't know
> what is the good solution.
I guess that the concrete problem is of_ioremap? Since that is a pretty
common function, I guess it could be reasonable to introduce a devm
function for it as well. Or maybe one already exists and we overlooked
it.
julia
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox