aboutsummaryrefslogtreecommitdiff
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* staging: android: ashmem: add missing includeRom Lemarchand2017-04-131-0/+1
| | | | | | | Include <linux/types.h> into ashmem.h to ensure referenced types are defined Signed-off-by: Rom Lemarchand <romlem@android.com> Change-Id: Iac18ed86dd47296d02a269607b1514724aaa9958
* drivers/rtc/interface.c: fix infinite loop in initializing the alarmAles Novak2017-04-131-2/+12
| | | | | | | | | | | | | | | | In __rtc_read_alarm(), if the alarm time retrieved by rtc_read_alarm_internal() from the device contains invalid values (e.g. month=2,mday=31) and the year not set (=-1), the initialization will loop infinitely because the year-fixing loop expects the time being invalid due to leap year. Fix reduces the loop to the leap years and adds final validity check. Signed-off-by: Ales Novak <alnovak@suse.cz> Acked-by: Alessandro Zummo <a.zummo@towertech.it> Reported-by: Jiri Bohac <jbohac@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* drivers/rtc/rtc-efi.c: check for invalid data coming back from UEFIJan Beulich2017-04-131-5/+27
| | | | | | | | | | | | | | | | | | | | In particular seeing zero in eft->month is problematic, as it results in -1 (converted to unsigned int, i.e. yielding 0xffffffff) getting passed to rtc_year_days(), where the value gets used as an array index (normally resulting in a crash). This was observed with the driver enabled on x86 on some Fujitsu system (with possibly not up to date firmware, but anyway). Perhaps efi_read_alarm() should not fail if neither enabled nor pending are set, but the returned time is invalid? Signed-off-by: Jan Beulich <jbeulich@suse.com> Reported-by: Raymund Will <rw@suse.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Jingoo Han <jg1.han@samsung.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* drivers/rtc/interface.c: check the error after __rtc_read_time()Hyogi Gim2017-04-131-0/+2
| | | | | | | | | | | | | In __rtc_set_alarm(), the error after __rtc_read_time() is not checked. If rtc device fail to read time, we cannot guarantee the following process. Add the verification code for returned __rtc_read_time() error. Signed-off-by: Hyogi Gim <hyogi.gim@lge.com> Acked-by: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* staging: android: ion: Remove ret variable in ion_handle_put_nolockJohanna Abrahamsson2017-04-131-5/+1
| | | | | | | | | | | It is not necessary to save the return value of kref_put since it is directly returned. Change-Id: Id1d2447b4a7f7b802cc001ed78d235808b6dc9f2 Signed-off-by: Johanna Abrahamsson <johanna@mjao.org> Acked-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Corinna Vinschen <xda@vinschen.de>
* sg_write()/bsg_write() is not fit to be called under KERNEL_DSAl Viro2017-04-131-0/+3
| | | | | | | | | | | | Both damn things interpret userland pointers embedded into the payload; worse, they are actually traversing those. Leaving aside the bad API design, this is very much _not_ safe to call with KERNEL_DS. Bail out early if that happens. Change-Id: I383485b4d44970eb61b7178c0b9a4376abfe8cd1 Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Corinna Vinschen <xda@vinschen.de>
* gl_p2p_kal: don't dereference 5ghz channels when disabledDiogo Ferreira2017-04-131-0/+2
| | | | | Change-Id: I8b08502528c4c80f813ebc2efc97e06298ca927d Ticket: PORRIDGE-495
* mediatek: wlan: Add an option to disable 5ghz channels for P2PDiogo Ferreira2017-04-132-0/+11
| | | | | | | | | | | | Some devices might contain antennas that can do ap-sta connectivity fine in 5ghz but cannot provide a consistent experience when forming P2P groups. This patch adds a toggle that, when active, disables 5ghz channels in P2P negotiations. Change-Id: I491f1a7973f1248bd50c381d05987d2814b6f7cd Ticket: PORRIDGE-56
* wifi: fix include for meizu kernelMister Oyster2017-04-131-1/+2
|
* mediatek: Update wifi & gps driverfire8552017-04-13948-478541/+128253
| | | | | | | | | Drivers from 3.18 MM kernel Improves wifi connecting speed adapted for m2 note: no ant, no fm driver Signed-off-by: Mister Oyster <oysterized@gmail.com>
* nl80211: fix scheduled scan RSSI matchset attribute confusionJohannes Berg2017-04-131-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The scheduled scan matchsets were intended to be a list of filters, with the found BSS having to pass at least one of them to be passed to the host. When the RSSI attribute was added, however, this was broken and currently wpa_supplicant adds that attribute in its own matchset; however, it doesn't intend that to mean that anything that passes the RSSI filter should be passed to the host, instead it wants it to mean that everything needs to also have higher RSSI. This is semantically problematic because we have a list of filters like [ SSID1, SSID2, SSID3, RSSI ] with no real indication which one should be OR'ed and which one AND'ed. To fix this, move the RSSI filter attribute into each matchset. As we need to stay backward compatible, treat a matchset with only the RSSI attribute as a "default RSSI filter" for all other matchsets, but only if there are other matchsets (an RSSI-only matchset by itself is still desirable.) To make driver implementation easier, keep a global min_rssi_thold for the entire request as well. The only affected driver is ath6kl. I found this when I looked into the code after Raja Mani submitted a patch fixing the n_match_sets calculation to disregard the RSSI, but that patch didn't address the semantic issue. Reported-by: Raja Mani <rmani@qti.qualcomm.com> Acked-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Git-commit: ea73cbce4e1fd93113301532ad98041b119bc85a [kseelam@codeaurora.org: intel wireless driver changes covered in original patch has dependency of other patches present in upstream kernel. So, only intel driver (iwlwifi) changes are skipped and also retained rssi_thold in cfg80211_sched_scan_request structure to retain backward compatibility] CRs-Fixed: 608887 Change-Id: Iffc3e2fca36340163d8ba289baaa992af41a53c8 Signed-off-by: Komal Seelam <kseelam@codeaurora.org> (cherry picked from commit d5b24231be76c54c5aefea222d40fac03fd7f4ee)
* UPSTREAM: zram/zcomp: do not zero out zcomp private pagesSergey Senozhatsky2017-04-132-4/+4
| | | | | | | | | | | | | | | | (cherry picked from commit e02d238c9852a91b30da9ea32ce36d1416cdc683) Do not __GFP_ZERO allocated zcomp ->private pages. We keep allocated streams around and use them for read/write requests, so we supply a zeroed out ->private to compression algorithm as a scratch buffer only once -- the first time we use that stream. For the rest of IO requests served by this stream ->private usually contains some temporarily data from the previous requests. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Acked-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* UPSTREAM: zram: pass gfp from zcomp frontend to backendMinchan Kim2017-04-133-33/+22
| | | | | | | | | | | | | | | | | | (cherry picked from commit 75d8947a36d0c9aedd69118d1f14bf424005c7c2) Each zcomp backend uses own gfp flag but it's pointless because the context they could be called is driven by upper layer(ie, zcomp frontend). As well, zcomp frondend could call them in different context. One context(ie, zram init part) is it should be better to make sure successful allocation other context(ie, further stream allocation part for accelarating I/O speed) is just optional so let's pass gfp down from driver (ie, zcomp frontend) like normal MM convention. [sergey.senozhatsky@gmail.com: add missing __vmalloc zero and highmem gfps] Signed-off-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* UPSTREAM: zram: try vmalloc() after kmalloc()Kyeongdon Kim2017-04-132-4/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry picked from commit d913897abace843bba20249f3190167f7895e9c3) When we're using LZ4 multi compression streams for zram swap, we found out page allocation failure message in system running test. That was not only once, but a few(2 - 5 times per test). Also, some failure cases were continually occurring to try allocation order 3. In order to make parallel compression private data, we should call kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order 2/3 size memory to allocate in that time, page allocation fails. This patch makes to use vmalloc() as fallback of kmalloc(), this prevents page alloc failure warning. After using this, we never found warning message in running test, also It could reduce process startup latency about 60-120ms in each case. For reference a call trace : Binder_1: page allocation failure: order:3, mode:0x10c0d0 CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20 Call trace: dump_backtrace+0x0/0x270 show_stack+0x10/0x1c dump_stack+0x1c/0x28 warn_alloc_failed+0xfc/0x11c __alloc_pages_nodemask+0x724/0x7f0 __get_free_pages+0x14/0x5c kmalloc_order_trace+0x38/0xd8 zcomp_lz4_create+0x2c/0x38 zcomp_strm_alloc+0x34/0x78 zcomp_strm_multi_find+0x124/0x1ec zcomp_strm_find+0xc/0x18 zram_bvec_rw+0x2fc/0x780 zram_make_request+0x25c/0x2d4 generic_make_request+0x80/0xbc submit_bio+0xa4/0x15c __swap_writepage+0x218/0x230 swap_writepage+0x3c/0x4c shrink_page_list+0x51c/0x8d0 shrink_inactive_list+0x3f8/0x60c shrink_lruvec+0x33c/0x4cc shrink_zone+0x3c/0x100 try_to_free_pages+0x2b8/0x54c __alloc_pages_nodemask+0x514/0x7f0 __get_free_pages+0x14/0x5c proc_info_read+0x50/0xe4 vfs_read+0xa0/0x12c SyS_read+0x44/0x74 DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB [minchan@kernel.org: change vmalloc gfp and adding comment about gfp] [sergey.senozhatsky@gmail.com: tweak comments and styles] Signed-off-by: Kyeongdon Kim <kyeongdon.kim@lge.com> Signed-off-by: Minchan Kim <minchan@kernel.org> Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* UPSTREAM: zram/zcomp: use GFP_NOIO to allocate streamsSergey Senozhatsky2017-04-133-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry picked from commit 3d5fe03a3ea013060ebba2a811aeb0f23f56aefa) We can end up allocating a new compression stream with GFP_KERNEL from within the IO path, which may result is nested (recursive) IO operations. That can introduce problems if the IO path in question is a reclaimer, holding some locks that will deadlock nested IOs. Allocate streams and working memory using GFP_NOIO flag, forbidding recursive IO and FS operations. An example: inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage. git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes: (jbd2_handle){+.+.?.}, at: start_this_handle+0x4ca/0x555 {IN-RECLAIM_FS-W} state was registered at: __lock_acquire+0x8da/0x117b lock_acquire+0x10c/0x1a7 start_this_handle+0x52d/0x555 jbd2__journal_start+0xb4/0x237 __ext4_journal_start_sb+0x108/0x17e ext4_dirty_inode+0x32/0x61 __mark_inode_dirty+0x16b/0x60c iput+0x11e/0x274 __dentry_kill+0x148/0x1b8 shrink_dentry_list+0x274/0x44a prune_dcache_sb+0x4a/0x55 super_cache_scan+0xfc/0x176 shrink_slab.part.14.constprop.25+0x2a2/0x4d3 shrink_zone+0x74/0x140 kswapd+0x6b7/0x930 kthread+0x107/0x10f ret_from_fork+0x3f/0x70 irq event stamp: 138297 hardirqs last enabled at (138297): debug_check_no_locks_freed+0x113/0x12f hardirqs last disabled at (138296): debug_check_no_locks_freed+0x33/0x12f softirqs last enabled at (137818): __do_softirq+0x2d3/0x3e9 softirqs last disabled at (137813): irq_exit+0x41/0x95 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(jbd2_handle); <Interrupt> lock(jbd2_handle); *** DEADLOCK *** 5 locks held by git/20158: #0: (sb_writers#7){.+.+.+}, at: [<ffffffff81155411>] mnt_want_write+0x24/0x4b #1: (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [<ffffffff81145087>] lock_rename+0xd9/0xe3 #2: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [<ffffffff8114f8e2>] lock_two_nondirectories+0x3f/0x6b #3: (&sb->s_type->i_mutex_key#11/4){+.+.+.}, at: [<ffffffff8114f909>] lock_two_nondirectories+0x66/0x6b #4: (jbd2_handle){+.+.?.}, at: [<ffffffff811e31db>] start_this_handle+0x4ca/0x555 stack backtrace: CPU: 2 PID: 20158 Comm: git Not tainted 4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211 Call Trace: dump_stack+0x4c/0x6e mark_lock+0x384/0x56d mark_held_locks+0x5f/0x76 lockdep_trace_alloc+0xb2/0xb5 kmem_cache_alloc_trace+0x32/0x1e2 zcomp_strm_alloc+0x25/0x73 [zram] zcomp_strm_multi_find+0xe7/0x173 [zram] zcomp_strm_find+0xc/0xe [zram] zram_bvec_rw+0x2ca/0x7e0 [zram] zram_make_request+0x1fa/0x301 [zram] generic_make_request+0x9c/0xdb submit_bio+0xf7/0x120 ext4_io_submit+0x2e/0x43 ext4_bio_write_page+0x1b7/0x300 mpage_submit_page+0x60/0x77 mpage_map_and_submit_buffers+0x10f/0x21d ext4_writepages+0xc8c/0xe1b do_writepages+0x23/0x2c __filemap_fdatawrite_range+0x84/0x8b filemap_flush+0x1c/0x1e ext4_alloc_da_blocks+0xb8/0x117 ext4_rename+0x132/0x6dc ? mark_held_locks+0x5f/0x76 ext4_rename2+0x29/0x2b vfs_rename+0x540/0x636 SyS_renameat2+0x359/0x44d SyS_rename+0x1e/0x20 entry_SYSCALL_64_fastpath+0x12/0x6f [minchan@kernel.org: add stable mark] Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Acked-by: Minchan Kim <minchan@kernel.org> Cc: Kyeongdon Kim <kyeongdon.kim@lge.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* mtk: mt_spm_sleep fw updateMoyster2017-04-131-7/+6
|
* drivers: usb: storage: transport: fix maybe-uninitialized warningsNathan Chancellor2017-04-131-2/+2
| | | | | | | | | | | | | | | | | | drivers/usb/storage/transport.c: In function 'usb_stor_bulk_srb': drivers/usb/storage/transport.c:473:40: warning: 'partial' may be used uninitialized in this function [-Wmaybe-uninitialized] scsi_set_resid(srb, scsi_bufflen(srb) - partial); ~~~~~~~~~~~~~~~~~~^~~~~~~~~ drivers/usb/storage/transport.c: In function 'usb_stor_bulk_transfer_sg': drivers/usb/storage/transport.c:499:15: warning: 'partial' may be used uninitialized in this function [-Wmaybe-uninitialized] length_left -= partial; ~~~~~~~~~~~~^~~~~~~~~~ drivers/usb/storage/transport.c: In function 'usb_stor_bulk_transfer_sg': drivers/usb/storage/transport.c:499:15: warning: 'partial' may be used uninitialized in this function [-Wmaybe-uninitialized] length_left -= partial; ~~~~~~~~~~~~^~~~~~~~~~ Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
* drivers: usb: core: hub: fix maybe-uninitialized warningNathan Chancellor2017-04-131-1/+1
| | | | | | | | | | | | drivers/usb/core/hub.c: In function 'usb_port_resume': drivers/usb/core/hub.c:3451:11: warning: 'portstatus' may be used uninitialized in this function [-Wmaybe-uninitialized] status = check_port_resume_type(udev, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ hub, port1, status, portchange, portstatus); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/usb/core/hub.c:3451:11: warning: 'portchange' may be used uninitialized in this function [-Wmaybe-uninitialized] Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
* UID: fix UID_CPUTIME issueAnmin Hsu2017-04-111-0/+18
| | | | | | | | | | | | | | | | | | | [Detail] KernelUidCpuTimeReader read uid_cputime_stat to get system time, but uid_cputime have some issue cause system update value error. Use workaround to fix this issue. [Solution] enable UID_CPUTIME and check new system is smaller than old. If true return old system time. [Feature] UID MTK-Commit-Id: db35d391a485746c9a12f4413a17961a94792323 Change-Id: I27bacb410365bd5144ef34177fe54a88535d1c0d Signed-off-by: May Huang <may.huang@mediatek.com> CR-Id: ALPS02294778
* ANDROID: mmc: move to a SCHED_FIFO threadTim Murray2017-04-111-0/+7
| | | | | | | | | | | | | (cherry picked from commit 011e507b413393eab8279dac8b778ad9b6e9971b) Running mmcqd as a prio 120 thread forces it to compete with standard user processes for IO performance, especially when the system is under severe CPU load. Move it to a SCHED_FIFO thread to reduce the impact of load on IO performance. Signed-off-by: Tim Murray <timmurray@google.com> Bug: 25392275 Change-Id: I1edfe73baa25e181367c30c1f40fee886e92b60d
* ANDROID: mmc: core: export emmc revisionJin Qian2017-04-111-0/+2
| | | | | Change-Id: If23bc838327ef751ee65baadc429e218eaa2a848 Signed-off-by: Jin Qian <jinqian@google.com>
* BACKPORT: mmc: core: Export device lifetime information through sysfsJungseung Lee2017-04-111-0/+14
| | | | | | | | | | | | | | | In the eMMC 5.0 version of the spec, several EXT_CSD fields about device lifetime are added. - Two types of estimated indications reflected by averaged wear out of memory - An indication reflected by average reserved blocks Export the information through sysfs. Signed-off-by: Jungseung Lee <js07.lee@samsung.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* acpi: %ld -> %lu to fix errors found using CppCheckMister Oyster2017-04-112-2/+2
| | | | | | | | [../android_kernel_m2note/drivers/acpi/battery.c:589]: (warning) %ld in format string (no. 1) requires 'long *' but the argument type is 'unsigned long *'. [../android_kernel_m2note/drivers/acpi/sbs.c:470]: (warning) %ld in format string (no. 1) requires 'long *' but the argument type is 'unsigned long *'.
* mtk: squashed security updatesMoyster2017-04-111-4/+4
|
* zram: Fix a wrong return after merged new LZ4 versionjollaman9992017-04-111-2/+4
| | | | | There was a wrong return in e9bd1d1c68dbbf3b76f8a08cc969ca38c18e8e8a. Fix this problem to initialize the zram correctly.
* zram: change usage of LZ4 to work with new LZ4 versionjollaman9992017-04-111-2/+2
|
* tty: n_hdlc: Drop redundant error messageJean Delvare2017-04-111-4/+0
| | | | | | | | | | On initialization failure, an error message is already printed with level KERN_ERR, no need to print another one with level KERN_INFO. Change-Id: I301dac0c178c686b2a027425754c91445c3685f0 Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drivers/tty/n_hdlc.c: replace kmalloc/memset by kzallocFabian Frederick2017-04-111-3/+1
| | | | | | | Change-Id: Ie5a8c08ec3e1cdaada7f9c9181730ff4a353ee97 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* fmradio: cleanupMister Oyster2017-04-111-1/+0
|
* drv_wlan: remove meizu/mtk debugMister Oyster2017-04-116-30/+0
|
* accdet: remove meizu log ifdefsMister Oyster2017-04-111-4/+0
|
* drivers: mediatek: wdt: Reduce unnecessary logsTim Kryger2017-04-111-4/+0
| | | | | | | | Avoid logging every start or stop of the WDT as this clutters the log. Bug: 27767950 Change-Id: I29e603b2514392fb1cf2168f89ff105eace6fc8e Signed-off-by: Tim Kryger <tkryger@google.com>
* leds: remove meizu logMoyster2017-04-111-4/+0
|
* Get rid of __cpuinitMoyster2017-04-1139-102/+102
| | | | | | | | | | | | | | | | | | | | | This commit is the result of find . -name '*.c' | xargs sed -i 's/ __cpuinit / /g' find . -name '*.c' | xargs sed -i 's/ __cpuexit / /g' find . -name '*.c' | xargs sed -i 's/ __cpuinitdata / /g' find . -name '*.c' | xargs sed -i 's/ __cpuinit$//g' find ./arch/ -name '*.h' | xargs sed -i 's/ __cpuinit//g' find . -name '*.c' | xargs sed -i 's/^__cpuinit //g' find . -name '*.c' | xargs sed -i 's/^__cpuinitdata //g' find . -name '*.c' | xargs sed -i 's/\*__cpuinit /\*/g' find . -name '*.c' | xargs sed -i 's/ __cpuinitconst / /g' find . -name '*.h' | xargs sed -i 's/ __cpuinit / /g' find . -name '*.h' | xargs sed -i 's/ __cpuinitdata / /g' git add . git reset include/linux/init.h git checkout -- include/linux/init.h based off : https://github.com/jollaman999/jolla-kernel_bullhead/commit/bc15db84a622eed7d61d3ece579b577154d0ec29
* tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.cKosuke Tatsukawa2017-04-111-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e81107d4c6bd098878af9796b24edc8d4a9524fd upstream. My colleague ran into a program stall on a x86_64 server, where n_tty_read() was waiting for data even if there was data in the buffer in the pty. kernel stack for the stuck process looks like below. #0 [ffff88303d107b58] __schedule at ffffffff815c4b20 #1 [ffff88303d107bd0] schedule at ffffffff815c513e #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818 #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2 #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23 #5 [ffff88303d107dd0] tty_read at ffffffff81368013 #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704 #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57 #8 [ffff88303d107f00] sys_read at ffffffff811a4306 #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7 There seems to be two problems causing this issue. First, in drivers/tty/n_tty.c, __receive_buf() stores the data and updates ldata->commit_head using smp_store_release() and then checks the wait queue using waitqueue_active(). However, since there is no memory barrier, __receive_buf() could return without calling wake_up_interactive_poll(), and at the same time, n_tty_read() could start to wait in wait_woken() as in the following chart. __receive_buf() n_tty_read() ------------------------------------------------------------------------ if (waitqueue_active(&tty->read_wait)) /* Memory operations issued after the RELEASE may be completed before the RELEASE operation has completed */ add_wait_queue(&tty->read_wait, &wait); ... if (!input_available_p(tty, 0)) { smp_store_release(&ldata->commit_head, ldata->read_head); ... timeout = wait_woken(&wait, TASK_INTERRUPTIBLE, timeout); ------------------------------------------------------------------------ The second problem is that n_tty_read() also lacks a memory barrier call and could also cause __receive_buf() to return without calling wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken() as in the chart below. __receive_buf() n_tty_read() ------------------------------------------------------------------------ spin_lock_irqsave(&q->lock, flags); /* from add_wait_queue() */ ... if (!input_available_p(tty, 0)) { /* Memory operations issued after the RELEASE may be completed before the RELEASE operation has completed */ smp_store_release(&ldata->commit_head, ldata->read_head); if (waitqueue_active(&tty->read_wait)) __add_wait_queue(q, wait); spin_unlock_irqrestore(&q->lock,flags); /* from add_wait_queue() */ ... timeout = wait_woken(&wait, TASK_INTERRUPTIBLE, timeout); ------------------------------------------------------------------------ There are also other places in drivers/tty/n_tty.c which have similar calls to waitqueue_active(), so instead of adding many memory barrier calls, this patch simply removes the call to waitqueue_active(), leaving just wake_up*() behind. This fixes both problems because, even though the memory access before or after the spinlocks in both wake_up*() and add_wait_queue() can sneak into the critical section, it cannot go past it and the critical section assures that they will be serialized (please see "INTER-CPU ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a better explanation). Moreover, the resulting code is much simpler. Latency measurement using a ping-pong test over a pty doesn't show any visible performance drop. Change-Id: I1bbb699d6f844ca9d47b8000f5fddc4e3bc5332b Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: - adjust context - s/wake_up_interruptible_poll/wake_up_interruptible/ - drop changes to __receive_buf() and n_tty_set_termios()] Signed-off-by: Zefan Li <lizefan@huawei.com>
* 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>
generated by cgit v1.2.3 (git 2.39.1) at 2026-04-21 03:34:56 +0000