aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-04-27perf bench numa: Fix immediate meeting of convergence conditionPetr Holasek1-0/+8
This patch fixes the race in the beginning of benchmark run when some threads hasn't got assigned curr_cpu yet so they don't occur in nodes-of-process stats and benchmark concludes that all remaining threads are converged already. The race can be reproduced with small amount of threads and some bigger amount of shared process memory, e.g. one process, two threads and 5GB of process memory. Signed-off-by: Petr Holasek <[email protected]> Reviewed-by: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2015-04-27perf bench numa: Fixes of --quiet argumentPetr Holasek1-2/+2
Corrected description and fixed function of --quiet argument. Signed-off-by: Petr Holasek <[email protected]> Reviewed-by: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2015-04-27perf bench futex: Fix hung wakeup tasks after requeueingDavidlohr Bueso1-7/+8
The futex-requeue benchmark can hang because of missing wakeups once the benchmark is done, ie: [Run 1]: Requeued 1024 of 1024 threads in 0.3290 ms perf: couldn't wakeup all tasks (135/1024) This bug, while perhaps suggesting missing wakeups in kernel futex code, is merely a consequence of the crappy FUTEX_CMP_REQUEUE man page, incorrectly mentioning that the number of requeued tasks is in fact returned, not the wakeups. This patch acknowledges this and updates the corresponding futex_wake code around it. Signed-off-by: Davidlohr Bueso <[email protected]> Cc: Mel Gorman <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2015-04-27perf probe: Fix bug with global variables handlingHe Kuang1-1/+3
There are missing curly braces which causes find_variable() return wrong value when probing with global variables. This problem can be reproduced as following: $ perf probe -v --add='generic_perform_write global_variable_for_test' ... Try to find probe point from debuginfo. Probe point found: generic_perform_write+0 Searching 'global_variable_for_test' variable in context. An error occurred in debuginfo analysis (-2). Error: Failed to add events. Reason: No such file or directory (Code: -2) After this patch: $ perf probe -v --add='generic_perform_write global_variable_for_test' ... Converting variable global_variable_for_test into trace event. global_variable_for_test type is int. Found 1 probe_trace_events. Opening /sys/kernel/debug/tracing/kprobe_events write=1 Added new event: Writing event: p:probe/generic_perform_write _stext+1237464 global_variable_for_test=@global_variable_for_test+0:s32 probe:generic_perform_write (on generic_perform_write with global_variable_for_test) You can now use it in all perf tools, such as: perf record -e probe:generic_perform_write -aR sleep 1 Signed-off-by: He Kuang <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Wang Nan <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2015-04-27SCSI: add 1024 max sectors black list flagMike Christie3-0/+8
This works around a issue with qnap iscsi targets not handling large IOs very well. The target returns: VPD INQUIRY: Block limits page (SBC) Maximum compare and write length: 1 blocks Optimal transfer length granularity: 1 blocks Maximum transfer length: 4294967295 blocks Optimal transfer length: 4294967295 blocks Maximum prefetch, xdread, xdwrite transfer length: 0 blocks Maximum unmap LBA count: 8388607 Maximum unmap block descriptor count: 1 Optimal unmap granularity: 16383 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0xffffffff blocks Maximum atomic transfer length: 0 Atomic alignment: 0 Atomic transfer length granularity: 0 and it is *sometimes* able to handle at least one IO of size up to 8 MB. We have seen in traces where it will sometimes work, but other times it looks like it fails and it looks like it returns failures if we send multiple large IOs sometimes. Also it looks like it can return 2 different errors. It will sometimes send iscsi reject errors indicating out of resources or it will send invalid cdb illegal requests check conditions. And then when it sends iscsi rejects it does not seem to handle retries when there are command sequence holes, so I could not just add code to try and gracefully handle that error code. The problem is that we do not have a good contact for the company, so we are not able to determine under what conditions it returns which error and why it sometimes works. So, this patch just adds a new black list flag to set targets like this to the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19 caused this regression, so I also ccing stable. Reported-by: Christian Hesse <[email protected]> Signed-off-by: Mike Christie <[email protected]> Cc: [email protected] Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: James Bottomley <[email protected]>
2015-04-27block: destroy bdi before blockdev is unregistered.NeilBrown4-5/+5
Because of the peculiar way that md devices are created (automatically when the device node is opened), a new device can be created and registered immediately after the blk_unregister_region(disk_devt(disk), disk->minors); call in del_gendisk(). Therefore it is important that all visible artifacts of the previous device are removed before this call. In particular, the 'bdi'. Since: commit c4db59d31e39ea067c32163ac961e9c80198fd37 Author: Christoph Hellwig <[email protected]> fs: don't reassign dirty inodes to default_backing_dev_info moved the device_unregister(bdi->dev); call from bdi_unregister() to bdi_destroy() it has been quite easy to lose a race and have a new (e.g.) "md127" be created after the blk_unregister_region() call and before bdi_destroy() is ultimately called by the final 'put_disk', which must come after del_gendisk(). The new device finds that the bdi name is already registered in sysfs and complains > [ 9627.630029] WARNING: CPU: 18 PID: 3330 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5a/0x70() > [ 9627.630032] sysfs: cannot create duplicate filename '/devices/virtual/bdi/9:127' We can fix this by moving the bdi_destroy() call out of blk_release_queue() (which can happen very late when a refcount reaches zero) and into blk_cleanup_queue() - which happens exactly when the md device driver calls it. Then it is only necessary for md to call blk_cleanup_queue() before del_gendisk(). As loop.c devices are also created on demand by opening the device node, we make the same change there. Fixes: c4db59d31e39ea067c32163ac961e9c80198fd37 Reported-by: Azat Khuzhin <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: [email protected] (v4.0) Signed-off-by: NeilBrown <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-04-27perf top: Fix a segfault when kernel map is restricted.Wang Nan1-1/+1
Perf top raise a warning if a kernel sample is collected but kernel map is restricted. The warning message needs to dereference al.map->dso... However, previous perf_event__preprocess_sample() doesn't always guarantee al.map != NULL, for example, when kernel map is restricted. This patch validates al.map before dereferencing, avoid the segfault. Before this patch: $ cat /proc/sys/kernel/kptr_restrict 1 $ perf top -p 120183 perf: Segmentation fault -------- backtrace -------- /path/to/perf[0x509868] /lib64/libc.so.6(+0x3545f)[0x7f9a1540045f] /path/to/perf[0x448820] /path/to/perf(cmd_top+0xe3c)[0x44a5dc] /path/to/perf[0x4766a2] /path/to/perf(main+0x5f5)[0x42e545] /lib64/libc.so.6(__libc_start_main+0xf4)[0x7f9a153ecbd4] /path/to/perf[0x42e674] And gdb call trace: Program received signal SIGSEGV, Segmentation fault. perf_event__process_sample (machine=0xa44030, sample=0x7fffffffa4c0, evsel=0xa43b00, event=0x7ffff41c3000, tool=0x7fffffffa8a0) at builtin-top.c:736 736 !RB_EMPTY_ROOT(&al.map->dso->symbols[MAP__FUNCTION]) ? (gdb) bt #0 perf_event__process_sample (machine=0xa44030, sample=0x7fffffffa4c0, evsel=0xa43b00, event=0x7ffff41c3000, tool=0x7fffffffa8a0) at builtin-top.c:736 #1 perf_top__mmap_read_idx (top=top@entry=0x7fffffffa8a0, idx=idx@entry=0) at builtin-top.c:855 #2 0x000000000044a5dd in perf_top__mmap_read (top=0x7fffffffa8a0) at builtin-top.c:872 #3 __cmd_top (top=0x7fffffffa8a0) at builtin-top.c:997 #4 cmd_top (argc=<optimized out>, argv=<optimized out>, prefix=<optimized out>) at builtin-top.c:1267 #5 0x00000000004766a3 in run_builtin (p=p@entry=0x8a6ce8 <commands+264>, argc=argc@entry=3, argv=argv@entry=0x7fffffffdf70) at perf.c:371 #6 0x000000000042e546 in handle_internal_command (argv=0x7fffffffdf70, argc=3) at perf.c:430 #7 run_argv (argv=0x7fffffffdcf0, argcp=0x7fffffffdcfc) at perf.c:474 #8 main (argc=3, argv=0x7fffffffdf70) at perf.c:589 (gdb) Signed-off-by: Wang Nan <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: David Ahern <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Zefan Li <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2015-04-27drm/radeon: fix userptr return value checking (v2)Christian König1-5/+5
Otherwise we print false warning from time to time. v2: agd5f: rebase Signed-off-by: Christian König <[email protected]> Signed-off-by: Jack Xiao <[email protected]> CC: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2015-04-27drm/radeon: check new address before removing old oneChristian König1-14/+17
Otherwise the change isn't atomic. Signed-off-by: Christian König <[email protected]> CC: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2015-04-27drm/radeon: reset BOs address after clearing it.Christian König1-0/+2
Otherwise it is possible that we will have page table corruption if we change a BOs address multiple times. Signed-off-by: Christian König <[email protected]> CC: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2015-04-27drm/radeon: fix lockup when BOs aren't part of the VM on releaseChristian König1-1/+2
If we unmap BOs before releasing them them the intervall tree locks up because we try to remove an entry not inside the tree. Based on a patch from Michel Dänzer. Signed-off-by: Christian König <[email protected]> CC: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2015-04-27block:bounce: fix call inc_|dec_zone_page_state on different pages confuse ↵Wang YanQing1-1/+1
value of NR_BOUNCE Commit d2c5e30c9a1420902262aa923794d2ae4e0bc391 ("[PATCH] zoned vm counters: conversion of nr_bounce to per zone counter") convert statistic of nr_bounce to per zone and one global value in vm_stat, but it call inc_|dec_zone_page_state on different pages, then different zones, and cause us to get unexpected value of NR_BOUNCE. Below is the result on my machine: Mar 2 09:26:08 udknight kernel: [144766.778265] Mem-Info: Mar 2 09:26:08 udknight kernel: [144766.778266] DMA per-cpu: Mar 2 09:26:08 udknight kernel: [144766.778268] CPU 0: hi: 0, btch: 1 usd: 0 Mar 2 09:26:08 udknight kernel: [144766.778269] CPU 1: hi: 0, btch: 1 usd: 0 Mar 2 09:26:08 udknight kernel: [144766.778270] Normal per-cpu: Mar 2 09:26:08 udknight kernel: [144766.778271] CPU 0: hi: 186, btch: 31 usd: 0 Mar 2 09:26:08 udknight kernel: [144766.778273] CPU 1: hi: 186, btch: 31 usd: 0 Mar 2 09:26:08 udknight kernel: [144766.778274] HighMem per-cpu: Mar 2 09:26:08 udknight kernel: [144766.778275] CPU 0: hi: 186, btch: 31 usd: 0 Mar 2 09:26:08 udknight kernel: [144766.778276] CPU 1: hi: 186, btch: 31 usd: 0 Mar 2 09:26:08 udknight kernel: [144766.778279] active_anon:46926 inactive_anon:287406 isolated_anon:0 Mar 2 09:26:08 udknight kernel: [144766.778279] active_file:105085 inactive_file:139432 isolated_file:0 Mar 2 09:26:08 udknight kernel: [144766.778279] unevictable:653 dirty:0 writeback:0 unstable:0 Mar 2 09:26:08 udknight kernel: [144766.778279] free:178957 slab_reclaimable:6419 slab_unreclaimable:9966 Mar 2 09:26:08 udknight kernel: [144766.778279] mapped:4426 shmem:305277 pagetables:784 bounce:0 Mar 2 09:26:08 udknight kernel: [144766.778279] free_cma:0 Mar 2 09:26:08 udknight kernel: [144766.778286] DMA free:3324kB min:68kB low:84kB high:100kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15976kB managed:15900kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes Mar 2 09:26:08 udknight kernel: [144766.778287] lowmem_reserve[]: 0 822 3754 3754 Mar 2 09:26:08 udknight kernel: [144766.778293] Normal free:26828kB min:3632kB low:4540kB high:5448kB active_anon:4872kB inactive_anon:68kB active_file:1796kB inactive_file:1796kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:892920kB managed:842560kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:4144kB slab_reclaimable:25676kB slab_unreclaimable:39864kB kernel_stack:1944kB pagetables:3136kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:2412612 all_unreclaimable? yes Mar 2 09:26:08 udknight kernel: [144766.778294] lowmem_reserve[]: 0 0 23451 23451 Mar 2 09:26:08 udknight kernel: [144766.778299] HighMem free:685676kB min:512kB low:3748kB high:6984kB active_anon:182832kB inactive_anon:1149556kB active_file:418544kB inactive_file:555932kB unevictable:2612kB isolated(anon):0kB isolated(file):0kB present:3001732kB managed:3001732kB mlocked:0kB dirty:0kB writeback:0kB mapped:17704kB shmem:1216964kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:75771152kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Mar 2 09:26:08 udknight kernel: [144766.778300] lowmem_reserve[]: 0 0 0 0 You can see bounce:75771152kB for HighMem, but bounce:0 for lowmem and global. This patch fix it. Signed-off-by: Wang YanQing <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-04-27ARM: dts: imx28: Fix AUART4 TX-DMA interrupt nameMarek Vasut2-2/+2
Fix a typo in the TX DMA interrupt name for AUART4. This patch makes AUART4 operational again. Signed-off-by: Marek Vasut <[email protected]> Fixes: f30fb03d4d3a ("ARM: dts: add generic DMA device tree binding for mxs-dma") Cc: [email protected] Acked-by: Stefan Wahren <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2015-04-27ARM: dts: imx25: Add #pwm-cells to pwm4Markus Pargmann1-0/+1
The property '#pwm-cells' is currently missing. It is not possible to use pwm4 without this property. Signed-off-by: Markus Pargmann <[email protected]> Fixes: 5658a68fb578 ("ARM i.MX25: Add devicetree") Cc: <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2015-04-27ALSA: hda - Fix missing va_end() call in snd_hda_codec_pcm_new()Takashi Iwai1-1/+2
Reported by coverity CID 1296024. Signed-off-by: Takashi Iwai <[email protected]>
2015-04-27ARM: dts: imx6: phyFLEX: USB VBUS control is active-highPhilipp Zabel1-0/+2
The fixed-regulator bindings require a separate property enable-active-high, the standard gpio phandle property polarity setting is ignored. Signed-off-by: Philipp Zabel <[email protected]> Fixes: 4fe69a934b1f ("ARM: dts: Add Phytec pfla02 with i.MX6 DualLite/Solo") Cc: [email protected] Signed-off-by: Shawn Guo <[email protected]>
2015-04-27drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5Alex Deucher1-0/+1
Seems to have problems with high mclks. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-04-27drm/radeon: adjust pll when audio is not enabledAlex Deucher1-0/+3
Fixes display problems with some monitors when audio is not enabled. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89505 https://bugzilla.kernel.org/show_bug.cgi?id=94171 Plus several reports on IRC. Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-04-27drm/radeon: only enable audio streams if the monitor supports itAlex Deucher2-12/+21
Selectively enable which packets we send based on monitor caps. Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-04-27drm/radeon: only mark audio as connected if the monitor supports it (v3)Alex Deucher2-14/+21
Otherwise the driver may try and send audio which may confuse the monitor. v2: set pin to NULL if no audio v3: avoid crash with analog encoders Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-04-27drm/radeon/audio: don't enable packets until the endAlex Deucher1-13/+17
Don't enable the audio and avi infoframes and audio stream until all the state is set up. Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-04-27drm/radeon: drop dce6_dp_enableAlex Deucher3-28/+2
It's mostly duplicated with evergreen_dp_enable. This is a prerequisite for fix implemented in another patch. Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-04-27drm/radeon: fix ordering of AVI packet setupAlex Deucher2-10/+11
Set the line first, then enable the stream. May fix pink line problems on some displays. Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-04-27drm/radeon: Use drm_calloc_ab for CS relocsMichel Dänzer1-2/+2
The number of relocs is passed in by userspace and can be large. It has been observed to cause kcalloc failures in the wild. Cc: [email protected] Reviewed-by: Christian König <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-04-27x86: pvclock: Really remove the sched notifier for cross-cpu migrationsPaolo Bonzini5-87/+15
This reverts commits 0a4e6be9ca17c54817cf814b4b5aa60478c6df27 and 80f7fdb1c7f0f9266421f823964fd1962681f6ce. The task migration notifier was originally introduced in order to support the pvclock vsyscall with non-synchronized TSC, but KVM only supports it with synchronized TSC. Hence, on KVM the race condition is only needed due to a bad implementation on the host side, and even then it's so rare that it's mostly theoretical. As far as KVM is concerned it's possible to fix the host, avoiding the additional complexity in the vDSO and the (re)introduction of the task migration notifier. Xen, on the other hand, hasn't yet implemented vsyscall support at all, so we do not care about its plans for non-synchronized TSC. Reported-by: Peter Zijlstra <[email protected]> Suggested-by: Marcelo Tosatti <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-04-27kvm: x86: fix kvmclock update protocolRadim Krčmář1-5/+28
The kvmclock spec says that the host will increment a version field to an odd number, then update stuff, then increment it to an even number. The host is buggy and doesn't do this, and the result is observable when one vcpu reads another vcpu's kvmclock data. There's no good way for a guest kernel to keep its vdso from reading a different vcpu's kvmclock data, but we don't need to care about changing VCPUs as long as we read a consistent data from kvmclock. (VCPU can change outside of this loop too, so it doesn't matter if we return a value not fit for this VCPU.) Based on a patch by Radim Krčmář. Reviewed-by: Radim Krčmář <[email protected]> Acked-by: Marcelo Tosatti <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-04-27pinctrl: qcom-spmi: Fix pin direction configurationIvan T. Ivanov2-0/+2
Pin direction configuration was incorrectly overwritten by output and function values in set_mux(). Fix this. Signed-off-by: Ivan T. Ivanov <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-04-27pinctrl: mvebu: Fix mapping of pin 63 (gpo -> gpio)Andrew Andrianov1-1/+1
Signed-off-by: Andrew Andrianov <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-04-27gpiolib: change gpio pin from unsigned to signed in acpi callbackQipeng Zha1-1/+1
The signed error will be wrongly used as valid gpio offset Reported-by: David Binderman <[email protected]> Signed-off-by: Alan Cox <[email protected]> Signed-off-by: Qipeng Zha <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-04-27ALSA: emux: Fix mutex deadlock at unloadingTakashi Iwai1-2/+0
The emux-synth driver has a possible AB/BA mutex deadlock at unloading the emu10k1 driver: snd_emux_free() -> snd_emux_detach_seq(): mutex_lock(&emu->register_mutex) -> snd_seq_delete_kernel_client() -> snd_seq_free_client(): mutex_lock(&register_mutex) snd_seq_release() -> snd_seq_free_client(): mutex_lock(&register_mutex) -> snd_seq_delete_all_ports() -> snd_emux_unuse(): mutex_lock(&emu->register_mutex) Basically snd_emux_detach_seq() doesn't need a protection of emu->register_mutex as it's already being unregistered. So, we can get rid of this for avoiding the deadlock. Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-04-27ARM: mach-imx: devices: platform-sdhci-esdhc-imx: fix broken email addressWolfram Sang1-1/+1
My Pengutronix address is not valid anymore, redirect people to the Pengutronix kernel team. Reported-by: Harald Geyer <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Acked-by: Robert Schwebel <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2015-04-27ARM: dts: imx23-olinuxino: Fix dr_mode of usb0Stefan Wahren1-0/+1
The dr_mode of usb0 on imx233-olinuxino is left to default "otg". Since the green LED (GPIO2_1) on imx233-olinuxino is connected to the same pin as USB_OTG_ID it's possible to disable USB host by LED toggling: echo 0 > /sys/class/leds/green/brightness [ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1 [ 1068.890000] usb usb1: USB disconnect, device number 1 [ 1068.920000] usb 1-1: USB disconnect, device number 2 [ 1068.920000] usb 1-1.1: USB disconnect, device number 3 [ 1069.070000] usb 1-1.2: USB disconnect, device number 4 [ 1069.450000] ci_hdrc ci_hdrc.0: USB bus 1 deregistered [ 1074.460000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11 This patch fixes the issue by setting dr_mode to "host" in the dts file. Reported-by: Harald Geyer <[email protected]> Signed-off-by: Stefan Wahren <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Reviewed-by: Marek Vasut <[email protected]> Acked-by: Peter Chen <[email protected]> Fixes: b49312948285 ("ARM: dts: imx23-olinuxino: Add USB host support") Cc: [email protected] Signed-off-by: Shawn Guo <[email protected]>
2015-04-27ARM: dts: imx23-olinuxino: Fix polarity of LED GPIOFabio Estevam1-1/+2
On imx23-olinuxino the LED turns on when level logic high is aplied to GPIO2_1. Fix the gpios property accordingly. Fixes: b34aa1850244 ("ARM: dts: imx23-olinuxino: Remove unneeded "default-on"") Reported-by: Stefan Wahren <[email protected]> Signed-off-by: Fabio Estevam <[email protected]> Tested-by: Stefan Wahren <[email protected]> Cc: [email protected] Signed-off-by: Shawn Guo <[email protected]>
2015-04-27ALSA: emu10k1: Fix card shortname string buffer overflowTakashi Iwai2-4/+6
Some models provide too long string for the shortname that has 32bytes including the terminator, and it results in a non-terminated string exposed to the user-space. This isn't too critical, though, as the string is stopped at the succeeding longname string. This patch fixes such entries by dropping "SB" prefix (it's enough to fit within 32 bytes, so far). Meanwhile, it also changes strcpy() with strlcpy() to make sure that this kind of problem won't happen in future, too. Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-04-27xen/grant: introduce func gnttab_unmap_refs_sync()Bob Liu4-53/+35
There are several place using gnttab async unmap and wait for completion, so move the common code to a function gnttab_unmap_refs_sync(). Signed-off-by: Bob Liu <[email protected]> Acked-by: Roger Pau Monné <[email protected]> Acked-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-04-27xen/blkback: safely unmap purge persistent grantsBob Liu1-6/+18
Commit c43cf3ea8385 ("xen-blkback: safely unmap grants in case they are still in use") use gnttab_unmap_refs_async() to wait until the mapped pages are no longer in use before unmapping them, but that commit missed the persistent case. Purge persistent pages can't be unmapped either unless no longer in use. Signed-off-by: Bob Liu <[email protected]> Acked-by: Roger Pau Monné <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-04-27arm64: dma-mapping: always clear allocated buffersMarek Szyprowski1-4/+2
Buffers allocated by dma_alloc_coherent() are always zeroed on Alpha, ARM (32bit), MIPS, PowerPC, x86/x86_64 and probably other architectures. It turned out that some drivers rely on this 'feature'. Allocated buffer might be also exposed to userspace with dma_mmap() call, so clearing it is desired from security point of view to avoid exposing random memory to userspace. This patch unifies dma_alloc_coherent() behavior on ARM64 architecture with other implementations by unconditionally zeroing allocated buffer. Cc: <[email protected]> # v3.14+ Signed-off-by: Marek Szyprowski <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2015-04-27ARM64: Enable CONFIG_GENERIC_IRQ_SHOW_LEVELSudeep Holla1-0/+1
Since several interrupt controllers including GIC support both edge and level triggered interrupts, it's useful to provide that information in /proc/interrupts even on ARM64 similar to ARM and PPC. This is based on Geert Uytterhoeven's commit 7c07005eea96 ("ARM: 8339/1: Enable CONFIG_GENERIC_IRQ_SHOW_LEVEL") Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2015-04-27arm64: add missing data types in smp_load_acquire/smp_store_releaseAndre Przywara1-0/+16
Commit 8053871d0f7f ("smp: Fix smp_call_function_single_async() locking") introduced a call to smp_load_acquire() with a u16 argument, but we only cared about u32 and u64 types in that function so far. This resulted in a compiler warning fortunately, pointing at an uninitialized use. Due to the implementation structure the compiler misses that bug in the smp_store_release(), though. Add the u16 and u8 variants using ldarh/stlrh and ldarb/stlrb, respectively. Together with the compiletime_assert_atomic_type() check this should cover all cases now. Acked-by: Will Deacon <[email protected]> Signed-off-by: Andre Przywara <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2015-04-27ALSA: hda - Add mute-LED mode control to ThinkpadTakashi Iwai1-0/+1
This patch adds the missing flag to enable "Mute-LED Mode" mixer enum ctl for Thinkpads that have also the software mute-LED control. Reported-and-tested-by: Pali Rohár <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-04-27ALSA: hda - Fix mute-LED fixed modeTakashi Iwai1-9/+12
The mute-LED mode control has the fixed on/off states that are supposed to remain on/off regardless of the master switch. However, this doesn't work actually because the vmaster hook is called in the vmaster code itself. This patch fixes it by calling the hook indirectly after checking the mute LED mode. Reported-and-tested-by: Pali Rohár <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-04-27ALSA: hda - Fix click noise at start on Dell XPS13Takashi Iwai2-5/+14
Dell XPS13 produces a click noise at boot up, and Gabriele spotted out that it's triggered by the initial pin control of the mic (NID 0x19). This has to be set to Hi-Z Vref while the driver initializes to Vref 80% as a normal mic. This patch fixes the generic parser code not to override the target vref if it has been already set by the driver, and adds a proper initialization of the target vref for this pin in the Realtek driver side. Reported-and-tested-by: Gabriele Mazzotta <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-04-27ARM: mvebu: armada-xp-openblocks-ax3-4: Disable internal RTCGregory CLEMENT1-0/+4
There is no crystal connected to the internal RTC on the Open Block AX3. So let's disable it in order to prevent the kernel probing the driver uselessly. Eventually this patches removes the following warning message from the boot log: "rtc-mv d0010300.rtc: internal RTC not ticking" Acked-by: Andrew Lunn <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Cc: <[email protected]> # v3.8 +
2015-04-27ARM: ux500: Enable GPIO regulator for SD-card for snowballUlf Hansson1-2/+0
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-04-27ARM: ux500: Enable GPIO regulator for SD-card for HREF boardsUlf Hansson1-2/+0
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-04-27ARM: ux500: Move GPIO regulator for SD-card into board DTSsUlf Hansson3-17/+32
The GPIO regulator for the SD-card isn't a ux500 SOC configuration, but instead it's specific to the board. Move the definition of it, into the board DTSs. Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-04-27drivers: sh: Remove test for now unsupported sh7372Geert Uytterhoeven1-2/+1
Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Simon Horman <[email protected]>
2015-04-27drivers: sh: Disable PM runtime for multi-platform r8a73a4 with genpdGeert Uytterhoeven1-1/+1
If the default PM domain using PM_CLK is used for PM runtime, the real PM domain(s) cannot be registered from DT later. Hence do not enable it when running a multi-platform kernel with genpd support on an r8a73a4. The R-Mobile PM domain driver will take care of PM runtime management of the module clocks. The default PM domain is still needed for: - platforms without genpd support, - the legacy (non-DT) case, where genpd may take over later, except for the C5 "always on" PM domain. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Simon Horman <[email protected]>
2015-04-27drivers: sh: Disable PM runtime for multi-platform sh73a0 with genpdGeert Uytterhoeven1-2/+2
If the default PM domain using PM_CLK is used for PM runtime, the real PM domain(s) cannot be registered from DT later. Hence do not enable it when running a multi-platform kernel with genpd support on an sh73a0. The R-Mobile PM domain driver will take care of PM runtime management of the module clocks. The default PM domain is still needed for: - platforms without genpd support, - the legacy (non-DT) case, where genpd may take over later, except for the C5 "always on" PM domain. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Simon Horman <[email protected]>
2015-04-26Merge branch 'ppp_mppe_desync'David S. Miller1-16/+20
Sylvain Rochet says: ==================== ppp: mppe: fixes MPPE desync on links which don't guarantee packet ordering I am currently having an issue with PPP over L2TP (UDP) and MPPE in stateless mode (default mode), UDP does not guarantee packet ordering so we might get out of order packet. MPPE needs to be continuously synched so we should drop late UDP packet. I added a printk on the number of time we rekeyed in MPPE decompressor, this is what we currently have if we receive a slightly out of order UDP packet: [1731001.049206] mppe_decompress[1]: ccount 1559 [1731001.049216] mppe_decompress[1]: rekeyed 1 times [1731001.049228] mppe_decompress[1]: ccount 1560 [1731001.049232] mppe_decompress[1]: rekeyed 1 times [1731001.050170] mppe_decompress[1]: ccount 1562 [1731001.050182] mppe_decompress[1]: rekeyed 2 times [1731001.050191] mppe_decompress[1]: ccount 1561 [1731001.062576] mppe_decompress[1]: rekeyed 4095 times ^^^^ This is obviously wrong, we missed packet 1561 and we already rekeyed 2 times for 1562 we previously received, we can't recover the decryption key we need for 1561, we should drop it instead of rekeying 4095 times. This patch series drop any packet with are not within the 4096/2 forward window. ==================== Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.