linux-stable.git/drivers, branch v3.17.3

HID: add keyboard input assist hid usages

2014-11-14T18:10:41+00:00

commit f974008f07a62171a9dede08250c9a35c2b2b986 upstream.

Add keyboard input assist controls usages from approved
hid usage table request HUTTR42:
http://www.usb.org/developers/hidpage/HUTRR42c.pdf

Signed-off-by: Olivier Gay 
Acked-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

of: Fix overflow bug in string property parsing functions

2014-11-14T18:10:40+00:00

commit a87fa1d81a9fb5e9adca9820e16008c40ad09f33 upstream.

The string property read helpers will run off the end of the buffer if
it is handed a malformed string property. Rework the parsers to make
sure that doesn't happen. At the same time add new test cases to make
sure the functions behave themselves.

The original implementations of of_property_read_string_index() and
of_property_count_strings() both open-coded the same block of parsing
code, each with it's own subtly different bugs. The fix here merges
functions into a single helper and makes the original functions static
inline wrappers around the helper.

One non-bugfix aspect of this patch is the addition of a new wrapper,
of_property_read_string_array(). The new wrapper is needed by the
device_properties feature that Rafael is working on and planning to
merge for v3.19. The implementation is identical both with and without
the new static inline wrapper, so it just got left in to reduce the
churn on the header file.

Signed-off-by: Grant Likely 
Cc: Rafael J. Wysocki 
Cc: Mika Westerberg 
Cc: Rob Herring 
Cc: Arnd Bergmann 
Cc: Darren Hart 
Signed-off-by: Greg Kroah-Hartman

sysfs: driver core: Fix glue dir race condition by gdp_mutex

2014-11-14T18:10:40+00:00

commit e4a60d139060975eb956717e4f63ae348d4d8cc5 upstream.

There is a race condition when removing glue directory.
It can be reproduced in following test:

path 1: Add first child device
device_add()
    get_device_parent()
            /*find parent from glue_dirs.list*/
            list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
                    if (k->parent == parent_kobj) {
                            kobj = kobject_get(k);
                            break;
                    }
            ....
            class_dir_create_and_add()

path2: Remove last child device under glue dir
device_del()
    cleanup_device_parent()
            cleanup_glue_dir()
                    kobject_put(glue_dir);

If path2 has been called cleanup_glue_dir(), but not
call kobject_put(glue_dir), the glue dir is still
in parent's kset list. Meanwhile, path1 find the glue
dir from the glue_dirs.list. Path2 may release glue dir
before path1 call kobject_get(). So kernel will report
the warning and bug_on.

This is a "classic" problem we have of a kref in a list
that can be found while the last instance could be removed
at the same time.

This patch reuse gdp_mutex to fix this race condition.

The following calltrace is captured in kernel 3.4, but
the latest kernel still has this bug.

-----------------------------------------------------
<4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
<4>[ 3965.441474] Hardware name: Romley
<4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
...
<4>[ 3965.441605] Call Trace:
<4>[ 3965.441611]  [] warn_slowpath_common+0x7a/0xb0
<4>[ 3965.441615]  [] warn_slowpath_null+0x15/0x20
<4>[ 3965.441618]  [] kobject_get+0x33/0x40
<4>[ 3965.441624]  [] get_device_parent.isra.11+0x135/0x1f0
<4>[ 3965.441627]  [] device_add+0xd4/0x6d0
<4>[ 3965.441631]  [] ? dev_set_name+0x3c/0x40
....
<2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65!
<4>[ 3965.441915] invalid opcode: 0000 [#1] SMP
...
<4>[ 3965.686743]  [] sysfs_create_group+0xe/0x10
<4>[ 3965.686748]  [] blk_trace_init_sysfs+0x14/0x20
<4>[ 3965.686753]  [] blk_register_queue+0x3b/0x120
<4>[ 3965.686756]  [] add_disk+0x1cc/0x490
....
-------------------------------------------------------

Signed-off-by: Yijing Wang 
Signed-off-by: Weng Meiling 
Signed-off-by: Greg Kroah-Hartman

i2c: at91: don't account as iowait

2014-11-14T18:10:40+00:00

commit 11cfbfb098b22d3e57f1f2be217cad20e2d48463 upstream.

iowait is for blkio [1]. I2C shouldn't use it.

[1] https://lkml.org/lkml/2014/11/3/317

Signed-off-by: Wolfram Sang 
Acked-by: Ludovic Desroches 
Signed-off-by: Greg Kroah-Hartman

irqchip: armada-370-xp: Fix MPIC interrupt handling

2014-11-14T18:10:40+00:00

commit 758e8366754d3fa57da978fef9d2c652f7b55c02 upstream.

In both Armada-375 and Armada-38x MPIC interrupts should be identified by
reading cause register multiplied by the interrupt mask.

A lack of above mentioned multiplication resulted in a bug, caused by the
fact that in Armada-375 and Armada-38x some of the interrupts
(e.g. network interrupts) can be handled either as a GIC or MPIC interrupts.
Therefore during MPIC interrupts handling, cause register shows hits from
interrupts even if they are masked for MPIC but unmasked for a GIC.

This resulted in 'bad IRQ' error, because masked MPIC interrupt without
registered interrupt handler, was trying to be handled during interrupt
handling procedure of some other unmasked MPIC interrupt (e.g. local timer
irq).

This commit fixes that by ensuring that during MPIC interrupt handling only
interrupts that are unmasked for MPIC are processed.

Signed-off-by: Grzegorz Jaszczyk 
Reviewed-by: Gregory CLEMENT 
Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC")
Acked-by: Ezequiel Garcia 
Link: https://lkml.kernel.org/r/1411643839-64925-3-git-send-email-jaz@semihalf.com
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

irqchip: armada-370-xp: Fix MSI interrupt handling

2014-11-14T18:10:40+00:00

commit 298dcb2dd0267d51e4f7c94a628cd0765a50ad75 upstream.

The MSI interrupts use the 16 high doorbells, which are notified by using IRQ1
of the main interrupt controller.

The MSI interrupts were handled correctly for Armada-XP and Armada-370 but not
for Armada-375 and Armada-38x, which use chained handler for the MPIC.

This commit fixes that by checking proper interrupt number in chained handler
for the MPIC.

Signed-off-by: Grzegorz Jaszczyk 
Reviewed-by: Gregory CLEMENT 
Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC")
Acked-by: Ezequiel Garcia 
Link: https://lkml.kernel.org/r/1411643839-64925-2-git-send-email-jaz@semihalf.com
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

regulator: max77693: Fix use of uninitialized regulator config

2014-11-14T18:10:40+00:00

commit ca0c37a0b489bb14bf3e1549e7a8d0c9a17f4919 upstream.

Driver allocated on stack struct regulator_config but didn't initialize
it fully. Few fields (driver_data, ena_gpio) were left untouched. This
lead to using random ena_gpio values as GPIOs for max77693 regulators.

On occasion these values could match real GPIO numbers leading to
interfering with other drivers and to unsuccessful enable/disable of
regulator.

Signed-off-by: Krzysztof Kozlowski 
Fixes: 80b022e29bfd ("regulator: max77693: Add max77693 regualtor driver.")
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

pinctrl: baytrail: show output gpio state correctly on Intel Baytrail

2014-11-14T18:10:39+00:00

commit d90c33818967c5e5371961604ad98b4dea4fa3f4 upstream.

Even if a gpio pin is set to output, we still need to set INPUT_EN
functionality (by clearing INPUT_EN bit) to be able to read the pin's
level.

E.g. without this change, we'll always read low level state from sysfs.

Cc: Mathias Nyman 
Signed-off-by: David Cohen 
Reviewed-by: Felipe Balbi 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

samsung-laptop: Add broken-acpi-video quirk for NC210/NC110

2014-11-14T18:10:39+00:00

commit 5a1426c99f9b7aa11d60c4e6b7a3211bb5321696 upstream.

The acpi-video backlight interface on the NC210 does not work, blacklist it
and use the samsung-laptop interface instead.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=861573
Signed-off-by: Hans de Goede 
Signed-off-by: Darren Hart 
Signed-off-by: Greg Kroah-Hartman

acer-wmi: Add acpi_backlight=video quirk for the Acer KAV80

2014-11-14T18:10:39+00:00

commit 183fd8fcd7f8afb7ac5ec68f83194872f9fecc84 upstream.

The acpi-video backlight interface on the Acer KAV80 is broken, and worse
it causes the entire machine to slow down significantly after a suspend/resume.

Blacklist it, and use the acer-wmi backlight interface instead. Note that
the KAV80 is somewhat unique in that it is the only Acer model where we
fall back to acer-wmi after blacklisting, rather then using the native
(e.g. intel) backlight driver. This is done because there is no native
backlight interface on this model.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1128309
Signed-off-by: Hans de Goede 
Signed-off-by: Darren Hart 
Signed-off-by: Greg Kroah-Hartman