aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-08-18ARM: 8418/1: add boot image dependencies to not generate invalid imagesMasahiro Yamada1-0/+3
U-Boot is often used to boot the kernel on ARM boards, but uImage is not built by "make all", so we are often inclined to do "make all uImage" to generate DTBs, modules and uImage in a single command, but we should notice a pitfall behind it. In fact, "make all uImage" could generate an invalid uImage if it is run with the parallel option (-j). You can reproduce this problem with the following procedure: [1] First, build "all" and "uImage" separately. You will get a valid uImage $ git clean -f -x -d $ export CROSS_COMPILE=<your-tools-prefix> $ make -s -j8 ARCH=arm multi_v7_defconfig $ make -s -j8 ARCH=arm all $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h Kernel: arch/arm/boot/Image is ready Kernel: arch/arm/boot/zImage is ready UIMAGE arch/arm/boot/uImage Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d Created: Sat Aug 8 23:21:35 2015 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6138648 Bytes = 5994.77 kB = 5.85 MB Load Address: 80208000 Entry Point: 80208000 Image arch/arm/boot/uImage is ready $ ls -l arch/arm/boot/*Image -rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:20 arch/arm/boot/Image -rw-rw-r-- 1 masahiro masahiro 6138712 Aug 8 23:21 arch/arm/boot/uImage -rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:20 arch/arm/boot/zImage [2] Update some source file(s) $ touch init/main.c [3] Then, re-build "all" and "uImage" simultaneously. You will get an invalid uImage at random. $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CC init/main.o CHK include/generated/compile.h LD init/built-in.o LINK vmlinux LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o KSYM .tmp_kallsyms1.o KSYM .tmp_kallsyms2.o LD vmlinux SORTEX vmlinux SYSMAP System.map OBJCOPY arch/arm/boot/Image Building modules, stage 2. Kernel: arch/arm/boot/Image is ready GZIP arch/arm/boot/compressed/piggy.gzip AS arch/arm/boot/compressed/piggy.gzip.o Kernel: arch/arm/boot/Image is ready LD arch/arm/boot/compressed/vmlinux GZIP arch/arm/boot/compressed/piggy.gzip OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready UIMAGE arch/arm/boot/uImage Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d Created: Sat Aug 8 23:23:14 2015 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 26472 Bytes = 25.85 kB = 0.03 MB Load Address: 80208000 Entry Point: 80208000 Image arch/arm/boot/uImage is ready MODPOST 192 modules AS arch/arm/boot/compressed/piggy.gzip.o LD arch/arm/boot/compressed/vmlinux OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready $ ls -l arch/arm/boot/*Image -rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:23 arch/arm/boot/Image -rw-rw-r-- 1 masahiro masahiro 26536 Aug 8 23:23 arch/arm/boot/uImage -rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:23 arch/arm/boot/zImage Please notice the uImage is extremely small when this issue is encountered. Besides, "Kernel: arch/arm/boot/zImage is ready" is displayed twice, before and after the uImage log. The root cause of this is the race condition between zImage and uImage. Actually, uImage depends on zImage, but the dependency between the two is only described in arch/arm/boot/Makefile. Because arch/arm/boot/Makefile is not included from the top-level Makefile, it cannot know the dependency between zImage and uImage. Consequently, when we run make with the parallel option, Kbuild updates vmlinux first, and then two different threads descends into the arch/arm/boot/Makefile almost at the same time, one for updating zImage and the other for uImage. While one thread is re-generating zImage, the other also tries to update zImage before creating uImage on top of that. zImage is overwritten by the slower thread and then uImage is created based on the half-written zImage. This is the reason why "Kernel: arch/arm/boot/zImage is ready" is displayed twice, and a broken uImage is created. The same problem could happen on bootpImage. This commit adds dependencies among Image, zImage, uImage, and bootpImage to arch/arm/Makefile, which is included from the top-level Makefile. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Russell King <[email protected]>
2015-08-18ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usageNicolas Pitre1-1/+1
The mmap semaphore should not be taken when page faults are disabled. Since pagefault_disable() no longer disables preemption, we now need to use faulthandler_disabled() in place of in_atomic(). Signed-off-by: Nicolas Pitre <[email protected]> Tested-by: Mark Salter <[email protected]> Signed-off-by: Russell King <[email protected]>
2015-08-18MIPS: Fix LLVM build issue.Ralf Baechle1-1/+1
Matthew Fortune <[email protected]> reports: The genex.S file appears to mix the case of a macro between its definition and use. A cut down example of this is below. The macro __build_clear_none has lower case 'build' but ends up being instantiated with upper case BUILD. Can this be fixed on master. It has been picked up by the LLVM integrated assembler which is currently case sensitive. We are likely to fix the assembler as well but the code is currently inconsistent in the kernel. .macro __build_clear_none .endm .macro __BUILD_HANDLER exception handler clear verbose ext .align 5 .globl handle_\exception; .align 2; .type handle_\exception, @function; .ent handle_\exception, 0; handle_\exception: .frame $29, 184, $29 .set noat .globl handle_\exception\ext; .type handle_\exception\ext, @function; handle_\exception\ext: __BUILD_clear_\clear .endm .macro BUILD_HANDLER exception handler clear verbose __BUILD_HANDLER \exception \handler \clear \verbose _int .endm BUILD_HANDLER ftlb ftlb none silent Signed-off-by: Ralf Baechle <[email protected]> Reported-by: Matthew Fortune <[email protected]>
2015-08-18drm: atmel-hlcdc: add support for sama5d4 SoCsBoris Brezillon1-0/+86
Describe capabilities of the HLCDC IP found on sama5d4 SoCs and add a new entry to the atmel_hlcdc_of_match table. Signed-off-by: Boris Brezillon <[email protected]>
2015-08-18drm: atmel-hlcdc: add support for at91sam9n12 SoCBoris Brezillon1-0/+29
Describe capabilities of the HLCDC IP found on at91sam9n12 SoC and add a new entry to the atmel_hlcdc_of_match table. Signed-off-by: Boris Brezillon <[email protected]>
2015-08-18drm: atmel-hlcdc: add support for at91sam9x5 SoCsBoris Brezillon1-0/+88
Describe capabilities of the HLCDC IP found on at91sam9x5 SoCs and add a new entry to the atmel_hlcdc_of_match table. Signed-off-by: Boris Brezillon <[email protected]>
2015-08-18drm: atmel-hlcdc: add RGB565 and RGB444 output supportBoris Brezillon1-0/+4
The HLCDC IP supports RGB565 and RGB444 output formats. Signed-off-by: Boris Brezillon <[email protected]>
2015-08-18drm: atmel-hlcdc: add the missing DRM_ATOMIC flagBoris Brezillon1-1/+2
The atmel-hlcdc driver already supports atomic operations, add the missing DRM_ATOMIC flag to expose the atomic features to userspace. Signed-off-by: Boris Brezillon <[email protected]>
2015-08-18drm: atmel-hlcdc: add PRIME supportBoris Brezillon1-1/+11
Signed-off-by: Boris Brezillon <[email protected]>
2015-08-18drm/atmel-hlcdc: Compile suspend/resume for PM_SLEEP onlyThierry Reding1-1/+1
If PM is enabled but PM_SLEEP is disabled, the suspend/resume functions are still unused and produce a compiler warning. Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Cc: <[email protected]> # 4.1+
2015-08-18Revert "sched/x86_64: Don't save flags on context switch"Andy Lutomirski1-8/+4
This reverts commit: 2c7577a75837 ("sched/x86_64: Don't save flags on context switch") It was a nice speedup. It's also not quite correct: SYSENTER enables interrupts too early. We can re-add this optimization once the SYSENTER code is beaten into shape, which should happen in 4.3 or 4.4. Signed-off-by: Andy Lutomirski <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] # v3.19 Link: http://lkml.kernel.org/r/85f56651f59f76624e80785a8fd3bdfdd089a818.1439838962.git.luto@kernel.org Signed-off-by: Ingo Molnar <[email protected]>
2015-08-17ASoC: topology: Add Kconfig option for topologyMark Brown3-0/+18
Allow the topology code to be compiled out so that users who don't need topology don't need to havve the code compiled in, saving them some memory. Some more configuration could be added to remove some of the hooks into the core data structures but that is probably best done with some refactoring to use functions to do the updates of the data structures rather than ifdefing in the code as we'd need to do at the minute. Suggested-by: Takashi Iwai <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2015-08-17Merge tag 'for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma Pull rdma bugfix from Doug Ledford: "Bugfix in iw_cxgb4" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: iw_cxgb4: gracefully handle unknown CQE status errors
2015-08-17Merge branch 'for-4.2-fixes' of ↵Linus Torvalds9-204/+24
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata Pull libata fixes from Tejun Heo: "Three minor device-specific fixes and revert of NCQ autosense added during this -rc1. It turned out that NCQ autosense as currently implemented interferes with the usual error handling behavior. It will be revisited in the near future" * 'for-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: ata: ahci_brcmstb: Fix misuse of IS_ENABLED sata_sx4: Check return code from pdc20621_i2c_read() Revert "libata: Implement NCQ autosense" Revert "libata: Implement support for sense data reporting" Revert "libata-eh: Set 'information' field for autosense" ata: ahci_brcmstb: Fix warnings with CONFIG_PM_SLEEP=n
2015-08-17Merge branch 'for-4.2-fixes' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fix from Tejun Heo: "A fix for a subtle bug introduced back during 3.17 cycle which interferes with setting configurations under specific conditions" * 'for-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cpuset: use trialcs->mems_allowed as a temp variable
2015-08-17net: phy: fix semicolon.cocci warningskbuild test robot1-1/+1
drivers/net/phy/smsc.c:127:3-4: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Igor Plyatov <[email protected]> Signed-off-by: Fengguang Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-08-17net: qmi_wwan: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G ModuleDavid Ward1-0/+1
This is an HP-branded Sierra Wireless EM7355: https://bugzilla.redhat.com/show_bug.cgi?id=1223646#c2 Signed-off-by: David Ward <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-08-17be2net: avoid vxlan offloading on multichannel configsIvan Vecera1-2/+2
VxLAN offloading is not functional if the NIC is running in multichannel mode (UMC, FLEX-10, VNIC...). Enabling this additionally kills whole connectivity through the NIC and the device needs to be down and up to restore it. The firmware should take care about it and does not allow the conversion of interface to tunnel type (be_cmd_manage_iface) or should support VxLAN offloading if multichannel config is enabled. I have tested this on the latest available firmware (10.6.144.21). Result: [root@sm-04 ~]# ip link set enp5s0f0 up[root@sm-04 ~]# ip addr add 172.30.10.50/24 dev enp5s0f0 [root@sm-04 ~]# ping -c 3 172.30.10.254PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data. 64 bytes from 172.30.10.254: icmp_seq=1 ttl=64 time=0.317 ms 64 bytes from 172.30.10.254: icmp_seq=2 ttl=64 time=0.187 ms 64 bytes from 172.30.10.254: icmp_seq=3 ttl=64 time=0.188 ms --- 172.30.10.254 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.187/0.230/0.317/0.063 ms [root@sm-04 ~]# ip link add link enp5s0f0 vxlan10 type vxlan id 10 remote 172.30.10.60 dstport 4789 [root@sm-04 ~]# ip link set vxlan10 up [ 7900.442811] be2net 0000:05:00.0: Enabled VxLAN offloads for UDP port 4789 [ 7900.455722] be2net 0000:05:00.1: Enabled VxLAN offloads for UDP port 4789 [ 7900.468635] be2net 0000:05:00.2: Enabled VxLAN offloads for UDP port 4789 [ 7900.481553] be2net 0000:05:00.3: Enabled VxLAN offloads for UDP port 4789 [root@sm-04 ~]# ping -c 3 172.30.10.254 PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data. --- 172.30.10.254 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 1999ms [root@sm-04 ~]# ip link set vxlan10 down [ 7959.434093] be2net 0000:05:00.0: Disabled VxLAN offloads for UDP port 4789 [ 7959.444792] be2net 0000:05:00.1: Disabled VxLAN offloads for UDP port 4789 [ 7959.455592] be2net 0000:05:00.2: Disabled VxLAN offloads for UDP port 4789 [ 7959.466416] be2net 0000:05:00.3: Disabled VxLAN offloads for UDP port 4789 [root@sm-04 ~]# ip link del vxlan10 [root@sm-04 ~]# ping -c 3 172.30.10.254 PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data. --- 172.30.10.254 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 1999ms [root@sm-04 ~]# ip link set enp5s0f0 down [root@sm-04 ~]# ip link set enp5s0f0 up [ 8071.019003] be2net 0000:05:00.0 enp5s0f0: Link is Up [root@sm-04 ~]# ping -c 3 172.30.10.254 PING 172.30.10.254 (172.30.10.254) 56(84) bytes of data. 64 bytes from 172.30.10.254: icmp_seq=1 ttl=64 time=0.318 ms 64 bytes from 172.30.10.254: icmp_seq=2 ttl=64 time=0.196 ms 64 bytes from 172.30.10.254: icmp_seq=3 ttl=64 time=0.194 ms --- 172.30.10.254 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.194/0.236/0.318/0.057 ms Cc: Sathya Perla <[email protected]> Cc: Ajit Khaparde <[email protected]> Cc: Padmanabh Ratnakar <[email protected]> Cc: Sriharsha Basavapatna <[email protected]> Signed-off-by: Ivan Vecera <[email protected]> Acked-by: Ajit Khaparde <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-08-17Merge branch 'ipv6_percpu_rt_deadlock'David S. Miller2-24/+57
Martin KaFai Lau says: ==================== ipv6: Fix a potential deadlock when creating pcpu rt v1 -> v2: A minor change in the commit message of patch 2. This patch series fixes a potential deadlock when creating a pcpu rt. It happens when dst_alloc() decided to run gc. Something like this: read_lock(&table->tb6_lock); ip6_rt_pcpu_alloc() => dst_alloc() => ip6_dst_gc() => write_lock(&table->tb6_lock); /* oops */ Patch 1 and 2 are some prep works. Patch 3 is the fix. Original report: https://bugzilla.kernel.org/show_bug.cgi?id=102291 ==================== Signed-off-by: David S. Miller <[email protected]>
2015-08-17ipv6: Fix a potential deadlock when creating pcpu rtMartin KaFai Lau2-11/+35
rt6_make_pcpu_route() is called under read_lock(&table->tb6_lock). rt6_make_pcpu_route() calls ip6_rt_pcpu_alloc(rt) which then calls dst_alloc(). dst_alloc() _may_ call ip6_dst_gc() which takes the write_lock(&tabl->tb6_lock). A visualized version: read_lock(&table->tb6_lock); rt6_make_pcpu_route(); => ip6_rt_pcpu_alloc(); => dst_alloc(); => ip6_dst_gc(); => write_lock(&table->tb6_lock); /* oops */ The fix is to do a read_unlock first before calling ip6_rt_pcpu_alloc(). A reported stack: [141625.537638] INFO: rcu_sched self-detected stall on CPU { 27} (t=60000 jiffies g=4159086 c=4159085 q=2139) [141625.547469] Task dump for CPU 27: [141625.550881] mtr R running task 0 22121 22081 0x00000008 [141625.558069] 0000000000000000 ffff88103f363d98 ffffffff8106e488 000000000000001b [141625.565641] ffffffff81684900 ffff88103f363db8 ffffffff810702b0 0000000008000000 [141625.573220] ffffffff81684900 ffff88103f363de8 ffffffff8108df9f ffff88103f375a00 [141625.580803] Call Trace: [141625.583345] <IRQ> [<ffffffff8106e488>] sched_show_task+0xc1/0xc6 [141625.589650] [<ffffffff810702b0>] dump_cpu_task+0x35/0x39 [141625.595144] [<ffffffff8108df9f>] rcu_dump_cpu_stacks+0x6a/0x8c [141625.601320] [<ffffffff81090606>] rcu_check_callbacks+0x1f6/0x5d4 [141625.607669] [<ffffffff810940c8>] update_process_times+0x2a/0x4f [141625.613925] [<ffffffff8109fbee>] tick_sched_handle+0x32/0x3e [141625.619923] [<ffffffff8109fc2f>] tick_sched_timer+0x35/0x5c [141625.625830] [<ffffffff81094a1f>] __hrtimer_run_queues+0x8f/0x18d [141625.632171] [<ffffffff81094c9e>] hrtimer_interrupt+0xa0/0x166 [141625.638258] [<ffffffff8102bf2a>] local_apic_timer_interrupt+0x4e/0x52 [141625.645036] [<ffffffff8102c36f>] smp_apic_timer_interrupt+0x39/0x4a [141625.651643] [<ffffffff8140b9e8>] apic_timer_interrupt+0x68/0x70 [141625.657895] <EOI> [<ffffffff81346ee8>] ? dst_destroy+0x7c/0xb5 [141625.664188] [<ffffffff813d45b5>] ? fib6_flush_trees+0x20/0x20 [141625.670272] [<ffffffff81082b45>] ? queue_write_lock_slowpath+0x60/0x6f [141625.677140] [<ffffffff8140aa33>] _raw_write_lock_bh+0x23/0x25 [141625.683218] [<ffffffff813d4553>] __fib6_clean_all+0x40/0x82 [141625.689124] [<ffffffff813d45b5>] ? fib6_flush_trees+0x20/0x20 [141625.695207] [<ffffffff813d6058>] fib6_clean_all+0xe/0x10 [141625.700854] [<ffffffff813d60d3>] fib6_run_gc+0x79/0xc8 [141625.706329] [<ffffffff813d0510>] ip6_dst_gc+0x85/0xf9 [141625.711718] [<ffffffff81346d68>] dst_alloc+0x55/0x159 [141625.717105] [<ffffffff813d09b5>] __ip6_dst_alloc.isra.32+0x19/0x63 [141625.723620] [<ffffffff813d1830>] ip6_pol_route+0x36a/0x3e8 [141625.729441] [<ffffffff813d18d6>] ip6_pol_route_output+0x11/0x13 [141625.735700] [<ffffffff813f02c8>] fib6_rule_action+0xa7/0x1bf [141625.741698] [<ffffffff813d18c5>] ? ip6_pol_route_input+0x17/0x17 [141625.748043] [<ffffffff81357c48>] fib_rules_lookup+0xb5/0x12a [141625.754050] [<ffffffff81141628>] ? poll_select_copy_remaining+0xf9/0xf9 [141625.761002] [<ffffffff813f0535>] fib6_rule_lookup+0x37/0x5c [141625.766914] [<ffffffff813d18c5>] ? ip6_pol_route_input+0x17/0x17 [141625.773260] [<ffffffff813d008c>] ip6_route_output+0x7a/0x82 [141625.779177] [<ffffffff813c44c8>] ip6_dst_lookup_tail+0x53/0x112 [141625.785437] [<ffffffff813c45c3>] ip6_dst_lookup_flow+0x2a/0x6b [141625.791604] [<ffffffff813ddaab>] rawv6_sendmsg+0x407/0x9b6 [141625.797423] [<ffffffff813d7914>] ? do_ipv6_setsockopt.isra.8+0xd87/0xde2 [141625.804464] [<ffffffff8139d4b4>] inet_sendmsg+0x57/0x8e [141625.810028] [<ffffffff81329ba3>] sock_sendmsg+0x2e/0x3c [141625.815588] [<ffffffff8132be57>] SyS_sendto+0xfe/0x143 [141625.821063] [<ffffffff813dd551>] ? rawv6_setsockopt+0x5e/0x67 [141625.827146] [<ffffffff8132c9f8>] ? sock_common_setsockopt+0xf/0x11 [141625.833660] [<ffffffff8132c08c>] ? SyS_setsockopt+0x81/0xa2 [141625.839565] [<ffffffff8140ac17>] entry_SYSCALL_64_fastpath+0x12/0x6a Fixes: d52d3997f843 ("pv6: Create percpu rt6_info") Signed-off-by: Martin KaFai Lau <[email protected]> CC: Hannes Frederic Sowa <[email protected]> Reported-by: Steinar H. Gunderson <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-08-17ipv6: Add rt6_make_pcpu_route()Martin KaFai Lau1-4/+16
It is a prep work for fixing a potential deadlock when creating a pcpu rt. The current rt6_get_pcpu_route() will also create a pcpu rt if one does not exist. This patch moves the pcpu rt creation logic into another function, rt6_make_pcpu_route(). Signed-off-by: Martin KaFai Lau <[email protected]> CC: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-08-17ipv6: Remove un-used argument from ip6_dst_alloc()Martin KaFai Lau1-12/+9
After 4b32b5ad31a6 ("ipv6: Stop rt6_info from using inet_peer's metrics"), ip6_dst_alloc() does not need the 'table' argument. This patch cleans it up. Signed-off-by: Martin KaFai Lau <[email protected]> CC: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-08-17net: phy: workaround for buggy cable detection by LAN8700 after cable pluggingIgor Plyatov1-12/+19
* Due to HW bug, LAN8700 sometimes does not detect presence of energy in the Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN bit is set, the ENERGYON bit does not asserted sometimes). This is a common bug of LAN87xx family of PHY chips. * The lan87xx_read_status() was improved to acquire ENERGYON bit. Its previous algorythm still not reliable on 100 % and sometimes skip cable plugging. Signed-off-by: Igor Plyatov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-08-17Merge tag 'mac80211-for-davem-2015-08-14' of ↵David S. Miller1-5/+6
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== We have a single bugfix for an invalid memory read. ==================== Signed-off-by: David S. Miller <[email protected]>
2015-08-17drm/amdgpu: wait on page directory changes. v2Bas Nieuwenhuizen3-0/+11
Pagetables can be moved and therefore the page directory update can be necessary for the current cs even if none of the the bo's are moved. In that scenario there is no fence between the sdma0 and gfx ring, so we add one. v2 (chk): rebased Signed-off-by: Bas Nieuwenhuizen <[email protected]> Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-08-17drm/amdgpu: Select BACKLIGHT_LCD_SUPPORTThierry Reding1-0/+1
Explicitly select BACKLIGHT_LCD_SUPPORT to satisfy the direct dependency of BACKLIGHT_CLASS_DEVICE. Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-08-17drm/radeon: Select BACKLIGHT_LCD_SUPPORTThierry Reding1-0/+1
Explicitly select BACKLIGHT_LCD_SUPPORT to satisfy the direct dependency of BACKLIGHT_CLASS_DEVICE. Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-08-17drm/amdgpu: cleanup sheduler rq handling v2Christian König3-76/+54
Rework run queue implementation, especially remove the odd list handling. v2: cleanup the code only, no algorithem change. Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]>
2015-08-17drm/amdgpu: move prepare work out of scheduler to cs_ioctlChunming Zhou1-13/+8
Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Christian K?nig <[email protected]>
2015-08-17drm/amdgpu: fix unnecessary wake upChunming Zhou2-4/+7
decrease CPU extra overhead. Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Jammy Zhou <[email protected]> Reviewed-by: Christian K?nig <[email protected]>
2015-08-17drm/amdgpu: fix duplicated mapping invoke bugmonk.liu1-0/+1
fix the bug that there is duplicated bo_update_mapping issued Signed-off-by: monk.liu <[email protected]> Reviewed-by: Chunming Zhou <[email protected]> Reviewed-by: Christian König <[email protected]>
2015-08-17drm/amdgpu: drop bo_list_clone when no schedulermonk.liu1-9/+13
bo_list_clone() will take a lot of time when bo_list hold too much elements, like above 7000 Signed-off-by: Monk.Liu <[email protected]> Reviewed-by: Chunming Zhou <[email protected]> Reviewed-by: Jammy Zhou <[email protected]>
2015-08-17drm/amdgpu: disable GPU reset by defaultAlex Deucher1-2/+2
It's not validated yet and causes more harm than good. Avoids spurious resets. Reviewed-by: Leo Liu <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-08-17drm/amdgpu: fix type mismatch errormonk.liu1-2/+3
remaining timeout returned by amdgpu_fence_wait_any can be larger than max int value, thus the truncated 32 bit value in r ends up being negative while its original long value is positive. Signed-off-by: monk.liu <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Christian König <[email protected]> Reviewed-by: Jammy Zhou <[email protected]>
2015-08-17drm/amdgpu: add reference for **fenceChunming Zhou11-3/+15
fix fence is released when pass to **fence sometimes. add reference for it. Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Christian K?nig <[email protected]>
2015-08-17drm/amdgpu: fix waiting for all fences before flippingChristian König2-29/+56
Otherwise we might see corruption. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-08-17drm/amdgpu: fix UVD return code checkingChristian König1-5/+5
Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Tested-and-Reviewed-by: Leo Liu <[email protected]>
2015-08-17drm/amdgpu: remove scheduler fence list v2Christian König3-21/+1
Unused and missing proper locking. v2: add locking comment to commit message. Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]> (v1)
2015-08-17drm/amdgpu: remove amd_sched_wait_emit v2Christian König3-73/+0
Not used any more. v2: remove amd_sched_emit as well. Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]>
2015-08-17drm/amdgpu: remove unecessary scheduler fence callbacksChristian König1-24/+7
Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]>
2015-08-17drm/amdgpu: fix scheduler fence implementationChristian König1-1/+1
Signed-off-by: Christian König <[email protected]> Reviewed-by: Chunming Zhou <[email protected]>
2015-08-17drm/amdgpu: don't grab dev->struct_mutex in pm functionsDaniel Vetter1-2/+0
Similar to radeon, except that amdgpu doesn't even use struct_mutex to protect anything like the shared z buffer (sane gpu architecture, yay!). And the code already grabs the globa adev->ring_lock, so this code can't race with itself. Which makes struct_mutex completely redundnant. Remove it. Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-08-17drm/amdgpu: Don't take dev->struct_mutex in bo_force_deleteDaniel Vetter1-3/+1
It really doesn't protect anything which doesn't have other locks already. Also this is run from driver unload code so not much need for locks anyway. Same changes as for radeon really. Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-08-17drm/radeon: Don't take dev->struct_mutex in pm functionsDaniel Vetter1-5/+0
We already grab 2 device-global locks (write-sema rdev->pm.mclk_lock and rdev->ring_lock), adding another global mutex won't serialize this code more. And since there's really nothing interesting that gets protected in radeon by dev->struct mutex (we only have the global z buffer owners and it's still serializing gem bo destruction in the drm core - which is irrelevant since radeon uses ttm anyway internally) this doesn't add protection. Remove it. Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-08-17drm/radeon: Don't take dev->struct_mutex in bo_force_deleteDaniel Vetter1-3/+1
It really doesn't protect anything which doesn't have other locks already. Also this is run from driver unload code so not much need for locks anyway. Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-08-17drm/amdgpu: remove VI hw bug workaround v3Christian König2-13/+1
The workaround simply doesn't work because VM mappings are controlled by userspace not the kernel. Additional to that this is just a performance problem which happens if you have holes in your VM mapping. v2: adjust virtual addr alignment as well. v3: fix trivial warning Signed-off-by: Christian König <[email protected]> Reviewed-by: Monk Liu <[email protected]> (v1) Reviewed-by: Jammy Zhou <[email protected]> (v2)
2015-08-17drm/amdgpu: cleanup amdgpu_fence_ring_wait_seqChristian König1-69/+15
Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-08-17drm/amdgpu: remove duplicate amdgpu_fence_process implementationChristian König1-58/+1
Looks like that somehow got missed while during porting the radeon changes. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-08-17drm/amdgpu: remove amdgpu_fence_waitChristian König6-30/+7
It was just a wrapper for fence_wait anyway. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-08-17drm/amdgpu: use the reservation obj wait for the UVD msgChristian König1-8/+5
Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.