- 30 Mar, 2015 40 commits
-
-
Takashi Iwai authored
commit 07892b10 upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Takashi Iwai authored
commit eaddf6fd upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
commit 24cc883c upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
commit bd14016f upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
commit 00a14c29 upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
commit 4c523ef6 upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
commit d7f58db4 upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
commit e8371aa0 upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
Paul Handrigan <Paul.Handrigan@cirrus.com> Signed-off-by:
-
Takashi Iwai authored
commit 08641d9b upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
-
Takashi Iwai authored
commit 2bf4c1d4 upstream. The correct values referred by a boolean control are value.integer.value[], not value.enumerated.item[]. The former is long while the latter is int, so it's even incompatible on 64bit architectures. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Andy Lutomirski authored
commit 394838c9 upstream. The one in do_debug() is probably harmless, but better safe than sorry. Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/d67deaa9df5458363623001f252d1aee3215d014.1425948056.git.luto@amacapital.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> [ luis: backported to 3.16: - drop changes to do_bounds() ] Signed-off-by:
-
Malcolm Priestley authored
commit 40c8790b upstream. When the driver sets this rate a power of zero value is set causing data flow stoppage until another rate is tried. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Benjamin Tissoires authored
commit b57a7128 upstream. The board id capability has been added in firmware 7.5. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Benjamin Tissoires authored
commit ebc80840 upstream. The Fimware 8.1 has a bug in which the extra buttons are only sent when the ExtBit is 1. This should be fixed in a future FW update which should have a bump of the minor version. Signed-off-by:
-
Dmitry Torokhov authored
commit dc5465dc upstream. On the X1 Carbon 3rd gen (with a 2015 broadwell cpu), the physical middle button of the trackstick (attached to the touchpad serio device, of course) seems to get lost. Actually, the touchpads reports 3 extra buttons, which falls in the switch below to the '2' case. Let's handle the case of odd numbers also, so that the middle button finds its way back. Signed-off-by:
-
Benjamin Tissoires authored
commit 02e07492 upstream. Post-2013 Lenovo laptops provide correct min/max dimensions, which are different with the ones currently quirked. According to https://bugzilla.kernel.org/show_bug.cgi?id=91541 the following board ids are assigned in the post-2013 touchpads: t440p/t440s: LEN0036 -> 2964/2962 t540p: LEN0034 -> 2964 Using 2961 as the common minimum makes these 3 laptops OK. We may need to update those values later if other pnp_ids has a lower board_id. Signed-off-by:
-
Daniel Martin authored
commit 5b3089dd upstream. Add a min/max range for board ids to the min/max coordinates quirk. This makes it possible to restrict quirks to specific models based upon their board id. The define ANY_BOARD_ID (0) serves as a wild card. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541Signed-off-by:
Daniel Martin <daniel.martin@secunet.com> Acked-by:
-
Daniel Martin authored
commit b05f4d1c upstream. The firmware of the X240 (LEN0035, 2013/12) exposes the same values x [1232..5710], y [1156..4696] as the quirk applies. Signed-off-by:
Daniel Martin <consume.noise@gmail.com> Acked-by:
-
Daniel Martin authored
commit ac097930 upstream. Query the min dimensions even if the check SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 7 fails, but we know that the firmware version 8.1 is safe. With that we don't need quirks for post-2013 models anymore as they expose correct min and max dimensions. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=91541Signed-off-by:
-
Daniel Martin authored
commit 9aff6598 upstream. Logging the dimension values we queried and the values we use from a quirk to overwrite can be helpful for debugging. This partly relates to bug: https://bugzilla.kernel.org/show_bug.cgi?id=91541Signed-off-by:
-
Daniel Martin authored
commit 8b04baba upstream. Split the function synaptics_resolution() into synaptics_resolution() and synaptics_quirks(). synaptics_resolution() will be called before synaptics_quirks() to query dimensions and resolutions before overwriting them with quirks. Signed-off-by:
-
Hans de Goede authored
commit 2c75ada6 upstream. The matches_pnp_id function from the synaptics driver is useful for other drivers too. Make it a generic psmouse helper function. Signed-off-by:
-
Doug Anderson authored
commit 29d62ec5 upstream. Normally _regulator_do_enable() isn't called on an already-enabled rdev. That's because the main caller, _regulator_enable() always calls _regulator_is_enabled() and only calls _regulator_do_enable() if the rdev was not already enabled. However, there is one caller of _regulator_do_enable() that doesn't check: regulator_suspend_finish(). While we might want to make regulator_suspend_finish() behave more like _regulator_enable(), it's probably also a good idea to make _regulator_do_enable() robust if it is called on an already enabled rdev. At the moment, _regulator_do_enable() is _not_ robust for already enabled rdevs if we're using an ena_pin. Each time _regulator_do_enable() is called for an rdev using an ena_pin the reference count of the ena_pin is incremented even if the rdev was already enabled. This is not as intended because the ena_pin is for something else: for keeping track of how many active rdevs there are sharing the same ena_pin. Here's how the reference counting works here: * Each time _regulator_enable() is called we increment rdev->use_count, so _regulator_enable() calls need to be balanced with _regulator_disable() calls. * There is no explicit reference counting in _regulator_do_enable() which is normally just a warapper around rdev->desc->ops->enable() with code for supporting delays. It's not expected that the "ops->enable()" call do reference counting. * Since regulator_ena_gpio_ctrl() does have reference counting (handling the sharing of the pin amongst multiple rdevs), we shouldn't call it if the current rdev is already enabled. Note that as part of this we cleanup (remove) the initting of ena_gpio_state in regulator_register(). In _regulator_do_enable(), _regulator_do_disable() and _regulator_is_enabled() is is clear that ena_gpio_state should be the state of whether this particular rdev has requested the GPIO be enabled. regulator_register() was initting it as the actual state of the pin. Fixes: 967cfb18 ("regulator: core: manage enable GPIO list") Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
-
Javier Martinez Canillas authored
commit 0548bf4f upstream. The _regulator_do_enable() call ought to be a no-op when called on an already-enabled regulator. However, as an optimization _regulator_enable() doesn't call _regulator_do_enable() on an already enabled regulator. That means we never test the case of calling _regulator_do_enable() during normal usage and there may be hidden bugs or warnings. We have seen warnings issued by the tps65090 driver and bugs when using the GPIO enable pin. Let's match the same optimization that _regulator_enable() in regulator_suspend_finish(). That may speed up suspend/resume and also avoids exposing hidden bugs. [Use much clearer commit message from Doug Anderson] Signed-off-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by:
-
Lars-Peter Clausen authored
commit 328f494d upstream. When inserting a new register into a block at the lower end the present bitmap is currently shifted into the wrong direction. The effect of this is that the bitmap becomes corrupted and registers which are present might be reported as not present and vice versa. Fix this by shifting left rather than right. Fixes: 472fdec7("regmap: rbtree: Reduce number of nodes, take 2") Reported-by:
Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by:
-
Eric Nelson authored
commit c7d910b8 upstream. The SGTL5000_CHIP_ANA_POWER register is cached. Update the cached value instead of writing it directly. Patch inspired by Russell King's more colorful remarks in this patch: https://github.com/SolidRun/linux-imx6-3.14/commit/dd4bf6aSigned-off-by:
Eric Nelson <eric.nelson@boundarydevices.com> Signed-off-by:
-
Jiri Slaby authored
commit e8932869 upstream. On gcc5 the kernel does not link: ld: .eh_frame_hdr table[4] FDE at 0000000000000648 overlaps table[5] FDE at 0000000000000670. Because prior GCC versions always emitted NOPs on ALIGN directives, but gcc5 started omitting them. .LSTARTFDEDLSI1 says: /* HACK: The dwarf2 unwind routines will subtract 1 from the return address to get an address in the middle of the presumed call instruction. Since we didn't get here via a call, we need to include the nop before the real start to make up for it. */ .long .LSTART_sigreturn-1-. /* PC-relative start address */ But commit 69d0627a ("x86 vDSO: reorder vdso32 code") from 2.6.25 replaced .org __kernel_vsyscall+32,0x90 by ALIGN right before __kernel_sigreturn. Of course, ALIGN need not generate any NOP in there. Esp. gcc5 collapses vclock_gettime.o and int80.o together with no generated NOPs as "ALIGN". So fix this by adding to that point at least a single NOP and make the function ALIGN possibly with more NOPs then. Kudos for reporting and diagnosing should go to Richard. Reported-by:
Richard Biener <rguenther@suse.de> Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Acked-by:
-
Yongbae Park authored
commit 1096be08 upstream. The interrupt is enabled before the handler is set. Even this bug did not appear, it is potentially dangerous as it can lead to a NULL pointer dereference. Fix the error by enabling the interrupt after clockevents_config_and_register() is called. Signed-off-by:
Yongbae Park <yongbae2@gmail.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Yongbae Park authored
commit 7b8f10da upstream. The initialisation of the efm32 clocksource first sets up the irq and only after that initialises the data needed for irq handling. In case this initialisation is delayed the irq handler would dereference a NULL pointer. I'm not aware of anything that could delay the process in such a way, but it's better to be safe than sorry, so setup the irq only when the clock event device is ready. Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Michael S. Tsirkin authored
commit eeb8a7e8 upstream. when multiport is off, virtio console invokes config access from irq context, config access is blocking on s390. Fix this up by scheduling work from config irq - similar to what we do for multiport configs. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Reviewed-by:
Amit Shah <amit.shah@redhat.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Michael S. Tsirkin authored
commit 4f6e24ed upstream. when multiport is off, we don't initialize config work, but we then cancel uninitialized control_work on freeze. Signed-off-by:
-
Lars-Peter Clausen authored
commit cdd3d2a9 upstream. Routes without a control must use NULL for the control name. The sn95031 driver uses "NULL" instead in a few places. Previous to commit 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the sn95031 driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit 8e6a75c1 upstream. Routes without a control must use NULL for the control name. The da732x driver uses "NULL" instead in a few places. Previous to commit 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the da732x driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by:
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit ce9594c6 upstream. Routes without a control must use NULL for the control name. The ak4671 driver uses "NULL" instead in a few places. Previous to commit 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") the DAPM core silently ignored non-NULL controls on non-mixer and non-mux routes. But starting with that commit it will complain and not add the route breaking the ak4671 driver in the process. This patch replaces the incorrect "NULL" control name with NULL to fix the issue. Fixes: 5fe5b767 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets") Signed-off-by:
-
Michal Kazior authored
commit aa75ebc2 upstream. Some APs experience problems when working with U-APSD. Decreasing the probability of that happening by using legacy mode for all ACs but VO isn't enough. Cisco 4410N originally forced us to enable VO by default only because it treated non-VO ACs as legacy. However some APs (notably Netgear R7000) silently reclassify packets to different ACs. Since u-APSD ACs require trigger frames for frame retrieval clients would never see some frames (e.g. ARP responses) or would fetch them accidentally after a long time. It makes little sense to enable u-APSD queues by default because it needs userspace applications to be aware of it to actually take advantage of the possible additional powersavings. Implicitly depending on driver autotrigger frame support doesn't make much sense. Signed-off-by:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Bob Copeland authored
commit d0c22119 upstream. The mesh forwarding path was not checking that data frames were protected when running an encrypted network; add the necessary check. Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Ard Biesheuvel authored
commit 001eabfd upstream. This updates the bit sliced AES module to the latest version in the upstream OpenSSL repository (e620e5ae37bc). This is needed to fix a bug in the XTS decryption path, where data chunked in a certain way could trigger the ciphertext stealing code, which is not supposed to be active in the kernel build (The kernel implementation of XTS only supports round multiples of the AES block size of 16 bytes, whereas the conformant OpenSSL implementation of XTS supports inputs of arbitrary size by applying ciphertext stealing). This is fixed in the upstream version by adding the missing #ifndef XTS_CHAIN_TWEAK around the offending instructions. The upstream code also contains the change applied by Russell to build the code unconditionally, i.e., even if __LINUX_ARM_ARCH__ < 7, but implemented slightly differently. Fixes: e4e7f10b ("ARM: add support for bit sliced AES using NEON instructions") Reported-by:
Adrian Kotelba <adrian.kotelba@gmail.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by:
Milan Broz <gmazyland@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Darrick J. Wong authored
commit e5db2980 upstream. Since it's possible for the discard and write same queue limits to change while the upper level command is being sliced and diced, fix up both of them (a) to reject IO if the special command is unsupported at the start of the function and (b) read the limits once and let the commands error out on their own if the status happens to change. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit 09ee96b2 upstream. The "dm snapshot: suspend origin when doing exception handover" commit fixed a exception store handover bug associated with pending exceptions to the "snapshot-origin" target. However, a similar problem exists in snapshot merging. When snapshot merging is in progress, we use the target "snapshot-merge" instead of "snapshot-origin". Consequently, during exception store handover, we must find the snapshot-merge target and suspend its associated mapped_device. To avoid lockdep warnings, the target must be suspended and resumed without holding _origins_lock. Introduce a dm_hold() function that grabs a reference on a mapped_device, but unlike dm_get(), it doesn't crash if the device has the DMF_FREEING flag set, it returns an error in this case. In snapshot_resume() we grab the reference to the origin device using dm_hold() while holding _origins_lock (_origins_lock guarantees that the device won't disappear). Then we release _origins_lock, suspend the device and grab _origins_lock again. NOTE to stable@ people: When backporting to kernels 3.18 and older, use dm_internal_suspend and dm_internal_resume instead of dm_internal_suspend_fast and dm_internal_resume_fast. Signed-off-by:
-
Mikulas Patocka authored
commit b735fede upstream. In the function snapshot_resume we perform exception store handover. If there is another active snapshot target, the exception store is moved from this target to the target that is being resumed. The problem is that if there is some pending exception, it will point to an incorrect exception store after that handover, causing a crash due to dm-snap-persistent.c:get_exception()'s BUG_ON. This bug can be triggered by repeatedly changing snapshot permissions with "lvchange -p r" and "lvchange -p rw" while there are writes on the associated origin device. To fix this bug, we must suspend the origin device when doing the exception store handover to make sure that there are no pending exceptions: - introduce _origin_hash that keeps track of dm_origin structures. - introduce functions __lookup_dm_origin, __insert_dm_origin and __remove_dm_origin that manipulate the origin hash. - modify snapshot_resume so that it calls dm_internal_suspend_fast() and dm_internal_resume_fast() on the origin device. NOTE to stable@ people: When backporting to kernels 3.12-3.18, use dm_internal_suspend and dm_internal_resume instead of dm_internal_suspend_fast and dm_internal_resume_fast. When backporting to kernels older than 3.12, you need to pick functions dm_internal_suspend and dm_internal_resume from the commit fd2ed4d2. Signed-off-by:
-
