* [PATCH v3] synaptics: Add min/max quirk for ThinkPad Edge E431
From: Hans de Goede @ 2014-04-23 16:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, Peter Hutterer, linux-input, Hans de Goede,
stable
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/mouse/synaptics.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 7c9f509..93cc8fd 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1566,6 +1566,14 @@ static const struct dmi_system_id min_max_dmi_table[] __initconst = {
.driver_data = (int []){1232, 5710, 1156, 4696},
},
{
+ /* Lenovo ThinkPad Edge E431 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad Edge E431"),
+ },
+ .driver_data = (int []){1024, 5022, 2508, 4832},
+ },
+ {
/* Lenovo ThinkPad T431s */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
--
1.9.0
^ permalink raw reply related
* Re: [PATCH v2 01/24] input: Add ff-memless-next module
From: Oliver Neukum @ 2014-04-23 17:06 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Michal Malý, linux-input, linux-kernel, jkosina, elias.vds,
anssi.hannula, simon
In-Reply-To: <20140423155923.GB10531@core.coreip.homeip.net>
On Wed, 2014-04-23 at 08:59 -0700, Dmitry Torokhov wrote:
> On Wed, Apr 23, 2014 at 02:12:59PM +0200, Oliver Neukum wrote:
> > On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
> > > +/* Some devices might have a limit on how many uncombinable effects
> > > + * can be played at once */
> > > +static int mlnx_upload_conditional(struct mlnx_device *mlnxdev,
> > > + const struct ff_effect *effect)
> > > +{
> > > + struct mlnx_effect_command ecmd = {
> > > + .cmd = MLNX_UPLOAD_UNCOMB,
> > > + .u.uncomb.id = effect->id,
> > > + .u.uncomb.effect = effect
> > > + };
> > > + return mlnxdev->control_effect(mlnxdev->dev, mlnxdev->private,
> > > &ecmd);
> > > +}
> > > +
> >
> > This mean you are building the structure on the stack
> >
> > 1. Are you sure nobody retains a reference?
> > 2. That is needlessly inefficient
>
> Why is it inefficient?
The compiler has to include the data structure and then make
a memcopy to the stack. Instead a pointer to the predined structure
could be passed.
Regards
Oliver
--
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 v2 01/24] input: Add ff-memless-next module
From: Dmitry Torokhov @ 2014-04-23 17:24 UTC (permalink / raw)
To: Oliver Neukum
Cc: Michal Malý, linux-input, linux-kernel, jkosina, elias.vds,
anssi.hannula, simon
In-Reply-To: <1398272768.23603.1.camel@linux-fkkt.site>
On Wed, Apr 23, 2014 at 07:06:08PM +0200, Oliver Neukum wrote:
> On Wed, 2014-04-23 at 08:59 -0700, Dmitry Torokhov wrote:
> > On Wed, Apr 23, 2014 at 02:12:59PM +0200, Oliver Neukum wrote:
> > > On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
> > > > +/* Some devices might have a limit on how many uncombinable effects
> > > > + * can be played at once */
> > > > +static int mlnx_upload_conditional(struct mlnx_device *mlnxdev,
> > > > + const struct ff_effect *effect)
> > > > +{
> > > > + struct mlnx_effect_command ecmd = {
> > > > + .cmd = MLNX_UPLOAD_UNCOMB,
> > > > + .u.uncomb.id = effect->id,
> > > > + .u.uncomb.effect = effect
> > > > + };
> > > > + return mlnxdev->control_effect(mlnxdev->dev, mlnxdev->private,
> > > > &ecmd);
> > > > +}
> > > > +
> > >
> > > This mean you are building the structure on the stack
> > >
> > > 1. Are you sure nobody retains a reference?
> > > 2. That is needlessly inefficient
> >
> > Why is it inefficient?
>
> The compiler has to include the data structure and then make
> a memcopy to the stack. Instead a pointer to the predined structure
> could be passed.
No, it does not do that. Memory on stack is reserved and zeroed out,
then individual members are filled in as requested. There is no memcopy.
Thanks.
--
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] input: add support for ALPS v7 protocol device
From: Dmitry Torokhov @ 2014-04-23 19:57 UTC (permalink / raw)
To: Elaine Chen
Cc: Peter Hutterer, Kevin Cernekee, david turvene, linux-input,
Justin Clift, Qiting Chen, Hans de Goede
In-Reply-To: <CAKvfdtJH4kA73FGCvLLTjN_UYyMt6wfv=Y33TApBfE9L_y61uQ@mail.gmail.com>
Hi Elaine,
On Wed, Apr 23, 2014 at 02:47:26PM +0800, Elaine Chen wrote:
> Hi, Peter, Dmitry,
>
> I see. As the xorg dosn't fully support Resting Finger now, will this
> patch be applied as a temp solution?
> Or this patch will be skipped. And we resubmit a new patch without
> kernel support of Resting Finger later?
> Please tell me. Thank you.
I believe the best way would be to submit driver changes without the
"resting finger" handling and work with Peter to add/enhance this
functionality in xorg driver.
Thanks!
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 7/9] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
From: Carlo Caione @ 2014-04-23 20:25 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
hdegoede-H+wXaHxf7aLQT0dZR+AlfA, emilio-0Z03zUJReD5OxF6Tv1QG9Q,
wens-jdAy2FN1RRM, sameo-VuQAYsv1563Yd54FQh9/CA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
lee.jones-QSEj5FYQhm4dnm+yROfE0A,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20140418151551.GZ12304-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Fri, Apr 18, 2014 at 04:15:51PM +0100, Mark Brown wrote:
> On Thu, Apr 17, 2014 at 12:06:34PM +0200, Carlo Caione wrote:
>
> > I'm fighting with a small issue when using the
> > regulator_bulk_register_supply_alias(). Problem is that when using the
> > .parent_supplies entry in the MFD driver, I hit the
> >
> > WARN_ON(!list_empty(&dev->devres_head));
> >
> > in linux/drivers/base/dd.c#L272, but, apart from the warning,
> > everything seems to work correctly.
> > A possible explanation I gave myself is that in the mfd_add_device()
> > we try to use the devm_* API when the regulator device is not bound to
> > the driver yet (I found some information here
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/104442.html).
> > Is this the case?
>
> Without knowing more about the case you're hitting it's hard to say - I
> do run a board which exercises the API for a MFD (with the arizona
> drivers) regularly and haven't noticed an issue so there must be
> something different about what you're trying to do.
I'm having a really hard time with this problem, so any hint is welcome
:) The small modification I'm using on top of the patches in this series
is here: http://bpaste.net/show/228330/
Unfortunately as I said I got this when booting:
http://bpaste.net/show/nUhUTzELT32v9HNPathL/
Thanks,
--
Carlo Caione
^ permalink raw reply
* Re: [PATCH 3/9] drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files.
From: Rusty Russell @ 2014-04-24 3:25 UTC (permalink / raw)
To: simon; +Cc: Michal Malý, linux-kernel, HID CORE LAYER, Greg KH
In-Reply-To: <4977a0bbe5c8625d93f771983991f30a.squirrel@mungewell.org>
simon@mungewell.org writes:
>> simon@mungewell.org writes:
>>> Yep I'm OK with that, however what it the recommended way to make sure
>>> that the end user is able to send changes to this /sys portal? I asked
>>> the
>>> same question before regarding the led class /sys interface, but never
>>> got
>>> any suggestions.
>>>
>>> Signed-off-by: Simon Wood <simon@mungewell.org>
>>
>> If you need that, we'll need to make an exception. That's one purpose
>> of spamming everyone with these changs...
>
>
> What's the right way of doing it?... I don't need to be 'special'. ;-)
>
> The '/sys/.../range' control allows the user to limit the rotation of the
> gaming wheel from a maximum of 900' down to match the 'car' they
> sim-driving. Probably not many people use it, but it probably should be
> assigned properly.
>
> With gaming controllers the /dev/input/event* seem to get set
> appropriately, but I'm not sure how this happens.
>
> The same /should/ also happen for all the LED class controls, I don't want
> to have to 'sudo' just to set a LED on/off. This is currently a problem
> for (at least) hid-lg, hid-sony and hid-steelseries.
> Simon
I think this is a udev duty. Someone needs to chmod/chown/chgrp the
files if you want to allow a particular group/user access (I just
checked, that works fot sysfs files).
I have no idea about HID, so I don't know how you'd figure out who that
user/group is...
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH] Input: atkbd - fix keyboard LG Electronics
From: Dmitry Torokhov @ 2014-04-24 5:25 UTC (permalink / raw)
To: Sheng-Liang Song
Cc: linux-arm-kernel, Shawn Nematbakhsh, linux-input, linux-kernel
In-Reply-To: <1398217882-29778-1-git-send-email-ssl@chromium.org>
On Tue, Apr 22, 2014 at 06:51:22PM -0700, Sheng-Liang Song wrote:
> After issuing ATKBD_CMD_RESET_DIS, LG Keyboard stop working.
> The workaround is to remove ATKBD_CMD_RESET_DIS for LG Keyboards.
>
> In order to keep the minimum changes to the current atkbd driver,
> I add logic to apply the patch if and only if the device is LG LW25-B7HV or P1-J273B.
How about if we rework this just a little bit... Does the version of the
patch below work for you?
Also, I do need your "signed-off-by".
Thanks!
--
Dmitry
Input: atkbd - fix keyboard LG Electronics
From: Sheng-Liang Song <ssl@chromium.org>
After issuing ATKBD_CMD_RESET_DIS, LG Keyboard stop working. The
workaround is to remove ATKBD_CMD_RESET_DIS for LG Keyboards.
In order to keep the minimum changes to the current atkbd driver, I add
logic to apply the patch if and only if the device is LG LW25-B7HV or
P1-J273B.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/atkbd.c | 30 ++++++++++++++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 2626773..06a4b0d 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -243,6 +243,12 @@ static void (*atkbd_platform_fixup)(struct atkbd *, const void *data);
static void *atkbd_platform_fixup_data;
static unsigned int (*atkbd_platform_scancode_fixup)(struct atkbd *, unsigned int);
+/*
+ * Certain keyboards to not like ATKBD_CMD_RESET_DIS and stop responding
+ * to many commands until full reset (ATKBD_CMD_RESET_BAT) is performed.
+ */
+static bool atkbd_skip_deactivate;
+
static ssize_t atkbd_attr_show_helper(struct device *dev, char *buf,
ssize_t (*handler)(struct atkbd *, char *));
static ssize_t atkbd_attr_set_helper(struct device *dev, const char *buf, size_t count,
@@ -698,7 +704,6 @@ static int atkbd_activate(struct atkbd *atkbd)
* atkbd_deactivate() resets and disables the keyboard from sending
* keystrokes.
*/
-
static void atkbd_deactivate(struct atkbd *atkbd)
{
struct ps2dev *ps2dev = &atkbd->ps2dev;
@@ -768,7 +773,8 @@ static int atkbd_probe(struct atkbd *atkbd)
* Make sure nothing is coming from the keyboard and disturbs our
* internal state.
*/
- atkbd_deactivate(atkbd);
+ if (!atkbd_skip_deactivate)
+ atkbd_deactivate(atkbd);
return 0;
}
@@ -1638,6 +1644,12 @@ static int __init atkbd_setup_scancode_fixup(const struct dmi_system_id *id)
return 1;
}
+static int __init atkbd_deactivate_fixup(const struct dmi_system_id *id)
+{
+ atkbd_skip_deactivate = true;
+ return 1;
+}
+
static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
{
.matches = {
@@ -1775,6 +1787,20 @@ static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
.callback = atkbd_setup_scancode_fixup,
.driver_data = atkbd_oqo_01plus_scancode_fixup,
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "LW25-B7HV"),
+ },
+ .callback = atkbd_deactivate_fixup,
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P1-J273B"),
+ },
+ .callback = atkbd_deactivate_fixup,
+ },
{ }
};
^ permalink raw reply related
* [PATCH] Input: evdev - get rid of old workaround for EVIOCGBIT
From: Dmitry Torokhov @ 2014-04-24 5:27 UTC (permalink / raw)
To: linux-input; +Cc: David Herrmann, Peter Hutterer, linux-kernel
We put this workaround in 2008 and the offending userspace has been fixed
up long time ago; the link in the message is no longer valid either, so it
is time to retire it.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/evdev.c | 18 ------------------
1 file changed, 18 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index ce953d8..fd325ec 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -629,12 +629,10 @@ static int str_to_user(const char *str, unsigned int maxlen, void __user *p)
return copy_to_user(p, str, len) ? -EFAULT : len;
}
-#define OLD_KEY_MAX 0x1ff
static int handle_eviocgbit(struct input_dev *dev,
unsigned int type, unsigned int size,
void __user *p, int compat_mode)
{
- static unsigned long keymax_warn_time;
unsigned long *bits;
int len;
@@ -652,24 +650,8 @@ static int handle_eviocgbit(struct input_dev *dev,
default: return -EINVAL;
}
- /*
- * Work around bugs in userspace programs that like to do
- * EVIOCGBIT(EV_KEY, KEY_MAX) and not realize that 'len'
- * should be in bytes, not in bits.
- */
- if (type == EV_KEY && size == OLD_KEY_MAX) {
- len = OLD_KEY_MAX;
- if (printk_timed_ratelimit(&keymax_warn_time, 10 * 1000))
- pr_warning("(EVIOCGBIT): Suspicious buffer size %u, "
- "limiting output to %zu bytes. See "
- "http://userweb.kernel.org/~dtor/eviocgbit-bug.html\n",
- OLD_KEY_MAX,
- BITS_TO_LONGS(OLD_KEY_MAX) * sizeof(long));
- }
-
return bits_to_user(bits, len, size, p, compat_mode);
}
-#undef OLD_KEY_MAX
static int evdev_handle_get_keycode(struct input_dev *dev, void __user *p)
{
--
1.9.0
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] Input: evdev - get rid of old workaround for EVIOCGBIT
From: Peter Hutterer @ 2014-04-24 5:37 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, David Herrmann, linux-kernel
In-Reply-To: <20140424052719.GA29764@core.coreip.homeip.net>
On Wed, Apr 23, 2014 at 10:27:20PM -0700, Dmitry Torokhov wrote:
> We put this workaround in 2008 and the offending userspace has been fixed
> up long time ago; the link in the message is no longer valid either, so it
> is time to retire it.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
works for me, Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Cheers,
Peter
> ---
> drivers/input/evdev.c | 18 ------------------
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index ce953d8..fd325ec 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -629,12 +629,10 @@ static int str_to_user(const char *str, unsigned int maxlen, void __user *p)
> return copy_to_user(p, str, len) ? -EFAULT : len;
> }
>
> -#define OLD_KEY_MAX 0x1ff
> static int handle_eviocgbit(struct input_dev *dev,
> unsigned int type, unsigned int size,
> void __user *p, int compat_mode)
> {
> - static unsigned long keymax_warn_time;
> unsigned long *bits;
> int len;
>
> @@ -652,24 +650,8 @@ static int handle_eviocgbit(struct input_dev *dev,
> default: return -EINVAL;
> }
>
> - /*
> - * Work around bugs in userspace programs that like to do
> - * EVIOCGBIT(EV_KEY, KEY_MAX) and not realize that 'len'
> - * should be in bytes, not in bits.
> - */
> - if (type == EV_KEY && size == OLD_KEY_MAX) {
> - len = OLD_KEY_MAX;
> - if (printk_timed_ratelimit(&keymax_warn_time, 10 * 1000))
> - pr_warning("(EVIOCGBIT): Suspicious buffer size %u, "
> - "limiting output to %zu bytes. See "
> - "http://userweb.kernel.org/~dtor/eviocgbit-bug.html\n",
> - OLD_KEY_MAX,
> - BITS_TO_LONGS(OLD_KEY_MAX) * sizeof(long));
> - }
> -
> return bits_to_user(bits, len, size, p, compat_mode);
> }
> -#undef OLD_KEY_MAX
>
> static int evdev_handle_get_keycode(struct input_dev *dev, void __user *p)
> {
> --
> 1.9.0
>
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH] HID: multitouch: add support of EliteGroup 05D8 panels
From: Jiri Kosina @ 2014-04-24 9:48 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Tomas Sokorai, linux-input, linux-kernel
In-Reply-To: <1398264161-7680-1-git-send-email-benjamin.tissoires@redhat.com>
On Wed, 23 Apr 2014, Benjamin Tissoires wrote:
> From: Tomas Sokorai <tsokorai@gmail.com>
>
> They need to have the class SERIAL.
>
> Note: it is a Win 7 panel, not Win 8 certified.
>
> Signed-off-by: Tomas Sokorai <tsokorai@gmail.com>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 09/24] input: Port hid-dr to ff-memless-next
From: Michal Malý @ 2014-04-24 10:32 UTC (permalink / raw)
To: Oliver Neukum
Cc: linux-input, linux-kernel, dmitry.torokhov, jkosina, elias.vds,
anssi.hannula, simon
In-Reply-To: <1398260463.32091.5.camel@linux-fkkt.site>
On Wednesday 23 of April 2014 15:41:03 Oliver Neukum wrote:
> On Tue, 2014-04-22 at 15:59 +0200, Michal Malý wrote:
> > static int drff_play(struct input_dev *dev, void *data,
> >
> > - struct ff_effect *effect)
> > + const struct mlnx_effect_command *command)
> >
> > {
> >
> > struct hid_device *hid = input_get_drvdata(dev);
> > struct drff_device *drff = data;
> >
> > + const struct mlnx_rumble_force *rumble_force =
> > &command->u.rumble_force;
> >
> > int strong, weak;
> >
> > - strong = effect->u.rumble.strong_magnitude;
> > - weak = effect->u.rumble.weak_magnitude;
> > + strong = rumble_force->strong;
> > + weak = rumble_force->weak;
> >
> > dbg_hid("called with 0x%04x 0x%04x", strong, weak);
> >
> > - if (strong || weak) {
> > - strong = strong * 0xff / 0xffff;
> > - weak = weak * 0xff / 0xffff;
> > -
> > - /* While reverse engineering this device, I found that
> > when
> > - this value is set, it causes the strong rumble to
> > function
> > - at a near maximum speed, so we'll bypass it. */
> > - if (weak == 0x0a)
> > - weak = 0x0b;
> > -
> > - drff->report->field[0]->value[0] = 0x51;
> > - drff->report->field[0]->value[1] = 0x00;
> > - drff->report->field[0]->value[2] = weak;
> > - drff->report->field[0]->value[4] = strong;
> > - hid_hw_request(hid, drff->report, HID_REQ_SET_REPORT);
> > -
> > - drff->report->field[0]->value[0] = 0xfa;
> > - drff->report->field[0]->value[1] = 0xfe;
> > - } else {
> > + switch (command->cmd) {
> > + case MLNX_START_RUMBLE:
> > + if (strong || weak) {
> > + strong = strong * 0xff / 0xffff;
> > + weak = weak * 0xff / 0xffff;
> > +
> > + /* While reverse engineering this device, I
> > found that when
> > + this value is set, it causes the strong rumble
> > to function
> > + at a near maximum speed, so we'll bypass it.
> > */
> > + if (weak == 0x0a)
> > + weak = 0x0b;
> > +
> > + drff->report->field[0]->value[0] = 0x51;
> > + drff->report->field[0]->value[1] = 0x00;
> > + drff->report->field[0]->value[2] = weak;
> > + drff->report->field[0]->value[4] = strong;
>
> This looks like an endianness bug.
I don't have a big endian machine to check but why would this be an endianness
issue? We're dealing with values all the time here, not addresses so I'd
expect the 'weak' and 'strong' values to be truncated if they won't fit into
byte. Division done beforehand makes sure that the values are within <0; 255>
range. As far as I can see this is quite common in the HID and Input code. Am
I missing something here?
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v2] HID: add missing hid usages
From: Jiri Kosina @ 2014-04-24 11:58 UTC (permalink / raw)
To: Olivier Gay
Cc: linux-input, Dmitry Torokhov, Nestor Lopez Casado,
Mathieu Meisser
In-Reply-To: <1398245926-16988-1-git-send-email-ogay@logitech.com>
On Wed, 23 Apr 2014, Olivier Gay wrote:
> Add some missing hid usages from consumer page, add
> display brightness control usages from approved hid usage
> table request HUTTR41:
> http://www.usb.org/developers/hidpage/HUTRR41.pdf
> and add voice command usage from approved request HUTTR45:
> http://www.usb.org/developers/hidpage/Voice_Command_Usage.pdf
>
> Signed-off-by: Olivier Gay <ogay@logitech.com>
> Signed-off-by: Mathieu Meisser <mmeisser@logitech.com>
Dmitry, if this is Acked by you, I'd be happy to take it through my tree.
Thanks.
> ---
> drivers/hid/hid-debug.c | 14 ++++++++++++++
> drivers/hid/hid-input.c | 15 +++++++++++++++
> include/uapi/linux/input.h | 16 ++++++++++++++++
> 3 files changed, 45 insertions(+)
>
> diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
> index 53b771d..742d78b 100644
> --- a/drivers/hid/hid-debug.c
> +++ b/drivers/hid/hid-debug.c
> @@ -855,6 +855,20 @@ static const char *keys[KEY_MAX + 1] = {
> [KEY_KBDILLUMDOWN] = "KbdIlluminationDown",
> [KEY_KBDILLUMUP] = "KbdIlluminationUp",
> [KEY_SWITCHVIDEOMODE] = "SwitchVideoMode",
> + [KEY_BUTTONCONFIG] = "ButtonConfig",
> + [KEY_TASKMANAGER] = "TaskManager",
> + [KEY_JOURNAL] = "Journal",
> + [KEY_CONTROLPANEL] = "ControlPanel",
> + [KEY_APPSELECT] = "AppSelect",
> + [KEY_SCREENSAVER] = "ScreenSaver",
> + [KEY_VOICECOMMAND] = "VoiceCommand",
> + [KEY_BRIGHTNESS_INC] = "BrightnessInc",
> + [KEY_BRIGHTNESS_DEC] = "BrightnessDec",
> + [KEY_BRIGHTNESS] = "Brightness",
> + [KEY_BRIGHTNESS_TOGGLE] = "BrightnessToggle",
> + [KEY_BRIGHTNESS_MIN] = "BrightnessMin",
> + [KEY_BRIGHTNESS_MAX] = "BrightnessMax",
> + [KEY_BRIGHTNESS_AUTO] = "BrightnessAuto",
> };
>
> static const char *relatives[REL_MAX + 1] = {
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index e7e8b19..f78b18d 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -721,6 +721,14 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> case 0x06c: map_key_clear(KEY_YELLOW); break;
> case 0x06d: map_key_clear(KEY_ZOOM); break;
>
> + case 0x06f: map_key_clear(KEY_BRIGHTNESS_INC); break;
> + case 0x070: map_key_clear(KEY_BRIGHTNESS_DEC); break;
> + case 0x071: map_key_clear(KEY_BRIGHTNESS); break;
> + case 0x072: map_key_clear(KEY_BRIGHTNESS_TOGGLE); break;
> + case 0x073: map_key_clear(KEY_BRIGHTNESS_MIN); break;
> + case 0x074: map_key_clear(KEY_BRIGHTNESS_MAX); break;
> + case 0x075: map_key_clear(KEY_BRIGHTNESS_AUTO); break;
> +
> case 0x082: map_key_clear(KEY_VIDEO_NEXT); break;
> case 0x083: map_key_clear(KEY_LAST); break;
> case 0x084: map_key_clear(KEY_ENTER); break;
> @@ -761,6 +769,7 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> case 0x0bf: map_key_clear(KEY_SLOW); break;
>
> case 0x0cd: map_key_clear(KEY_PLAYPAUSE); break;
> + case 0x0cf: map_key_clear(KEY_VOICECOMMAND); break;
> case 0x0e0: map_abs_clear(ABS_VOLUME); break;
> case 0x0e2: map_key_clear(KEY_MUTE); break;
> case 0x0e5: map_key_clear(KEY_BASSBOOST); break;
> @@ -768,6 +777,7 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> case 0x0ea: map_key_clear(KEY_VOLUMEDOWN); break;
> case 0x0f5: map_key_clear(KEY_SLOW); break;
>
> + case 0x181: map_key_clear(KEY_BUTTONCONFIG); break;
> case 0x182: map_key_clear(KEY_BOOKMARKS); break;
> case 0x183: map_key_clear(KEY_CONFIG); break;
> case 0x184: map_key_clear(KEY_WORDPROCESSOR); break;
> @@ -781,6 +791,8 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> case 0x18c: map_key_clear(KEY_VOICEMAIL); break;
> case 0x18d: map_key_clear(KEY_ADDRESSBOOK); break;
> case 0x18e: map_key_clear(KEY_CALENDAR); break;
> + case 0x18f: map_key_clear(KEY_TASKMANAGER); break;
> + case 0x190: map_key_clear(KEY_JOURNAL); break;
> case 0x191: map_key_clear(KEY_FINANCE); break;
> case 0x192: map_key_clear(KEY_CALC); break;
> case 0x193: map_key_clear(KEY_PLAYER); break;
> @@ -789,12 +801,15 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> case 0x199: map_key_clear(KEY_CHAT); break;
> case 0x19c: map_key_clear(KEY_LOGOFF); break;
> case 0x19e: map_key_clear(KEY_COFFEE); break;
> + case 0x19f: map_key_clear(KEY_CONTROLPANEL); break;
> + case 0x1a2: map_key_clear(KEY_APPSELECT); break;
> case 0x1a3: map_key_clear(KEY_NEXT); break;
> case 0x1a4: map_key_clear(KEY_PREVIOUS); break;
> case 0x1a6: map_key_clear(KEY_HELP); break;
> case 0x1a7: map_key_clear(KEY_DOCUMENTS); break;
> case 0x1ab: map_key_clear(KEY_SPELLCHECK); break;
> case 0x1ae: map_key_clear(KEY_KEYBOARD); break;
> + case 0x1b1: map_key_clear(KEY_SCREENSAVER); break;
> case 0x1b4: map_key_clear(KEY_FILE); break;
> case 0x1b6: map_key_clear(KEY_IMAGES); break;
> case 0x1b7: map_key_clear(KEY_AUDIO); break;
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index bd24470..389be5d 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -722,6 +722,22 @@ struct input_keymap_entry {
>
> #define KEY_ALS_TOGGLE 0x230 /* Ambient light sensor */
>
> +#define KEY_BUTTONCONFIG 0x240 /* AL Button Configuration */
> +#define KEY_TASKMANAGER 0x241 /* AL Task/Project Manager */
> +#define KEY_JOURNAL 0x242 /* AL Log/Journal/Timecard */
> +#define KEY_CONTROLPANEL 0x243 /* AL Control Panel */
> +#define KEY_APPSELECT 0x244 /* AL Select Task/Application */
> +#define KEY_SCREENSAVER 0x245 /* AL Screen Saver */
> +#define KEY_VOICECOMMAND 0x246 /* Listening Voice Command */
> +
> +#define KEY_BRIGHTNESS_INC KEY_BRIGHTNESSUP
> +#define KEY_BRIGHTNESS_DEC KEY_BRIGHTNESSDOWN
> +#define KEY_BRIGHTNESS 0x250 /* Set Brightness */
> +#define KEY_BRIGHTNESS_TOGGLE KEY_DISPLAYTOGGLE
> +#define KEY_BRIGHTNESS_MIN 0x251 /* Set Brightness to Minimum */
> +#define KEY_BRIGHTNESS_MAX 0x252 /* Set Brightness to Maximum */
> +#define KEY_BRIGHTNESS_AUTO 0x253 /* Set Auto Brightness */
> +
> #define BTN_TRIGGER_HAPPY 0x2c0
> #define BTN_TRIGGER_HAPPY1 0x2c0
> #define BTN_TRIGGER_HAPPY2 0x2c1
> --
> 1.9.0
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 7/9] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
From: Mark Brown @ 2014-04-24 13:30 UTC (permalink / raw)
To: Carlo Caione
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
hdegoede-H+wXaHxf7aLQT0dZR+AlfA, emilio-0Z03zUJReD5OxF6Tv1QG9Q,
wens-jdAy2FN1RRM, sameo-VuQAYsv1563Yd54FQh9/CA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
lee.jones-QSEj5FYQhm4dnm+yROfE0A,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, Charles Keepax
In-Reply-To: <20140423202546.GA3890-OP/Sd6KM9CusbfqNwF1Yyl6hYfS7NtTn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]
On Wed, Apr 23, 2014 at 10:25:46PM +0200, Carlo Caione wrote:
> I'm having a really hard time with this problem, so any hint is welcome
> :) The small modification I'm using on top of the patches in this series
> is here: http://bpaste.net/show/228330/
> Unfortunately as I said I got this when booting:
> http://bpaste.net/show/nUhUTzELT32v9HNPathL/
Huh, actually the arizona drivers do show this (it was being masked in
my logs by another unrelated bug). I guess the Wolfson guys aren't
working with upstream much (though Charles did write the orignal code
here...).
The issue is the MFD core, it shouldn't be using managed allocations
here - the error reported by the assert is entirely correct. If the
CODEC driver is bound and unbound it'll not be possible to reload it
as things stand.
Your driver is correct but the implementation needs to be fixed -
possibly with an API change on free since at the minute the cells to be
freed don't get passed back into the MFD core when deallocating.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] Input: atkbd - fix keyboard LG Electronics
From: Sheng-Liang Song @ 2014-04-24 14:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sheng-Liang Song, Shawn Nematbakhsh, Dmitry Torokhov, linux-input,
linux-kernel
After issuing ATKBD_CMD_RESET_DIS, LG Keyboard stop working. The
workaround is to remove ATKBD_CMD_RESET_DIS for LG Keyboards.
In order to keep the minimum changes to the current atkbd driver, I add
logic to apply the patch if and only if the device is LG LW25-B7HV or
P1-J273B.
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/atkbd.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 2626773..2dd1d0d 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -243,6 +243,12 @@ static void (*atkbd_platform_fixup)(struct atkbd *, const void *data);
static void *atkbd_platform_fixup_data;
static unsigned int (*atkbd_platform_scancode_fixup)(struct atkbd *, unsigned int);
+/*
+ * Certain keyboards to not like ATKBD_CMD_RESET_DIS and stop responding
+ * to many commands until full reset (ATKBD_CMD_RESET_BAT) is performed.
+ */
+static bool atkbd_skip_deactivate;
+
static ssize_t atkbd_attr_show_helper(struct device *dev, char *buf,
ssize_t (*handler)(struct atkbd *, char *));
static ssize_t atkbd_attr_set_helper(struct device *dev, const char *buf, size_t count,
@@ -768,7 +774,8 @@ static int atkbd_probe(struct atkbd *atkbd)
* Make sure nothing is coming from the keyboard and disturbs our
* internal state.
*/
- atkbd_deactivate(atkbd);
+ if (!atkbd_skip_deactivate)
+ atkbd_deactivate(atkbd);
return 0;
}
@@ -1638,6 +1645,12 @@ static int __init atkbd_setup_scancode_fixup(const struct dmi_system_id *id)
return 1;
}
+static int __init atkbd_deactivate_fixup(const struct dmi_system_id *id)
+{
+ atkbd_skip_deactivate = true;
+ return 1;
+}
+
static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
{
.matches = {
@@ -1775,6 +1788,20 @@ static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
.callback = atkbd_setup_scancode_fixup,
.driver_data = atkbd_oqo_01plus_scancode_fixup,
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "LW25-B7HV"),
+ },
+ .callback = atkbd_deactivate_fixup,
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P1-J273B"),
+ },
+ .callback = atkbd_deactivate_fixup,
+ },
{ }
};
--
1.9.1.423.g4596e3a
^ permalink raw reply related
* Re: [PATCH v4 7/9] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
From: Charles Keepax @ 2014-04-24 16:35 UTC (permalink / raw)
To: Mark Brown
Cc: Carlo Caione, boris.brezillon, sameo, linux-doc, emilio,
dmitry.torokhov, wens, lgirdwood, hdegoede, linux-sunxi,
linux-input, maxime.ripard, lee.jones, linux-arm-kernel
In-Reply-To: <20140424133036.GY12304@sirena.org.uk>
On Thu, Apr 24, 2014 at 02:30:36PM +0100, Mark Brown wrote:
> On Wed, Apr 23, 2014 at 10:25:46PM +0200, Carlo Caione wrote:
>
> > I'm having a really hard time with this problem, so any hint is welcome
> > :) The small modification I'm using on top of the patches in this series
> > is here: http://bpaste.net/show/228330/
>
> > Unfortunately as I said I got this when booting:
> > http://bpaste.net/show/nUhUTzELT32v9HNPathL/
>
> Huh, actually the arizona drivers do show this (it was being masked in
> my logs by another unrelated bug). I guess the Wolfson guys aren't
> working with upstream much (though Charles did write the orignal code
> here...).
I run upstream fairly regularly here (although mostly on Arndale
rather than Speyside). On closer inspection of my kernel log
don't seem to have anything related to it, which is odd.
> The issue is the MFD core, it shouldn't be using managed allocations
> here - the error reported by the assert is entirely correct. If the
> CODEC driver is bound and unbound it'll not be possible to reload it
> as things stand.
>
> Your driver is correct but the implementation needs to be fixed -
> possibly with an API change on free since at the minute the cells to be
> freed don't get passed back into the MFD core when deallocating.
This does indeed look broken, I will have a look and think about it.
Unfortunately I am travelling most of next week, so if I don't
manage to get something out over the weekend there may be a slight
delay on me getting a fix out.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v5 0/7] HID: sony: More Sony controller fixes and improvements.
From: Jiri Kosina @ 2014-04-24 16:56 UTC (permalink / raw)
To: Frank Praznik; +Cc: linux-input, simon
In-Reply-To: <1397484697-2389-1-git-send-email-frank.praznik@oh.rr.com>
On Mon, 14 Apr 2014, Frank Praznik wrote:
> v5 has the following changes:
I finally managed to review this patchset. Now queued for 3.16, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 7/9] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
From: Charles Keepax @ 2014-04-24 16:58 UTC (permalink / raw)
To: Mark Brown
Cc: boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
sameo-VuQAYsv1563Yd54FQh9/CA, linux-doc-u79uwXL29TY76Z2rM5mHXA,
emilio-0Z03zUJReD5OxF6Tv1QG9Q, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
wens-jdAy2FN1RRM, linux-input-u79uwXL29TY76Z2rM5mHXA,
Carlo Caione, maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20140424163523.GB25663-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Thu, Apr 24, 2014 at 05:35:23PM +0100, Charles Keepax wrote:
> On Thu, Apr 24, 2014 at 02:30:36PM +0100, Mark Brown wrote:
> > On Wed, Apr 23, 2014 at 10:25:46PM +0200, Carlo Caione wrote:
> >
> > > I'm having a really hard time with this problem, so any hint is welcome
> > > :) The small modification I'm using on top of the patches in this series
> > > is here: http://bpaste.net/show/228330/
> >
> > > Unfortunately as I said I got this when booting:
> > > http://bpaste.net/show/nUhUTzELT32v9HNPathL/
> >
> > Huh, actually the arizona drivers do show this (it was being masked in
> > my logs by another unrelated bug). I guess the Wolfson guys aren't
> > working with upstream much (though Charles did write the orignal code
> > here...).
>
> I run upstream fairly regularly here (although mostly on Arndale
> rather than Speyside). On closer inspection of my kernel log
> don't seem to have anything related to it, which is odd.
Ah ok seems I am getting an error but for some reason for me it
shows up looking very unrelated to the supply mapping. In that it
shows up much later in the log and doesn't seem to mention the
MFD at all:
[ 2.938985] ------------[ cut here ]------------
[ 2.942216] WARNING: CPU: 0 PID: 1 at drivers/base/dd.c:272 driver_probe_device+0x127/0x184()
[ 2.950680] Modules linked in:
[ 2.953677] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2+ #636
[ 2.960246] [<80011ab9>] (unwind_backtrace) from [<8000f461>] (show_stack+0x11/0x14)
[ 2.967972] [<8000f461>] (show_stack) from [<804c3bab>] (dump_stack+0x53/0x68)
[ 2.975171] [<804c3bab>] (dump_stack) from [<8001bc55>] (warn_slowpath_common+0x51/0x70)
[ 2.983239] [<8001bc55>] (warn_slowpath_common) from [<8001bc8b>] (warn_slowpath_null+0x17/0x1c)
[ 2.992009] [<8001bc8b>] (warn_slowpath_null) from [<802c040f>] (driver_probe_device+0x127/0x184)
[ 3.000864] [<802c040f>] (driver_probe_device) from [<802c04bd>] (__driver_attach+0x51/0x54)
[ 3.009278] [<802c04bd>] (__driver_attach) from [<802bf2fd>] (bus_for_each_dev+0x2d/0x4c)
[ 3.017437] [<802bf2fd>] (bus_for_each_dev) from [<802bfde7>] (bus_add_driver+0x8f/0x130)
[ 3.025603] [<802bfde7>] (bus_add_driver) from [<802c08b7>] (driver_register+0x3b/0x88)
[ 3.033540] [<802c08b7>] (driver_register) from [<800087df>] (do_one_initcall+0xa7/0xe8)
[ 3.041618] [<800087df>] (do_one_initcall) from [<8097d9e7>] (kernel_init_freeable+0xb7/0x14c)
[ 3.050219] [<8097d9e7>] (kernel_init_freeable) from [<804bec2b>] (kernel_init+0xf/0xa4)
[ 3.058286] [<804bec2b>] (kernel_init) from [<8000cebd>] (ret_from_fork+0x11/0x20)
[ 3.065835] ---[ end trace f838bbad8b4018a1 ]---
The fix looks pretty trivial though, hopefully get it out
tonight/tomorrow morning.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v4 7/9] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
From: Mark Brown @ 2014-04-24 17:12 UTC (permalink / raw)
To: Charles Keepax
Cc: boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
sameo-VuQAYsv1563Yd54FQh9/CA, linux-doc-u79uwXL29TY76Z2rM5mHXA,
emilio-0Z03zUJReD5OxF6Tv1QG9Q, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
wens-jdAy2FN1RRM, linux-input-u79uwXL29TY76Z2rM5mHXA,
Carlo Caione, maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20140424165847.GC25663-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
On Thu, Apr 24, 2014 at 05:58:47PM +0100, Charles Keepax wrote:
> Ah ok seems I am getting an error but for some reason for me it
> shows up looking very unrelated to the supply mapping. In that it
> shows up much later in the log and doesn't seem to mention the
> MFD at all:
If you look at the warning you'll see that it's complaining that it's
trying to probe a device which has devres stuff attached to it which is
happens at the time the function driver gets loaded.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] HID: rmi: do not fetch more than 16 bytes in a query
From: Benjamin Tissoires @ 2014-04-24 22:26 UTC (permalink / raw)
To: Andrew Duggan, Christopher Heiny, Jiri Kosina, linux-input,
linux-kernel
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>
---
drivers/hid/hid-rmi.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 7da9509..cee89c9 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -613,10 +613,15 @@ static int rmi_populate_f11(struct hid_device *hdev)
}
}
- /* retrieve the ctrl registers */
- ret = rmi_read_block(hdev, data->f11.control_base_addr, buf, 20);
+ /*
+ * retrieve the ctrl registers
+ * the ctrl register has a size of 20 but a fw bug split it into 16 + 4,
+ * and there is no way to know if the first 20 bytes are here or not.
+ * We use only the first 10 bytes, so get only them.
+ */
+ ret = rmi_read_block(hdev, data->f11.control_base_addr, buf, 10);
if (ret) {
- hid_err(hdev, "can not read ctrl block of size 20: %d.\n", ret);
+ hid_err(hdev, "can not read ctrl block of size 10: %d.\n", ret);
return ret;
}
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] HID: add missing hid usages
From: Dmitry Torokhov @ 2014-04-24 23:26 UTC (permalink / raw)
To: Olivier Gay
Cc: Jiri Kosina, linux-input, Nestor Lopez Casado, Mathieu Meisser
In-Reply-To: <CAFLMSp-S9rh+i7VkX-gEdjjdrjPDZN_2=rGqLVWo=kPLBcUprw@mail.gmail.com>
On Wed, Apr 23, 2014 at 11:37:17AM +0200, Olivier Gay wrote:
> On Wed, Apr 23, 2014 at 2:04 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Mon, Apr 07, 2014 at 09:49:52AM +0200, Jiri Kosina wrote:
> >> > +#define KEY_BRIGHTNESS 0x250 /* Display Brightness */
> >
> > What is it supposed to do exactly? Show OSD for brightness?
>
> No, it's a linear control usage to (HUTTR41) "Sets brightness to a
> value between logical min and max.". I'm changing the comment to /*
> Set Brightness */.
Then it does not make sense to expose it as a key - how system should
respond to such event? Pick a random value?
If we really need to support this we need ABS_BRIGHTNESS, like we have
ABS_VOLUME.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] Input: twl6040-vibra - use devm_regulator_bulk_get()
From: Fabio Estevam @ 2014-04-25 1:40 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: peter.ujfalusi, linux-input, Fabio Estevam
From: Fabio Estevam <fabio.estevam@freescale.com>
Using devm_regulator_bulk_get() can make the code cleaner and smaller as we
do not need to call regulator_bulk_free() in the error and remove paths.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/input/misc/twl6040-vibra.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/input/misc/twl6040-vibra.c b/drivers/input/misc/twl6040-vibra.c
index 77dc23b..bf0cb2d 100644
--- a/drivers/input/misc/twl6040-vibra.c
+++ b/drivers/input/misc/twl6040-vibra.c
@@ -323,8 +323,9 @@ static int twl6040_vibra_probe(struct platform_device *pdev)
* When booted with Device tree the regulators are attached to the
* parent device (twl6040 MFD core)
*/
- ret = regulator_bulk_get(twl6040_core_dev, ARRAY_SIZE(info->supplies),
- info->supplies);
+ ret = devm_regulator_bulk_get(twl6040_core_dev,
+ ARRAY_SIZE(info->supplies),
+ info->supplies);
if (ret) {
dev_err(info->dev, "couldn't get regulators %d\n", ret);
return ret;
@@ -336,7 +337,7 @@ static int twl6040_vibra_probe(struct platform_device *pdev)
if (ret) {
dev_err(info->dev, "failed to set VDDVIBL volt %d\n",
ret);
- goto err_regulator;
+ return ret;
}
}
@@ -346,7 +347,7 @@ static int twl6040_vibra_probe(struct platform_device *pdev)
if (ret) {
dev_err(info->dev, "failed to set VDDVIBR volt %d\n",
ret);
- goto err_regulator;
+ return ret;
}
}
@@ -355,8 +356,7 @@ static int twl6040_vibra_probe(struct platform_device *pdev)
info->input_dev = input_allocate_device();
if (info->input_dev == NULL) {
dev_err(info->dev, "couldn't allocate input device\n");
- ret = -ENOMEM;
- goto err_regulator;
+ return -ENOMEM;
}
input_set_drvdata(info->input_dev, info);
@@ -387,8 +387,6 @@ err_iff:
input_ff_destroy(info->input_dev);
err_ialloc:
input_free_device(info->input_dev);
-err_regulator:
- regulator_bulk_free(ARRAY_SIZE(info->supplies), info->supplies);
return ret;
}
@@ -397,7 +395,6 @@ static int twl6040_vibra_remove(struct platform_device *pdev)
struct vibra_info *info = platform_get_drvdata(pdev);
input_unregister_device(info->input_dev);
- regulator_bulk_free(ARRAY_SIZE(info->supplies), info->supplies);
return 0;
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] Input: atkbd - fix keyboard LG Electronics
From: Dmitry Torokhov @ 2014-04-25 6:35 UTC (permalink / raw)
To: Sheng-Liang Song
Cc: linux-arm-kernel, Shawn Nematbakhsh, linux-input, linux-kernel
In-Reply-To: <1398351432-5361-1-git-send-email-ssl@chromium.org>
On Thu, Apr 24, 2014 at 07:57:12AM -0700, Sheng-Liang Song wrote:
> After issuing ATKBD_CMD_RESET_DIS, LG Keyboard stop working. The
> workaround is to remove ATKBD_CMD_RESET_DIS for LG Keyboards.
>
> In order to keep the minimum changes to the current atkbd driver, I add
> logic to apply the patch if and only if the device is LG LW25-B7HV or
> P1-J273B.
>
> Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: twl6040-vibra - use devm_regulator_bulk_get()
From: Dmitry Torokhov @ 2014-04-25 6:36 UTC (permalink / raw)
To: Fabio Estevam; +Cc: peter.ujfalusi, linux-input, Fabio Estevam
In-Reply-To: <1398390004-20535-1-git-send-email-festevam@gmail.com>
On Thu, Apr 24, 2014 at 10:40:04PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Using devm_regulator_bulk_get() can make the code cleaner and smaller as we
> do not need to call regulator_bulk_free() in the error and remove paths.
Can we complete the conversion and use devm_input_allocate_device() as
well?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] synaptics: Add min/max quirk for ThinkPad Edge E431
From: Dmitry Torokhov @ 2014-04-25 6:37 UTC (permalink / raw)
To: Hans de Goede; +Cc: Benjamin Tissoires, Peter Hutterer, linux-input, stable
In-Reply-To: <1398270248-24403-1-git-send-email-hdegoede@redhat.com>
On Wed, Apr 23, 2014 at 06:24:08PM +0200, Hans de Goede wrote:
> Cc: stable@vger.kernel.org
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied, thank you.
> ---
> drivers/input/mouse/synaptics.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 7c9f509..93cc8fd 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -1566,6 +1566,14 @@ static const struct dmi_system_id min_max_dmi_table[] __initconst = {
> .driver_data = (int []){1232, 5710, 1156, 4696},
> },
> {
> + /* Lenovo ThinkPad Edge E431 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad Edge E431"),
> + },
> + .driver_data = (int []){1024, 5022, 2508, 4832},
> + },
> + {
> /* Lenovo ThinkPad T431s */
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> --
> 1.9.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: ads7877: Remove bitrotted comment
From: Dmitry Torokhov @ 2014-04-25 6:38 UTC (permalink / raw)
To: Mark Brown; +Cc: Michael Hennerich, linux-input, linaro-kernel
In-Reply-To: <20140423101623.GL12304@sirena.org.uk>
On Wed, Apr 23, 2014 at 11:16:23AM +0100, Mark Brown wrote:
> On Tue, Apr 22, 2014 at 05:39:28PM -0700, Dmitry Torokhov wrote:
> > On Tue, Apr 22, 2014 at 10:18:21PM +0100, Mark Brown wrote:
>
> > > Remove the bitrotted comment, though in actual fact the use case mentioned
> > > is a great use for spi_async() since it would cut down on latency handling
> > > the interrupt by saving us a context switch before we start SPI.
>
> > > This was previously implemented, it was removed in commit b534422b2d11
> > > (Input: ad7877 - switch to using threaded IRQ) for code complexity reasons.
> > > It may be better to revert that commit instead.
>
> > Hmm, maybe.. although I think original would cause device 'stuck' if
> > call to spi_async() fails, so probably not a straight revert...
>
> Probably best just to apply this, then - someone can always reimplement
> if they need to.
OK, applied.
Thanks.
--
Dmitry
^ 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