aboutsummaryrefslogtreecommitdiff
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
* tty: n_hdlc: get rid of racy n_hdlc.tbufAlexander Popov2017-04-111-63/+69
| | | | | | | | | | | | | | | | | | | | | | commit 82f2341c94d270421f383641b7cd670e474db56b upstream. Currently N_HDLC line discipline uses a self-made singly linked list for data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after an error. The commit be10eb7589337e5defbe214dae038a53dd21add8 ("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf. After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put one data buffer to tx_free_buf_list twice. That causes double free in n_hdlc_release(). Let's use standard kernel linked list and get rid of n_hdlc.tbuf: in case of tx error put current data buffer after the head of tx_buf_list. Change-Id: I82071092f122d8c26fe22ce1835812427cc5d282 Signed-off-by: Alexander Popov <alex.popov@linux.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* TTY: n_hdlc, fix lockdep false positiveJiri Slaby2017-04-111-15/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e9b736d88af1a143530565929390cadf036dc799 upstream. The class of 4 n_hdls buf locks is the same because a single function n_hdlc_buf_list_init is used to init all the locks. But since flush_tx_queue takes n_hdlc->tx_buf_list.spinlock and then calls n_hdlc_buf_put which takes n_hdlc->tx_free_buf_list.spinlock, lockdep emits a warning: ============================================= [ INFO: possible recursive locking detected ] 4.3.0-25.g91e30a7-default #1 Not tainted --------------------------------------------- a.out/1248 is trying to acquire lock: (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fd020>] n_hdlc_buf_put+0x20/0x60 [n_hdlc] but task is already holding lock: (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fdc07>] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&list->spinlock)->rlock); lock(&(&list->spinlock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by a.out/1248: #0: (&tty->ldisc_sem){++++++}, at: [<ffffffff814c9eb0>] tty_ldisc_ref_wait+0x20/0x50 #1: (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fdc07>] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc] ... Call Trace: ... [<ffffffff81738fd0>] _raw_spin_lock_irqsave+0x50/0x70 [<ffffffffa01fd020>] n_hdlc_buf_put+0x20/0x60 [n_hdlc] [<ffffffffa01fdc24>] n_hdlc_tty_ioctl+0x144/0x1d0 [n_hdlc] [<ffffffff814c25c1>] tty_ioctl+0x3f1/0xe40 ... Fix it by initializing the spin_locks separately. This removes also reduntand memset of a freshly kzallocated space. Change-Id: Iddbfb4fd69a00fb0e1cb1239a8badfdfa05f7898 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* masp: remove unused filp related functions.tadd.kao2017-04-1194-13613/+0
| | | | | | | | | | | | | [Detail] Open file in kernel space is not a secure way. [Solution] Remove the file operation in kernel since they are not used. [Feature] Secure Boot BUG=23460645 Change-Id: I79bd3f4f29ca1b1b3aa4ca43b8e8d60382341dbc Signed-off-by: tadd.kao <tadd.kao@mediatek.com> CR-Id: ALPS02363269
* arm: mediate; remove file open apissu-ying hung2017-04-114-75/+50
| | | | | | | User request_firmware api to read CONNSYS patch binary instead of file_open apiq Change-Id: I87982afa8b47958e899a7af8ab0d04a72e3f771a Signed-off-by: ssu-ying hung <ssu-ying.hung@mediatek.com>
* wakeup: Add last wake up source logging for suspend abort reason.Ruchi Kandoi2017-04-111-3/+19
| | | | | | | | | | | | There is a possibility that a wakeup source event is received after the device prepares to suspend which might cause the suspend to abort. This patch adds the functionality of reporting the last active wakeup source which is currently not active but caused the suspend to abort reason via the /sys/kernel/power/last_wakeup_reason file. Change-Id: I1760d462f497b33e425f5565cb6cff5973932ec3 Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
* remove filp_open in bt driverStanley Yeh2017-04-111-57/+0
| | | | Change-Id: I0c8d1539891af9370ba8b364c6eaab8473c8ca0c
* drivers: mediatek: battery_meter: Reduce debug logTim Kryger2017-04-111-1/+1
| | | | | | | | Reduce the amount of information printed to the kernel log. Bug: 27767950 Change-Id: Ibd3b84615bc50bdc82673ee7fc2ff07e97a45c37 Signed-off-by: Tim Kryger <tkryger@google.com>
* PM: Disable unnecessary loggingTim Kryger2017-04-111-2/+0
| | | | | | | | Switch off extra debug prints that clutters the log. Bug: 27767950 Change-Id: I5344729b8c34d8121b334f2f84bb0afa1e64c583 Signed-off-by: Tim Kryger <tkryger@google.com>
* A2DP performance improvement.David Chu2017-04-111-2/+2
| | | | | | | Replaced busy udelay loop with usleep_range to reduce CPU usage in stp_sdio_tx_rx. Bug: 27713674
* arm:mediatek: Resolve wmtFunCtrl wakelock issuessu-ying hung2017-04-114-13/+91
| | | | | | | | 1.add the unlock step in some error case 2.add a timer to control the abnormal flow Change-Id: Ief9108eae213214123c8c68aaa83eafc7101bec9 Signed-off-by: ssu-ying hung <ssu-ying.hung@mediatek.com>
* power: align wakeup_sources formatyangdongdong2017-04-111-2/+2
| | | | | | | | This aligns every column of elements in wakeup_sources to conveniently check any specific column for suspicious power consumption wakeup source or for other easily human readable purpose. Signed-off-by: yangdongdong <yangdongdong@xiaomi.com>
* cpuidle: don't disable cpuidle when entering suspendTim Murray2017-04-111-3/+0
| | | | | | | | | | cpuidle was disabled while entering suspend as part of commit 8651f97bd951d0bb1c10fa24e3fa3455193f3548 in order to work around some ACPI bugs. However, there's no reason to do this on modern platforms. Leaving cpuidle enabled can result in improved power consumption if dpm_resume_noirq runs for a significant time. Change-Id: Ie182785b176f448698c0264eba554d1e315e8a06
* drivers:lmk: implement task's adj rbtreeYi-wei Zhao2017-04-112-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on the current LMK implementation, LMK has to scan all processes to select the correct task to kill during low memory. The basic idea for the optimization is to : queue all tasks with oom_score_adj priority, and then LMK just selects the proper task from the queue(rbtree) to kill. performance improvement: current: average time to find a task to kill : 1004us optimized: average time to find a task to kill: 43us Change-Id: I32504e9f2f370d58c038eea7457d95c8ed8b6b9b Signed-off-by: Hong-Mei Li <a21834@motorola.com> Signed-off-by: Yi-wei Zhao <gbjc64@motorola.com> Reviewed-on: http://gerrit.mot.com/701205 SLTApproved: Slta Waiver <sltawvr@motorola.com> Tested-by: Jira Key <jirakey@motorola.com> Submit-Approved: Jira Key <jirakey@motorola.com> Conflicts: drivers/staging/android/Kconfig include/linux/sched.h
* binder: use group leader instead of open threadMartijn Coenen2017-04-111-3/+3
| | | | | | | | | | | | | | | The binder allocator assumes that the thread that called binder_open will never die for the lifetime of that proc. That thread is normally the group_leader, however it may not be. Use the group_leader instead of current. Bug: 35707103 Test: Created test case to open with temporary thread Change-Id: Id693f74b3591f3524a8c6e9508e70f3e5a80c588 Signed-off-by: Todd Kjos <tkjos@google.com> Signed-off-by: Martijn Coenen <maco@android.com>
* input: evdev: Move wake_lock_destroy callAnurag Singh2017-04-111-1/+1
| | | | | | | | | | | | | | Calling wake_lock_destroy from inside a spinlock protected region (or, in general, from atomic context) leads to a 'scheduling while atomic bug' because the internal wakeup source deletion logic calls synchronize_rcu, which can sleep. Moreover, since the interal lists are already protected with RCUs and spinlocks, putting the wake_lock_destroy call in a spinlock is redundant. Change-Id: I10a2239b664a5f43e54495f24fe588fb09282305 Signed-off-by: Anurag Singh <anursing@codeaurora.org>
* UPSTREAM staging: ion: Fix error handling in ion_buffer_createRohit kumar2017-04-111-10/+4
| | | | | | | | | | | | | | | | This patch fixes error handling case when buffer->pages allocation fails. Also, it removes unreachable code of checking ret variable although it is not updated. Signed-off-by: Rohit kumar <rohit.kr@samsung.com> Reviewed-by: Laura Abbott <labbott@redhat.com> Suggested-by: Pintu Kumar <pintu.k@samsung.com> Reviewed-by: Pintu Kumar <pintu.k@samsung.com> Reviewed-by: Gioh Kim <gioh.kim@lge.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit a56d092aa94ebcc9452ddaa47423b9a478aa6aa5) Change-Id: Ic38b8e3ef0a21de4e38e58b4bb942535fe671ae5 Bug: 34283718
* UPSTREAM: regulator: core: Fix regualtor_ena_gpio_free not to access pin ↵Seung-Woo Kim2017-04-111-0/+2
| | | | | | | | | | | | after freeing After freeing pin from regulator_ena_gpio_free, loop can access the pin. So this patch fixes not to access pin after freeing. Bug: 35399757 Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit 60a2362f769cf549dc466134efe71c8bf9fbaaba)
* lsm6ds3: fix suspend/resume behaviorMister Oyster2017-04-112-7/+3
|
* spm: update to pcm_deepidle_v0.2.5.6.4.1_20160311-dummy_readMister Oyster2017-04-111-7/+6
|
* lmk: revert mediatek's modificationsChinwen Chang2017-04-111-419/+11
| | | | | | | | | | | | | | | [Detail] Revert mediatek's modifications on LMK driver to reduce kernel merge conflicts. [Solution] Revert mediatek's modifications. [Feature] LMK Change-Id: I37c747252f4ca880376878735ec2a3826161cd98 Signed-off-by: Chinwen Chang <chinwen.chang@mediatek.com> CR-Id: ALPS02383593
* binder: blacklist %p kptr_restrictNick Desaulniers2017-04-111-13/+13
| | | | | | | | | Bug: 31495231 Change-Id: Iebc150f6bc939b56e021424ee44fb30ce8d732fd [d-cagle@codeaurora.org: Applied to correct file location] Git-repo: https://android.googlesource.com/kernel/msm.git Git-commit: 0804d7840364fc1a93652632bd43a93c055c658e Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
* Update m4u, smi and gud driversfire8552017-04-11180-16669/+29653
| | | | Backported from 3.18 MM kernel
* Fix "Elevation of privilege vulnerability in MediaTek video driver"fire8552017-04-111-23/+0
| | | | | | CVE-2016-3936, CVE-2016-3937 An elevation of privilege vulnerability in the MediaTek video driver could enable a local malicious application to execute arbitrary code within the context of the kernel. This issue is rated as High because it first requires compromising a privileged process.
* binder: blacklist %p kptr_restrictfire8552017-04-111-12/+12
|
* ion: blacklist %p kptr_restrictfire8552017-04-111-22/+22
|
* drivers: video: Add bounds checking in fb_cmap_to_userSteve Pfetsch2017-04-111-0/+3
| | | | | | | | Verify that unsigned int value will not become negative before cast to signed int. Bug: 31651010 Change-Id: I548a200f678762042617f11100b6966a405a3920
* adf: Zero out the mapping dataDennis Cagle2017-04-111-1/+3
| | | | | | | | | | | | | The adf_device_post_nocopy function eventually calls the dma_buf_attach and dma_buf_map_attachment functions. If the dma_buf_attach function succeeds but the dma_buf_map_attachment function fails, both the adf_buffer_map function and the adf_device_post_nocopy function will call the dma_buf_detach function to tear down the same dma-buf attachment. b/28447556 Change-Id: I8eb40486496fe2a2ae5dfa1be4b76a4af0d6b827 Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
* block: make rq->cmd_flags be 64-bitJens Axboe2017-04-112-3/+3
| | | | | | | | We have officially run out of flags in a 32-bit space. Extend it to 64-bit even on 32-bit archs. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
* random: initialize the non-blocking pool via add_hwgenerator_randomness()Theodore Ts'o2017-04-111-5/+11
| | | | | | | | | If we have a hardware RNG and are using the in-kernel rngd, we should use this to initialize the non-blocking pool so that getrandom(2) doesn't block unnecessarily. Cc: stable@kernel.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* random: Remove kernel blocking APIHerbert Xu2017-04-111-12/+0
| | | | | | | This patch removes the kernel blocking API as it has been completely replaced by the callback API. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* random: Add callback API for random pool readinessHerbert Xu2017-04-111-0/+78
| | | | | | | | | | | | | | | | | The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with a callback API instead. The callback is invoked potentially from interrupt context so the user needs to schedule their own work thread if necessary. In addition to adding callbacks, they can also be removed as otherwise this opens up a way for user-space to allocate kernel memory with no bound (by opening algif_rng descriptors and then closing them). Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* random: Blocking API for accessing nonblocking_poolStephan Mueller2017-04-111-0/+12
| | | | | | | | | | | | The added API calls provide a synchronous function call get_blocking_random_bytes where the caller is blocked until the nonblocking_pool is initialized. CC: Andreas Steffen <andreas.steffen@strongswan.org> CC: Theodore Ts'o <tytso@mit.edu> CC: Sandy Harris <sandyinchina@gmail.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* random: Wake up all getrandom(2) callers when pool is readyHerbert Xu2017-04-111-1/+1
| | | | | | | | | | If more than one application invokes getrandom(2) before the pool is ready, then all bar one will be stuck forever because we use wake_up_interruptible which wakes up a single task. This patch replaces it with wake_up_all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* fbdev/efifb: Fix 16 color palette entry calculationMax Staudt2017-04-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | commit d50b3f43db739f03fcf8c0a00664b3d2fed0496e upstream. When using efifb with a 16-bit (5:6:5) visual, fbcon's text is rendered in the wrong colors - e.g. text gray (#aaaaaa) is rendered as green (#50bc50) and neighboring pixels have slightly different values (such as #50bc78). The reason is that fbcon loads its 16 color palette through efifb_setcolreg(), which in turn calculates a 32-bit value to write into memory for each palette index. Until now, this code could only handle 8-bit visuals and didn't mask overlapping values when ORing them. With this patch, fbcon displays the correct colors when a qemu VM is booted in 16-bit mode (in GRUB: "set gfxpayload=800x600x16"). Fixes: 7c83172b98e5 ("x86_64 EFI boot support: EFI frame buffer driver") # v2.6.24+ Signed-off-by: Max Staudt <mstaudt@suse.de> Acked-By: Peter Jones <pjones@redhat.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* dm: mark request_queue dead before destroying the DM deviceBart Van Assche2017-04-111-0/+5
| | | | | | | | | | | | | | commit 3b785fbcf81c3533772c52b717f77293099498d3 upstream. This avoids that new requests are queued while __dm_destroy() is in progress. [js] use md->queue instead of non-present helper Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Willy Tarreau <w@1wt.eu>
* regulator: tps65910: Work around silicon erratum SWCZ010Jan Remmet2017-04-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8f9165c981fed187bb483de84caf9adf835aefda upstream. http://www.ti.com/lit/pdf/SWCZ010: DCDC o/p voltage can go higher than programmed value Impact: VDDI, VDD2, and VIO output programmed voltage level can go higher than expected or crash, when coming out of PFM to PWM mode or using DVFS. Description: When DCDC CLK SYNC bits are 11/01: * VIO 3-MHz oscillator is the source clock of the digital core and input clock of VDD1 and VDD2 * Turn-on of VDD1 and VDD2 HSD PFETis synchronized or at a constant phase shift * Current pulled though VCC1+VCC2 is Iload(VDD1) + Iload(VDD2) * The 3 HSD PFET will be turned-on at the same time, causing the highest possible switching noise on the application. This noise level depends on the layout, the VBAT level, and the load current. The noise level increases with improper layout. When DCDC CLK SYNC bits are 00: * VIO 3-MHz oscillator is the source clock of digital core * VDD1 and VDD2 are running on their own 3-MHz oscillator * Current pulled though VCC1+VCC2 average of Iload(VDD1) + Iload(VDD2) * The switching noise of the 3 SMPS will be randomly spread over time, causing lower overall switching noise. Workaround: Set DCDCCTRL_REG[1:0]= 00. Signed-off-by: Jan Remmet <j.remmet@phytec.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Willy Tarreau <w@1wt.eu>
* hwmon: (adt7411) set bit 3 in CFG1 registerMichael Walle2017-04-111-1/+4
| | | | | | | | | | | | commit b53893aae441a034bf4dbbad42fe218561d7d81f upstream. According to the datasheet you should only write 1 to this bit. If it is not set, at least AIN3 will return bad values on newer silicon revisions. Fixes: d84ca5b345c2 ("hwmon: Add driver for ADT7411 voltage and temperature sensor") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Willy Tarreau <w@1wt.eu>
* can: dev: fix deadlock reported after bus-offSergei Miroshnichenko2017-04-111-10/+17
| | | | | | | | | | | | | | | | | | | | commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream. A timer was used to restart after the bus-off state, leading to a relatively large can_restart() executed in an interrupt context, which in turn sets up pinctrl. When this happens during system boot, there is a high probability of grabbing the pinctrl_list_mutex, which is locked already by the probe() of other device, making the kernel suspect a deadlock condition [1]. To resolve this issue, the restart_timer is replaced by a delayed work. [1] https://github.com/victronenergy/venus/issues/24 Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Willy Tarreau <w@1wt.eu>
* dm flakey: fix reads to be issued if drop_writes configuredMike Snitzer2017-04-111-11/+16
| | | | | | | | | | | | | commit 299f6230bc6d0ccd5f95bb0fb865d80a9c7d5ccc upstream. v4.8-rc3 commit 99f3c90d0d ("dm flakey: error READ bios during the down_interval") overlooked the 'drop_writes' feature, which is meant to allow reads to be issued rather than errored, during the down_interval. Fixes: 99f3c90d0d ("dm flakey: error READ bios during the down_interval") Reported-by: Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* PCI: Handle read-only BARs on AMD CS553x devicesMyron Stowe2017-04-111-4/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream. Some AMD CS553x devices have read-only BARs because of a firmware or hardware defect. There's a workaround in quirk_cs5536_vsa(), but it no longer works after 36e8164882ca ("PCI: Restore detection of read-only BARs"). Prior to 36e8164882ca, we filled in res->start; afterwards we leave it zeroed out. The quirk only updated the size, so the driver tried to use a region starting at zero, which didn't work. Expand quirk_cs5536_vsa() to read the base addresses from the BARs and hard-code the sizes. On Nix's system BAR 2's read-only value is 0x6200. Prior to 36e8164882ca, we interpret that as a 512-byte BAR based on the lowest-order bit set. Per datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to avoid clearing any address bits if a platform uses only 64-byte alignment. [js] pcibios_bus_to_resource takes pdev, not bus in 3.12 [bhelgaas: changelog, reduce BAR 2 size to 64] Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs") Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4 Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf Reported-and-tested-by: Nix <nix@esperi.org.uk> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Willy Tarreau <w@1wt.eu>
* ACPI / APEI: Fix incorrect return value of ghes_proc()Punit Agrawal2017-04-111-1/+1
| | | | | | | | | | | | | | | | commit 806487a8fc8f385af75ed261e9ab658fc845e633 upstream. Although ghes_proc() tests for errors while reading the error status, it always return success (0). Fix this by propagating the return value. Fixes: d334a49113a4a33 (ACPI, APEI, Generic Hardware Error Source memory error support) Signed-of-by: Punit Agrawal <punit.agrawa.@arm.com> Tested-by: Tyler Baicar <tbaicar@codeaurora.org> Reviewed-by: Borislav Petkov <bp@suse.de> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* mei: bus: fix received data size check in NFC fixupAlexander Usyskin2017-04-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | commit 582ab27a063a506ccb55fc48afcc325342a2deba upstream. NFC version reply size checked against only header size, not against full message size. That may lead potentially to uninitialized memory access in version data. That leads to warnings when version data is accessed: drivers/misc/mei/bus-fixup.c: warning: '*((void *)&ver+11)' may be used uninitialized in this function [-Wuninitialized]: => 212:2 Reported in Build regressions/improvements in v4.9-rc3 https://lkml.org/lkml/2016/10/30/57 [js] the check is in 3.12 only once Fixes: 59fcd7c63abf (mei: nfc: Initial nfc implementation) Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Willy Tarreau <w@1wt.eu>
* staging: iio: ad5933: avoid uninitialized variable in error caseArnd Bergmann2017-04-111-7/+10
| | | | | | | | | | | | | | | | | | | | | commit 34eee70a7b82b09dbda4cb453e0e21d460dae226 upstream. The ad5933_i2c_read function returns an error code to indicate whether it could read data or not. However ad5933_work() ignores this return code and just accesses the data unconditionally, which gets detected by gcc as a possible bug: drivers/staging/iio/impedance-analyzer/ad5933.c: In function 'ad5933_work': drivers/staging/iio/impedance-analyzer/ad5933.c:649:16: warning: 'status' may be used uninitialized in this function [-Wmaybe-uninitialized] This adds minimal error handling so we only evaluate the data if it was correctly read. Link: https://patchwork.kernel.org/patch/8110281/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Willy Tarreau <w@1wt.eu>
* hv: do not lose pending heartbeat vmbus packetsLong Li2017-04-111-3/+7
| | | | | | | | | | | | | | | | commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c upstream. The host keeps sending heartbeat packets independent of the guest responding to them. Even though we respond to the heartbeat messages at interrupt level, we can have situations where there maybe multiple heartbeat messages pending that have not been responded to. For instance this occurs when the VM is paused and the host continues to send the heartbeat messages. Address this issue by draining and responding to all the heartbeat messages that maybe pending. Signed-off-by: Long Li <longli@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* uio: fix dmem_region_start computationJan Viktorin2017-04-111-1/+1
| | | | | | | | | | | | | | | | commit 4d31a2588ae37a5d0f61f4d956454e9504846aeb upstream. The variable i contains a total number of resources (including IORESOURCE_IRQ). However, we want the dmem_region_start to point after the last resource of type IORESOURCE_MEM. The original behaviour leads (very likely) to skipping several UIO mapping regions and makes them useless. Fix this by computing dmem_region_start from the uiomem which points to the last used UIO mapping. Fixes: 0a0c3b5a24bd ("Add new uio device for dynamic memory allocation") Signed-off-by: Jan Viktorin <viktorin@rehivetech.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* gpio: mpc8xxx: Correct irq handler functionLiu Gang2017-04-111-1/+1
| | | | | | | | | | | | | | | | | | commit d71cf15b865bdd45925f7b094d169aaabd705145 upstream. From the beginning of the gpio-mpc8xxx.c, the "handle_level_irq" has being used to handle GPIO interrupts in the PowerPC/Layerscape platforms. But actually, almost all PowerPC/Layerscape platforms assert an interrupt request upon either a high-to-low change or any change on the state of the signal. So the "handle_level_irq" is not reasonable for PowerPC/Layerscape GPIO interrupt, it should be "handle_edge_irq". Otherwise the system may lost some interrupts from the PIN's state changes. Signed-off-by: Liu Gang <Gang.Liu@nxp.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Willy Tarreau <w@1wt.eu>
* cx231xx: fix GPIOs for Pixelview SBTVD hybridMauro Carvalho Chehab2017-04-112-2/+3
| | | | | | | | | | | | | commit 24b923f073ac37eb744f56a2c7f77107b8219ab2 upstream. This device uses GPIOs: 28 to switch between analog and digital modes: on digital mode, it should be set to 1. The code that sets it on analog mode is OK, but it misses the logic that sets it on digital mode. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* cx231xx: don't return error on successMauro Carvalho Chehab2017-04-111-1/+4
| | | | | | | | | | | commit 1871d718a9db649b70f0929d2778dc01bc49b286 upstream. The cx231xx_set_agc_analog_digital_mux_select() callers expect it to return 0 or an error. Returning a positive value makes the first attempt to switch between analog/digital to fail. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* mb86a20s: fix demod settingsMauro Carvalho Chehab2017-04-111-50/+42
| | | | | | | | | | | | | | | | | commit 505a0ea706fc1db4381baa6c6bd2e596e730a55e upstream. With the current settings, only one channel locks properly. That's likely because, when this driver was written, Brazil were still using experimental transmissions. Change it to reproduce the settings used by the newer drivers. That makes it lock on other channels. Tested with both PixelView SBTVD Hybrid (cx231xx-based) and C3Tech Digital Duo HDTV/SDTV (em28xx-based) devices. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* mb86a20s: fix the locking logicMauro Carvalho Chehab2017-04-111-1/+11
| | | | | | | | | | | | | | | | | | | commit dafb65fb98d85d8e78405e82c83e81975e5d5480 upstream. On this frontend, it takes a while to start output normal TS data. That only happens on state S9. On S8, the TS output is enabled, but it is not reliable enough. However, the zigzag loop is too fast to let it sync. As, on practical tests, the zigzag software loop doesn't seem to be helping, but just slowing down the tuning, let's switch to hardware algorithm, as the tuners used on such devices are capable of work with frequency drifts without any help from software. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-17 20:52:27 +0000