aboutsummaryrefslogtreecommitdiff
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
* staging: alarm-dev: Remove unnecessary parenthesisSeongJae Park2017-04-131-2/+2
| | | | | Signed-off-by: SeongJae Park <sj38.park@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* staging/android: Add kerneldoc to one function in alarm-dev.cCruz Julian Bishop2017-04-131-1/+6
| | | | | | | | | | | | Sorry. I thought that this would be a nice easy class to document fully. Turns out I was very wrong - I will have to research the Linux alarm and timer subsystem one day next week and try again. Here is what I started out with, anyway. It's not much, but it's better than nothing! Signed-off-by: Cruz Julian Bishop <cruzjbishop@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PowerOffAlarms: Clean a bit ...Cesar Matias2017-04-131-4/+0
|
* PowerOffAlarms: Fixs for 3.10 kernelCesar Matias2017-04-131-51/+11
|
* PowerOffAlarms: add ANDROID_INTF_ALARM_DEV and activate itDerTeufel2017-04-134-0/+678
| | | | | | | Provides non-wakeup and rtc backed wakeup alarms based on rtc or elapsed realtime, and a non-wakeup alarm on the monotonic clock. Espically for wake up alarm ioctl. Also exports the alarm interface to user-space.
* scsi: sg: check length passed to SG_NEXT_CMD_LENpeter chang2017-04-131-0/+2
| | | | | | | | | | | | The user can control the size of the next command passed along, but the value passed to the ioctl isn't checked against the usable max command size. Change-Id: I9e8eb8ca058c0103a22f5d99d77919432893aa4c Cc: <stable@vger.kernel.org> Signed-off-by: Peter Chang <dpf@google.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
* BACKPORT: sg: relax 16 byte cdb restrictionDouglas Gilbert2017-04-131-17/+29
| | | | | | | | | | | | | | | - remove the 16 byte CDB (SCSI command) length limit from the sg driver by handling longer CDBs the same way as the bsg driver. Remove comment from sg.h public interface about the cmd_len field being limited to 16 bytes. - remove some dead code caused by this change - cleanup comment block at the top of sg.h, fix urls Change-Id: Ie8150e5375b3316d5d5206f079c4a50f1c50b755 Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
* BACKPORT: block: add blk_rq_set_block_pc()Jens Axboe2017-04-1313-16/+17
| | | | | | | | | | | | | | | | | With the optimizations around not clearing the full request at alloc time, we are leaving some of the needed init for REQ_TYPE_BLOCK_PC up to the user allocating the request. Add a blk_rq_set_block_pc() that sets the command type to REQ_TYPE_BLOCK_PC, and properly initializes the members associated with this type of request. Update callers to use this function instead of manipulating rq->cmd_type directly. Includes fixes from Christoph Hellwig <hch@lst.de> for my half-assed attempt. Change-Id: Ifc386dfb951c5d6adebf48ff38135dda28e4b1ce Signed-off-by: Jens Axboe <axboe@fb.com>
* GPIO: Remove unused gpio debug cmd arraryDavid Chu2017-04-131-20/+2
| | | | | | | | | [Detail] Remove unused gpio debug cmd arrary which will cause secure problem Bug: ALPS02943506 Change-Id: If5f63928fd5788f853e5e956d7117775e58e32a2
* Security Vulnerability in Mediatek driver : arbitrary kernel writeEddie Chen2017-04-131-17/+19
| | | | | | | | | google security issue fix Bug num:25873324 Change-Id: I2eb8e03dc67209d9a709fc4a27976f986f0b7606 Signed-off-by: Eddie Chen <eddie.chen@mediatek.com>
* wifi: fix mergeMister Oyster2017-04-131-0/+2
|
* BACKPORT: HID: input: generic hidinput_input_event handlerDavid Herrmann2017-04-132-26/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | The hidinput_input_event() callback converts input events written from userspace into HID reports and sends them to the device. We currently implement this in every HID transport driver, even though most of them do the same. This provides a generic hidinput_input_event() implementation which is mostly copied from usbhid. It uses a delayed worker to allow multiple LED events to be collected into a single output event. We use the custom ->request() transport driver callback to allow drivers to adjust the outgoing report and handle the request asynchronously. If no custom ->request() callback is available, we fall back to the generic raw output report handler (which is synchronous). Drivers can still provide custom hidinput_input_event() handlers (see logitech-dj) if the generic implementation doesn't fit their needs. Conflicts: drivers/hid/hid-input.c Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Michael Wright <michaelwr@google.com> Change-Id: Iccb0b1de6460f6854b3d55d4008cc1d744472a06
* Revert "[ARM] armv6 dcc tty driver"Amit Pundir2017-04-133-331/+0
| | | | | | | | | | This reverts commit 0ddfd45dee0d0de1038bb4adcc774a43493af647. Drop AOSP's "armv6 dcc tty driver" in favor of upstream DCC driver for ARMv6/v7 16c63f8ea49c (drivers: char: hvc: add arm JTAG DCC console support). Change-Id: I0ca651ef2d854fff03cee070524fe1e3971b6d8f Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
* video: adf: Set ADF_MEMBLOCK to booleanGuenter Roeck2017-04-131-1/+1
| | | | | | | | | | | | | | | Attempts to build with CONFIG_ADF_MEMBLOCK=m result in the following build error. ERROR: "memblock_free" [drivers/video/adf/adf_memblock.ko] undefined! memblock_free() is marked as __init_memblock, so exporting it seems to be a bad idea. All other callers are only configurable into the kernel, so do the same with ADF_MEMBLOCK. Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit 077be8a752875772589c70299a291070807c8046) Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
* video: adf: Fix modular buildGuenter Roeck2017-04-131-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Builds with ADF configured as module fail the following errors. ERROR: "adf_fops" [drivers/video/adf/adf_sysfs.ko] undefined! ERROR: "adf_obj_sysfs_find" [drivers/video/adf/adf_fops.ko] undefined! ERROR: "adf_buffer_cleanup" [drivers/video/adf/adf_fops.ko] undefined! ERROR: "adf_attachment_validate" [drivers/video/adf/adf_client.ko] undefined! ERROR: "adf_attachment_find" [drivers/video/adf/adf_client.ko] undefined! ERROR: "adf_buffer_mapping_cleanup" [drivers/video/adf/adf_client.ko] undefined! ERROR: "adf_attachment_free" [drivers/video/adf/adf_client.ko] undefined! ERROR: "adf_obj_find_event_refcount" [drivers/video/adf/adf_client.ko] undefined! ERROR: "adf_file_queue_event" [drivers/video/adf/adf.ko] undefined! ERROR: "adf_interface_sysfs_init" [drivers/video/adf/adf.ko] undefined! ERROR: "adf_interface_sysfs_destroy" [drivers/video/adf/adf.ko] undefined! ERROR: "adf_device_sysfs_init" [drivers/video/adf/adf.ko] undefined! ERROR: "adf_device_sysfs_destroy" [drivers/video/adf/adf.ko] undefined! ERROR: "adf_sysfs_destroy" [drivers/video/adf/adf.ko] undefined! ERROR: "adf_overlay_engine_sysfs_init" [drivers/video/adf/adf.ko] undefined! ERROR: "adf_overlay_engine_sysfs_destroy" [drivers/video/adf/adf.ko] undefined! ERROR: "adf_sysfs_init" [drivers/video/adf/adf.ko] undefined! If ADF is configured as module, each of the object files ends up being a separate module. Since the functions are used across the various files but not exported, this results in the observed build errors. Modify the Makefile to create a single module instead. Fixes: 066a50cee536 ("video: add atomic display framework") Signed-off-by: Guenter Roeck <groeck@chromium.org> (cherry picked from commit bb485f9d7aac6f4f2a75e0c3bd48d3b55966afb6) Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
* 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>