* Re: [PATCH] Input: trivial: fix typo in Kconfig help
From: Dmitry Torokhov @ 2014-05-12 17:59 UTC (permalink / raw)
To: Daniele Forsi; +Cc: Jiri Kosina, linux-input
In-Reply-To: <1399911842-28081-1-git-send-email-dforsi@gmail.com>
On Mon, May 12, 2014 at 06:24:02PM +0200, Daniele Forsi wrote:
> s/Logictech/Logitech/
>
> CC: Jiri Kosina <trivial@kernel.org>
> Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Applied, thank you.
> ---
> drivers/input/mouse/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
> index effa9c5..ff9b65d 100644
> --- a/drivers/input/mouse/Kconfig
> +++ b/drivers/input/mouse/Kconfig
> @@ -53,7 +53,7 @@ config MOUSE_PS2_LOGIPS2PP
> default y
> depends on MOUSE_PS2
> help
> - Say Y here if you have a Logictech PS/2++ mouse connected to
> + Say Y here if you have a Logitech PS/2++ mouse connected to
> your system.
>
> If unsure, say Y.
> --
> 2.0.0.rc0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Stephen Warren @ 2014-05-12 20:02 UTC (permalink / raw)
To: Nick Dyer
Cc: Dmitry Torokhov, Benson Leung, Yufeng Shen, Daniel Kurtz,
linux-input@vger.kernel.org, Stephen Warren, Bowens, Alan
In-Reply-To: <536BDFFD.4080009@itdev.co.uk>
On 05/08/2014 01:50 PM, Nick Dyer wrote:
> Stephen Warren wrote:
>> Anyway, I'd like to pull these patches into my local repo to build on.
>> Can you point me at a tree where Dmitry applied them even if not in
>> linux-next? Alternatively, does your github repo contain exactly the
>> patches from the recent mailing list posting you linked above?
>
> https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/log/?h=atmel-mxt-ts
>
> However, I have made minor updates on top of that to take account of API
> changes since he worked on them (reinit_completion).
>
> The patches I posted at the end of March are the first 22 out of this tag:
>
> https://github.com/ndyer/linux/tree/for-next-20140316-v8
I took those 22 patches, applied them on top of next-20150507 (which is
just what I happened to be developing on top of right now), and rebased
my patches which add DT support. You can find the result here if you want:
git://github.com/swarren/linux-tegra.git tegra_dev
However, with that code-base, the touchpad doesn't work for me. I see a
long pause and errors during boot:
> [ 1.246253] atmel_mxt_ts 1-004b: Direct firmware load failed with error -2
> [ 1.253120] atmel_mxt_ts 1-004b: Falling back to user helper
> [ 61.394348] atmel_mxt_ts 1-004b: Failure to request config file maxtouch.cfg
> [ 61.403717] atmel_mxt_ts 1-004b: Family: 130 Variant: 1 Firmware V1.0.AA Objects: 22
... and the touchpad doesn't work once X starts. With next-20140507 plus
the patches I sent to the mailing list, everything works.
I'm not sure if I'm supposed to have some configuration file now and
that's why it doesn't work, or whether some other problem has been
introduced? If I do need a config file, can you tell me what to put into it?
Thanks for any pointers.
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Dmitry Torokhov @ 2014-05-13 1:16 UTC (permalink / raw)
To: Stephen Warren
Cc: Nick Dyer, Benson Leung, Yufeng Shen, Daniel Kurtz,
linux-input@vger.kernel.org, Stephen Warren, Bowens, Alan
In-Reply-To: <537128D0.3060005@wwwdotorg.org>
On Mon, May 12, 2014 at 02:02:24PM -0600, Stephen Warren wrote:
> On 05/08/2014 01:50 PM, Nick Dyer wrote:
> > Stephen Warren wrote:
> >> Anyway, I'd like to pull these patches into my local repo to build on.
> >> Can you point me at a tree where Dmitry applied them even if not in
> >> linux-next? Alternatively, does your github repo contain exactly the
> >> patches from the recent mailing list posting you linked above?
> >
> > https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/log/?h=atmel-mxt-ts
> >
> > However, I have made minor updates on top of that to take account of API
> > changes since he worked on them (reinit_completion).
> >
> > The patches I posted at the end of March are the first 22 out of this tag:
> >
> > https://github.com/ndyer/linux/tree/for-next-20140316-v8
>
> I took those 22 patches, applied them on top of next-20150507 (which is
> just what I happened to be developing on top of right now), and rebased
> my patches which add DT support. You can find the result here if you want:
>
> git://github.com/swarren/linux-tegra.git tegra_dev
>
> However, with that code-base, the touchpad doesn't work for me. I see a
> long pause and errors during boot:
>
> > [ 1.246253] atmel_mxt_ts 1-004b: Direct firmware load failed with error -2
> > [ 1.253120] atmel_mxt_ts 1-004b: Falling back to user helper
> > [ 61.394348] atmel_mxt_ts 1-004b: Failure to request config file maxtouch.cfg
> > [ 61.403717] atmel_mxt_ts 1-004b: Family: 130 Variant: 1 Firmware V1.0.AA Objects: 22
>
> ... and the touchpad doesn't work once X starts. With next-20140507 plus
> the patches I sent to the mailing list, everything works.
>
> I'm not sure if I'm supposed to have some configuration file now and
> that's why it doesn't work, or whether some other problem has been
> introduced? If I do need a config file, can you tell me what to put into it?
>
> Thanks for any pointers.
If you build firmware into kernel or build the driver as a module it
will work, but we do need to solve it general case as well.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Dmitry Torokhov @ 2014-05-13 1:17 UTC (permalink / raw)
To: Mark Brown
Cc: Nick Dyer, Stephen Warren, Benson Leung, Yufeng Shen,
Daniel Kurtz, linux-input@vger.kernel.org, Stephen Warren,
Bowens, Alan
In-Reply-To: <20140509184908.GX12304@sirena.org.uk>
On Fri, May 09, 2014 at 07:49:08PM +0100, Mark Brown wrote:
> On Thu, May 08, 2014 at 08:56:04PM +0100, Nick Dyer wrote:
>
> > Thanks! I had wondered why you had left it, you never communicated this to
> > me unfortunately. Would it be preferable for me to switch to
> > request_firmware_nowait() and complete the probe asynchronously after it
> > returns?
>
> Another common option is to defer the firmware request/load until the
> device is opened, but that doesn't work for all devices. That should
> mean that userspace is up and running.
That would not work for input devices as firmware quite often defines
capabilities of the devices and we need them before registering input
device (which is the object that userspace opens).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: pcap2: avoid calling mutex_lock() in irq handler
From: Dmitry Torokhov @ 2014-05-13 2:14 UTC (permalink / raw)
To: Antonio Ospite
Cc: Alexey Khoroshilov, linux-input, linux-kernel, ldv-project,
Daniel Ribeiro, Ilya Petrov, Antonio Ospite
In-Reply-To: <20140406233744.c40387e9bead51ee48e5ebd1@ao2.it>
On Sun, Apr 06, 2014 at 11:37:44PM +0200, Antonio Ospite wrote:
> On Sun, 6 Apr 2014 13:24:36 -0700
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> > On Sun, Apr 06, 2014 at 12:54:50AM +0400, Alexey Khoroshilov wrote:
> > > pcap_keys_handler() calls ezx_pcap_read() that calls mutex_lock().
> > > pcap_keys_handler() is registered as nonthreaded irq handler,
> > > that means sleeping function is called in irq handler.
> > >
> > > The patch makes a switch to threaded irq handling.
> > > Compile tested only.
> > >
> > > Found by Linux Driver Verification project (linuxtesting.org).
> > >
> > > Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
> > > ---
> > > drivers/input/misc/pcap_keys.c | 10 ++++++----
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/input/misc/pcap_keys.c b/drivers/input/misc/pcap_keys.c
> > > index cd230365166e..2a10f3a30969 100644
> > > --- a/drivers/input/misc/pcap_keys.c
> > > +++ b/drivers/input/misc/pcap_keys.c
> > > @@ -79,13 +79,15 @@ static int pcap_keys_probe(struct platform_device *pdev)
> > > if (err)
> > > goto fail_allocate;
> > >
> > > - err = request_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_ONOFF),
> > > - pcap_keys_handler, 0, "Power key", pcap_keys);
> > > + err = request_threaded_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_ONOFF),
> > > + NULL, pcap_keys_handler, 0,
> > > + "Power key", pcap_keys);
> > > if (err)
> > > goto fail_register;
> > >
> > > - err = request_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_MIC),
> > > - pcap_keys_handler, 0, "Headphone button", pcap_keys);
> > > + err = request_threaded_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_MIC),
> > > + NULL, pcap_keys_handler, 0,
> > > + "Headphone button", pcap_keys);
> >
> > So I guess we do need threaded IRQ here, but I do not see the pcap's
> > irqchip specifying IRQCHIP_ONESHOT_SAFE so I do not think
> > request_threaded_irq() without IRQF_ONESHOT would succeed.
> >
> > Can someone test the change to be sure?
> >
>
> I can try to test it in a couple of weeks, I don't have the hardware
> at hand right now.
Antonio, did you have a chance to try this out yet?
Thanks!
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Stephen Warren @ 2014-05-13 2:31 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Nick Dyer, Benson Leung, Yufeng Shen, Daniel Kurtz,
linux-input@vger.kernel.org, Stephen Warren, Bowens, Alan
In-Reply-To: <20140513011635.GB26152@core.coreip.homeip.net>
On 05/12/2014 07:16 PM, Dmitry Torokhov wrote:
> On Mon, May 12, 2014 at 02:02:24PM -0600, Stephen Warren wrote:
>> On 05/08/2014 01:50 PM, Nick Dyer wrote:
>>> Stephen Warren wrote:
>>>> Anyway, I'd like to pull these patches into my local repo to build on.
>>>> Can you point me at a tree where Dmitry applied them even if not in
>>>> linux-next? Alternatively, does your github repo contain exactly the
>>>> patches from the recent mailing list posting you linked above?
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/log/?h=atmel-mxt-ts
>>>
>>> However, I have made minor updates on top of that to take account of API
>>> changes since he worked on them (reinit_completion).
>>>
>>> The patches I posted at the end of March are the first 22 out of this tag:
>>>
>>> https://github.com/ndyer/linux/tree/for-next-20140316-v8
>>
>> I took those 22 patches, applied them on top of next-20150507 (which is
>> just what I happened to be developing on top of right now), and rebased
>> my patches which add DT support. You can find the result here if you want:
>>
>> git://github.com/swarren/linux-tegra.git tegra_dev
>>
>> However, with that code-base, the touchpad doesn't work for me. I see a
>> long pause and errors during boot:
>>
>>> [ 1.246253] atmel_mxt_ts 1-004b: Direct firmware load failed with error -2
>>> [ 1.253120] atmel_mxt_ts 1-004b: Falling back to user helper
>>> [ 61.394348] atmel_mxt_ts 1-004b: Failure to request config file maxtouch.cfg
>>> [ 61.403717] atmel_mxt_ts 1-004b: Family: 130 Variant: 1 Firmware V1.0.AA Objects: 22
>>
>> ... and the touchpad doesn't work once X starts. With next-20140507 plus
>> the patches I sent to the mailing list, everything works.
>>
>> I'm not sure if I'm supposed to have some configuration file now and
>> that's why it doesn't work, or whether some other problem has been
>> introduced? If I do need a config file, can you tell me what to put into it?
>>
>> Thanks for any pointers.
>
> If you build firmware into kernel or build the driver as a module it
> will work, but we do need to solve it general case as well.
Building it as a module does solve the long delay at bootup, but doesn't
make the device actually work.
I believe the HW doesn't require any firmware; it has non-volatile
storage for both the firmware and configuration. However, the driver
doesn't seem to work without a firmware file being present.
^ permalink raw reply
* Re: [PATCH] input: pcap2: avoid calling mutex_lock() in irq handler
From: Antonio Ospite @ 2014-05-13 8:13 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Alexey Khoroshilov, linux-input, linux-kernel, ldv-project,
Daniel Ribeiro, Ilya Petrov, Antonio Ospite
In-Reply-To: <20140513021456.GE26152@core.coreip.homeip.net>
On Mon, 12 May 2014 19:14:56 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Sun, Apr 06, 2014 at 11:37:44PM +0200, Antonio Ospite wrote:
> > On Sun, 6 Apr 2014 13:24:36 -0700
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> > > On Sun, Apr 06, 2014 at 12:54:50AM +0400, Alexey Khoroshilov wrote:
> > > > pcap_keys_handler() calls ezx_pcap_read() that calls mutex_lock().
> > > > pcap_keys_handler() is registered as nonthreaded irq handler,
> > > > that means sleeping function is called in irq handler.
> > > >
> > > > The patch makes a switch to threaded irq handling.
> > > > Compile tested only.
> > > >
> > > > Found by Linux Driver Verification project (linuxtesting.org).
> > > >
> > > > Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
> > > > ---
> > > > drivers/input/misc/pcap_keys.c | 10 ++++++----
> > > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/input/misc/pcap_keys.c b/drivers/input/misc/pcap_keys.c
> > > > index cd230365166e..2a10f3a30969 100644
> > > > --- a/drivers/input/misc/pcap_keys.c
> > > > +++ b/drivers/input/misc/pcap_keys.c
> > > > @@ -79,13 +79,15 @@ static int pcap_keys_probe(struct platform_device *pdev)
> > > > if (err)
> > > > goto fail_allocate;
> > > >
> > > > - err = request_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_ONOFF),
> > > > - pcap_keys_handler, 0, "Power key", pcap_keys);
> > > > + err = request_threaded_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_ONOFF),
> > > > + NULL, pcap_keys_handler, 0,
> > > > + "Power key", pcap_keys);
> > > > if (err)
> > > > goto fail_register;
> > > >
> > > > - err = request_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_MIC),
> > > > - pcap_keys_handler, 0, "Headphone button", pcap_keys);
> > > > + err = request_threaded_irq(pcap_to_irq(pcap_keys->pcap, PCAP_IRQ_MIC),
> > > > + NULL, pcap_keys_handler, 0,
> > > > + "Headphone button", pcap_keys);
> > >
> > > So I guess we do need threaded IRQ here, but I do not see the pcap's
> > > irqchip specifying IRQCHIP_ONESHOT_SAFE so I do not think
> > > request_threaded_irq() without IRQF_ONESHOT would succeed.
> > >
> > > Can someone test the change to be sure?
> > >
> >
> > I can try to test it in a couple of weeks, I don't have the hardware
> > at hand right now.
>
> Antonio, did you have a chance to try this out yet?
>
> Thanks!
I'll try to set up the environment this week-end, if I fail I'll tell
you; sorry for stalling you.
Ciao,
Antonio
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
^ permalink raw reply
* RE: [PATCH] HID: i2c-hid: hid report descriptor retrieval changes
From: Jiri Kosina @ 2014-05-13 9:23 UTC (permalink / raw)
To: Patni, Archana
Cc: Benjamin Tissoires, Archana Patni, jic23@kernel.org, linux-input,
Westerberg, Mika, Pandruvada, Srinivas, Sesha, Subramony
In-Reply-To: <C6E4BB9533783C4B9F391CD7AD09A49B45EB600D@BGSMSX104.gar.corp.intel.com>
On Mon, 12 May 2014, Patni, Archana wrote:
> > The reason I am asking is whether I should rush this in for 3.15
> > still, but as the patch doesn't have stable annotation anyway, my
> > understanding is that 3.16 is enough?
> 3.16 is fine.
Queued for 3.16, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: rmi: check for the existence of some optional queries before reading query 12
From: Jiri Kosina @ 2014-05-13 14:41 UTC (permalink / raw)
To: Andrew Duggan
Cc: Benjamin Tissoires, linux-input, linux-kernel, Christopher Heiny
In-Reply-To: <1399054456-4594-1-git-send-email-aduggan@synaptics.com>
On Fri, 2 May 2014, Andrew Duggan wrote:
> The rmi4 spec defines some optional query registers in F11 which appear before
> query 12. This patch checks for the existence of some of the lesser used queries to
> compute the location of query12 and all subsequent query registers.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: rmi: do not fetch more than 16 bytes in a query
From: Jiri Kosina @ 2014-05-13 14:44 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Andrew Duggan, Christopher Heiny, linux-input, linux-kernel
In-Reply-To: <1398378398-24825-1-git-send-email-benjamin.tissoires@redhat.com>
On Thu, 24 Apr 2014, Benjamin Tissoires wrote:
> A firmware bug is present on the XPS Haswell edition which silently
> split the request in two responses when the caller ask for a read of
> more than 16 bytes.
> The FW sends the first 16 then the 4 next, but it says that it answered
> the 20 bytes in the first report.
>
> This occurs only on the retrieving of the min/max of X and Y of the F11
> function.
> We only use the first 10 bytes of the Ctrl register, so we can get only
> those 10 bytes to prevent the bug from happening.
>
> Resolves:
> https://bugzilla.redhat.com/show_bug.cgi?id=1090161
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] HID: rmi: fix duplicated argument to && or ||
From: Benjamin Tissoires @ 2014-05-13 19:15 UTC (permalink / raw)
To: Jiri Kosina, Dan Carpenter, Andrew Duggan, linux-input,
linux-kernel
This resulted from an unfortunate copy/paste.
Detected automagically by kbuild.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-rmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 7da9509..8a2ad19 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -754,9 +754,9 @@ static void rmi_input_configured(struct hid_device *hdev, struct hid_input *hi)
input_set_abs_params(input, ABS_MT_POSITION_X, 1, data->max_x, 0, 0);
input_set_abs_params(input, ABS_MT_POSITION_Y, 1, data->max_y, 0, 0);
- if (data->x_size_mm && data->x_size_mm) {
+ if (data->x_size_mm && data->y_size_mm) {
res_x = (data->max_x - 1) / data->x_size_mm;
- res_y = (data->max_y - 1) / data->x_size_mm;
+ res_y = (data->max_y - 1) / data->y_size_mm;
input_abs_set_res(input, ABS_MT_POSITION_X, res_x);
input_abs_set_res(input, ABS_MT_POSITION_Y, res_y);
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] HID: rmi: fix duplicated argument to && or ||
From: Jiri Kosina @ 2014-05-13 19:18 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dan Carpenter, Andrew Duggan, linux-input, linux-kernel
In-Reply-To: <1400008501-7165-1-git-send-email-benjamin.tissoires@redhat.com>
On Tue, 13 May 2014, Benjamin Tissoires wrote:
> This resulted from an unfortunate copy/paste.
>
> Detected automagically by kbuild.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
I have already fixed this in the tree after seeing Dan's email.
Thanks, good catch!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: rmi: fix duplicated argument to && or ||
From: Benjamin Tissoires @ 2014-05-13 19:23 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Dan Carpenter, Andrew Duggan, linux-input,
linux-kernel@vger.kernel.org
In-Reply-To: <alpine.LNX.2.00.1405132118200.16459@pobox.suse.cz>
On Tue, May 13, 2014 at 3:18 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Tue, 13 May 2014, Benjamin Tissoires wrote:
>
>> This resulted from an unfortunate copy/paste.
>>
>> Detected automagically by kbuild.
>>
>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> I have already fixed this in the tree after seeing Dan's email.
>
> Thanks, good catch!
Hey, thanks to you! :)
Cheers,
Benjamin
^ permalink raw reply
* RE: [PATCH] Add VID/PID for HID-type Multi-Touch Module of AFO CO., LTD.
From: Jiri Kosina @ 2014-05-13 22:32 UTC (permalink / raw)
To: YongHwan Ki; +Cc: rydberg, linux-input, linux-kernel
In-Reply-To: <003a01cf488c$ab9c4400$02d4cc00$@afoi.co.kr>
On Wed, 26 Mar 2014, YongHwan Ki wrote:
> Sorry, I woud like to add the AFO defines in the Linux Kernel.
> No afo defines exists in the current kernel tree.
> I correctly changed the log for adding the afo defines.
>
> Kernel Version : linux-3.14.rc7
> Signed-off-by: Yonghwan Ki <kyhw@afoi.co.kr>
Sorry, but this patch is broken again.
It contains the PRIVATE RSA KEY stuff and 'dontdiff' stuff again.
I can create the patch myself and add your signoff / Reported-by (please
let me know if you want me to do that), but it's crucial for you to fix
your workflow for any next submission.
Especially the private key disclosure should probably better be avoided :)
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] HID: hid-sensor-hub: Add and set report quirk for Microsoft Surface Pro 2
From: Reyad Attiyat @ 2014-05-14 0:53 UTC (permalink / raw)
To: linux-kernel, linux-input, derya.kiran, linux-iio,
Srinivas Pandruvada
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/hid-sensor-hub.c | 8 ++++++++
2 files changed, 11 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..f6dc7ea 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -710,6 +710,14 @@ static const struct hid_device_id sensor_hub_devices[] = {
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB,
USB_VENDOR_ID_TEXAS_INSTRUMENTS,
USB_DEVICE_ID_TEXAS_INSTRUMENTS_LENOVO_YOGA),
+ { 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) },
--
1.9.0
^ permalink raw reply related
* [PATCH] HID: Debug: Add labels for HID Sensor Usages
From: Reyad Attiyat @ 2014-05-14 0:54 UTC (permalink / raw)
To: linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-input,
Srinivas Pandruvada
---
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" },
--
1.9.0
^ permalink raw reply related
* [PATCH] HID: hid-sensor-hub: Fix lockdep warning for dynamic callback locks.
From: Reyad Attiyat @ 2014-05-14 1:03 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-input,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Srinivas Pandruvada
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.
---
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
^ permalink raw reply related
* Re: [PATCH] HID: hid-sensor-hub: Add and set report quirk for Microsoft Surface Pro 2
From: Reyad Attiyat @ 2014-05-14 1:05 UTC (permalink / raw)
To: linux-kernel, linux-input, derya.kiran, linux-iio,
Srinivas Pandruvada
In-Reply-To: <CA+BWVUQEa-X7D=d1eh4do=GQSjJ-TT4pLj-5eKpBp9wnVgQsRg@mail.gmail.com>
Ignore this patch I'll have to resend
On Tue, May 13, 2014 at 7:53 PM, Reyad Attiyat <reyad.attiyat@gmail.com> wrote:
> ---
> drivers/hid/hid-ids.h | 3 +++
> drivers/hid/hid-sensor-hub.c | 8 ++++++++
> 2 files changed, 11 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..f6dc7ea 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -710,6 +710,14 @@ static const struct hid_device_id sensor_hub_devices[] = {
> .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
> { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB,
> USB_VENDOR_ID_TEXAS_INSTRUMENTS,
> USB_DEVICE_ID_TEXAS_INSTRUMENTS_LENOVO_YOGA),
> + { 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) },
> --
> 1.9.0
^ permalink raw reply
* [PATCH] HID: hid-sensor-hub: Add Microsoft Surface Pro 2 HID ID and set report quirk
From: Reyad Attiyat @ 2014-05-14 1:41 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: Reyad Attiyat
---
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) },
{ }
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] HID: hid-sensor-hub: Fix lockdep warning for dynamic callback locks.
From: Reyad Attiyat @ 2014-05-14 1:49 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-input,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Srinivas Pandruvada
In-Reply-To: <CA+BWVUS0QYG54W3ws5s3g6iM=SXQHxBxJcKnjCxcEfZRAqp_Dg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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.
> ---
> 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
^ permalink raw reply
* Re: [PATCH] input: pxa27x-keypad: bug fix of getting scan code
From: Dmitry Torokhov @ 2014-05-14 6:12 UTC (permalink / raw)
To: Chao Xie; +Cc: linux-input, linux-arm-kernel, xiechao.mail
In-Reply-To: <1390797697-29217-1-git-send-email-chao.xie@marvell.com>
On Mon, Jan 27, 2014 at 12:41:37PM +0800, Chao Xie wrote:
> From: Chao Xie <chao.xie@marvell.com>
>
> The rows of pxa27x-keypad used by each boards are not fixed.
> So in the driver, it will get the rows from DT and register
> the keymap as:
> matrix_keypad_build_keymap(keymap_data, NULL,
> pdata->matrix_key_rows,
> pdata->matrix_key_cols,
> keypad->keycodes, input_dev);
>
> But the scan code is gotten as
> MATRIX_SCAN_CODE(row, col, MATRIX_ROW_SHIFT);
> It is not correct. Fix it as
> MATRIX_SCAN_CODE(row, col, keypad->row_shift);
>
> row_shift is calculated from pdata->matrix_key_rows.
>
> Signed-off-by: Chao Xie <chao.xie@marvell.com>
Applied with minor edits, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: Request a shared interrupt for AMBA KMI devices.
From: Dmitry Torokhov @ 2014-05-14 6:19 UTC (permalink / raw)
To: Mark Brown
Cc: Russell King, linux-input, linaro-kernel, Liviu Dudau, Mark Brown
In-Reply-To: <1399553053-20305-1-git-send-email-broonie@kernel.org>
On Thu, May 08, 2014 at 01:44:13PM +0100, Mark Brown wrote:
> From: Liviu Dudau <Liviu.Dudau@arm.com>
>
> Recent ARM boards have the KMI devices share one interrupt line rather
> than having dedicated IRQs. Update the driver to take that into account.
>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> Signed-off-by: Mark Brown <broonie@linaro.org>
Applied, thank you.
> ---
> drivers/input/serio/ambakmi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/serio/ambakmi.c b/drivers/input/serio/ambakmi.c
> index 762b08432de0..8b748d99b934 100644
> --- a/drivers/input/serio/ambakmi.c
> +++ b/drivers/input/serio/ambakmi.c
> @@ -79,7 +79,8 @@ static int amba_kmi_open(struct serio *io)
> writeb(divisor, KMICLKDIV);
> writeb(KMICR_EN, KMICR);
>
> - ret = request_irq(kmi->irq, amba_kmi_int, 0, "kmi-pl050", kmi);
> + ret = request_irq(kmi->irq, amba_kmi_int, IRQF_SHARED, "kmi-pl050",
> + kmi);
> if (ret) {
> printk(KERN_ERR "kmi: failed to claim IRQ%d\n", kmi->irq);
> writeb(0, KMICR);
> --
> 2.0.0.rc2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Dmitry Torokhov @ 2014-05-14 6:38 UTC (permalink / raw)
To: Michal Malý
Cc: linux-input, linux-kernel, jkosina, elias.vds, anssi.hannula,
simon
In-Reply-To: <1398524543-15012-2-git-send-email-madcatxster@devoid-pointer.net>
Hi Michal,
On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> +
> +/** DEFINITION OF TERMS
> + *
> + * Combined effect - An effect whose force is a superposition of forces
> + * generated by all effects that can be added together.
> + * Only one combined effect can be playing at a time.
> + * Effects that can be added together to create a combined
> + * effect are FF_CONSTANT, FF_PERIODIC and FF_RAMP.
> + * Uncombinable effect - An effect that cannot be combined with another effect.
> + * All conditional effects - FF_DAMPER, FF_FRICTION,
> + * FF_INERTIA and FF_SPRING are uncombinable.
> + * Number of uncombinable effects playing simultaneously
> + * depends on the capabilities of the hardware.
> + * Rumble effect - An effect generated by device's rumble motors instead of
> + * force feedback actuators.
> + *
> + *
> + * HANDLING OF UNCOMBINABLE EFFECTS
> + *
> + * Uncombinable effects cannot be combined together into just one effect, at
> + * least not in a clear and obvious manner. Therefore these effects have to
> + * be handled individually by ff-memless-next. Handling of these effects is
> + * left entirely to the hardware-specific driver, ff-memless-next merely
> + * passes these effects to the hardware-specific driver at appropriate time.
> + * ff-memless-next provides the UPLOAD command to notify the hardware-specific
> + * driver that the userspace is about to request playback of an uncombinable
> + * effect. The hardware-specific driver shall take all steps needed to make
> + * the device ready to play the effect when it receives the UPLOAD command.
> + * The actual playback shall commence when START_UNCOMB command is received.
> + * Opposite to the UPLOAD command is the ERASE command which tells
> + * the hardware-specific driver that the playback has finished and that
> + * the effect will not be restarted. STOP_UNCOMB command tells
> + * the hardware-specific driver that the playback shall stop but the device
> + * shall still be ready to resume the playback immediately.
> + *
> + * In case it is not possible to make the device ready to play an uncombinable
> + * effect (all hardware effect slots are occupied), the hardware-specific
> + * driver may return an error when it receives an UPLOAD command. If the
This part concerns me. It seems to me that devices supporting
"uncombinable" effects are in fact not memoryless devices and we should
not be introducing this term here. If the goal is to work around limited
number of effect slots in the devices by combining certain effects then
it needs to be done at ff-core level as it will be potentially useful
for all devices.
> + * hardware-specific driver returns 0, the upload is considered successful.
> + * START_UNCOMB and STOP_UNCOMB commands cannot fail and the device must always
> + * start the playback of the requested effect if the UPLOAD command of the
> + * respective effect has been successful. ff-memless-next will never send
> + * a START/STOP_UNCOMB command for an effect that has not been uploaded
> + * successfully, nor will it send an ERASE command for an effect that is
> + * playing (= has been started with START_UNCOMB command).
> + */
> +
> +enum mlnx_commands {
> + /* Start or update a combined effect. This command is sent whenever
> + * a FF_CONSTANT, FF_PERIODIC or FF_RAMP is started, stopped or
> + * updated by userspace, when the applied envelopes are recalculated
> + * or when periodic effects are recalculated. */
> + MLNX_START_COMBINED,
> + /* Stop combined effect. This command is sent when all combinable
> + * effects are stopped. */
> + MLNX_STOP_COMBINED,
> + /* Start or update a rumble effect. This command is sent whenever
> + * a FF_RUMBLE effect is started or when its magnitudes or directions
> + * change. */
> + MLNX_START_RUMBLE,
> + /* Stop a rumble effect. This command is sent when all FF_RUMBLE
> + * effects are stopped. */
> + MLNX_STOP_RUMBLE,
> + /* Start or update an uncombinable effect. This command is sent
> + * whenever an uncombinable effect is started or updated. */
Why do we have make a distinction between rumble and all other effects?
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Michal Malý @ 2014-05-14 8:35 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, linux-kernel, jkosina, elias.vds, anssi.hannula,
simon
In-Reply-To: <20140514063806.GC13621@core.coreip.homeip.net>
Hi Dmitry,
thank you for reviewing this.
On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:
> On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> > +
> > +/** DEFINITION OF TERMS
> > + *
> > + * Combined effect - An effect whose force is a superposition of forces
> > + * generated by all effects that can be added together.
> > + * Only one combined effect can be playing at a time.
> > + * Effects that can be added together to create a
> > combined + * effect are FF_CONSTANT, FF_PERIODIC and
> > FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
> > another effect. + * All conditional effects -
> > FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
> > FF_SPRING are uncombinable. + * Number of
> > uncombinable effects playing simultaneously + *
> > depends on the capabilities of the hardware. + * Rumble effect - An
> > effect generated by device's rumble motors instead of + *
> > force feedback actuators.
> > + *
> > + *
> > + * HANDLING OF UNCOMBINABLE EFFECTS
> > + *
> > + * Uncombinable effects cannot be combined together into just one effect,
> > at + * least not in a clear and obvious manner. Therefore these effects
> > have to + * be handled individually by ff-memless-next. Handling of these
> > effects is + * left entirely to the hardware-specific driver,
> > ff-memless-next merely + * passes these effects to the hardware-specific
> > driver at appropriate time. + * ff-memless-next provides the UPLOAD
> > command to notify the hardware-specific + * driver that the userspace is
> > about to request playback of an uncombinable + * effect. The
> > hardware-specific driver shall take all steps needed to make + * the
> > device ready to play the effect when it receives the UPLOAD command. + *
> > The actual playback shall commence when START_UNCOMB command is received.
> > + * Opposite to the UPLOAD command is the ERASE command which tells + *
> > the hardware-specific driver that the playback has finished and that + *
> > the effect will not be restarted. STOP_UNCOMB command tells
> > + * the hardware-specific driver that the playback shall stop but the
> > device + * shall still be ready to resume the playback immediately.
> > + *
> > + * In case it is not possible to make the device ready to play an
> > uncombinable + * effect (all hardware effect slots are occupied), the
> > hardware-specific + * driver may return an error when it receives an
> > UPLOAD command. If the
> This part concerns me. It seems to me that devices supporting
> "uncombinable" effects are in fact not memoryless devices and we should
> not be introducing this term here. If the goal is to work around limited
> number of effect slots in the devices by combining certain effects then
> it needs to be done at ff-core level as it will be potentially useful
> for all devices.
Force generated by a conditional effect (referred to as "uncombinable" within
ff-memless-next to make the distinction clear) depends on a position of the
device. For instance the more a device is deflected from a neutral position the
greater force FF_SPRING generates. A truly memoryless device would have to
report its position to the driver, have it calculate the appropriate force and
send it back to the device. IMHO such a loop would require a very high USB
polling rate to play conditional effects with acceptable quality.
We know for a fact that at least many (all?) Logitech devices that support
conditional effects use this "semi-memoryless" approach where FF_CONSTANT and
FF_PERIODIC are handled in the memoryless fashion and conditional effects are
uploaded to the device (in a somewhat simplified form). The amount of effects
that can be uploaded to a device is limited which is why ff-memless-next uses
two steps (UPLOAD/ERASE and START/STOP) to handle these effects.
Conditional effects - even if they are of the same type - cannot be effectively
combined into one because superposition doesn't seem to work here so they have
to be processed one by one.
If we ever come across a really memoryless device it should not be
particularly difficult to add another callback to ff-memless-next which would
emulate conditional effects with constant force.
> > + * hardware-specific driver returns 0, the upload is considered
> > successful. + * START_UNCOMB and STOP_UNCOMB commands cannot fail and the
> > device must always + * start the playback of the requested effect if the
> > UPLOAD command of the + * respective effect has been successful.
> > ff-memless-next will never send + * a START/STOP_UNCOMB command for an
> > effect that has not been uploaded + * successfully, nor will it send an
> > ERASE command for an effect that is + * playing (= has been started with
> > START_UNCOMB command).
> >
> > + */
> > +
> > +enum mlnx_commands {
> > + /* Start or update a combined effect. This command is sent whenever
> > + * a FF_CONSTANT, FF_PERIODIC or FF_RAMP is started, stopped or
> > + * updated by userspace, when the applied envelopes are recalculated
> > + * or when periodic effects are recalculated. */
> > + MLNX_START_COMBINED,
> > + /* Stop combined effect. This command is sent when all combinable
> > + * effects are stopped. */
> > + MLNX_STOP_COMBINED,
> > + /* Start or update a rumble effect. This command is sent whenever
> > + * a FF_RUMBLE effect is started or when its magnitudes or directions
> > + * change. */
> > + MLNX_START_RUMBLE,
> > + /* Stop a rumble effect. This command is sent when all FF_RUMBLE
> > + * effects are stopped. */
> > + MLNX_STOP_RUMBLE,
> > + /* Start or update an uncombinable effect. This command is sent
> > + * whenever an uncombinable effect is started or updated. */
>
> Why do we have make a distinction between rumble and all other effects?
Because "combined" effect consists of two vectors pointing along X and Y axes
whereas "rumble" effect is a rotation speed of a rumble motor and the direction
of rotation. Naturally these effects have to be handled in a different fashion.
It is also possible to have a device with both rumble motors and FF actuator.
Having such a distinction also makes it easier to handle emulation of rumble
effects through constant force and vice versa.
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [STLinux Kernel] [PATCH v4 0/7] Add ST Keyscan driver
From: Maxime Coquelin @ 2014-05-14 8:47 UTC (permalink / raw)
To: Gabriel FERNANDEZ, Dmitry Torokhov, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Grant Likely
Cc: devicetree, kernel, linux-doc, linux-kernel, Gabriel Fernandez,
linux-input, Lee Jones, linux-arm-kernel
In-Reply-To: <1397228856-9218-1-git-send-email-gabriel.fernandez@linaro.org>
Hi Gabi,
For the reset and DT patches:
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Regards,
Maxime
On 04/11/2014 05:07 PM, Gabriel FERNANDEZ wrote:
>
> Changes in v4:
> - add reset controller management
> - rename 'st,debounce_us' into 'st,debounce-us' in dt binding
>
> Changes in v3: (bad manipulation)
>
> Changes in v2:
> - use standard format for matrix keymap
> - suppress __exit mark for keyscan_remove()
> - Call to keyscan_stop() shoudl go into keyscan_close() implementation
> - use of SIMPLE_DEV_PM_OPS()
> - rename compatibility name into "st,sti-keyscan"
> - suppress platform data management
> - omit vendor information
> - cosmetic change and renaming
>
> The goal of this series is to add ST Keyscan support to ST SoCs.
> The DT definition is added for STiH415 and STiH416 SoCs on
> B2000 board.
>
>
> Gabriel Fernandez (7):
> drivers: input: keyboard: st-keyscan: add keyscan driver
> driver: reset: sti: add keyscan for stih415
> driver: reset: sti: add keyscan for stih416
> ARM: STi: DT: add keyscan for stih415
> ARM: STi: DT: add keyscan for stih416
> ARM: STi: DT: add keyscan for stih41x-b2000
> ARM: multi_v7_defconfig: add ST Keyscan driver
>
> .../devicetree/bindings/input/st-keyscan.txt | 60 +++++
> arch/arm/boot/dts/stih415-pinctrl.dtsi | 16 ++
> arch/arm/boot/dts/stih415.dtsi | 12 +
> arch/arm/boot/dts/stih416-pinctrl.dtsi | 16 ++
> arch/arm/boot/dts/stih416.dtsi | 12 +
> arch/arm/boot/dts/stih41x-b2000.dtsi | 23 ++
> arch/arm/configs/multi_v7_defconfig | 1 +
> drivers/input/keyboard/Kconfig | 12 +
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/st-keyscan.c | 260 +++++++++++++++++++++
> drivers/reset/sti/reset-stih415.c | 1 +
> drivers/reset/sti/reset-stih416.c | 1 +
> .../dt-bindings/reset-controller/stih415-resets.h | 1 +
> .../dt-bindings/reset-controller/stih416-resets.h | 1 +
> 14 files changed, 417 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/st-keyscan.txt
> create mode 100644 drivers/input/keyboard/st-keyscan.c
>
^ 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