BMC/Intel-BMC/linux.git/drivers, branch dev-4.3

mtd: spi-nor: aspeed-smc: Use io string accessors to fifo

2016-02-22T05:27:33+00:00

Make and use new routines to access the fifo when in user mode. Instead of using memcpy_fromio, base the new routines on the io port string accessors. When the smc controllers are configured to transfer in user mode, the exact address within the chip select region is ignored and all valid data bytes are sent to the device fifo. It has been determined the reason _memcpy_fromio, an arm specific byte-by-byte variant of memcpy_fromio was required in read_reg, is that the later will stutter when coping from memory, discarding some bytes read, when switching from words to bytes for the final unaligned length. This change includes a hack to make inw/outw work. The default generic IO_SPACE_LIMIT is 0, and twenty bits when PCI is selected. While there is a PCMCIA SOC config to select the full 4GB space it would bring in the PCMCIA core for no use to the ast2400. We want to be part of the generic multi-platform arm kernel and therefore mach/io.h is not going to work. However, the limit is under an ifndef, so define it in this file an check it was not redefine at probe time. To avoid redefinition errors or warnings, guard the setting with CONFIG_ARM for cross-arch compile testing and with a Kconfig dependency for arm cross-compile tests. While some other architecture may not accept unsigned long addresses as ioport cookies, that can be addressed when, if ever, the hardware appears on another arch. While the change to use the designed-for-memory optimised copy template, even reusing the bytes of memcpy, was a recent change and only for little endian arm, designing and proposing a patch will take some time and there could be debate if the routine needs to work on changing memory. Signed-off-by: Milton Miller Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

i2c: aspeed: Don't rename added devices

2016-02-22T05:21:47+00:00

Changing the name of a device with dev_set_name after device_add is not allowed. However, of_create_device takes a bus_id parameter that specifies the name of the platform device being added. This does mean the bus property has to be retrieved multiple times. Creation is skiped if there is trouble retrieving or formatting the name. The documentation for kobject_set_name (non-vargs) says: * This sets the name of the kobject. If you have already added the * kobject to the system, you must call kobject_rename() in order to * change the name of the kobject. As the kernel doc for device_rename says: * Make up a "real" name in the driver before you register anything, or add * some other attributes for userspace to find the device, or use udev to add * symlinks -- but never rename kernel devices later, it's a complete mess. We * don't even want to get into that and try to implement the missing pieces in * the core. We really have other pieces to fix in the driver core mess. :) before: 1e78a000.i2c/1e78a1c0.i2c-bus/i2c-6/i2c-dev/i2c-6 1e78a000.i2c/1e78a180.i2c-bus/i2c-5/i2c-dev/i2c-5 1e78a000.i2c/1e78a140.i2c-bus/i2c-4/i2c-dev/i2c-4 1e78a000.i2c/1e78a100.i2c-bus/i2c-3/i2c-dev/i2c-3 1e78a000.i2c/1e78a100.i2c-bus/i2c-3/3-0050 1e78a000.i2c/1e78a0c0.i2c-bus/i2c-2/i2c-dev/i2c-2 1e78a000.i2c/1e78a0c0.i2c-bus/i2c-2/2-004c/hwmon/hwmon0 1e78a000.i2c/1e78a080.i2c-bus/i2c-1/i2c-dev/i2c-1 1e78a000.i2c/1e78a040.i2c-bus/i2c-0/i2c-dev/i2c-0 1e78a000.i2c/1e78a040.i2c-bus/i2c-0/0-0050 1e78a000.i2c/1e78a040.i2c-bus/i2c-0/0-0068/rtc/rtc0 1e78a000.i2c/1e78a340.i2c-bus/i2c-8/i2c-dev/i2c-8 after: 1e78a000.i2c/i2c-0/i2c-0/i2c-dev/i2c-0 1e78a000.i2c/i2c-0/i2c-0/0-0050 1e78a000.i2c/i2c-0/i2c-0/0-0068/rtc/rtc0 1e78a000.i2c/i2c-1/i2c-1/i2c-dev/i2c-1 1e78a000.i2c/i2c-2/i2c-2/i2c-dev/i2c-2 1e78a000.i2c/i2c-2/i2c-2/2-004c/hwmon/hwmon0 1e78a000.i2c/i2c-3/i2c-3/i2c-dev/i2c-3 1e78a000.i2c/i2c-3/i2c-3/3-0050 1e78a000.i2c/i2c-4/i2c-4/i2c-dev/i2c-4 1e78a000.i2c/i2c-5/i2c-5/i2c-dev/i2c-5 1e78a000.i2c/i2c-6/i2c-6/i2c-dev/i2c-6 1e78a000.i2c/i2c-7/i2c-7/i2c-dev/i2c-7 1e620000.fmc 1e78e000.serial 1e620000.fmc:flash@0 1e78f000.serial 1e630000.spi ahb 1e630000.spi:flash ahb:apb 1e660000.ethernet alarmtimer 1e6c0080.interrupt-controller i2c-0 1e6e2000.syscon i2c-1 1e720000.sram i2c-2 1e780000.gpio i2c-3 1e782000.timer i2c-4 1e783000.serial i2c-5 1e784000.serial i2c-6 1e785000.wdt i2c-7 1e787000.vuart i2c-8 1e789140.ibt leds 1e78a000.i2c serial8250 1e78d000.serial Signed-off-by: Milton Miller Signed-off-by: Joel Stanley

Remove GPIO and LPC from WDT reset list

2016-02-22T05:16:02+00:00

WDT reset mode must also be set to SOC mode. These changes are required so host is not interrupted when BMC is reboot. This change will keep the GPIO and LPC units from being reset during an SOC reset. The SOC reset is used to perform a BMC reboot. Signed-off-by: Norman James Signed-off-by: Joel Stanley

Merge tag 'v4.3.6' into dev-4.3

2016-02-22T05:13:27+00:00

This is the 4.3.6 stable release Signed-off-by: Joel Stanley

HID: multitouch: fix input mode switching on some Elan panels

2016-02-19T22:28:38+00:00

commit 73e7d63efb4d774883a338997943bfa59e127085 upstream. as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481 This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") as the origin of the problem but this commit actually masked 2 firmware bugs that are annihilating each other: The report descriptor declares two features in reports 3 and 5: 0x05, 0x0d, // Usage Page (Digitizers) 318 0x09, 0x0e, // Usage (Device Configuration) 320 0xa1, 0x01, // Collection (Application) 322 0x85, 0x03, // Report ID (3) 324 0x09, 0x22, // Usage (Finger) 326 0xa1, 0x00, // Collection (Physical) 328 0x09, 0x52, // Usage (Inputmode) 330 0x15, 0x00, // Logical Minimum (0) 332 0x25, 0x0a, // Logical Maximum (10) 334 0x75, 0x08, // Report Size (8) 336 0x95, 0x02, // Report Count (2) 338 0xb1, 0x02, // Feature (Data,Var,Abs) 340 0xc0, // End Collection 342 0x09, 0x22, // Usage (Finger) 343 0xa1, 0x00, // Collection (Physical) 345 0x85, 0x05, // Report ID (5) 347 0x09, 0x57, // Usage (Surface Switch) 349 0x09, 0x58, // Usage (Button Switch) 351 0x15, 0x00, // Logical Minimum (0) 353 0x75, 0x01, // Report Size (1) 355 0x95, 0x02, // Report Count (2) 357 0x25, 0x03, // Logical Maximum (3) 359 0xb1, 0x02, // Feature (Data,Var,Abs) 361 0x95, 0x0e, // Report Count (14) 363 0xb1, 0x03, // Feature (Cnst,Var,Abs) 365 0xc0, // End Collection 367 The report ID 3 presents 2 input mode features, while only the first one is handled by the device. Given that we did not checked if one was previously assigned, we were dealing with the ignored featured and we should never have been able to switch this panel into the multitouch mode. However, the firmware presents an other bugs which allowed 6d4f5440 to counteract the faulty report descriptor. When we request the values of the feature 5, the firmware answers "03 03 00". The fields are correct but the report id is wrong. Before 6d4f5440, we retrieved all the features and injected them in the system. So when we called report 5, we injected in the system the report 3 with the values "03 00". Setting the second input mode to 03 in this report changed it to "03 03" and the touchpad switched to the mt mode. We could have set anything in the second field because the actual value (the first 03 in this report) was given by the query of report ID 5. To sum up: 2 bugs in the firmware were hiding that we were accessing the wrong feature. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

zram: don't call idr_remove() from zram_remove()

2016-02-19T22:28:38+00:00

commit 17ec4cd985780a7e30aa45bb8f272237c12502a4 upstream. The use of idr_remove() is forbidden in the callback functions of idr_for_each(). It is therefore unsafe to call idr_remove in zram_remove(). This patch moves the call to idr_remove() from zram_remove() to hot_remove_store(). In the detroy_devices() path, idrs are removed by idr_destroy(). This solves an use-after-free detected by KASan. [akpm@linux-foundation.org: fix coding stype, per Sergey] Signed-off-by: Jerome Marchand Acked-by: Sergey Senozhatsky Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

zram: try vmalloc() after kmalloc()

2016-02-19T22:28:38+00:00

commit d913897abace843bba20249f3190167f7895e9c3 upstream. 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 Signed-off-by: Minchan Kim Acked-by: Sergey Senozhatsky Sergey Senozhatsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

zram/zcomp: use GFP_NOIO to allocate streams

2016-02-19T22:28:38+00:00

commit 3d5fe03a3ea013060ebba2a811aeb0f23f56aefa upstream. 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); lock(jbd2_handle); *** DEADLOCK *** 5 locks held by git/20158: #0: (sb_writers#7){.+.+.+}, at: [] mnt_want_write+0x24/0x4b #1: (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [] lock_rename+0xd9/0xe3 #2: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [] lock_two_nondirectories+0x3f/0x6b #3: (&sb->s_type->i_mutex_key#11/4){+.+.+.}, at: [] lock_two_nondirectories+0x66/0x6b #4: (jbd2_handle){+.+.?.}, at: [] 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 Acked-by: Minchan Kim Cc: Kyeongdon Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

drm/nouveau/pmu: do not assume a PMU is present

2016-02-19T22:28:38+00:00

commit 579b7c58215329803ce184704463de09f0f310ac upstream. Some devices may not have a PMU. Avoid a NULL pointer dereference in such cases by checking whether the pointer given to nvkm_pmu_pgob() is valid. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman

HID: multitouch: Fetch feature reports on demand for Win8 devices

2016-02-19T22:28:38+00:00

commit 6d4f5440a3a2bb2e9d0d582bbf98234e9e9bb095 upstream. Some newer Intel Skylake based Dell laptops with Win8 precision touchpad fail when initial feature reports are fetched from it. Below is an example output with some additional debug included: i2c_hid i2c-DLL0704:01: Fetching the HID descriptor i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00 i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ... ... i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00 i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05 i2c_hid i2c-DLL0704:01: report id 13 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00 i2c_hid i2c-DLL0704:01: failed to retrieve report from device. i2c_hid i2c-DLL0704:01: report id 7 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00 i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ... i2c_hid i2c-DLL0704:01: report id 4 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00 We manage to fetch few reports but then the touchpad dies: i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0704:01: failed to retrieve report from device. it eventually pulls the whole I2C bus low: i2c_designware i2c_designware.1: controller timed out i2c_hid i2c-DLL0704:01: failed to set a report to device. Fix this by preventing initial feature report retrieval for Win8 devices. Instead we fetch reports as needed in mt_feature_mapping(). This prevents fetching reports which might cause problems with the device in question. Suggested-by: Benjamin Tissoires Signed-off-by: Mika Westerberg Reviewed-by: Benjamin Tissoires Tested-by: Seth Forshee Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman