linux/arch/arc, branch v4.9

ARC: mm: PAE40: Fix crash at munmap

2016-11-29T17:12:08Z

commit 1c3c90930392 broke PAE40. Macro pfn_pte(pfn, prot) creates paddr from pfn, but the page shift was getting truncated to 32 bits since we lost the proper cast to 64 bits (for PAE400 Instead of reverting that commit, use a better helper which is 32/64 bits safe just like ARM implementation. Fixes: 1c3c90930392 ("ARC: mm: fix build breakage with STRICT_MM_TYPECHECKS") Cc: #4.4+ Signed-off-by: Yuriy Kolerov [vgupta: massaged changelog] Signed-off-by: Vineet Gupta

ARC: mm: IOC: Don't enable IOC by default

2016-11-28T17:18:36Z

Signed-off-by: Vineet Gupta

ARC: Don't use "+l" inline asm constraint

2016-11-28T17:17:32Z

Apparenty this is coming in the way of gcc fix which inhibits the usage of LP_COUNT as a gpr. Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta

Merge tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc

2016-11-12T00:51:50Z

Pull ARC fixes from Vineet Gupta: - mmap handler for dma ops as generic handler no longer works for us [Alexey] - Fixes for EZChip platform [Noam] - Fix RTC clocksource driver build issue - ARC IRQ handling fixes [Yuriy] - Revert a recent makefile change which doesn't go well with oldish tools out in the wild * tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core ARC: IRQ: Do not use hwirq as virq and vice versa ARC: [plat-eznps] set default baud for early console ARC: [plat-eznps] remove IPI clear from SMP operations Revert "ARC: build: retire old toggles" ARC: timer: rtc: implement read loop in "C" vs. inline asm ARC: change return value of userspace cmpxchg assist syscall arc: Implement arch-specific dma_map_ops.mmap ARC: [SMP] avoid overriding present cpumask ARC: Enable PERF_EVENTS in nSIM driven platforms

Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"

2016-11-11T16:45:08Z

Traditionally, we have always had warnings about uninitialized variables enabled, as this is part of -Wall, and generally a good idea [1], but it also always produced false positives, mainly because this is a variation of the halting problem and provably impossible to get right in all cases [2]. Various people have identified cases that are particularly bad for false positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized when building with -Os"), I turned off the warning for any build that was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number of false positive warnings in the default build but unfortunately had the side effect of turning the warning off completely in 'allmodconfig' builds, which in turn led to a lot of warnings (both actual bugs, and remaining false positives) to go in unnoticed. With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE definition") enabled the warning again for allmodconfig builds in v4.7 and in v4.8-rc1, I had finally managed to address all warnings I get in an ARM allmodconfig build and most other maybe-uninitialized warnings for ARM randconfig builds. However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally") was merged at the same time and disabled it completely for all configurations, because of false-positive warnings on x86 that I had not addressed until then. This caused a lot of actual bugs to get merged into mainline, and I sent several dozen patches for these during the v4.9 development cycle. Most of these are actual bugs, some are for correct code that is safe because it is only called under external constraints that make it impossible to run into the case that gcc sees, and in a few cases gcc is just stupid and finds something that can obviously never happen. I have now done a few thousand randconfig builds on x86 and collected all patches that I needed to address every single warning I got (I can provide the combined patch for the other warnings if anyone is interested), so I hope we can get the warning back and let people catch the actual bugs earlier. This reverts the change to disable the warning completely and for now brings it back at the "make W=1" level, so we can get it merged into mainline without introducing false positives. A follow-up patch enables it on all levels unless some configuration option turns it off because of false-positives. Link: https://rusty.ozlabs.org/?p=232 [1] Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2] Signed-off-by: Arnd Bergmann Signed-off-by: Linus Torvalds

ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core

2016-11-08T20:22:52Z

ARC linux uses 2 distribution modes for common interrupts: round robin mode (IDU_M_DISTRI_RR) and a simple destination mode (IDU_M_DISTRI_DEST). The first one is used when more than 1 cores may handle a common interrupt and the second one is used when only 1 core may handle a common interrupt. However idu_irq_set_affinity() always sets IDU_M_DISTRI_RR for all affinity values. But there is no sense in setting of such mode if only 1 core must handle a common interrupt. Signed-off-by: Yuriy Kolerov Signed-off-by: Vineet Gupta

ARC: IRQ: Do not use hwirq as virq and vice versa

2016-11-08T20:05:10Z

This came up when reviewing code to address missing IRQ affinity setting in AXS103 platform and/or implementing hierarchical IRQ domains - smp_ipi_irq_setup() callers pass hwirq but in turn calls request_percpu_irq() which expects a linux virq. So invoke irq_find_mapping() to do the conversion (also explicitify this in code by renaming the args appropriately) - idu_of_init()/idu_cascade_isr() were similarly using linux virq where hwirq is expected, so do the conversion using irqd_to_hwirq() helper Signed-off-by: Yuriy Kolerov [vgupta: made changelog a bit concise a bit] Signed-off-by: Vineet Gupta

ARC: [plat-eznps] set default baud for early console

2016-11-08T17:39:37Z

For CONFIG_SERIAL_EARLYCON we need 800MHz for NPS SoC The early console driver uses BASE_BAUD and not using dtb. The default of 50MHz is NOT good for NPS SoC. Signed-off-by: Noam Camus Signed-off-by: Vineet Gupta

ARC: [plat-eznps] remove IPI clear from SMP operations

2016-11-08T17:25:18Z

Today we register to plat_smp_ops.clear() method which actually is acking the IPI. However this is already taking care by our irqchip driver specifically by the irq_chip.irq_eoi() method. This is perfect timing where it should be done and no special handling is needed at plat_smp_ops.clear(). Signed-off-by: Noam Camus Signed-off-by: Vineet Gupta

Revert "ARC: build: retire old toggles"

2016-11-08T17:23:52Z

This has caused a bunch of build failures at a few sites, with GNU 2015.12 and older as the assembler seems to need -mlock to be able to grok llock/scond instructions for ARC700 builds. different places since the older tools still seem to release of tools which most people are using seem to trip with the -mlock flag not being passed. This reverts commit c3005475889c7c730638f95d13be3360f0b33e98.